> I think programmers find double-entry bookkeeping counterintuitive. It feels error-prone. In programming, you keep a single source of truth. Any time you copy the same data to two different places, one of them is always wrong.
Double-entry bookkeeping is creating of an audit-trail/error-evident data store; which is the purpose of the apparent duplication. But it can be viewed as a view of dataset reflecting a single source of truth, that documents value flows; every movement of value has a source and a sink, and the amount that moves from the source must equal the amount that moves to the sink. Losing the redundancy that allows error-checking of records, you could view each accounting transaction as a triple of (source, sink, amount).
I think if a programmer were designing accounting, they'd put the flows in the database, and build views out of that. They might materialize the views for performance reasons, but they'd treat those views as suspect and the first response to any bug would be "blow away the accounts and recreate them".
You couldn't do bookkeping with actual books that way, and historically this way makes sense. Nor is it likely that the accountants are going to rethink their field from the ground up for the convenience of programmers.
> I think if a programmer were designing accounting, they'd put the flows in the database, and build views out of that. They might materialize the views for performance reasons, but they'd treat those views as suspect and the first response to any bug would be "blow away the accounts and recreate them".
That is actually how it works, if you don't have "flows" you don't have accounting postings and if you have to fix an error you redo the postings from the flows. In this sense I would say that the "flows" are the source of truth.
Right. The only actual raw data is transactions. Account balances are just filtered rollups. Double entry bookkeeping is just how you manually accumulate a set of account balances from transaction data, and a set of conventions for consistently labeling and grouping the transaction sources and destinations.
I mean, this is kind of how accounting does work. To a basic approximation a reconciliation is a line by line review of each of the flows, and an audit is "blow away the accounts and recreate them" and both happen all the time.
Double-entry bookkeeping is creating of an audit-trail/error-evident data store; which is the purpose of the apparent duplication. But it can be viewed as a view of dataset reflecting a single source of truth, that documents value flows; every movement of value has a source and a sink, and the amount that moves from the source must equal the amount that moves to the sink. Losing the redundancy that allows error-checking of records, you could view each accounting transaction as a triple of (source, sink, amount).