Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Double Entry Accounting for Developers

django-hordak.readthedocs.io

Post reply on HN
Print view View original

121–130 of 237 posts

Re: Double Entry Accounting for Developers

#121

Post by braho »

dragonsh wrote: post #57

Please take a look at document [1] by author of beancount regarding how to do double entry accounting, including introduction to single entry bookkeeping. So far I find this is the best resource for developers to learn about accounting along with illustrations. Debit and Credits are introduced later once the basics are explained in details grounded in accounting principles in play for thousands of years. [1] https://…

Not only is Martin Blais' explanation very helpful, his software, Beancount, is also very suitable for any personal finance projects, especially if you have a background as Developer.

Personally, I combine beancount with fava and find it much better than e.g. GnuCash.

Re: Double Entry Accounting for Developers

#122

Post by mcjiggerlog »

CobrastanJorji wrote: post #42

Way back when I first tried switching to using Open Source alternatives to my previous apps, I wanted a Quicken alternative and tried GnuCash. Opening the help for the first time, I found it hilarious and ever so "open source software" of them that the help document opened with a whole chapter on how double book accounting worked, because of course you'd need to know that if you wanted to use GnuCash well. Anyway, wh…

"GnuCash" was the first thing I looked for when I opened this thread. This application is an absolute godsend and I'm not sure why it's not more popular with developers. It takes some getting used to / setting up, but once you understand how it works it will revolutionize the control you have over your finances.

Re: Double Entry Accounting for Developers

#123

Post by robertlagrant »

CobrastanJorji wrote: post #42

Way back when I first tried switching to using Open Source alternatives to my previous apps, I wanted a Quicken alternative and tried GnuCash. Opening the help for the first time, I found it hilarious and ever so "open source software" of them that the help document opened with a whole chapter on how double book accounting worked, because of course you'd need to know that if you wanted to use GnuCash well. Anyway, wh…

That sounds less hilarious, and more extremely useful free info and software.

Re: Double Entry Accounting for Developers

#124

Post by hluska »

neffy wrote: post #38
goat_whisperer wrote: post #4

From the site: "I found the core explanation of double entry accounting to be confusing. After some time I distilled it down to the following: "Debits decrease the value of an account. Always. [1] Credits increase the value of an account. Always. [1] "[1] (1, 2) This is absolutely not what accountancy teaches. You’ll quickly see that there is a lot of wrangling over what account types get increased/decreased with a d…

The operation performed by debit/credit depends on the classification of the accounts. Accounts are listed traditionally with Assets on the left, and Liabilities and Equity on the right. A debit to a Liability account is a minus, and a credit is a plus, but it's the other way around on the asset side, where a debit is a plus, and a credit is a minus. (This kind of thing happens when English mugs other languages - Ita…

I prefer to think of double entry accounting (with reasonable controls) as the first reasonable implementation of a blockchain. At its core, a double entry accounting system is a giant ledger where each transaction is linked to the last one ‘forever’ (assuming proper controls).

It’s likely the only reasonable implementation of a blockchain but we won’t know that for sure until cryptocurrency matures enough to develop reasonable controls. I’m not holding my breathe because then it’s just an accounting system with reasonable controls built in and there are already more than enough of those built with databases.

Re: Double Entry Accounting for Developers

#125

Post by feanaro »

juped wrote: post #114
juped wrote: post #78

Earlier quoted context omitted.

This comment expressing confusion on this valiantly misguided OP seems like a good place to throw my standard explanation out into the aether to do neither readers nor myself any good. A transaction has two polarities, because it represents a flow of value. The credit side is the source, the debit side is the sink/destination/whatever. Let's temporarily pretend that every transaction hits exactly two accounts for the…

BTW, why is "running the balance" a discrete operation to accountants? Because accountants' source of truth is the transaction log, which they call a "ledger". Ledger entries look (conceptually, not literally) like this: |tx id| account | debit|credit| | 123|Cash (bank 1) | 25| 0| | 123|Cash (bank 2) | 25| 0| | 123|Accounts Receivable| 0| 50| with the constraint that a transaction is not valid unless the sum of debit…

Well, they are databases. That doesn't imply accountants don't understand accounting. Both can be true.

I think a large factor in the "programmers reinterpreting accounting" phenomenon is the fact that accounting is full of somewhat idiosyncratic terminology and conventions which are somewhat counter to modern mathematical conventions. These conventions should still be upheld in order to be mutually intelligible with the accounting world, but it seems quite unlikely they are the optimum in terms of ergonomics and ease of understanding. If we designed accounting from scratch today, I doubt we would end up with these conventions.

A naive programmer is perhaps in one of the best positions to see these idiosyncrasies and think "This is using the wrong conventions and can be made much simpler by just shifting some signs around!".

Re: Double Entry Accounting for Developers

#126

Post by kgwgk »

juped wrote: post #83
patmcc wrote: post #82

Earlier quoted context omitted.

One minor "error" - depreciation only happens on capital assets, that should be a Pizza Expense.

Yeah, I guess eating pizza usually counts as opex.

But looking down at the balance you may find some of it gets capitalized.

Re: Double Entry Accounting for Developers

#127

Post by captainmuon »

I think I understand the mechanics of double entry bookkeeping, but what I find confusing about it is that it is the redundancy. People emphasize the error detection, but these errors can only exist in the first place because of the requirement to record each transaction twice. Also you get a lot of "fictious" or virtual accounts that don't correspond to concrete piles of cash or bank accounts.

It seems much easier to me to just record the transactions ($100 from bank account to shop on date). Then you can generate balanced account sheets from this automatically.

But you can go further and look at the actual cash flow. This is something you can't easily do with double entry: how much money did I have on day X? How much money will I have approximately on day Y? Will any asset fall below a certain value? And make nice graphs out of everything.

Re: Double Entry Accounting for Developers

#128

Post by neolog »

braho wrote: post #121
dragonsh wrote: post #57

Please take a look at document [1] by author of beancount regarding how to do double entry accounting, including introduction to single entry bookkeeping. So far I find this is the best resource for developers to learn about accounting along with illustrations. Debit and Credits are introduced later once the basics are explained in details grounded in accounting principles in play for thousands of years. [1] https://…

Not only is Martin Blais' explanation very helpful, his software, Beancount, is also very suitable for any personal finance projects, especially if you have a background as Developer. Personally, I combine beancount with fava and find it much better than e.g. GnuCash.

Is beancount the kind of tool that's mostly useful if you put a lot of time into it, like Emacs? Or is it immediately useful with even small investments of time?

Re: Double Entry Accounting for Developers

#129

Post by feanaro »

mumblemumble wrote: post #62
jamesmackennon wrote: post #58

Earlier quoted context omitted.

...but sometimes things aren't inflows or outflows. Depreciation is neither, yet it's (almost) fundamental to accounting.

Depreciation is also neither a credit nor a debit. Doesn't one normally handle depreciation by creating an expense account called "depreciation", and recording the depreciation as a debit in the asset account and a credit in the depreciation account? And couldn't one just as easily word that as, "We track the depreciation by creating an account for it, and recording a flow of money into it from the asset's account?"

Yes, but the other way around: you debit the "Depreciation" expense account (since it is the sink, it increases) and credit the asset account (it is the source, it decreases).

Re: Double Entry Accounting for Developers

#130

Post by fauigerzigerk »

wrycoder wrote: post #103
neffy wrote: post #38

Earlier quoted context omitted.

The operation performed by debit/credit depends on the classification of the accounts. Accounts are listed traditionally with Assets on the left, and Liabilities and Equity on the right. A debit to a Liability account is a minus, and a credit is a plus, but it's the other way around on the asset side, where a debit is a plus, and a credit is a minus. (This kind of thing happens when English mugs other languages - Ita…

I’ve found the best way is to remember the phrase, “Debits come in and credits go out.” Let’s say you have a bank account. Your view of that account is opposite from the bank’s view. You have $100 cash. That’s an asset from your POV, and it carries a debit balance on your books - when you received it, the cash “came in”. You walk into the bank and deposit it. The cash goes out of your books, but an asset (the increas…

>It’s conventional to make assets positive (hey, having lots of assets is good, right?). OP gains nothing but confusion by turning everything upside down.

I agree. However, the problem is that you can either make the vocabulary consistent or you can make the math simple, never both.

Making the math simple means you have to make a decision to always treat debits as positive and credits as negative or the other way around. You just have to be consistent.

Making the vocabulary work means you have to switch signs based on account type. But that makes the math and hence the software complicated and error prone.

Assets being positive makes sense. But debiting an asset account to make it more positive is counter intuitive. And expenses being positive doesn't make much sense either, because having lots of expenses is not so good, is it?

We're just accepting the inconsistent vocabulary as a price for having a simple mathematical model.

Post reply on HN