← Back to context

Comment by jes5199

1 year ago

what you’ve sketched out already looks like a double-entry bookkeeping system, if you have the constraint that all of the deltas in your array on your transaction sum to zero (so money always _moves_ and is not created or destroyed)

calling it “double” might be misleading - in the ledger systems I’ve worked on, a transaction that has only two entries - a single source and a single destination - is actually rare. In practice, a payment tends to have a source, the intended destination, a secondary destination for platform fees, possibly another destination for taxes.

And much more complicated situations are possible - I currently work in medical billing where there are multiple virtual internal accounts involved in each transaction for different kinds of revenue (including, for example, money we billed for but don’t expect will actually get paid)

so a transaction becomes a bundle of a set of several debits or credits that happen simultaneously and sum to zero. if you have that, you have double-entry bookkeeping, even if you schema puts it all in one table

Ahh thanks so much, that clears it up for me! Every description of double entry I'd seen so far seemed to have the notion of keeping a running balance for each account (and then having a separate transaction for each one where they all sum to zero) as a central feature, so I thought avoiding that would make it no longer double-entry, and it always puzzled me why that was so crucial. Your comment made me see that wasn't actually the point!