I never understood double entry bookkeeping and that's where the author immediately loses me again:
Early on after 4th diagram, author includes sentence : "Because every transaction appears twice, once positive and once negative"
There is something so obvious about this to accounting folks that they always make the massive jump without any explanation. The previous diagram absolutely does not have positive and negative for each transaction! In fact, there is 5000 going into banking account and 500+5 coming out of it. Nothing in 4th diagram is obviously the negative of that 5k transaction, to me.
Similarly next sentence is "obviously" false:
"If you partition the set of nodes into any two disjoint sets, and add up all of the balances in each set, then the sum for the one set is always the negative sum of the other set" -- the sum of the left two balances is minus five, and the sum of right three balances is 505.
And just like that, I'm completely lost and booted out of yet another accounting lesson without passing the introduction :-(
(fwiw, my experience of reading accounting is broadly the same as reading Plato: "it is obviously true that..." What, no, stop, that's not obvious at all, you gotta do better than that! :-)
It only makes sense in the context of a company. Yes you can shoehorn it into a personal context and/or treating it like some sort of database like hn's accounting posts love to do but that's not what the real accounting world looks like at all.
An accountant armed with a low/no code solution isn't going to write great code. That I think is obvious to every hn reader. But somehow hn gang think they'll reinvent a system that has been in place for 100s of years because it's backed by a different DB tech that's better suited to double entry.
I know a decent bit of both worlds so that disconnect in perceptions always amuses me.
[As a side note I don't think the average tech guy gains much from learning "accounting". Even that is a complete misunderstanding of what it is. Unless you're dealing with cap tables and corporate structuring you're better off doubling down on personal finances & taxes and risk management...not double entry]
edit: yes am accountant, yes can code..rust and python mostly, not amazing at either
While I completely agree with you and have had the same experience, I'll try to phrase it in a way that might "click" for you:
1. An account is an abstract bucket that aggregates things of the same type. For example, the "Sales" account contains all the income from sales and the "Furniture" account represents the value of all the furniture. The "bank account" represents your dollars stored in the bank.
2. A transaction is an event where something of value is moved from one account to another. For example, when you buy furniture, money goes out of your bank account and is "transformed" into furniture. When you get paid, dollars go from an "Income" account to a "Bank account".
3. The goal of double-entry bookkeeping is to show both the source and destination of every transaction. For example, if you have furniture worth $375 in your possession, where did that value come from? Right, a transaction "debited" the furniture account by $375 and also "credited" the "bank account" with the same amount.
I suspect the original article only makes sense if you already have a solid understanding of both graphs and double-entry bookkeeping though...
> Early on after 4th diagram, author includes sentence : "Because every transaction appears twice, once positive and once negative"
This isn't quite right, but it is a simplification that works here.
> The previous diagram absolutely does not have positive and negative for each transaction! In fact, there is 5000 going into banking account and 500+5 coming out of it.
Yes, those are two separate transactions. Each arrow is a transaction, and each of the accounts that it connects reflects the transaction (one as a positive, the other as a negative.)
> Nothing in 4th diagram is obviously the negative of that 5k transaction, to me.
The arrow with the $5000 has both the positive and the negative.
Each arrow (each edge of the directed graph) represents a "negative" for the account at the tail and a "positive" for the account at the head.
Money must flow from a source to potentially multiple destination. Because of that previous fact, you must have at least two postings per transaction (the double in double entry). If you manage to move money correctly without any errors, those postings in that transaction will add up to zero, making it trivial to verify you've done everything correctly without any errors.
Every time it comes up in my life, I search for an easy answer, yet I haven't found one yet. It reduces errors, makes it easy to track things and other reasons... all don't make sense to me if there is no physical bookkeeping involved. I am nearly convinced the reason is simply: It has been done like that for centuries. That's it.
Accounting generally wouldn't depict it this way, and it's quite confusing with the bubble diagram. I always found it easier when looking at things called "t accounts" [1]
Anyway, for the example you mention, it's supposed to mean that it takes 5k from the bubble on the left (founder) and gives to next bubble (bank)
Then each line again takes from left and gives to the new bubble on right. So each line is a transaction that balances out by adjusting both sides.
Thanks, I appreciate your answer, though sadly it does not move the needle much for me.
* the article still loses me because it defines transactions one way (the edges) and then seems to make this big switch that each edge/transaction is really two transactions suddenly (one on each side of the edge) .
Similarly the explanation In Wikipedia is completely contrary to my mental framework: "tenant who writes a rent cheque to a landlord would enter a credit for the bank account on which the cheque is drawn, and a debit in a rent expense account. Similarly, the landlord would enter a credit in the rent income account associated with the tenant and a debit for the bank account where the cheque is deposited."
I cannot even begin to parse that, and I'm honestly reasonably bright :-). Paying my landlord is "obviously" a transaction from my banking account (negative) into their banking account (positive). How it becomes four transaction is, as ever, the magic bit glossed over. That landlord is entering "debit for the bank account where the cheque is deposited" just feels like someone is yanking my chain.
Anyvoo! Like with French language, I'll try again one day :-). Merci!
Double entry book keeping is just recording the "edge" in two places, once based on the source node, and once based on the target node. So you have a nice list of all edges coming from each node and a nice list of all edges going to each node. This was important before computers, since the process of looking up all edges going to/from a node would take real time and effort.
For your example of the landlord and the tenant, think, what if the landlord wanted a list of all payments that went into a specific bank account, what if the tenant wanted a list of all rent payments, etc. It's basically a database index to speed up those queries, but for a written database that is updates by hand. The fact that there is redundancy is just a bonus because you can now notice if the two places a piece of information are written down don't match.
> The previous diagram absolutely does not have positive and negative for each transaction!
But it does. The $500 transaction for furniture is an edge from the bank to the furniture asset account. This edge is outgoing from the bank account (-$500) and incoming to the furniture asset account (+$500). That’s it, that’s double entry bookkeeping. Each edge represents both entries.
Thank you for writing and sharing that. It's one of the simplest and sane explanations I've seen. How did discussions go with accountants separating the debits/credits into being a presentation issue?
It's a good comment but I think to make something intuitive you really need to understand why something exists and I think for most people there just isn't in fact a good reason.
If you know it, it's easy to use, so why not? But if you don't, whatever method you come up with to track account balances and revenues vs. expenses is going to be useful enough. For individuals not accounting for receivables, debts, depreciation properly isn't likely to make a big difference.
That was my thinking reading this. You need the basics but I would assume the main motivation is to look at a company's financial statement and at least recognize a lot of the language and the significance of the relationships. Of course there are going to be a lot of subtleties but the statement shouldn't be seen as being written in an ancient language.
Double entry account is, in fact, what gave “transactional” databases their name: They were meant for financial transactions!
Nowadays TigerBeetle is a custom built financial database just for double entry accounting. The implementation is fascinating.
This is so nicely presented it’s tempting me to have Claude whip up an implementation.
Just need aome form of graphic persistence then ways of summing across partitions of nodes to generate reports. And some convenience methods for adding transactions.
Final step would be to slap a CLI or UI on top of everything.
I never understood double entry bookkeeping and that's where the author immediately loses me again:
Early on after 4th diagram, author includes sentence : "Because every transaction appears twice, once positive and once negative"
There is something so obvious about this to accounting folks that they always make the massive jump without any explanation. The previous diagram absolutely does not have positive and negative for each transaction! In fact, there is 5000 going into banking account and 500+5 coming out of it. Nothing in 4th diagram is obviously the negative of that 5k transaction, to me.
Similarly next sentence is "obviously" false: "If you partition the set of nodes into any two disjoint sets, and add up all of the balances in each set, then the sum for the one set is always the negative sum of the other set" -- the sum of the left two balances is minus five, and the sum of right three balances is 505.
And just like that, I'm completely lost and booted out of yet another accounting lesson without passing the introduction :-(
(fwiw, my experience of reading accounting is broadly the same as reading Plato: "it is obviously true that..." What, no, stop, that's not obvious at all, you gotta do better than that! :-)
>I never understood double entry bookkeeping
It only makes sense in the context of a company. Yes you can shoehorn it into a personal context and/or treating it like some sort of database like hn's accounting posts love to do but that's not what the real accounting world looks like at all.
An accountant armed with a low/no code solution isn't going to write great code. That I think is obvious to every hn reader. But somehow hn gang think they'll reinvent a system that has been in place for 100s of years because it's backed by a different DB tech that's better suited to double entry.
I know a decent bit of both worlds so that disconnect in perceptions always amuses me.
[As a side note I don't think the average tech guy gains much from learning "accounting". Even that is a complete misunderstanding of what it is. Unless you're dealing with cap tables and corporate structuring you're better off doubling down on personal finances & taxes and risk management...not double entry]
edit: yes am accountant, yes can code..rust and python mostly, not amazing at either
> I never understood double entry bookkeeping
While I completely agree with you and have had the same experience, I'll try to phrase it in a way that might "click" for you:
1. An account is an abstract bucket that aggregates things of the same type. For example, the "Sales" account contains all the income from sales and the "Furniture" account represents the value of all the furniture. The "bank account" represents your dollars stored in the bank.
2. A transaction is an event where something of value is moved from one account to another. For example, when you buy furniture, money goes out of your bank account and is "transformed" into furniture. When you get paid, dollars go from an "Income" account to a "Bank account".
3. The goal of double-entry bookkeeping is to show both the source and destination of every transaction. For example, if you have furniture worth $375 in your possession, where did that value come from? Right, a transaction "debited" the furniture account by $375 and also "credited" the "bank account" with the same amount.
I suspect the original article only makes sense if you already have a solid understanding of both graphs and double-entry bookkeeping though...
> Early on after 4th diagram, author includes sentence : "Because every transaction appears twice, once positive and once negative"
This isn't quite right, but it is a simplification that works here.
> The previous diagram absolutely does not have positive and negative for each transaction! In fact, there is 5000 going into banking account and 500+5 coming out of it.
Yes, those are two separate transactions. Each arrow is a transaction, and each of the accounts that it connects reflects the transaction (one as a positive, the other as a negative.)
> Nothing in 4th diagram is obviously the negative of that 5k transaction, to me.
The arrow with the $5000 has both the positive and the negative.
Each arrow (each edge of the directed graph) represents a "negative" for the account at the tail and a "positive" for the account at the head.
Money must flow from a source to potentially multiple destination. Because of that previous fact, you must have at least two postings per transaction (the double in double entry). If you manage to move money correctly without any errors, those postings in that transaction will add up to zero, making it trivial to verify you've done everything correctly without any errors.
can't two errors cancel each other out and you still wind up at zero?
Every time it comes up in my life, I search for an easy answer, yet I haven't found one yet. It reduces errors, makes it easy to track things and other reasons... all don't make sense to me if there is no physical bookkeeping involved. I am nearly convinced the reason is simply: It has been done like that for centuries. That's it.
Accounting generally wouldn't depict it this way, and it's quite confusing with the bubble diagram. I always found it easier when looking at things called "t accounts" [1]
Anyway, for the example you mention, it's supposed to mean that it takes 5k from the bubble on the left (founder) and gives to next bubble (bank)
Then each line again takes from left and gives to the new bubble on right. So each line is a transaction that balances out by adjusting both sides.
[1] https://en.wikipedia.org/wiki/Debits_and_credits
Thanks, I appreciate your answer, though sadly it does not move the needle much for me.
* the article still loses me because it defines transactions one way (the edges) and then seems to make this big switch that each edge/transaction is really two transactions suddenly (one on each side of the edge) .
Similarly the explanation In Wikipedia is completely contrary to my mental framework: "tenant who writes a rent cheque to a landlord would enter a credit for the bank account on which the cheque is drawn, and a debit in a rent expense account. Similarly, the landlord would enter a credit in the rent income account associated with the tenant and a debit for the bank account where the cheque is deposited."
I cannot even begin to parse that, and I'm honestly reasonably bright :-). Paying my landlord is "obviously" a transaction from my banking account (negative) into their banking account (positive). How it becomes four transaction is, as ever, the magic bit glossed over. That landlord is entering "debit for the bank account where the cheque is deposited" just feels like someone is yanking my chain.
Anyvoo! Like with French language, I'll try again one day :-). Merci!
Double entry book keeping is just recording the "edge" in two places, once based on the source node, and once based on the target node. So you have a nice list of all edges coming from each node and a nice list of all edges going to each node. This was important before computers, since the process of looking up all edges going to/from a node would take real time and effort.
For your example of the landlord and the tenant, think, what if the landlord wanted a list of all payments that went into a specific bank account, what if the tenant wanted a list of all rent payments, etc. It's basically a database index to speed up those queries, but for a written database that is updates by hand. The fact that there is redundancy is just a bonus because you can now notice if the two places a piece of information are written down don't match.
That’s a great way of explaining why this was historically done.
Fwiw, I think the four in the wikipedia comes from two people using the double entry system simultaneously.
So it's two records in the landlord's own books which u dont necesarily know about, and two records in your books.
> The previous diagram absolutely does not have positive and negative for each transaction!
But it does. The $500 transaction for furniture is an edge from the bank to the furniture asset account. This edge is outgoing from the bank account (-$500) and incoming to the furniture asset account (+$500). That’s it, that’s double entry bookkeeping. Each edge represents both entries.
I wrote this a long time ago. It does tend to upset some people, but it did work as an accurate and testable mental model:
https://django-hordak.readthedocs.io/en/latest/accounting-fo...
Thank you for writing and sharing that. It's one of the simplest and sane explanations I've seen. How did discussions go with accountants separating the debits/credits into being a presentation issue?
Previously:
Accounting for computer scientists (2011) - https://news.ycombinator.com/item?id=37940973 - Oct 2023 (50 comments)
Accounting for Computer Scientists - https://news.ycombinator.com/item?id=15446202 - Oct 2017 (1 comment)
Accounting for Computer Scientists - https://news.ycombinator.com/item?id=2298471 - March 2011 (75 comments)
The last time this was posted on HN (October 2023), I posted this comment which I think makes it easy to understand the fundamentals of accounting:
https://news.ycombinator.com/item?id=37951781
It's a good comment but I think to make something intuitive you really need to understand why something exists and I think for most people there just isn't in fact a good reason.
If you know it, it's easy to use, so why not? But if you don't, whatever method you come up with to track account balances and revenues vs. expenses is going to be useful enough. For individuals not accounting for receivables, debts, depreciation properly isn't likely to make a big difference.
This is a great point.
I take it for granted that people want to be able to read a balance sheet and an income statement.
But most people don't.
That was my thinking reading this. You need the basics but I would assume the main motivation is to look at a company's financial statement and at least recognize a lot of the language and the significance of the relationships. Of course there are going to be a lot of subtleties but the statement shouldn't be seen as being written in an ancient language.
Double entry account is, in fact, what gave “transactional” databases their name: They were meant for financial transactions! Nowadays TigerBeetle is a custom built financial database just for double entry accounting. The implementation is fascinating.
Those graphs look cool, but I'd prefer a growing log of entries, so you can see what happens over time and more easily roll back or fix things.
That's actually what's missing in this presentation: how do you deal with time?
This is so nicely presented it’s tempting me to have Claude whip up an implementation.
Just need aome form of graphic persistence then ways of summing across partitions of nodes to generate reports. And some convenience methods for adding transactions.
Final step would be to slap a CLI or UI on top of everything.
As someone who failed an accounting class I will definitely read this.