3 ms·

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

by 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.
- derefr 5y ago
  Yes, I understand the point of the physical equivalent. I was asking specifically if there was a specific point in doing "double-entry bookkeeping" digitally, in the sense of having two transfer-event rows to represent each transaction in your database, rather than one. (Which is something that people do do — I've seen it in some ledger data-models — but it's always felt redundant to me.) My understanding aligns with the GP's sibling comment: in a digital ledger, having one {txid, sender, recipient, value} row for each transfer of value, is strictly equivalent to having two separate complementary {txid, party, value_delta} rows.

by derefr 5y ago

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.

derefr 5y ago
Yes, I understand the point of the physical equivalent. I was asking specifically if there was a specific point in doing "double-entry bookkeeping" digitally, in the sense of having two transfer-event rows to represent each transaction in your database, rather than one. (Which is something that people do do — I've seen it in some ledger data-models — but it's always felt redundant to me.) My understanding aligns with the GP's sibling comment: in a digital ledger, having one {txid, sender, recipient, value} row for each transfer of value, is strictly equivalent to having two separate complementary {txid, party, value_delta} rows.