How Event Sourcing Supports a General Ledger

Event sourcing is often described as an architecture pattern: store what happened, in order, then derive the current state from that history. For a general ledger, its value is more concrete. It makes the history behind a balance part of the primary record.

How the model works

A LedgerWriter account records a sequence of events: an account opening, a journal entry posting, and a reversal. It calculates the balance from them. Developers often call that calculated view a projection.

The event store is append-only. The system adds each event to the history.

Commands produce new events, and each command is checked before storage. For example, the command to post a journal entry verifies that debits equal credits. The ledger rejects an unbalanced entry before posting it.

Why this matters beyond architecture

This model produces three useful properties:

1. The audit trail is the primary data. The event stream is the record from which the current view is built.

2. Corrections stay visible. Fixing a mistake creates a new, timestamped, attributed reversal. The original entry and its correction remain connected in the history.

3. History is built into the write path. The system preserves prior ledger activity by adding events to the record.

Where LedgerWriter draws the boundary

Event sourcing governs LedgerWriter’s core ledger domain, where the history has lasting financial value. Authentication and identity use a simpler model for current access.

That boundary keeps the ledger history focused on the activity that carries lasting financial value. See the architecture breakdown on the developers page for more detail.