3 ms·

>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 i

by Havoc 10mo ago

>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

verbify 10mo ago
> 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".
TuringTest 10mo ago
> 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.
- bokenator 10mo ago
  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.
  - TuringTest 10mo ago
    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.

by Havoc 10mo ago

verbify 10mo ago

> 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".

TuringTest 10mo ago

> 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.

bokenator 10mo ago
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.
- TuringTest 10mo ago
  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.