It really irks me that the author assumes I know how double-entry accounting works and doesn't mention a single sentence about it. I read half way through the article and couldn't follow it, except that single-entry is bad and double-entry is good.
In practice you have virtual accounts like "cloud expenses" and "customer subscription" that only go up/down over time, to be the counter-party for transactions in/out of your company. So it's not impossible to mess up, but it eliminates a class of mistakes.
Entry2: Account B: sends 1000 to Account A
And from GP:
> A consequence of that is you can check that the sum of all accounts is always 0.
Entry1 + Entry2 = 1000 + -1000 = 0
Amusingly, when I made my own personal money tracking program over a decade ago for my bank accounts, this was how I implemented transfers between them just because it was simpler to do. Years later when I heard this name, I also had trouble understanding it because I assumed I had done it the bad way and banks did somehow did something more in-depth.
The legal entity or entities involved - if any - would be described in the linked commercial document that explains the transaction, and the chart of accounts that describes the meaning of each account code.
There is no requirement for a transaction to have exactly two entries. The term "double-entry" is slightly misleading; it is only trying to express that both sides of the accounting equation are equal. When recording a sale, for example, it is more likely that three or more entries are journaled, due to the additional coded entries for sales tax, and those produced for separate line items for each SKU, shipping etc.
A better phrase is "two-sided accounting", which is also used, but less commonly than "double-entry".
The total amount of the credits would equal the cash debit.
"For every debit there must be a credit"
or
"Every transaction has two sides"
In the case of moving money between regular bank accounts in the same institution, you regard that as a movement between two asset accounts, whilst the bank regards that as a movement between two liability accounts.
So their entries would have the same magnitude as yours, but inverted signs.
Which means you aren't even thinking of the "bad" single-entry version, which is what a lot of people here are stumbling over because apparently it's more natural: A "transfers" table with the columns FromAccount, ToAccount, Amount, were a single row represents both the "Entry" rows from mine above.
In practice most systems allow for more than two entries in a single transaction (ex: take from bank account, give to salary, give to taxes) but always at least two, and always adding up to 0.
> Ledgers are conceptually a data model, represented by three entities: Accounts, Entries and Transactions.
> Most people think of money in terms of what’s theirs, and Accounts are the representation of that point of view. They are the reason why engineers naturally gravitate towards the “simplicity” of single-entry systems. Accounts are both buckets of value, and a particular point of view of how its value changes over time.
> Entries represent the flow of funds between Accounts. Crucially, they are always an exchange of value. Therefore, they always come in pairs: an Entry represents one leg of the exchange.
> The way we ensure that Entries are paired correctly is with Transactions. Ledgers shouldn’t interact with Entries directly, but through the Transaction entity.
Edit: no offense but sibling comment is an example :P
Single-entry: each row of your DB stores {account, delta}.
With double-entry you are guaranteed via your schema that sum(debit delta) = sum(credit delta), that's it. Money is "conserved".
It's easy to denormalize the double-entry into a single-entry view.
That kleppman article talking about movements as edges of a DAG is the only place this is ever talked about clearly.
Once you pair this with another entity or company doing the same, it becomes very hard for money or goods to vanish without the possibility to track it down. Either your books are consistent (sum of "stock" + sum of "ingress" - sum of "egress" - sum of "waste" makes sense), or something is weird. Either your incoming or outgoing goods match the other entities incoming or outgoing records, or something is amiss in between.
This is more about anomaly detection, because paying a clerk can be cheaper than losing millions of dollars of material by people unloading it off of a truck en-route.
Double entry accounting is useful because it enables local reasoning. Let me explain why! If you've remembered those other explanations, you hopefully remember the fundamental equation of accounting:
assets - liabilities = shareholder equity
assets + Δassets - liabilities - Δliabilities = equity
(assets - liabilities) + (Δassets - Δliabilities) = equity
In practice what this means is if your system is losing cents on every transaction as OP article states, each transaction should be flagged as imbalanced. From there it should be super easy to see why, since you can examine a single transaction.
To achieve this you need all entries / actions to have a unique transaction ID to group by, and a notion of which accounts are liabilities and which are assets, etc. As OP article mentions, there's a ton of implementation nuance.
There's an entire section on double-entry accounting in the article. The tl;dr is that if you take money out of an account, you need to place money in another account and vice versa. So, you have a table called "accounts receivable" which track money the company is owed. If you actually get paid, you remove money from "accounts receivable" and add money to the "cash" account, instead of just increasing the amount of cash you have.
It makes it much more difficult to lose track of money or have it stolen. In a single-entry system, I could receive money from a customer for services owed and just keep it for myself.