6 ms·

A $1M deposit adds to both assets and liabilities. In double entry accounting, you mark any changes with both a debit and a credit. This allows you to see not

by acchow 4y ago

A $1M deposit adds to both assets and liabilities. 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).

jfengel 4y ago
I think programmers find double-entry bookkeeping counterintuitive. It feels error-prone. In programming, you keep a single source of truth. Any time you copy the same data to two different places, one of them is always wrong. 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.
- ghaff 4y ago
  The other thing you get into as scenarios get complex is that there's a tendency to ask questions like "Why are you recording it this way rather than that way? The second way seems more logical to me." The answer usually being some variation of "Because that's the way the Financial Accounting Standards Board says to do it."
- btilly 4y ago
  Double entry bookkeeping IS error prone - you have 2 opportunities to make each mistake. 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.
  - crdrost 4y ago
    Yes, and once you get the programmer to realize this, it all makes sense. 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.
    - sScTE9qEMCxEk34 4y ago
      The zero sum property also makes it really easy to just add up along (any subset of) each column and find most errors. Not so important now when everything's stored in a computerized database anyway, but a lot more relevant to actual books with actual writing in them.
  - rkhacker 4y ago
    So, in essence, the single entry bookkeeping will be sound if the change is not allowed?
- spicybright 4y ago
  I have a friend that's an accountant that tried to explain how it worked. I thought it was more or less being responsible for counting money, but I think my eyes glazed over a bit trying to understand it. 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.
  - lamontcg 4y ago
    I'm trying to understand how to read older 10-Ks and apply the capitalization of operating leases to those reports (converting property that is leased into capital to get an accurate estimate of the capital employed at the business) and with my background in IT and physics it is still a bit hard to follow (what I'm slow at is language, and really this is just learning a foreign language).
- hathawsh 4y ago
  You'd think that the solution to that confusion would be database transactions (commit everything or nothing), but there are exceptions. In ACH, sometimes you have to send out a lone credit or debit with no matching entry. It feels very wrong, but it's necessary because it balances out some other entry in another file (that you might not have access to.) 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.
- matteotom 4y ago
  I've been running my own finances with double entry bookkeeping (via beancount) for about 4 years now, and it's ended up being super useful. As long as I'm 90% sure I got all the income, expenses, investment buys and sells, and transfers between accounts, I can add "balance" statements for a date and easily work backwards to find if I missed anything.
- dragonwriter 4y ago
  > I think programmers find double-entry bookkeeping counterintuitive. It feels error-prone. In programming, you keep a single source of truth. Any time you copy the same data to two different places, one of them is always wrong. 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).
  - jfengel 4y ago
    I think if a programmer were designing accounting, they'd put the flows in the database, and build views out of that. They might materialize the views for performance reasons, but they'd treat those views as suspect and the first response to any bug would be "blow away the accounts and recreate them". 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.
    - CPLX 4y ago
      I mean, this is kind of how accounting does work. To a basic approximation a reconciliation is a line by line review of each of the flows, and an audit is "blow away the accounts and recreate them" and both happen all the time.
    - melenaboija 4y ago
      > I think if a programmer were designing accounting, they'd put the flows in the database, and build views out of that. They might materialize the views for performance reasons, but they'd treat those views as suspect and the first response to any bug would be "blow away the accounts and recreate them". 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.
- mytailorisrich 4y ago
  If by 'error' you mean the amount of a transaction then yes you enter it twice but that should not really increase errors. 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.
- WalterBright 4y ago
  The reason for the invention of double entry bookkeeping was to detect arithmetic errors in summing the ledgers.
- zestyping 4y ago
  The name "double-entry" is a little bit misleading. The "double" part makes it sound like you are duplicating work, but that's not really what's happening. 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."
  - sapling-ginger 4y ago
    > This maintains the invariant that money cannot be created or destroyed. 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.
    - youainti 4y ago
      Not really. Money is created but it is created by the fractional reserve baking model where banks borrow from people who are willing to lend for short periods of time (depositors) and lend to those who are looking to borrow in the long term. The fact that you tend to deposit in checking accounts is what creates the money.
- mcsoft 4y ago
  Double-entry bookkeeping is essentially the law of conservation of energy applied to balance sheets. It's much more deep as it was invented some 5 centuries earlier than programming.
  - Aeolun 4y ago
    Conservation of money in that case. Money doesn’t just disappear. What goes away somewhere has to appear somewhere else.
    - mcsoft 4y ago
      exactly
- tylerhou 4y ago
  Programmers like a single source of truth — until duplicating data is necessary for reliability (redundancy) or performance (replication). There is a reason why planes use 3+ CPUs running the same code, or why Google runs more than just one cluster of search.
- danbruc 4y ago
  I think programmers find double-entry bookkeeping counterintuitive. It feels error-prone. In programming, you keep a single source of truth. Any time you copy the same data to two different places, one of them is always wrong. 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?
  - nulbyte 4y ago
    > 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.
- sScTE9qEMCxEk34 4y ago
  > 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). 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!)

by acchow 4y ago

jfengel 4y ago

I think programmers find double-entry bookkeeping counterintuitive. It feels error-prone. In programming, you keep a single source of truth. Any time you copy the same data to two different places, one of them is always wrong. 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.

ghaff 4y ago
The other thing you get into as scenarios get complex is that there's a tendency to ask questions like "Why are you recording it this way rather than that way? The second way seems more logical to me." The answer usually being some variation of "Because that's the way the Financial Accounting Standards Board says to do it."
btilly 4y ago
Double entry bookkeeping IS error prone - you have 2 opportunities to make each mistake. 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.
- crdrost 4y ago
  Yes, and once you get the programmer to realize this, it all makes sense. 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.
  - sScTE9qEMCxEk34 4y ago
    The zero sum property also makes it really easy to just add up along (any subset of) each column and find most errors. Not so important now when everything's stored in a computerized database anyway, but a lot more relevant to actual books with actual writing in them.
- rkhacker 4y ago
  So, in essence, the single entry bookkeeping will be sound if the change is not allowed?
spicybright 4y ago
I have a friend that's an accountant that tried to explain how it worked. I thought it was more or less being responsible for counting money, but I think my eyes glazed over a bit trying to understand it. 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.
- lamontcg 4y ago
  I'm trying to understand how to read older 10-Ks and apply the capitalization of operating leases to those reports (converting property that is leased into capital to get an accurate estimate of the capital employed at the business) and with my background in IT and physics it is still a bit hard to follow (what I'm slow at is language, and really this is just learning a foreign language).
hathawsh 4y ago
You'd think that the solution to that confusion would be database transactions (commit everything or nothing), but there are exceptions. In ACH, sometimes you have to send out a lone credit or debit with no matching entry. It feels very wrong, but it's necessary because it balances out some other entry in another file (that you might not have access to.) 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.
matteotom 4y ago
I've been running my own finances with double entry bookkeeping (via beancount) for about 4 years now, and it's ended up being super useful. As long as I'm 90% sure I got all the income, expenses, investment buys and sells, and transfers between accounts, I can add "balance" statements for a date and easily work backwards to find if I missed anything.
dragonwriter 4y ago
> I think programmers find double-entry bookkeeping counterintuitive. It feels error-prone. In programming, you keep a single source of truth. Any time you copy the same data to two different places, one of them is always wrong. 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).
- jfengel 4y ago
  I think if a programmer were designing accounting, they'd put the flows in the database, and build views out of that. They might materialize the views for performance reasons, but they'd treat those views as suspect and the first response to any bug would be "blow away the accounts and recreate them". 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.
  - CPLX 4y ago
    I mean, this is kind of how accounting does work. To a basic approximation a reconciliation is a line by line review of each of the flows, and an audit is "blow away the accounts and recreate them" and both happen all the time.
  - melenaboija 4y ago
    > I think if a programmer were designing accounting, they'd put the flows in the database, and build views out of that. They might materialize the views for performance reasons, but they'd treat those views as suspect and the first response to any bug would be "blow away the accounts and recreate them". 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.
mytailorisrich 4y ago
If by 'error' you mean the amount of a transaction then yes you enter it twice but that should not really increase errors. 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.
WalterBright 4y ago
The reason for the invention of double entry bookkeeping was to detect arithmetic errors in summing the ledgers.
zestyping 4y ago
The name "double-entry" is a little bit misleading. The "double" part makes it sound like you are duplicating work, but that's not really what's happening. 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."
- sapling-ginger 4y ago
  > This maintains the invariant that money cannot be created or destroyed. 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.
  - youainti 4y ago
    Not really. Money is created but it is created by the fractional reserve baking model where banks borrow from people who are willing to lend for short periods of time (depositors) and lend to those who are looking to borrow in the long term. The fact that you tend to deposit in checking accounts is what creates the money.
mcsoft 4y ago
Double-entry bookkeeping is essentially the law of conservation of energy applied to balance sheets. It's much more deep as it was invented some 5 centuries earlier than programming.
- Aeolun 4y ago
  Conservation of money in that case. Money doesn’t just disappear. What goes away somewhere has to appear somewhere else.
  - mcsoft 4y ago
    exactly
tylerhou 4y ago
Programmers like a single source of truth — until duplicating data is necessary for reliability (redundancy) or performance (replication). There is a reason why planes use 3+ CPUs running the same code, or why Google runs more than just one cluster of search.
danbruc 4y ago
I think programmers find double-entry bookkeeping counterintuitive. It feels error-prone. In programming, you keep a single source of truth. Any time you copy the same data to two different places, one of them is always wrong. 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?
- nulbyte 4y ago
  > 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.
sScTE9qEMCxEk34 4y ago
> 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). 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!)