6 ms·

Does anyone have a good explanation for why a ledger database should care about credits and debits and normal balances? This has always seemed more natural to

by amluto 2y ago

Does anyone have a good explanation for why a ledger database should care about credits and debits and normal balances? This has always seemed more natural to me as a front-end / presentation layer concept. Your ledger entries always sum to zero for each transaction, your income account has a negative balance, and you display it in a sensible manner. I’m also surprised that this whole article starts by discussing stock trading but has no mention of how to represent stock trades. I assume they are “Sagas” consisting of money moving from the customer to the clearinghouse (or prime broker or PFOF provider or whatever) and shares moving from that provider to the account at which the shares are held. And maybe other associated entries representing fees? It seems to me that this is multi-entry accounting, which is quite common, and that entries don’t actually come in pairs as the article would like us to think.

jfengel 2y ago
I've never understood that either. As a computer guy it always struck me as a redundancy -- the kind of redundancy where one thing will always eventually be wrong. I assumed it has to do with the fact that it was invented for bookkeeping by hand. Accountants assure me that it's even more important with computers, but I've never managed to figure out how that works
- fallingknife 2y ago
  Neither have I. It always seems like a massive cargo culting. Human accountants are liable to make very different kinds of mistakes than computers.
- dboreham 2y ago
  I've been doing this so long that I've finally realized that if someone can't explain why something is the way it is, that means it's wrong, or at least some arbitrary choice among several equally good alternatives.
  - dagenix 2y ago
    https://en.wikipedia.org/wiki/G._K._Chesterton#Chesterton's_fence https://en.wikipedia.org/wiki/G._K._Chesterton#Chesterton's_...
    - bvrmn 2y ago
      The funny thing with debit/credit wall: only long dead Italian merchchants knew its purpose.
  - ffsm8 2y ago
    Being able to explain it is something different then you being able to understand it. And double entry bookkeeping should be both easy to explain (there are countless articles for it, precisely because it is a pretty easy concept) And easy to understand if you have ever tried to keep a ledger of transactions around and wanted to audit it for errors.
    - jfengel 2y ago
      I always get hung up on the different kinds of accounts and their respective definitions of "credit" and "debit". It isn't that much to memorize but it's very counter to the way I understood those terms and it keeps throwing me off.
      - FredPret 2y ago
        The simplest way to memorize it is to remember the accounting formula and one simple rule. - Assets minus Liabilities = Equity (net worth) - Your bank account or cash balance increases on the debit side From this you can figure out that if you borrowed money, the debt increases on the credit side and the cash influx debits your bank account. The same goes for an income.
        bvrmn 2y ago
        But signed amounts (instead of debit/credit) formula is a way easier. Sum of entries of assets/liabilities accounts = Equity. Moreover assets and liabilities become one type.
- thaumasiotes 2y ago
  > As a computer guy it always struck me as a redundancy -- the kind of redundancy where one thing will always eventually be wrong. That's the purpose. If you have a system with no redundancy, it's equally true that something will always eventually be wrong. But in that case, you'll have no way of knowing what's wrong. With the redundancy, you can detect problems and often determine what happened.
- nicwilson 2y ago
  Double entry accounting is still error prone, but single entry accounting is fraud prone.
- Aspos 2y ago
  A single debit can result in many credits. A single record can (and will) be lost. Network issue, db issue, etc., some transactions will not make it to the db. With double entry you at least have a chance of reconciling the lost transaction.
- kdmtctl 2y ago
  It is not a redundancy. Actually the meaning of a transaction encoded in a pair of accounts. You will need to store it somewhere anyway in a real world scenario, but predefined account pairs is the universal language. The accounting system.
yobbo 2y ago
In double-entry, a transaction is the tuple (amount, credit_account, debit_account). In singly-entry, it is the tuple (amount, account).
- amluto 2y ago
  > In double-entry, a transaction is the tuple (amount, credit_account, debit_account). Every “double entry” accounting package I’ve ever used can easily handle transactions that are awkward in this schema and transactions that don’t fit at all. Moving $1 from one current account to another? I guess you declare that the $1 needs to be a positive amount, but your two accounts have the same normal balance, and calling one a “debit account” is a bit awkward. Adding an accounts payable entry that is split between two expense accounts? Not so easy.
  - eviks 2y ago
    it's not "debit account" but "debit an account"
  - kdmtctl 2y ago
    "Debit" is a verb here.
rawgabbit 2y ago
It is best explained by common scenarios an Italian merchant in the Middle Ages experienced. The basic concept is Assets==Liability (plus Equity). Where positive Assets are entered on the left hand side (debit). And positive Liabilities are entered on the right hand side (credit). In accounting, debit and credit just means left and right. 1. Merchant takes out a loan for $5,000 and receives $5,000 in cash. • Assets (Cash) increase by $5,000 (Debit). • Liabilities (Loan Payable) increase by $5,000 (Credit). • Equity remains unchanged. 2. Merchant buys inventory for $1,000 cash. • Assets (Cash) decrease by $1,000 (Credit). • Assets (Inventory) increase by $1,000 (Debit). • Total assets remain unchanged, and liabilities and equity are unaffected. 3. Merchant sells all inventory for $1,500 cash. • Assets (Cash) increase by $1,500 (Debit). • Assets (Inventory) decrease by $1,000 (Credit) (recording cost of goods sold). • Equity (Retained Earnings) increases by $500 (Credit), representing the profit ($1,500 sales - $1,000 cost). 4. Customer1 deposits $500 in cash for future delivery of goods. • Assets (Cash) increase by $500 (Debit). • Liabilities (Unearned Revenue) increase by $500 (Credit). • Equity remains unchanged. 5. Customer1 transfers half of the future delivery of goods to Customer2. • No changes to assets, liabilities, or equity occur at this point. The merchant’s obligation to deliver goods (reflected as Unearned Revenue) is still $500 but now split between two customers (Customer1 and Customer2). Internal tracking of this obligation may be updated, but the total financial liability remains the same.
- amluto 2y ago
  I understand this. But we’re talking about computers, not Italian merchants. Italian merchants had actual pieces of paper. Computers have tables and views and frontends that are separate from the tables. Any self-respecting accounting system should be able to produce a balance sheet that matches the conventions you’re describing. I don’t think it follows that the actual numbers in the database that get summed to produce the total liabilities should be positive.
  - FredPret 2y ago
    I've often wondered about this in the shower. Why debits and credits, when we can just make income negative and let everything sum to 0? Then you can track the balance for each account in a single field in the database. And the answer is that "0" first entered Europe around the time they invented double-entry bookkeeping there. Negative numbers reached Europe centuries after that. I showed the internals of a number-line-based accounting systems to an accountant once, and he was so confused by the negative incomes. https://en.wikipedia.org/wiki/Negative_number#History https://en.wikipedia.org/wiki/Negative_number#History https://en.wikipedia.org/wiki/Double-entry_bookkeeping#History https://en.wikipedia.org/wiki/Double-entry_bookkeeping#Histo...
mamcx 2y ago
> This has always seemed more natural to me as a front-end / presentation layer concept. Consistence is a property of the backend, if that is wrong there is not hope for later > Your ledger entries always sum to zero for each transaction, your income account has a negative balance, and you display it in a sensible manner. 'sensible manner' is the problem here. The data/money will be diverge with time, and without proper storage of the data it will by impossible to figure out. The problem here is NOT store 'a transaction'. That with a RDBMs works. Is to store the FLOW of MANY transactions and the divergent ways things works. Like, your bank is telling you has $100 and your system $120. And your system sum right, but the bank rules. Or when you do a return and cents are lost in the interchanges and chargebacks. Or, just wrong data entry, sync, import/export, etc. --- The way to see this is that `double entry` is a variation of `inmutable data that don't mutate and always track the flow of it' that is golden for business apps.
BillyTheKing 2y ago
yes, agree, I think a 'source' 'destination' model is significantly more straight-forward. Just record the 'source' account and the destination account and you essentially end up with a ledger as a directed graph (Martin Kleppmann wrote a great post on it) I also wrote a super short post on how to model such a system on postgres https://blog.nxos.io/A-simple-double-entry-ledger-with-source-and-destination-accounts-da43efadf3d2421cae083c719c31b7fa https://blog.nxos.io/A-simple-double-entry-ledger-with-sourc... Blockchain actually kinda nails it, that's in essence a source/destination ledger, no 'postings' or similar needed, and from a balance calculation POV has been working pretty well One reason this model isn't applied in accounting, in my personal view :), is simply historical and the fact that the number 0 didn't exist when accounting principles were created. Wrote another post on how to model debit/credits on a source/destination ledger here: https://blog.nxos.io/Debit-and-Credits-on-a-Source-Destination-Ledger-4442b28fe1c241ca82a14f20c6754beb https://blog.nxos.io/Debit-and-Credits-on-a-Source-Destinati... It's very straight-forward, you just have to accept that asset accounts have negative balances and present the absolute amount instead of a negative amount in a view.
- jnwatson 2y ago
  It isn't always clear which is "source" and which is "destination" and now you need a bunch of new conventions about these things. Accounting already has these (admittedly arbitrary) conventions so we might as well use those.
- jes5199 2y ago
  okay but how do you model a three-party transaction? say you want to collect fees or taxes
  - BillyTheKing 2y ago
    you simple create two records linked by one 'transaction', the source in both cases is the same account, while the destination for one of those postings is the fee account and the other destination is a merchant or similar account. And you can link as many of those postings under a single transaction
jasim 2y ago
That part of the article felt quite wrong to me as well. I've built accounting systems that worked well for a decade, where internally the values were a single amount column in the journal table. If it was a debit, it'd be positive, if a credit, it'd be negative. In fact, we could call these values yin and yang, for all it mattered. Also, I'm not able to really follow what he means by "money = assets in the future". Money is money, but if you wanted to track the intermediate state until the customer gets receipt, you would use an In Transit account (Good In Transit / Service In Transit etc.) Yet, it doesn't change the fundamental definition of the value in the accounting system. I think the author confuses an engineering concept (sagas, or thunks, or delayed but introspectable/cancellable actions in general) with accounting.
- scrollaway 2y ago
  IMO it's entirely wrong, and it also makes it a lot more difficult to programmatically create transactions with 3+ legs (For example: A payment with a line item + sales tax). I think the author is just wrong on that point, but the rest is sound. (Source: I've built bookkeeping software)
  - kdmtctl 2y ago
    There are no 3 leg transactions in a ledger. You described an order. Ledger transactions is one layer deeper. Order creates 2 different transactions: Payment correspond to payments accounts, taxes to the Taxes Payable. That is how classic bookkeeping works.
    - scrollaway 2y ago
      Sorry what? No, I'm describing a transaction. There is nothing preventing n-leg transactions in a ledger. Neither a physical one, nor a digital one. They're complicated to balance, so it's not commonly done in physical ledgers for sure, but in digital ledgers it's completely fine. You just have to make sure they do balance. Orders are not relevant for ledgers. The system I describe is relevant for individual transactions -- for example, a single bank payment that pays for two outstanding invoices at once absolutely SHOULD create a single transaction with three legs: One out of the bank account, two to payables.
neffy 2y ago
Double entry book keeping implements an error correction and detection algorithm.

by amluto 2y ago

jfengel 2y ago

I've never understood that either. As a computer guy it always struck me as a redundancy -- the kind of redundancy where one thing will always eventually be wrong. I assumed it has to do with the fact that it was invented for bookkeeping by hand. Accountants assure me that it's even more important with computers, but I've never managed to figure out how that works

fallingknife 2y ago
Neither have I. It always seems like a massive cargo culting. Human accountants are liable to make very different kinds of mistakes than computers.
dboreham 2y ago
I've been doing this so long that I've finally realized that if someone can't explain why something is the way it is, that means it's wrong, or at least some arbitrary choice among several equally good alternatives.
- dagenix 2y ago
  https://en.wikipedia.org/wiki/G._K._Chesterton#Chesterton's_fence https://en.wikipedia.org/wiki/G._K._Chesterton#Chesterton's_...
  - bvrmn 2y ago
    The funny thing with debit/credit wall: only long dead Italian merchchants knew its purpose.
- ffsm8 2y ago
  Being able to explain it is something different then you being able to understand it. And double entry bookkeeping should be both easy to explain (there are countless articles for it, precisely because it is a pretty easy concept) And easy to understand if you have ever tried to keep a ledger of transactions around and wanted to audit it for errors.
  - jfengel 2y ago
    I always get hung up on the different kinds of accounts and their respective definitions of "credit" and "debit". It isn't that much to memorize but it's very counter to the way I understood those terms and it keeps throwing me off.
    - FredPret 2y ago
      The simplest way to memorize it is to remember the accounting formula and one simple rule. - Assets minus Liabilities = Equity (net worth) - Your bank account or cash balance increases on the debit side From this you can figure out that if you borrowed money, the debt increases on the credit side and the cash influx debits your bank account. The same goes for an income.
      - bvrmn 2y ago
        But signed amounts (instead of debit/credit) formula is a way easier. Sum of entries of assets/liabilities accounts = Equity. Moreover assets and liabilities become one type.
thaumasiotes 2y ago
> As a computer guy it always struck me as a redundancy -- the kind of redundancy where one thing will always eventually be wrong. That's the purpose. If you have a system with no redundancy, it's equally true that something will always eventually be wrong. But in that case, you'll have no way of knowing what's wrong. With the redundancy, you can detect problems and often determine what happened.
nicwilson 2y ago
Double entry accounting is still error prone, but single entry accounting is fraud prone.
Aspos 2y ago
A single debit can result in many credits. A single record can (and will) be lost. Network issue, db issue, etc., some transactions will not make it to the db. With double entry you at least have a chance of reconciling the lost transaction.
kdmtctl 2y ago
It is not a redundancy. Actually the meaning of a transaction encoded in a pair of accounts. You will need to store it somewhere anyway in a real world scenario, but predefined account pairs is the universal language. The accounting system.

yobbo 2y ago

In double-entry, a transaction is the tuple (amount, credit_account, debit_account). In singly-entry, it is the tuple (amount, account).

amluto 2y ago
> In double-entry, a transaction is the tuple (amount, credit_account, debit_account). Every “double entry” accounting package I’ve ever used can easily handle transactions that are awkward in this schema and transactions that don’t fit at all. Moving $1 from one current account to another? I guess you declare that the $1 needs to be a positive amount, but your two accounts have the same normal balance, and calling one a “debit account” is a bit awkward. Adding an accounts payable entry that is split between two expense accounts? Not so easy.
- eviks 2y ago
  it's not "debit account" but "debit an account"
- kdmtctl 2y ago
  "Debit" is a verb here.

rawgabbit 2y ago

It is best explained by common scenarios an Italian merchant in the Middle Ages experienced. The basic concept is Assets==Liability (plus Equity). Where positive Assets are entered on the left hand side (debit). And positive Liabilities are entered on the right hand side (credit). In accounting, debit and credit just means left and right. 1. Merchant takes out a loan for $5,000 and receives $5,000 in cash. • Assets (Cash) increase by $5,000 (Debit). • Liabilities (Loan Payable) increase by $5,000 (Credit). • Equity remains unchanged. 2. Merchant buys inventory for $1,000 cash. • Assets (Cash) decrease by $1,000 (Credit). • Assets (Inventory) increase by $1,000 (Debit). • Total assets remain unchanged, and liabilities and equity are unaffected. 3. Merchant sells all inventory for $1,500 cash. • Assets (Cash) increase by $1,500 (Debit). • Assets (Inventory) decrease by $1,000 (Credit) (recording cost of goods sold). • Equity (Retained Earnings) increases by $500 (Credit), representing the profit ($1,500 sales - $1,000 cost). 4. Customer1 deposits $500 in cash for future delivery of goods. • Assets (Cash) increase by $500 (Debit). • Liabilities (Unearned Revenue) increase by $500 (Credit). • Equity remains unchanged. 5. Customer1 transfers half of the future delivery of goods to Customer2. • No changes to assets, liabilities, or equity occur at this point. The merchant’s obligation to deliver goods (reflected as Unearned Revenue) is still $500 but now split between two customers (Customer1 and Customer2). Internal tracking of this obligation may be updated, but the total financial liability remains the same.

amluto 2y ago
I understand this. But we’re talking about computers, not Italian merchants. Italian merchants had actual pieces of paper. Computers have tables and views and frontends that are separate from the tables. Any self-respecting accounting system should be able to produce a balance sheet that matches the conventions you’re describing. I don’t think it follows that the actual numbers in the database that get summed to produce the total liabilities should be positive.
- FredPret 2y ago
  I've often wondered about this in the shower. Why debits and credits, when we can just make income negative and let everything sum to 0? Then you can track the balance for each account in a single field in the database. And the answer is that "0" first entered Europe around the time they invented double-entry bookkeeping there. Negative numbers reached Europe centuries after that. I showed the internals of a number-line-based accounting systems to an accountant once, and he was so confused by the negative incomes. https://en.wikipedia.org/wiki/Negative_number#History https://en.wikipedia.org/wiki/Negative_number#History https://en.wikipedia.org/wiki/Double-entry_bookkeeping#History https://en.wikipedia.org/wiki/Double-entry_bookkeeping#Histo...

mamcx 2y ago

> This has always seemed more natural to me as a front-end / presentation layer concept. Consistence is a property of the backend, if that is wrong there is not hope for later > Your ledger entries always sum to zero for each transaction, your income account has a negative balance, and you display it in a sensible manner. 'sensible manner' is the problem here. The data/money will be diverge with time, and without proper storage of the data it will by impossible to figure out. The problem here is NOT store 'a transaction'. That with a RDBMs works. Is to store the FLOW of MANY transactions and the divergent ways things works. Like, your bank is telling you has $100 and your system $120. And your system sum right, but the bank rules. Or when you do a return and cents are lost in the interchanges and chargebacks. Or, just wrong data entry, sync, import/export, etc. --- The way to see this is that `double entry` is a variation of `inmutable data that don't mutate and always track the flow of it' that is golden for business apps.

BillyTheKing 2y ago

yes, agree, I think a 'source' 'destination' model is significantly more straight-forward. Just record the 'source' account and the destination account and you essentially end up with a ledger as a directed graph (Martin Kleppmann wrote a great post on it) I also wrote a super short post on how to model such a system on postgres https://blog.nxos.io/A-simple-double-entry-ledger-with-source-and-destination-accounts-da43efadf3d2421cae083c719c31b7fa https://blog.nxos.io/A-simple-double-entry-ledger-with-sourc... Blockchain actually kinda nails it, that's in essence a source/destination ledger, no 'postings' or similar needed, and from a balance calculation POV has been working pretty well One reason this model isn't applied in accounting, in my personal view :), is simply historical and the fact that the number 0 didn't exist when accounting principles were created. Wrote another post on how to model debit/credits on a source/destination ledger here: https://blog.nxos.io/Debit-and-Credits-on-a-Source-Destination-Ledger-4442b28fe1c241ca82a14f20c6754beb https://blog.nxos.io/Debit-and-Credits-on-a-Source-Destinati... It's very straight-forward, you just have to accept that asset accounts have negative balances and present the absolute amount instead of a negative amount in a view.

jnwatson 2y ago
It isn't always clear which is "source" and which is "destination" and now you need a bunch of new conventions about these things. Accounting already has these (admittedly arbitrary) conventions so we might as well use those.
jes5199 2y ago
okay but how do you model a three-party transaction? say you want to collect fees or taxes
- BillyTheKing 2y ago
  you simple create two records linked by one 'transaction', the source in both cases is the same account, while the destination for one of those postings is the fee account and the other destination is a merchant or similar account. And you can link as many of those postings under a single transaction

jasim 2y ago

That part of the article felt quite wrong to me as well. I've built accounting systems that worked well for a decade, where internally the values were a single amount column in the journal table. If it was a debit, it'd be positive, if a credit, it'd be negative. In fact, we could call these values yin and yang, for all it mattered. Also, I'm not able to really follow what he means by "money = assets in the future". Money is money, but if you wanted to track the intermediate state until the customer gets receipt, you would use an In Transit account (Good In Transit / Service In Transit etc.) Yet, it doesn't change the fundamental definition of the value in the accounting system. I think the author confuses an engineering concept (sagas, or thunks, or delayed but introspectable/cancellable actions in general) with accounting.

scrollaway 2y ago
IMO it's entirely wrong, and it also makes it a lot more difficult to programmatically create transactions with 3+ legs (For example: A payment with a line item + sales tax). I think the author is just wrong on that point, but the rest is sound. (Source: I've built bookkeeping software)
- kdmtctl 2y ago
  There are no 3 leg transactions in a ledger. You described an order. Ledger transactions is one layer deeper. Order creates 2 different transactions: Payment correspond to payments accounts, taxes to the Taxes Payable. That is how classic bookkeeping works.
  - scrollaway 2y ago
    Sorry what? No, I'm describing a transaction. There is nothing preventing n-leg transactions in a ledger. Neither a physical one, nor a digital one. They're complicated to balance, so it's not commonly done in physical ledgers for sure, but in digital ledgers it's completely fine. You just have to make sure they do balance. Orders are not relevant for ledgers. The system I describe is relevant for individual transactions -- for example, a single bank payment that pays for two outstanding invoices at once absolutely SHOULD create a single transaction with three legs: One out of the bank account, two to payables.

neffy 2y ago

Double entry book keeping implements an error correction and detection algorithm.