4 ms·

I know that account balances were just a "motivating example" here, but please, I beg you: don't handle accounts this way. Double-entry accounting predates com

I know that account balances were just a "motivating example" here, but please, I beg you: don't handle accounts this way. Double-entry accounting predates computers by many centuries, and solves a problem which computers still have. Use double-entry accounting internally if you're handling money! This means both the liability and the asset side of the equation are balanced when written, and can be (should be, must be) balanced across both entries as well.

exdsq 5y ago
One of those great moments where domain knowledge results in a substantially different system to the intuitive approach :)
PoignardAzur 5y ago
Naive question: how does double-entry accounting help computer accouting systems?
- inopinatus 5y ago
  It’s the original CRDT.
- OJFord 5y ago
  Everything is accounted for, you can't accidentally (or 'accidentally') have money come from or go nowhere, since it must balance - account1 going up by a pound is matched to account2 going down a pound.
  - kzrdude 5y ago
    (Serious question) Why don't we see money-out-of-nowhere bugs in banks? How do they ensure they don't happen? Even maliciously, for that reason.
    - OJFord 5y ago
      Well we've done the (more direct) question and answer in reverse here really! Balancing is one part of the answer (I think it would be fair to say it doesn't necessarily have to be - or at least not obviously look like - double-entry). You could argue immutable (append-only) records help too - no amendments only additional corrective records. I've never worked in a bank btw so pinch of salt etc., just have a bit of an interest and fiddle on and off with a related project.
derefr 5y ago
In my mental model of a digital financial ledger, it just looks like a table of transfer events, e.g. {timestamp, from_acct=A, to_acct=B, balance_delta=V}. Which, yes, tracks the counterparty balances as well as your own. But it's not double entry per se. Each transfer only has its data in one place; there's no second corresponding entry in the table looking like {timestamp, from_acct=B, to_acct=A, balance_delta=-V}. You don't need that second entry; you can already do everything you need with just the one. (E.g. someone's current balance is the sum of the balance_deltas for which they're the receiver, minus the sum of the balance_deltas for which they're the sender.) Are you suggesting there's a point in having rows in corresponding pairs like this? If so, what is it? (If it's data integrity, IMHO that should be guaranteed at a lower level, with cryptographic checksums et al.)
- samatman 5y ago
  I'm not sure which of us is confused and it doesn't matter: let us say that there is a confusion about double entry, which I used to have and no longer do. It's exactly having from: and to: in a single entry which makes for double entry accounting. Or one from: and several to: but that's effectively an elision. By implication there is a second double-entry on the other side, but that's often their business, not mine: as an example, the Income statements in my personal ledger are balanced by an Expenses:Payroll on the other side... spiritually, I neither know nor care about the details of how that accounting is done. In the special case that both accounts are internal to the business, then yes, expense on one account becomes asset on the other. Whether that is one or two (double) entries depends on a bunch of things. In terms of specific data modeling, I would urge you that yes, the rows corresponding to any debit or credit should include a 'from' field. The reasons are numerous, and have more to do with audit than data integrity per se. The sufficient reason is that there might not be a counterparty inside your database.
- saltminer 5y ago
  > Are you suggesting there's a point in having rows in corresponding pairs like this? If so, what is it? If you've ever read a balance sheet (e.g. on a 10k), those things are much easier to compile with double-entry bookkeeping because everything is already neatly categorized. But another thing to think about is that accounting is a very old profession, and when you're totaling everything by hand (or using an abacus, adding machine, etc.), mistakes are easy to make. If you notice your debits not matching your credits, you immediately know you messed something up. Making the same mistake twice (and thus not catching it) is much less likely, so double-entry makes your work more reliable.

exdsq 5y ago

One of those great moments where domain knowledge results in a substantially different system to the intuitive approach :)

PoignardAzur 5y ago

Naive question: how does double-entry accounting help computer accouting systems?

inopinatus 5y ago
It’s the original CRDT.
OJFord 5y ago
Everything is accounted for, you can't accidentally (or 'accidentally') have money come from or go nowhere, since it must balance - account1 going up by a pound is matched to account2 going down a pound.
- kzrdude 5y ago
  (Serious question) Why don't we see money-out-of-nowhere bugs in banks? How do they ensure they don't happen? Even maliciously, for that reason.
  - OJFord 5y ago
    Well we've done the (more direct) question and answer in reverse here really! Balancing is one part of the answer (I think it would be fair to say it doesn't necessarily have to be - or at least not obviously look like - double-entry). You could argue immutable (append-only) records help too - no amendments only additional corrective records. I've never worked in a bank btw so pinch of salt etc., just have a bit of an interest and fiddle on and off with a related project.

derefr 5y ago

In my mental model of a digital financial ledger, it just looks like a table of transfer events, e.g. {timestamp, from_acct=A, to_acct=B, balance_delta=V}. Which, yes, tracks the counterparty balances as well as your own. But it's not double entry per se. Each transfer only has its data in one place; there's no second corresponding entry in the table looking like {timestamp, from_acct=B, to_acct=A, balance_delta=-V}. You don't need that second entry; you can already do everything you need with just the one. (E.g. someone's current balance is the sum of the balance_deltas for which they're the receiver, minus the sum of the balance_deltas for which they're the sender.) Are you suggesting there's a point in having rows in corresponding pairs like this? If so, what is it? (If it's data integrity, IMHO that should be guaranteed at a lower level, with cryptographic checksums et al.)

samatman 5y ago
I'm not sure which of us is confused and it doesn't matter: let us say that there is a confusion about double entry, which I used to have and no longer do. It's exactly having from: and to: in a single entry which makes for double entry accounting. Or one from: and several to: but that's effectively an elision. By implication there is a second double-entry on the other side, but that's often their business, not mine: as an example, the Income statements in my personal ledger are balanced by an Expenses:Payroll on the other side... spiritually, I neither know nor care about the details of how that accounting is done. In the special case that both accounts are internal to the business, then yes, expense on one account becomes asset on the other. Whether that is one or two (double) entries depends on a bunch of things. In terms of specific data modeling, I would urge you that yes, the rows corresponding to any debit or credit should include a 'from' field. The reasons are numerous, and have more to do with audit than data integrity per se. The sufficient reason is that there might not be a counterparty inside your database.
saltminer 5y ago
> Are you suggesting there's a point in having rows in corresponding pairs like this? If so, what is it? If you've ever read a balance sheet (e.g. on a 10k), those things are much easier to compile with double-entry bookkeeping because everything is already neatly categorized. But another thing to think about is that accounting is a very old profession, and when you're totaling everything by hand (or using an abacus, adding machine, etc.), mistakes are easy to make. If you notice your debits not matching your credits, you immediately know you messed something up. Making the same mistake twice (and thus not catching it) is much less likely, so double-entry makes your work more reliable.