In double entry accounting, you mark any changes with both a debit and a credit. This allows you to see not only why one account changes (a single entry), but also the cause of that change (the second entry).
Double-entry bookkeeping makes sense once you understand the the invariants you have to keep, and why you need to track 5 different types of books. Some of those accounts work in opposite ways, such that credit to one is a debit to another.
It all works out and is essential for "debugging" problems (when money appears to go missing -- or worse, materializes and you don't know why). But there's some counterintuitive language and it'll mess you up until you accept it.
The answer usually being some variation of "Because that's the way the Financial Accounting Standards Board says to do it."
However single entry bookkeeping is FRAUD prone. Just change one number and your theft is hard to track down!
That is why the adoption of double entry bookkeeping was critical for allowing commercial institutions to outgrow a size where owners could individually trust all who were working for them with access to money.
The ledgers are not the source of truth. No: this is a journaled filesystem; the transaction log is the ultimate source of truth. When you detect faults you recover from the journal, if something isn't completely written into the journal then it does not exist. The zero-sum property exists on every individual transaction and each transaction has an ID and the ledgers point at these IDs for auditing purposes.
So why have the zero sum property? Well, for one thing, it creates a uniform access model, I can't just credit my account, I have to debit someone else's account and they can have rules that might prohibit me from doing so. By carefully setting up these accounts you can also do what's sometimes called "behavior anomaly detection."
So for instance normal financial cards kind of work by opening up your entire wallet to a cash register and asking the cash register to pull out exactly the amount that you owe, understandably this might not be desirable if you are tracking some in-game-gold transactions in an internet game. You can get as elaborate as you want but think for example of a quick-consistency-check rule saying that “accounts starting 4xxx (player balances) never transfer directly to each other, instead users are expected to put the exact sum of money plus a little 5% padding into one of their 5xxx accounts and then give someone else a token permitting them to withdraw from that account." Stuff like that. A developer tries to code something up that doesn't go through this process and runs into errors in testing and has to conform their code’s behavior to the less risky process so that nobody is ever opening their entire wallet to a griefer.
Double entry basically just means that for every transaction on your books, you are showing where the money/asset/liability came from and/or where it's going. If you enter that you paid $100 for the AWS bill, you need to indicate from what account that money came from. So you would debit AWS Expense and you would credit your Wells Fargo Checking Account. With modern software, this basically just amounts to entering the expense and specifying which account it came from.
Doble entry accounting is very similar to a checksum in that sense. It provides error detection. If you make a mistake in one of those two places, you will know immediately. As opposed to single entry, where you can carry that error indefinitely until somehow you catch it.
Wikipedia tells us that double-entry bookkeeping is first attested in the late 13th century.
But commercial institutions larger than the personal-trust threshold are attested as far back as written history goes.
[citation needed]? I don't necessarily doubt you but I'd like to see an example. The only thing I can really think of would be governments, but that was definitely personal trust (mixed with a little bit of threat of summary execution if the king didn't like you).
The smallest amount of tribute listed there is more than five and a half tons of silver. If we make the assumption that each of these districts was handled by a different person, we already have a staff of 20 people plus the king.
(Not to mention, the large majority of Achaemenid taxation was not collected in this form. It was collected in kind and stored in an empire-wide system of distributed warehouses. I assume metal tribute was centralized. If you think the warehouse administrators - who inventory the goods and are responsible for making payments out of them - are "responsible for money", you're probably adding at least a couple dozen more people.)
By contrast, https://www.theofficialboard.com/org-chart/exxonmobil suggests that the top two levels (including the board) of Exxon total 26 people, or (excluding the board as a level, but still including the CEO) 24 people. The CEO has 13 direct reports.
So if the argument is that ancient kingdoms were below the personal trust threshold because the king had a low - and therefore manageably trustworthy - number of direct reports, it appears to be the case that our largest corporations today are also comfortably below the personal trust threshold, so there was never any need to exceed the threshold and in fact we never have.
(This isn't quite an apples-to-apples comparison; maybe there are 20 tribute administrators who report to a high overseer of tribute who reports to the king. Maybe each tribute administrator is one of five reporting to a low overseer of tribute, the four low overseers report to a high overseer, and he reports to the king. I don't know. How many employees do you think Exxon has who are directly responsible for submitting revenue totals in excess of three million dollars?)
On the other hand, if we think Exxon is beyond the personal trust threshold by virtue of its geographic extent (huge!), or its total number of employees (huge!), or its total number of employees touching money with the potential opportunity to steal that money (still huge!)... I think we have to say the same thing about ancient palaces, and really about ancient temples. A temple might "only" employ a few hundred people, but that's more people than you can personally trust. An important temple employed a few thousand people.
In a business I hand you my money and trust that you will hand me back my profits.
A ancient government put someone in charge and demanded tribute. Failure to produce tribute resulted in an army showing up to collect tribute. It was so common as to be expected that the administrator, called a satrap, would collect excess tribute and live a lavish lifestyle. The king sent spies to root out the worst of the abuse, but it was an uphill battle.
Governments can be run this way because efficiency is not particularly essential to their profitability. But efficiency is required for commercial enterprises. It is not enough to collect money and let your subordinates enrich themselves. You want to track all the money and not let your subordinates cheat the enterprise to their personal profit.
> But efficiency is required for commercial enterprises. It is not enough to collect money and let your subordinates enrich themselves. You want to track all the money and not let your subordinates cheat the enterprise to their personal profit.
The first two sentences are obviously false; you want to track all the money, but you have no particular need to do so as long as some of the money is making its way to you.
But to be fair he did pretty much the same when I tried to explain programming.
Always important to step outside your software bubble once and a while.
OTOH, once you have double-entry bookkeeping in your brain, you won't want to go back. I now feel that, from the perspective of a business or consumer, money is never created or destroyed, it only moves between accounts.
Double-entry bookkeeping is creating of an audit-trail/error-evident data store; which is the purpose of the apparent duplication. But it can be viewed as a view of dataset reflecting a single source of truth, that documents value flows; every movement of value has a source and a sink, and the amount that moves from the source must equal the amount that moves to the sink. Losing the redundancy that allows error-checking of records, you could view each accounting transaction as a triple of (source, sink, amount).
You couldn't do bookkeping with actual books that way, and historically this way makes sense. Nor is it likely that the accountants are going to rethink their field from the ground up for the convenience of programmers.
That is actually how it works, if you don't have "flows" you don't have accounting postings and if you have to fix an error you redo the postings from the flows. In this sense I would say that the "flows" are the source of truth.
Now, on the other hand, it is especially designed to account correctly for that amount in order to keep your accounts correct and balanced. It is be much easier to lose track of things with single-entry accounting.
If you were accounting with pen and paper, you would write the transaction amount twice — positive in one column and negative in another. This maintains the invariant that money cannot be created or destroyed.
In terms of an abstract data model, though, each transaction is best thought of as a flow, or a weighted arrow. It has one amount and two ends: a source and a destination. The "double" in "double-entry" really just means that the arrow has two ends. Obviously every arrow has to have a head and a tail — it doesn't make sense for there to be no source or no destination.
The credit vs. debit thing confuses people a lot, and in my opinion is a red herring. If I could wave a magic wand, I would delete the words "credit" and "debit" from accounting because they are hopelessly inconsistent.
All you have to do is think of the conservation of money like the conservation of mass — when it moves, it leaves one place and arrives at another. The moment I stopped using the words "credit" and "debit", my understanding of accounting went from "I have no idea what I'm doing" to "Everything is intuitively obvious."
And if you wonder, if money cannot be created or destroyed, how does a monetary system handle the population tripling over the past 50 years?
The answer is national debt. The US national debt is just an artifact of this double entry bookkeeping. In order for there to be +money in the economy for the ever-growing number of citizens to do commerce with, the treasury incurs on itself -money. That's national debt.
The corollary then, if the US ever pays back all of its national debt, the economy will crash because there just aren't cash available for people to do commerce with. A +90trillion on the government balance sheet equals a -90trillion on the private sector balance sheet.
If the private banks have conjured up 100x the monetary base in 1970, then when the population doubles by 2020, the banks cannot multiply further up to 200x. The treasury has to expand the base while the banks keep their multiplier fairly constant.
There is ONE special actor (in the US) that can create money out of the thin air: the Federal Reserve.
It alone can "buy" securities by crediting banks with money created out of nothing. Banks simply see a transaction with a dollar amount on their accounts within the Federal Reserve, and that's it. The money just appears.
The invariant "money can't be created or destroyed" holds for everybody else, including individual banks.
> The answer is national debt.
That's completely incorrect. The Federal Reserve can arbitrarily create (or destroy) money even if the national debt goes away entirely.
Saying that the Fed can arbitrarily create and destroy money misses the point, that they then have to buy SOMETHING with those money, and there are strict rules about what they can buy, and it just happens that the Treasury controls the supply of the primary asset class that the Fed is allowed to buy. Once you clear out all the dance and ceremony, you arrive at the conclusion that the Treasury issues new money by issuing new securities.
That's true, simply because they're the most convenient way to manipulate the monetary supply. Not much else is readily available in the volumes needed.
But they are not _essential_.
> Saying that the Fed can arbitrarily create and destroy money misses the point, that they then have to buy SOMETHING with those money, and there are strict rules about what they can buy
Sure, the invariant: "money goes out, asset goes in" holds.
But they can buy quite a lot of different securities if needed. E.g. the Fed directly bought about $3T of MBS: https://www.newyorkfed.org/markets/programs-archive/large-sc...
Also, I would say transactions are actually “multi-arrows” since there can be multiple sources and/or multiple destinations. A Bitcoin transaction captures this structure more or less perfectly.
There is a reason why planes use 3+ CPUs running the same code, or why Google runs more than just one cluster of search.
In essence you are just recording transactions with source and destination accounts and the amount. And at least in principle you could just log all transactions in this way without any redundant information. If you insist on making the change to each account more obvious, then you will have to record the amount twice, once for each account, but if you are doing the accounting with a computer, then I would guess that you always just record the transaction and only show the amount twice with different signs for the two involved accounts. Or does bookkeeping for some weird reasons really record each amount twice?
There is a surprisingly common reason, but it isn't weird. Consider a paycheck. You have income, but then you split that up. Some pays for insurance premiums, some is withheld for taxes, some may be contributed to a retirement account, and some is deposited into a bank account. Earnings is a credit to an income account, but everything else is a debit to some other account. The total debits equal the total credits, but each credit and debit must necessarily be a separate entry, because they all affect different accounts.
That's equally true in programming. The problem is that it only helps you debug problems that it created or participated in...
The difference in accounting is that it's not "two entries for the same thing". It's a credit and debit entry. It's a source and a target entry. It's two different entries for two different things, even though some of the details (like the transaction that they actually relate to) will be shared.
(And they're treated as separate "rows", rather than as additional columns on a single row, because it's a many-to-many relationship. Very database-designy!)