Hacker News Reader

Comment by mtlynch | Hacker News Reader

+1 to OP's book, which is the best beginner guide I've found for understanding Beancount / plaintext accounting.

I was also confused about double-entry accounting for most of my life until I read the article, "Accounting for Computer Scientists"[0] by Martin Kleppman (author of Designing Data-Intensive Applications). It explains double entry accounting in a surprisingly accessible way by putting it in terms of graph theory. I don't even like graph theory that much or consider myself competent in it, but Kleppman's explanation was extremely effective.

[0] https://martin.kleppmann.com/2011/03/07/accounting-for-compu...

View on HN

"Quicken is a single-entry accounting system, which means that amounts can appear out of or disappear into thin air. In a double-entry accounting system you can't put amounts in an account without taking it out of another account."

This summed it up nicely, from https://github.com/mortisj/quicken2beancount

What did you find hard to understand about double entry accounting? Seems pretty straightforward. Every transaction affects at least two accounts, and the total debits must equal the total credits. I can't imagine how introducing graph theory simplifies it, although I trust there are interesting insights none-the-less.

I think it explains the "why" of double entry accounting. Since it is used to track flows of money, a graph representation is a natural representation (just not the only one and not necessarily the most useful for day to day operations).

That core idea is simple. But the details, such as credit and debit having the opposite meaning to casual bank account accounting, and the use of a variety of accounts makes things not intuitive.

>What did you find hard to understand about double entry accounting?

I didn't understand the point of the two entries.

My prior experience with bookkeeping was that I imported my bank statements into some tool and categorized each transaction. So, if I bought a cookie for $5, I'd mark that transaction as "food," and that felt intuitive to me. I didn't understand why it would become two transactions where one is food and the other is my cash. It just felt like, why split it into two? What does that do for me?

The "ah-ha" moment from Kleppman's post was seeing how it's not just about creating two entries but about defining flows between accounts. The graphs helped because they show how balances increase or decrease as you traverse the nodes.

To be clear, it wasn't like I spent hours banging my head against the wall trying to understand double-entry accounting and failed until Kleppman's post. It was just that I'd encountered the idea a few times, and it never clicked until Klepmman.

Thank you. IMO a couple of good motivating examples (as I said a couple of years ago: https://news.ycombinator.com/item?id=32497843) are:

• Bank accounts and cash. If you're tracking a single number, do you track a cash withdrawal (and then ignore purchases with cash), or do you ignore cash withdrawals (and track cash purchases)? With double-entry accounting, you just track withdrawals as money flowing (Bank account) -> (Cash), and purchases as (Cash) -> (Stuff) or whatever you want to call it; both are equally cleanly represented.

• Bank accounts and credit-card (or other loan) repayments. Similar thing: if you were to use a single number, do you change it when you make a purchase with a credit card (and ignore tracking paying your credit card bill) or do you change it when you pay your credit card bill (and ignore purchases with your card)? With double-entry accounting you just treat them as money flowing (Bank account) -> (Credit card) and (Credit card) -> (Expenses). And your bank account statements and credit card statements will both make sense in isolation, if you have this complete picture.

(Personally I found https://beancount.github.io/docs/the_double_entry_counting_m... even more useful for the basic idea than https://martin.kleppmann.com/2011/03/07/accounting-for-compu... but both are interesting.)

>The "ah-ha" moment from Kleppman's post was seeing how it's not just about creating two entries but about defining flows between accounts. The graphs helped because they show how balances increase or decrease as you traverse the nodes.

Thank you for clarifying. That makes sense. Graph's do more directly depict the transition with edges. Whereas that part is kind of just implicit in double entry accounting.

I was confused about it for a long time, though. I recall the confusion centered around terminology. I'm from Denmark and there we say "aktiver" (actives) must equal "passiver" (passives/liabilities) - which seemed very unintuitive. Why would they be equal - and exactly equal (down to the last cent)? I mean, what if I buy a piece of candy and then eat it? Even if we accept that buying it turns it into an asset, wouldn't eating it cause a reduction in assets and thereby make the two sides diverge? Surely when eaten, something is lost, so again how can they be equal? I saw the 'light' when I started tracking my own finances in a spreadsheet. I started tracking the value of all accounts in a separate sheet, summing them to see how much money I had. Then, I started tracking all expenses to see in detail how much I spent each month. Eventually, it dawned on me to connect these subsheets to check that I hadn't forgotten an expense or typed a wrong number. It worked like this: every month I summed up the accounts and made a note. At the end of the next month, I would update the account values with new balances from the bank, and then verify that the change in balance matched exactly the sum of the spending (plus income). Then I realized: hey, maybe this is what double entry accounting is all about. It is mostly a terminology question; the "assets equal liabilities" phrasing is what trips people up, and the candy mystery is of course explained by just having various entries accounting for this. While I do know graph theory, I don't see the relation to double entry accounting. I can't imagine how introducing graph theory simplifies it, though maybe I don't truly understand it after all ;)

Thanks a lot for the shout out, Michael!

Reply on news.ycombinator.com