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