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! :-)
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...
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 know a decent bit of both worlds so that disconnect in perceptions always amuses me.
Double-entry bookkeeping was from its inception an error-correction code that could be calculated by hand.
Modern databases contain much more powerful error correction methods in the form of transactional commits, so from a pure technical point, double-entry bookkeeping is no longer needed at all; that's why programmers have a hard time understanding why it's there: for us, when we store a value in the DB, we can trust that it's been recorded correctly and forever as soon as the transaction ends.
The thing is, cultural accounting still relies on the concepts derived from double entry bookkeeping as described in the article; all those assets and debts and equity are still used by the finances people to make sense of the corporate world, so there's no chance that they'll fall out of use anytime, at least 'in the context of a company' as you out it.
Now would it be possible to create a new accounting system from scratch that relied on DB transactions and didn't depend on double entry? Sure it can, in fact crypto coins is exactly what happens when computer engineers design a money system unrestricted from tradition. But in practical terms it still needs to relate to the traditional categories in order to be understood and used.
> from a pure technical point, double-entry bookkeeping is no longer needed at all
Just because databases are transactional doesn't mean the entire system is. Double-entry accounting still helps catch errors.
A concrete example, since people like to think databases dealing with money are especially transactional, when they're not ...
I used to work at a small regional bank. In the course of some network maintenance, I accidentally disrupted the connectivity to an ATM while a customer was doing a transaction.
The next day, our accounting folks caught a problem with reconciliation, and the customer called to follow up as well. My interruption caused a deposit to proceed far enough to take their checks and money, but failed to credit the customer's account.
It's very hard to orchestrate transactions perfectly across multiple organizations and systems. You can't hand-wave this away by pointing at db consistency guarantees. Traditional accounting techniques will catch these errors.
I'm not sure that ATMs even have the ability to communicate certain failure classes back to the acquiring bank. eg, a cash dispenser malfunction is common enough to be mentioned by VISAs network rules explicitly, but as far as I know will almost always require manual reconciliation between the ATM operator and the network.
The crypto model of single entries with "from" and "to" field works well for transactions. For example you move $100 from checking to savings account, something like the following will capture it perfectly.
But the main reason why we need double entry accounting is that not all accounting entries are transfers. For example, is we are logging a sales, cash increases by $100, and revenue increases by $100. What's the "from" here? Revenue isn't an account where account is taken from, it is the "source" of the cash increase. So something like the following doesn't capture the true semantics of the transaction.
- Depreciation: Nothing moves. You're recognizing that a truck is worth less than before and that this consumed value is an expense.
- Accruals: Recording revenue you earned but haven't been paid for yet. No cash moved anywhere.
The limitation of ledgers with "from" and "to" is that it assumes conservation of value (something moves from A to B). But accounting tracks value creation, destruction, and transformation, not just movement. Double-entry handles these without forcing a transfer metaphor onto non-transfer events.
But you don't need double entry to register increases or decreases of value; you could as well just use single-entry accounting and add or remove money from a single account, using transactions that are not transfers.
In the past this was problematic because you missed error-checking by redundance, but nowadays you can trust a computer to do all the checking with database transactions (which are more complex checks than double entry, though they don't need to be exposed into the business domain). Any tracking that you'd want to do with double-entry accounting could be done by creating single-entry accounts with similar meaning, and registering each transaction once, if you know that you can trust the transaction to be recorded correctly.
I think this depends on what you consider to be the fundamental trait of double-entry accounting: the error-checking or the explanatory power.
It is true that by enforcing that value movement have both a source and a target, we make it possible to add a useful checksum to the system. But I believe this is a side benefit to the more fundamental trait of requiring all value flow to record both sides, in order to capture the cause for each effect.
I agree with your general perspective though: technology has afforded us new and different tools, and thus we should be open to new data models for accounting. I don't agree with other commenters that we should tread lightly in trying to decipher another field, nor do I agree with the view that the field of Accounting would have found a better way by now if there were one. Accountants are rarely, if ever, experts in CS or software engineering; likewise software developers rarely have depth in accounting.
Source: just my opinions. I've been running an accounting software startup for 5 years.
You should stop presuming that you know more about what’s needed than an entire field of business practice and study. There is actual theory behind accounting. Accountants understand that there can be different views on the same underlying data, and the system they continue to choose to use has a lot of benefits. You seem to be really stuck on the idea that the mental model accounting as a profession finds useful doesn’t seem useful to you. But it doesn’t need to make sense to you.
I'm not presuming I know anything about accounting. I know a great deal about data recording and management though, and my analysis is done from that perspective.
I explicitly recognized that the practice of accounting as a discipline keeps using traditional concepts that are culturally adequate for its purpose. What my posts are pointing out is that the original reason for double-entry records, which was having redundant data checks, is no longer a technical need in order to guarantee consistency because computers are already doing it automatically. From the pure data management perspective I'm analysing, that's undeniable.
The most obvious consequence of this analysis is that traditional bookkeeping is no longer the only viable way of traking accountability; new tools open the possibility of exploring alternative methods.
Compare it to music notation; people keep proposing new ways to write music scores, some of them computer assisted; and though none of them is going to replace the traditional way any time soon, there are places where alternative methods may prove useful; such as guitar tablature, or piano-roll sheets for digital samplers. The same could be true for accounting (and in fact some people in this thread have pointed out at different ways to build accounting software such as the
Resources, Events, Agents model.)
> It only makes sense in the context of a company.
Don't you think it can make sense in terms of pension contributions?
I used to track my finances very carefully (but now I'm more lackadaisical). Double entry would've been helpful for "I'm taking money from this pocket and putting it in this pocket".
It's like Newton's third law of motion, that "every force has an equal and opposite reaction", which when I was a wee child made no sense to me because "surely then nothing would happen". The key was that the equal and opposite reactions are on different objects.
It's the same thing with double entry accounting! The two entries are on different accounts.
> which when I was a wee child made no sense to me because "surely then nothing would happen"
I've literally just had this conversation today about jet aircraft with my 5-year-old, and how when you push air out of the jet engine really fast, that action pushes the nozzle forwards - it's not pushing against anything, it's like if you push against the sides of a box.
But he's still not quite got it, so we're going to go to the workshop and play with a high-volume fire pump.
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 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)"
Perhaps the word "transaction" should have been explained better. It doesn't mean an entry/record/action. It means a collection of several actions, all happening at the same time. Several actions that are interlinked and only can happen because of one another.
For instance, if I buy a house. "Ensuring the transaction" would be to make sure that a) I get registered as owner to the house and b) that the sellers gets my money. Either a)+b) should both happen (and those two things both happening is ONE transaction), or neither happens. (If I only give the money but don't get the house the transaction didn't complete/is invalid, but incomplete transactions are sort of out of scope for accounting systems)
Back to the article. An edge of 100 from X to Y means "move 100 from X to Y", which is the same as "subtract 100 from X and add 100 to Y, and those two entries belong together and should be done transactionally".
How else would you move money between two accounts if you did not subtract from one and add to the other?
Anyway: The edge is definitely not turned into 2 transactions. But, each edge causes two accounting entries, belonging to the same transaction.
>An edge of 100 from X to Y means "move 100 from X to Y", which is the same as "subtract 100 from X and add 100 to Y"
I think this is a perfectly succint explanation for people who have trouble grasping the double entry system.
Because they are usually stuck thinking in terms of "move 100 from X to Y". And its hard to get them to think in terms of "subtract 100 from X and add 100 to Y".
>* 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)
The author messed up by charactizing edges as one way transactions because in that moment he is only looking at the movement of cash. When he switches to edges being two transactions, he is now recognizing that the exchange of cash leads to the recognition of equities and liablities.
If you give your startup $5000 in cash, you expect to have $5000 in equity on the company books. When you charge to a credit card to buy food, you spend $13 buying food and paid $5 to your creditor so you still owe $-8 in liablities.
>Paying my landlord is "obviously" a transaction from my banking account (negative) into their banking account (positive). How it becomes four transaction is,the magic bit glossed over.
The magic of double entry is that you are only taking into account how your transaction affect your own balances. Thats why you need two entries, If you only debit your own account for rent, you would have a non-balanced set of books which would indicate that something is really wrong. So that why you have to credit Rent expense which is an account that doesnt track an actual balance in your bank account but a running total of all your rent expense for the year.
In the wikipedia example, you have your own set of accounting books and the landlord has his own set of books. That is how there are four entries, but you as an indivdual would only see and deal with your own double-entry.
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.
What made a lot of Econ and related stuff click for me is the idea that there is no such thing as a sale, only a purchase. When you buy a tv for $200, the electronics store buys $200 dollars of cash for $200 of TV.
So the electronic store hasn’t made any money on the transaction. They lost $200 dollars of tv and received $200 of cash. So the tv account got deducted 200 and the cash account got increased 200.
That is a bit of a over-simplification. Its true that there would be corresponding $200 entries that balance. But the store did make money on the transaction, and the journal entries would show it in a manner as shown below (assumption 50% margin on sales). (COGS is Cost of goods sold).
Yes, the journal entries don't immediatly show the profit as an explicit line item. But once closing entries are done, an income statement can be created that essentially shows the change in value of all your accounts for a certain period. In the income statement, profits would be calculated.
> the sum of the left two balances is minus five, and the sum of right three balances is 505.
Recheck your math the left two balances is actually 505.
5,000
-4,495
=====
0505
its (4,495) not (4,995)
So it all balances out, which is what accountant actually do but intstead of choosing any two disjoint sets. Specific nodes are grouped into either Assets or Liablities+Equity. Essentially group all the accounts with negative balances and all the accounts with positive balances into another set. Which in this case is 5008 and -5008.
It's just a convention to be able to capture the flow of money. Roughly, money comes in via Income, stays in Asset, goes to Expense (there is also Liability and Equity). Let's consider a home, as an asset. You could have got it with your own money (`Asset:Bank -> Asset:House`), or by taking a loan (`Liability:Home Loan -> Asset:House`). Both have very different implications. If you are just tracking current value of home, it won't capture the whole picture. E.g. if you want to sell the house, the price is going to be different in both cases.
Double entry is just a way to track the flow of money from these different categories of account. Once you have that, you can do a lot over it, generate all kinds of report that companies can use to understand their operations (and to share with investors).
There are even attempts to go beyond with triple-entry account, etc. I think the way to look at it is, companies need a way to understand and report the flow of money, the current state etc. Double entry helps with that. And they way it helps, it to keep track of both where money came from and where it went.
Double entry bookkeeping is a view that was confused for a model centuries ago, and has persisted ever since.
There have been attempts to correct this, such as the "Resources, Events, Agents" (REA) model[1], which according to the Wikipedia article "is a standard approach in teaching accounting information systems." But it doesn't really seem to have had a substantial impact on the practice of accounting.
The bottom line from a modern system design perspective, is that double-entry accounting makes much more sense if you treat it as a view of some more fundamental underlying model. REA provides one example of such a model.
The "double entry" stems from the fundamental accounting equation: assets = liabilities + equity. Whatever you have is either yours or borrowed. Change in one must have an equal change in the other to keep the equation balanced, otherwise you would lose track of how much you own and how much you owe.
For example, you have £200 in cash. £100 was your own earnings, £100 your mum gave you to pass on to someone. In pure single entry system, Cash account would have £200, with no distinction between the two. Double entry tracks ownership explicitly: £100 would be recorded in Equity and £100 in Payables.
> 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?
They can, but the probability of two opposite errors of exactly the same magnitude is much lower than of any individual random error.
It's the same as with any other error-correction encoding. You don't have a guarantee that all errors will be caught by it, but most of them can be, so it's useful overall.
> 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 like that. The fourth rule, "flipped on display" makes it conceptually a lot easier than the lengthy table of sign rules for different accounts that my boss kept on his wall.
A way I learned about it was that you want to be able to know the tangible cash value of your business at any given moment.
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?
Well, they didn’t like it! :) I considered just providing views onto the tables that would present the data in the way that made the accountants happy. But in the end we just ended up changing to using separate debit/credit columns. They managed to talk me around somehow, but I don’t remember the details any more. I think this was the relevant issue:
This website is absolutely nonsensical and I would not recommend it to anyone to understand how GAAP or IFRS accounting works. It might be useful for someone wanting to learn unicorn fantasy land accounting.
Double-entry accounting is basically checksum. For any transaction, the total in and out of all accounts involved in the transaction should be zero. If it's not, you have an error.
Conceptually, one of the hard parts to grasp and what many accounting students struggle with in the beginning is that in accounting financials, asset accounts have the opposite polarity as revenue accounts. This is because revenue is treated as an item that flows into Equity (in the famous equation Assets = Liabilities + Equity). The cash earned from a revenue-generating transaction is a (positive) asset, and so to balance it you need that revenue amount to be a negative somewhere in the books. This just affects the accounting financial statements (like the income statement or balance sheet; in the books both numbers would be entered as positive amounts in a transaction known as a "journal entry" in which you report the increase to one account and the offsetting decrease to another account.
Credit = money flowing out of an account or creating a new liability = decreases asset and expense accounts but increases liability and revenue accounts
Debit = money flowing into an account or reducing a liability = increases assets and expense accounts but decreases liability and revenue accounts
This website that you call nonsensical was a huge help to me when starting to learn about accounting systems. And I have spent several years of my life working on a (special purpose, non-generalist) accounting system.
The important thing is just a shift of perspective. It is just a different way of viewing the same system. The website doesn't contradict the things you write about at all.
Saying "double entry book-keeping is basically a checksum" and "a transaction of two entries is basically an edge in a graph" is just two views into the same model. Like working in real space vs Fourier domain. You can move between the representations but they represent the same underlying thing.
It seems your main gripe is the use of negative numbers instead of credit/debit.
I feel certain that if negative numbers where around when double entry book-keeping was first done then credit/debit would not have been invented.
Once you "grok" it, viewing an income account balance as a negative number and an expense account as a positive number makes so much sense.
Yes, using credit/debit instead of +/- is more normal, and if you use +/- you have to be prepared to translate at the UI later to terms more commonly used in accounting. But is is the same thing. You can just translate between them.
The article is not nonsensical at all. But perhaps it should have explained the regular use of debit/credit instead of negative numbers more explicitly.
The words used doesn't change the concepts though.
> I feel certain that if negative numbers where around when double entry book-keeping was first done
They were; one of negative numbers first documented uses in Europe after the Classical period was by Fibonacci in the specific context of financial calculations, around the turn of the 13th Century; the first evidence of the double entry bookkeeping is also in Italy, around the turn of the 14th Century.
I literally deal with accounting every day. I have used all of the major ERPs and implemented several of them, including Oracle, Netsuite, and Workday.
This website would not help a layman (i.e., non-accountant) or accounting student understand accounting, at all.
My issue with the website is not the use of credit/debit vs negative/non-negative numbers. My issue with this website is that it presents transaction flows without properly explaining the accounting logic of those transaction flows to its intended audience and even then it's way of framing transaction flows only works for the simplest transactions. The website's chosen way of explaining accounting would be actively harmful to understanding more advanced accounting issues. It would be like trying to teach someone how the internet works by framing everything in terms of plumbing.
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.
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.
I read this article on HN ten years ago and it has been very important to me in a career working on a special purpose accounting (for automated reconciliation of bank accounts of a payments processor).
The biggest shift from conventional accounting is the use of negative numbers instead of debit/credit.
I believe that accounting would have been a lot more accessible to professionals from science/math backgrounds if negative numbers had been used instead of debit/credit.
I think biggest challenge to introducing negative numbers in accounting now is that people don't like the look of an income account accumulating a negative balance and the expense account accumulating a positive balance. But once you bend your mind around that it makes perfect sense...expense is where the money "went" (positive), income is where the money "came from" (negative).
(The alternative sign convention would make cash on hand negative.)
That said: Credit/debit does carry an extra bit of information, because you can put negative numbers as credit/debit to convey flow going the opposite direction of the usual one. (This can also be inferred from the accounts being credit-normal or debit-normal, just wanted to note it is not 100% the same model.)
My Norwegian small business accounting system vendor (Fiken) has started to present data using +/- in addition to debit/credit columns, perhaps there is some adaption of signed numbers accounting happening..
I think the biggest challenge is that negative numbers are fundamentally a hack in this context. You don't have negative $100 in your bank account, and you don't pay negative $100 for something. Instead, you are $100 in debt or you receive $100, which is qualitatively different. Such qualitative differences should be represented using the type system.
Overdrafting accounts or negative balance in a bank account has nothing to do with what I was talking about.
A negative number in my comment is just the "from" part of a flow.
Just like in engineering, if you consider a dam, you can talk about the outflow as "-100 L/min" to indicate that the dam looses 100 litres per minute, for instance.
That does not mean that the litres of water anywhere ever becomes negative.
You do not say using negative numbers in engineering is a hack just because some numbers (like volume of water in the dam) is constrained to be positive.
In accounting one instead talks about the dam being debited 100 L and the electric plant being credited 100 L. That is basically just a different way of spelling "minus". It is the same thing just using different words.
And it is of course entirely possible to overdraft an account by debiting too much and get an invalid state entirely without negative numbers.
Negative numbers are actually a "hack" (or useful invention) in engineering and everywhere else too. They don't actually "exist", it is an abstraction similar to imaginary numbers and real numbers. But all of these are useful.
Negative numbers are a hack in the sense that they can be confusing, and it's easy to make mistakes with them. For example, I would interpret "-100 L/min outflow" as an indirect equivalent of "100 L/min inflow". To avoid confusion, you could drop terms "inflow" and "outflow" completely and talk about "-100 L/min (net) flow". Or you could separate the type and the magnitude of the flow.
The first one is just simpler, and you also get the nice graph properties (cuts, zero-sums, etc) discussed in the OP. Simpler database model, simpler code, less cases to test, easier to do ad hoc analysis queries, etc.
Of course in the UI one can simply flip signs on credit-normal accounts to avoid displaying negative numbers if one wishes.
Negative numbers are probably convenient, if your background is in a field, where numerical calculations are the norm. Traditional accounting is better justified from a mathematical perspective, as mathematics is more about definitions than calculations.
There are usually multiple levels of abstraction in code. When choosing the one to use for a particular task, it's a good idea to prioritize both simplicity and conceptual clarity. Bad things often happen, when the two priorities disagree. And you should try to use the same terminology and same concepts as the user as much as reasonably possible. Otherwise it's easy to make wrong choices by thinking about the problem from a wrong perspective.
This is the freshest take I have ever seen. Kudos, so cool.
My professional career has been 20 years of physical ai research and now industry. My dad insisted I take corporate accounting in undergrad.
It’s a skill I use every single day, double entry bookkeeping is one humanities great inventions and deeply related to conservation laws utility in various other areas. Could not have built my business without having gotten so into this
Topic.
That's cash bookkeeping, which is well defined.
The hard problems in accounting revolve around the time value of money and risk. Those are not as well defined. At best they are probability distributions.
I had independently invented diagrams like that many decades ago. I had also made up a "matrix accounting", which uses a new accounting equation:
<BAL|FSV> = 0
(It is assumed that <BAL| remains constant but |FSV> changes over time.)
However, I think that both the diagrams and the matrix accounting are not really practical compared with the double entry accounting, but that does not mean that they are not worth anything.
Accounting is just learning tax breaks, loopholes, and evasion. This article is weirdly written, as it claims accounting is just graph theory, and then provides the most convoluted way of calculating basic things like profit and loss. I recommend not reading this article at all.
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
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...
Thanks, this was a good explanation.
Thanks for this explanation, I see the “graph” now!
>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 know a decent bit of both worlds so that disconnect in perceptions always amuses me.
Double-entry bookkeeping was from its inception an error-correction code that could be calculated by hand.
Modern databases contain much more powerful error correction methods in the form of transactional commits, so from a pure technical point, double-entry bookkeeping is no longer needed at all; that's why programmers have a hard time understanding why it's there: for us, when we store a value in the DB, we can trust that it's been recorded correctly and forever as soon as the transaction ends.
The thing is, cultural accounting still relies on the concepts derived from double entry bookkeeping as described in the article; all those assets and debts and equity are still used by the finances people to make sense of the corporate world, so there's no chance that they'll fall out of use anytime, at least 'in the context of a company' as you out it.
Now would it be possible to create a new accounting system from scratch that relied on DB transactions and didn't depend on double entry? Sure it can, in fact crypto coins is exactly what happens when computer engineers design a money system unrestricted from tradition. But in practical terms it still needs to relate to the traditional categories in order to be understood and used.
> from a pure technical point, double-entry bookkeeping is no longer needed at all
Just because databases are transactional doesn't mean the entire system is. Double-entry accounting still helps catch errors.
A concrete example, since people like to think databases dealing with money are especially transactional, when they're not ...
I used to work at a small regional bank. In the course of some network maintenance, I accidentally disrupted the connectivity to an ATM while a customer was doing a transaction.
The next day, our accounting folks caught a problem with reconciliation, and the customer called to follow up as well. My interruption caused a deposit to proceed far enough to take their checks and money, but failed to credit the customer's account.
It's very hard to orchestrate transactions perfectly across multiple organizations and systems. You can't hand-wave this away by pointing at db consistency guarantees. Traditional accounting techniques will catch these errors.
I'm not sure that ATMs even have the ability to communicate certain failure classes back to the acquiring bank. eg, a cash dispenser malfunction is common enough to be mentioned by VISAs network rules explicitly, but as far as I know will almost always require manual reconciliation between the ATM operator and the network.
The crypto model of single entries with "from" and "to" field works well for transactions. For example you move $100 from checking to savings account, something like the following will capture it perfectly.
```json { "from": "Checking", "to": "Savings", "amount": 100 } ```
This is basically what a crypto ledger does.
But the main reason why we need double entry accounting is that not all accounting entries are transfers. For example, is we are logging a sales, cash increases by $100, and revenue increases by $100. What's the "from" here? Revenue isn't an account where account is taken from, it is the "source" of the cash increase. So something like the following doesn't capture the true semantics of the transaction.
```json { "from": "Revenue", "to": "Cash", "amount": 100 } ```
Instead, in accounting, the above transaction is captured as the following.
```json { "transaction": "Sale", "entries": [ { "account": "Cash", "debit": 100, "credit": null }, { "account": "Revenue", "debit": null, "credit": 100 } ] } ```
It gets worse with other entries like:
- Depreciation: Nothing moves. You're recognizing that a truck is worth less than before and that this consumed value is an expense. - Accruals: Recording revenue you earned but haven't been paid for yet. No cash moved anywhere.
The limitation of ledgers with "from" and "to" is that it assumes conservation of value (something moves from A to B). But accounting tracks value creation, destruction, and transformation, not just movement. Double-entry handles these without forcing a transfer metaphor onto non-transfer events.
But you don't need double entry to register increases or decreases of value; you could as well just use single-entry accounting and add or remove money from a single account, using transactions that are not transfers.
In the past this was problematic because you missed error-checking by redundance, but nowadays you can trust a computer to do all the checking with database transactions (which are more complex checks than double entry, though they don't need to be exposed into the business domain). Any tracking that you'd want to do with double-entry accounting could be done by creating single-entry accounts with similar meaning, and registering each transaction once, if you know that you can trust the transaction to be recorded correctly.
I think this depends on what you consider to be the fundamental trait of double-entry accounting: the error-checking or the explanatory power.
It is true that by enforcing that value movement have both a source and a target, we make it possible to add a useful checksum to the system. But I believe this is a side benefit to the more fundamental trait of requiring all value flow to record both sides, in order to capture the cause for each effect.
I agree with your general perspective though: technology has afforded us new and different tools, and thus we should be open to new data models for accounting. I don't agree with other commenters that we should tread lightly in trying to decipher another field, nor do I agree with the view that the field of Accounting would have found a better way by now if there were one. Accountants are rarely, if ever, experts in CS or software engineering; likewise software developers rarely have depth in accounting.
Source: just my opinions. I've been running an accounting software startup for 5 years.
You should stop presuming that you know more about what’s needed than an entire field of business practice and study. There is actual theory behind accounting. Accountants understand that there can be different views on the same underlying data, and the system they continue to choose to use has a lot of benefits. You seem to be really stuck on the idea that the mental model accounting as a profession finds useful doesn’t seem useful to you. But it doesn’t need to make sense to you.
I'm not presuming I know anything about accounting. I know a great deal about data recording and management though, and my analysis is done from that perspective.
I explicitly recognized that the practice of accounting as a discipline keeps using traditional concepts that are culturally adequate for its purpose. What my posts are pointing out is that the original reason for double-entry records, which was having redundant data checks, is no longer a technical need in order to guarantee consistency because computers are already doing it automatically. From the pure data management perspective I'm analysing, that's undeniable.
The most obvious consequence of this analysis is that traditional bookkeeping is no longer the only viable way of traking accountability; new tools open the possibility of exploring alternative methods.
Compare it to music notation; people keep proposing new ways to write music scores, some of them computer assisted; and though none of them is going to replace the traditional way any time soon, there are places where alternative methods may prove useful; such as guitar tablature, or piano-roll sheets for digital samplers. The same could be true for accounting (and in fact some people in this thread have pointed out at different ways to build accounting software such as the Resources, Events, Agents model.)
https://en.wikipedia.org/wiki/Resources,_Events,_Agents
> It only makes sense in the context of a company.
Don't you think it can make sense in terms of pension contributions?
I used to track my finances very carefully (but now I'm more lackadaisical). Double entry would've been helpful for "I'm taking money from this pocket and putting it in this pocket".
It's like Newton's third law of motion, that "every force has an equal and opposite reaction", which when I was a wee child made no sense to me because "surely then nothing would happen". The key was that the equal and opposite reactions are on different objects.
It's the same thing with double entry accounting! The two entries are on different accounts.
> which when I was a wee child made no sense to me because "surely then nothing would happen"
I've literally just had this conversation today about jet aircraft with my 5-year-old, and how when you push air out of the jet engine really fast, that action pushes the nozzle forwards - it's not pushing against anything, it's like if you push against the sides of a box.
But he's still not quite got it, so we're going to go to the workshop and play with a high-volume fire pump.
> so we're going to go to the workshop and play with a high-volume fire pump.
Sounds like a joke. Had me laughing. (I would not let a 5 y/o play with a fire pump!)
We let firefighters play with them, and they're basically 5-year-olds with access to powerful hydraulic cutting equipment.
I love them all really.
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.
"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)"
Perhaps the word "transaction" should have been explained better. It doesn't mean an entry/record/action. It means a collection of several actions, all happening at the same time. Several actions that are interlinked and only can happen because of one another.
For instance, if I buy a house. "Ensuring the transaction" would be to make sure that a) I get registered as owner to the house and b) that the sellers gets my money. Either a)+b) should both happen (and those two things both happening is ONE transaction), or neither happens. (If I only give the money but don't get the house the transaction didn't complete/is invalid, but incomplete transactions are sort of out of scope for accounting systems)
Back to the article. An edge of 100 from X to Y means "move 100 from X to Y", which is the same as "subtract 100 from X and add 100 to Y, and those two entries belong together and should be done transactionally".
How else would you move money between two accounts if you did not subtract from one and add to the other?
Anyway: The edge is definitely not turned into 2 transactions. But, each edge causes two accounting entries, belonging to the same transaction.
>An edge of 100 from X to Y means "move 100 from X to Y", which is the same as "subtract 100 from X and add 100 to Y"
I think this is a perfectly succint explanation for people who have trouble grasping the double entry system. Because they are usually stuck thinking in terms of "move 100 from X to Y". And its hard to get them to think in terms of "subtract 100 from X and add 100 to Y".
>* 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)
The author messed up by charactizing edges as one way transactions because in that moment he is only looking at the movement of cash. When he switches to edges being two transactions, he is now recognizing that the exchange of cash leads to the recognition of equities and liablities.
If you give your startup $5000 in cash, you expect to have $5000 in equity on the company books. When you charge to a credit card to buy food, you spend $13 buying food and paid $5 to your creditor so you still owe $-8 in liablities.
>Paying my landlord is "obviously" a transaction from my banking account (negative) into their banking account (positive). How it becomes four transaction is,the magic bit glossed over.
The magic of double entry is that you are only taking into account how your transaction affect your own balances. Thats why you need two entries, If you only debit your own account for rent, you would have a non-balanced set of books which would indicate that something is really wrong. So that why you have to credit Rent expense which is an account that doesnt track an actual balance in your bank account but a running total of all your rent expense for the year.
In the wikipedia example, you have your own set of accounting books and the landlord has his own set of books. That is how there are four entries, but you as an indivdual would only see and deal with your own double-entry.
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.
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.
What made a lot of Econ and related stuff click for me is the idea that there is no such thing as a sale, only a purchase. When you buy a tv for $200, the electronics store buys $200 dollars of cash for $200 of TV.
So the electronic store hasn’t made any money on the transaction. They lost $200 dollars of tv and received $200 of cash. So the tv account got deducted 200 and the cash account got increased 200.
That is a bit of a over-simplification. Its true that there would be corresponding $200 entries that balance. But the store did make money on the transaction, and the journal entries would show it in a manner as shown below (assumption 50% margin on sales). (COGS is Cost of goods sold).
Yes, the journal entries don't immediatly show the profit as an explicit line item. But once closing entries are done, an income statement can be created that essentially shows the change in value of all your accounts for a certain period. In the income statement, profits would be calculated.> the sum of the left two balances is minus five, and the sum of right three balances is 505.
Recheck your math the left two balances is actually 505.
5,000
-4,495
=====
its (4,495) not (4,995)So it all balances out, which is what accountant actually do but intstead of choosing any two disjoint sets. Specific nodes are grouped into either Assets or Liablities+Equity. Essentially group all the accounts with negative balances and all the accounts with positive balances into another set. Which in this case is 5008 and -5008.
We wrote about it here: https://finbodhi.com/docs/understanding-double-entry
It's just a convention to be able to capture the flow of money. Roughly, money comes in via Income, stays in Asset, goes to Expense (there is also Liability and Equity). Let's consider a home, as an asset. You could have got it with your own money (`Asset:Bank -> Asset:House`), or by taking a loan (`Liability:Home Loan -> Asset:House`). Both have very different implications. If you are just tracking current value of home, it won't capture the whole picture. E.g. if you want to sell the house, the price is going to be different in both cases.
Double entry is just a way to track the flow of money from these different categories of account. Once you have that, you can do a lot over it, generate all kinds of report that companies can use to understand their operations (and to share with investors).
There are even attempts to go beyond with triple-entry account, etc. I think the way to look at it is, companies need a way to understand and report the flow of money, the current state etc. Double entry helps with that. And they way it helps, it to keep track of both where money came from and where it went.
Hi, your compound interest article on ciju.in was good.
Any way to contact you to talk?
you can email me at ping@ciju.in, we can setup a call via email.
Double entry bookkeeping is a view that was confused for a model centuries ago, and has persisted ever since.
There have been attempts to correct this, such as the "Resources, Events, Agents" (REA) model[1], which according to the Wikipedia article "is a standard approach in teaching accounting information systems." But it doesn't really seem to have had a substantial impact on the practice of accounting.
The bottom line from a modern system design perspective, is that double-entry accounting makes much more sense if you treat it as a view of some more fundamental underlying model. REA provides one example of such a model.
[1] https://en.wikipedia.org/wiki/Resources,_Events,_Agents
The "double entry" stems from the fundamental accounting equation: assets = liabilities + equity. Whatever you have is either yours or borrowed. Change in one must have an equal change in the other to keep the equation balanced, otherwise you would lose track of how much you own and how much you owe.
For example, you have £200 in cash. £100 was your own earnings, £100 your mum gave you to pass on to someone. In pure single entry system, Cash account would have £200, with no distinction between the two. Double entry tracks ownership explicitly: £100 would be recorded in Equity and £100 in Payables.
> Double entry tracks ownership explicitly: £100 would be recorded in Equity and £100 in Payables.
Isn't it more about showing the -100 in the mum account and the -100 in the company account so that everything balances to zero?
> 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?
> can't two errors cancel each other out and you still wind up at zero?
They can, but the probability of two opposite errors of exactly the same magnitude is much lower than of any individual random error.
It's the same as with any other error-correction encoding. You don't have a guarantee that all errors will be caught by it, but most of them can be, so it's useful overall.
https://en.wikipedia.org/wiki/Error_correction_code
> 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...
I like that. The fourth rule, "flipped on display" makes it conceptually a lot easier than the lengthy table of sign rules for different accounts that my boss kept on his wall.
A way I learned about it was that you want to be able to know the tangible cash value of your business at any given moment.
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?
Well, they didn’t like it! :) I considered just providing views onto the tables that would present the data in the way that made the accountants happy. But in the end we just ended up changing to using separate debit/credit columns. They managed to talk me around somehow, but I don’t remember the details any more. I think this was the relevant issue:
https://github.com/adamcharnock/django-hordak/issues/59
This website is absolutely nonsensical and I would not recommend it to anyone to understand how GAAP or IFRS accounting works. It might be useful for someone wanting to learn unicorn fantasy land accounting.
Double-entry accounting is basically checksum. For any transaction, the total in and out of all accounts involved in the transaction should be zero. If it's not, you have an error.
Conceptually, one of the hard parts to grasp and what many accounting students struggle with in the beginning is that in accounting financials, asset accounts have the opposite polarity as revenue accounts. This is because revenue is treated as an item that flows into Equity (in the famous equation Assets = Liabilities + Equity). The cash earned from a revenue-generating transaction is a (positive) asset, and so to balance it you need that revenue amount to be a negative somewhere in the books. This just affects the accounting financial statements (like the income statement or balance sheet; in the books both numbers would be entered as positive amounts in a transaction known as a "journal entry" in which you report the increase to one account and the offsetting decrease to another account.
Credit = money flowing out of an account or creating a new liability = decreases asset and expense accounts but increases liability and revenue accounts
Debit = money flowing into an account or reducing a liability = increases assets and expense accounts but decreases liability and revenue accounts
This website that you call nonsensical was a huge help to me when starting to learn about accounting systems. And I have spent several years of my life working on a (special purpose, non-generalist) accounting system.
The important thing is just a shift of perspective. It is just a different way of viewing the same system. The website doesn't contradict the things you write about at all.
Saying "double entry book-keeping is basically a checksum" and "a transaction of two entries is basically an edge in a graph" is just two views into the same model. Like working in real space vs Fourier domain. You can move between the representations but they represent the same underlying thing.
It seems your main gripe is the use of negative numbers instead of credit/debit.
I feel certain that if negative numbers where around when double entry book-keeping was first done then credit/debit would not have been invented.
Once you "grok" it, viewing an income account balance as a negative number and an expense account as a positive number makes so much sense.
Yes, using credit/debit instead of +/- is more normal, and if you use +/- you have to be prepared to translate at the UI later to terms more commonly used in accounting. But is is the same thing. You can just translate between them.
The article is not nonsensical at all. But perhaps it should have explained the regular use of debit/credit instead of negative numbers more explicitly.
The words used doesn't change the concepts though.
> I feel certain that if negative numbers where around when double entry book-keeping was first done
They were; one of negative numbers first documented uses in Europe after the Classical period was by Fibonacci in the specific context of financial calculations, around the turn of the 13th Century; the first evidence of the double entry bookkeeping is also in Italy, around the turn of the 14th Century.
Thanks for correcting me!
But probably they were not as widespread and natural to people as today?
Perhaps though things like income account balance being a negative number would have made credit/debit invented anyway.
I literally deal with accounting every day. I have used all of the major ERPs and implemented several of them, including Oracle, Netsuite, and Workday.
This website would not help a layman (i.e., non-accountant) or accounting student understand accounting, at all.
My issue with the website is not the use of credit/debit vs negative/non-negative numbers. My issue with this website is that it presents transaction flows without properly explaining the accounting logic of those transaction flows to its intended audience and even then it's way of framing transaction flows only works for the simplest transactions. The website's chosen way of explaining accounting would be actively harmful to understanding more advanced accounting issues. It would be like trying to teach someone how the internet works by framing everything in terms of plumbing.
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.
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.
I read this article on HN ten years ago and it has been very important to me in a career working on a special purpose accounting (for automated reconciliation of bank accounts of a payments processor).
The biggest shift from conventional accounting is the use of negative numbers instead of debit/credit.
I believe that accounting would have been a lot more accessible to professionals from science/math backgrounds if negative numbers had been used instead of debit/credit.
I think biggest challenge to introducing negative numbers in accounting now is that people don't like the look of an income account accumulating a negative balance and the expense account accumulating a positive balance. But once you bend your mind around that it makes perfect sense...expense is where the money "went" (positive), income is where the money "came from" (negative).
(The alternative sign convention would make cash on hand negative.)
That said: Credit/debit does carry an extra bit of information, because you can put negative numbers as credit/debit to convey flow going the opposite direction of the usual one. (This can also be inferred from the accounts being credit-normal or debit-normal, just wanted to note it is not 100% the same model.)
My Norwegian small business accounting system vendor (Fiken) has started to present data using +/- in addition to debit/credit columns, perhaps there is some adaption of signed numbers accounting happening..
I think the biggest challenge is that negative numbers are fundamentally a hack in this context. You don't have negative $100 in your bank account, and you don't pay negative $100 for something. Instead, you are $100 in debt or you receive $100, which is qualitatively different. Such qualitative differences should be represented using the type system.
Overdrafting accounts or negative balance in a bank account has nothing to do with what I was talking about.
A negative number in my comment is just the "from" part of a flow.
Just like in engineering, if you consider a dam, you can talk about the outflow as "-100 L/min" to indicate that the dam looses 100 litres per minute, for instance.
That does not mean that the litres of water anywhere ever becomes negative.
You do not say using negative numbers in engineering is a hack just because some numbers (like volume of water in the dam) is constrained to be positive.
In accounting one instead talks about the dam being debited 100 L and the electric plant being credited 100 L. That is basically just a different way of spelling "minus". It is the same thing just using different words.
And it is of course entirely possible to overdraft an account by debiting too much and get an invalid state entirely without negative numbers.
Negative numbers are actually a "hack" (or useful invention) in engineering and everywhere else too. They don't actually "exist", it is an abstraction similar to imaginary numbers and real numbers. But all of these are useful.
Negative numbers are a hack in the sense that they can be confusing, and it's easy to make mistakes with them. For example, I would interpret "-100 L/min outflow" as an indirect equivalent of "100 L/min inflow". To avoid confusion, you could drop terms "inflow" and "outflow" completely and talk about "-100 L/min (net) flow". Or you could separate the type and the magnitude of the flow.
There's a difference between UI and code. In code, it is more complicated to do
than to simply use negative numbers and do The same in accounting, it can in my experience often be convenient that your Entry database tables look like rather than The first one is just simpler, and you also get the nice graph properties (cuts, zero-sums, etc) discussed in the OP. Simpler database model, simpler code, less cases to test, easier to do ad hoc analysis queries, etc.Of course in the UI one can simply flip signs on credit-normal accounts to avoid displaying negative numbers if one wishes.
Negative numbers are probably convenient, if your background is in a field, where numerical calculations are the norm. Traditional accounting is better justified from a mathematical perspective, as mathematics is more about definitions than calculations.
There are usually multiple levels of abstraction in code. When choosing the one to use for a particular task, it's a good idea to prioritize both simplicity and conceptual clarity. Bad things often happen, when the two priorities disagree. And you should try to use the same terminology and same concepts as the user as much as reasonably possible. Otherwise it's easy to make wrong choices by thinking about the problem from a wrong perspective.
This is the freshest take I have ever seen. Kudos, so cool.
My professional career has been 20 years of physical ai research and now industry. My dad insisted I take corporate accounting in undergrad.
It’s a skill I use every single day, double entry bookkeeping is one humanities great inventions and deeply related to conservation laws utility in various other areas. Could not have built my business without having gotten so into this Topic.
I wrote an article on how to model a ledger with a DB. https://www.jaygoel.com/posts/building-a-scalable-accounting...
It addresses how to model dr/cr in a DB with positive and negative numbers, but still produce reports with positive numbers as expected
That's cash bookkeeping, which is well defined. The hard problems in accounting revolve around the time value of money and risk. Those are not as well defined. At best they are probability distributions.
I had independently invented diagrams like that many decades ago. I had also made up a "matrix accounting", which uses a new accounting equation:
(It is assumed that <BAL| remains constant but |FSV> changes over time.)However, I think that both the diagrams and the matrix accounting are not really practical compared with the double entry accounting, but that does not mean that they are not worth anything.
Accounting is just learning tax breaks, loopholes, and evasion. This article is weirdly written, as it claims accounting is just graph theory, and then provides the most convoluted way of calculating basic things like profit and loss. I recommend not reading this article at all.
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.
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?
A.k.a. How do you deal with a time dependent network?
Double-entry accounting was invented at the time we tracked things with paper and pencil.
As someone who failed an accounting class I will definitely read this.
Can I replace Credit = From and Debit = To?
It depends on the “normal balance” of the account.
For Asset and Expense accounts, yes. For Liabilities, Equity, and Revenue it is the opposite.