The Ledger That
Forgot Its Name

On double-entry bookkeeping, event sourcing, and the software industry's habit of rediscovering the fifteenth century

By Anonymous

There is a habit, common in the software industry and perhaps endemic to it, of treating as novel what is in fact ancient — of discovering, with considerable fanfare, a principle that has been in continuous practical use for five or six centuries, publishing it under a new name, and then building a small conference ecosystem around the new name without anyone involved pausing to check whether the idea has a prior history. The habit is not unique to software; every field has its enthusiasms, its reinventions, its parallel discoveries that are not, on inspection, parallel discoveries at all. But software does this with a particular vigour, perhaps because its practitioners are overwhelmingly trained as engineers rather than as historians, and the engineering disposition is to solve problems rather than to survey what solutions exist. The result is a literature of considerable sophistication applied to problems whose solutions were settled in Renaissance Venice, and a community that has spent the last two decades debating the fine points of event sourcing and Command Query Responsibility Segregation without, for the most part, noticing that what they are debating is double-entry bookkeeping.

This essay is an attempt to make the identification precise rather than merely impressionistic. The claim is not that CQRS and event sourcing are vaguely similar to double-entry bookkeeping, or that they share a loose family resemblance, or that practitioners might find it illuminating to look at the accounting literature for inspiration. The claim is stronger than that. The claim is that the conceptual structure of event-sourced CQRS systems is the conceptual structure of double-entry bookkeeping, stated in the vocabulary of distributed systems rather than in the vocabulary of accounting, with the names changed and the historical context removed, and that every design principle that the software literature presents as a hard-won discovery of the 2000s and 2010s is present — explicitly stated, precisely formulated, and already battle-tested — in a codified accounting tradition that dates to at least 1494 and probably earlier.

To understand what this means requires being precise about what double-entry bookkeeping is. It is, in the first instance, a method for recording transactions. Every economic event — a sale, a payment, a purchase, the acquisition of an asset, the incurrence of a debt — is recorded not once but twice: as a debit to one or more accounts and as a corresponding credit to one or more other accounts. The total of all debits and the total of all credits must always be equal. This is not a verification step appended to the recording process; it is a structural property of the recording process itself. An entry that does not balance cannot be entered. The system rejects it at the point of insertion, not at the point of audit.

The record of these entries — the journal — is the primary artifact of the bookkeeping system. It is an append-only, chronologically ordered sequence of immutable facts about what happened. Nothing is deleted from the journal. Nothing is amended in place. When a transaction is reversed, the reversal is a new entry, added to the journal, which records the reversal as an event in its own right, with its own date, its own debit and credit, and its own relationship to the original entry. The journal does not store the current state of any account. It stores the history of every change to every account. The current state of any account — its balance — is derived from the journal by summing all the debits and credits that pertain to that account across all entries in the journal's history. The balance is not the ground truth. The journal is the ground truth. The balance is a projection of the journal onto a single number.

From the journal, bookkeepers construct a second set of records: the ledger, which organises the same information by account rather than by date, and from the ledger they construct summary reports — the trial balance, the income statement, the balance sheet — which are projections of the ledger onto successively more aggregated views. Each of these views is derived. None of them is the record. The record is the journal, and the record is never overwritten.

With this structure in mind, consider what CQRS and event sourcing describe, in the vocabulary of software architecture. Event sourcing holds that the system of record for an application's state should be an ordered, append-only log of immutable events — things that happened, stated in the past tense, that cannot be modified after recording. The current state of any entity is not stored directly; it is derived by replaying the relevant events in sequence. When a business process changes some aspect of the world, the system does not update a stored value; it appends an event to the log. To reverse a change, it appends a compensating event. The event log is the ground truth. The derived state is a projection. The projection is useful, but the log is authoritative.¹

CQRS extends this by observing that the processes that change state — commands — and the processes that read state — queries — have sufficiently different structural requirements that they are best handled by separate models. The command side receives instructions, validates them against current state, and, if valid, records events. The query side maintains projections of the event log in whatever shape is convenient for reading — denormalised views, search indexes, aggregated reports — and these projections are rebuilt from the event log whenever they need to be updated or corrected. The event log feeds the projections; the projections do not feed back into the event log. The write model and the read model are structurally separate, with the log as the canonical source that the read model serves.

The correspondence is not approximate. It is exact. The event log is the journal. The command side is the process of making journal entries — events are validated for correctness before being admitted, exactly as double-entry's balancing requirement validates entries before admission. The projections maintained by the query side are the ledger and its derived statements. The CQRS read model that rebuilds itself from the event log is the bookkeeper constructing a balance sheet from the journal. The compensating event that reverses a prior event is the contra-entry that reverses a prior transaction. The principle that a projection can be destroyed and rebuilt from the log without loss of information — a point that event sourcing practitioners emphasise as one of the pattern's distinctive advantages — is the bookkeeper's understanding that the balance sheet can be torn up and reconstructed from the journal at any time, because the journal contains everything and the balance sheet contains only a summary of it.²

The objection most likely to be offered at this point is that the similarity is superficial — that both systems happen to use an append-only log because an append-only log is an obvious choice for recording history, and that the resemblance is a consequence of both systems confronting the same underlying problem rather than evidence that the software literature has reinvented an accounting practice. This objection is weaker than it appears. It would have force if the similarities were limited to the append-only log. They are not. The similarities extend to design decisions that are not forced by the problem structure — decisions that required considerable intellectual effort in the accounting tradition and that the software literature has presented as discoveries.

Consider the treatment of corrections. In a naive system — one designed by someone who has not thought carefully about the requirements of audit and reconstruction — corrections are made by amending the original record. You went back and changed the entry. This is natural from the perspective of someone who cares only about the current state being correct; if the current state is what matters, then fixing the record at source is the most direct approach. The accounting tradition rejected this approach, and rejected it decisively, for reasons that took centuries to fully articulate but that can now be stated clearly: if you amend the original record, you lose the history of what was believed to be true at each point in time, you lose the ability to reconstruct the state of the system as it existed before the correction, and you create a record that cannot be trusted because it has been changed. The event sourcing literature reached the same conclusion, via a different route, and presents it as an architectural insight: events are immutable; corrections are new events; the log is never rewritten. This is not an architectural insight. It is a five-hundred-year-old bookkeeping rule.³

Consider next the treatment of derived state. A common concern raised against event sourcing by practitioners encountering it for the first time is that replaying an entire event log to determine the current state of an entity is computationally expensive for entities with long histories. The solution that the event sourcing literature offers is snapshotting: periodically compute and store the current state, and replay only the events that occurred after the most recent snapshot. This is presented as a technical optimisation, which it is. It is also the balance brought forward — the bookkeeper's practice, as old as double-entry itself, of summarising prior periods into an opening balance and then recording only current-period transactions in detail, so that the current ledger need not contain the full history of the entity since its inception. The balance brought forward is a snapshot. It has been a standard bookkeeping practice since the fifteenth century. The event sourcing literature discovered it around 2010.⁴

The temporal dimension of this reinvention deserves particular attention, because it is the dimension that is most fully developed in the accounting tradition and most incompletely acknowledged in the software literature. Double-entry bookkeeping does not merely record that a state changed; it records when the state changed, by how much, under whose authority, and in relation to which external event. This is not incidental. The date of the journal entry is part of the entry's meaning. The question of which period a transaction belongs to — a question that gives rise to the entire body of accounting standards around accruals, deferrals, and period-end cut-offs — is a question about the relationship between the time of the event in the world and the time of its recording in the journal. These are not always the same, and the accounting tradition has developed precise rules for handling the discrepancy. The event sourcing literature has rediscovered this distinction under the heading of event time versus processing time, and the distributed systems literature has elaborated it under the heading of out-of-order event handling. The accounting practice predates the software discussion by several centuries.

There is also the question of what, precisely, constitutes an event. In both traditions, this turns out to be non-trivial. The accounting tradition distinguishes between economic events — things that happen in the world, such as the delivery of goods — and their recognition — the point at which those events are recorded as affecting the financial statements. The distinction matters because recognition is not automatic; it is governed by rules — realisation principles, matching principles, the conditions under which revenue may be recognised — and these rules are, themselves, a specification of what counts as a valid event for recording purposes. The event sourcing literature has an analogue: the distinction between domain events — things that happened in the business domain — and their validation — the process by which the command handler determines whether a command should result in an event being recorded. The validation logic of the command handler is the recognition principle of the accounting entry. The command that is rejected without producing an event is the transaction that fails to meet recognition criteria. The terms are different; the structure is identical.

It is worth being precise about what is and is not being claimed here, because the strong form of the claim — that CQRS and event sourcing are simply double-entry bookkeeping with different names — can be made to sound dismissive in a way that is not intended. The practitioners who developed and popularised event sourcing and CQRS were solving real problems: the problems of building distributed systems at scale, of maintaining consistency across services, of supporting audit requirements in software systems that had historically been designed without audit in mind. The fact that the accounting tradition had already developed a comprehensive solution to these problems does not mean that the software practitioners were foolish or that their work was without value. The translation of a principle from one domain to another — from the ledger to the message queue, from the trial balance to the eventually consistent read model — requires genuine intellectual work, and the software practitioners did that work carefully and well.

What is being claimed is narrower and, in its way, more interesting than the dismissive reading: that the design principles underlying these patterns are not empirically derived from the experience of building software systems, but are logically necessary consequences of any system that needs to record history reliably and make that history queryable efficiently — and that the accounting tradition reached these consequences centuries earlier, under different pressures and with different tools, and that therefore the software literature has independent confirmation of the pattern's soundness but not independent discovery of the pattern itself. The pattern is not the invention of software engineering. The pattern is the invention of the Venetian merchant class. Software engineering has, at considerable effort, arrived at the same place.⁵

The question of why this reinvention occurred — why the software industry arrived at double-entry bookkeeping from first principles rather than recognising it and borrowing it — is, in some ways, the more interesting question, and it has a straightforward answer that should be slightly uncomfortable for a profession that prides itself on building on prior work. The software industry did not look. The engineering curriculum does not include accounting history. The conference circuit does not include historians of commerce. The canonical texts of software architecture — the books and papers and blog posts that practitioners cite when they explain event sourcing — do not cite Luca Pacioli's Summa de Arithmetica. The tradition that codified double-entry bookkeeping in 1494, that developed the practice through the Florentine banking houses and the Dutch trading companies, that gave the modern world its concepts of the balance sheet and the income statement and the audit trail, is simply not visible from inside the discourse of software design. It is not that practitioners consulted the accounting literature and rejected it. It is that the accounting literature was never consulted.

The consequence is a literature that is right about its conclusions and uninformed about its precedents — that presents as architectural discovery what is, in historical perspective, architectural archaeology. This matters for a reason that goes beyond intellectual credit assignment. The accounting tradition did not stop at the discovery of the journal and the ledger. Over five centuries, it developed a sophisticated body of standards, conventions, and edge-case handling that addresses, in considerable detail, problems that the software literature is currently treating as open questions: how to handle events whose timing is uncertain, how to partition periods cleanly when data arrives late, how to communicate the state of a system to an external reader who was not present for its history, how to structure an audit so that it establishes not just that the numbers are correct but that the process that produced them is sound. These are not easy problems. The accounting profession spent a very long time developing workable answers to them. The software industry is, in many places, reinventing those answers, and the reinvention is slower and less complete than it would be if it were informed by the tradition it is, without knowing it, continuing.⁶

What should follow from this? Not, certainly, a proposal that software architects should study for accountancy qualifications, or that the vocabulary of CQRS should be replaced with the vocabulary of ledgers. Vocabulary matters, and the vocabulary of software architecture is well adapted to its domain. What should follow is something more modest and more practical: an acknowledgement that the design space of event-sourced systems is not virgin territory, that the conceptual foundations have been tested under conditions far more demanding than any software system has so far faced — the conditions of financial accountability, of legal enforceability, of audits whose outcome could result in imprisonment — and that the literature that emerged from those conditions is available and worth reading.

The specific recommendation is simply this: before a software practitioner invests effort in reasoning from first principles about how an event-sourced system should handle temporal uncertainty, or late-arriving events, or the relationship between the log and its projections, or the conditions under which a compensating event is preferable to a reversal — they should spend some time reading about how bookkeepers handle the same problems. Not because the accounting answer is automatically correct for the software context, but because the accounting answer was arrived at through practice under adversarial conditions, and adversarial conditions are a better test of a design principle than conference presentations. The trial balance is not merely an analogue of the eventually consistent read model. It is, in a precise sense, the same thing — and five hundred years of experience with it, both its successes and its failure modes, is available to anyone who cares to look.

The software industry will continue to invent things that turn out to have been invented before. This is the nature of a young discipline, and it is not, in itself, a criticism. But the ledger has been forgotten for long enough. It is time to give the Venetian merchants their due, and to recognise that what we have been calling event sourcing is, at its foundations, the same answer that commerce arrived at when it needed, for the first time, to record what happened rather than merely where it left you.