Why a Carried-Forward Balance Is Not Evidence: The Model for Journal Entries in Financial Systems

When an account balance appears incorrect—R$ 1,200 too much in one account and R$ 800 too little in another—the most basic question any auditor asks is: where did it come from? The answer depends entirely on the data architecture. Systems that store balances on a per-line basis do not record the origin of each discrepancy as structured data, so the path that led to that number is not available for review. Transaction-based systems record each entry with its source, timestamp, and linked account, and the balance is always derived from these records.

The Principle

Every financial transaction has two sides: an amount leaves one place and enters another, with debits and credits in constant balance. Double-entry bookkeeping is a mathematical principle that has been in continuous use for about 500 years: the sum of debits equals the sum of credits in any correct transaction.

What makes this model robust in software is atomicity. A transaction is either applied in its entirety or not at all: all the entries that make up the transaction persist together, or none of them persist. There is no intermediate state where a debit has occurred but the corresponding credit has not. This guarantee is what prevents value from disappearing or appearing out of nowhere in the event of a system failure.

Entries as Events

The transaction model is, in practice, an immutable event log. Each entry records what happened, in which account, at what point in time, and as part of which transaction. The balance is not a separately stored number: it is a projection calculated from these events. This distinction has an important operational consequence: the complete state of the ledger can be reconstructed from scratch at any time by reprocessing the events in the order in which they occurred. Auditing, historical reconstruction, and debugging discrepancies all become queries against the same log that powers the operation.

Consistency

In financial systems, eventual consistency is not an option. A balance must be correct at the time of the query, and any read operation that returns an outdated state creates concrete operational risk: authorization of a payment based on an incorrect balance, discrepancies between a statement and the actual position, or inconsistencies between systems that access the same ledger. A ledger based on atomic postings guarantees strong consistency: once a transaction is confirmed, all the postings that comprise it are visible, and the balance reflects the actual state, with no windows of inconsistency.

What Most Systems Do

Most financial systems track balances by updating a single number per line for each transaction. This approach works well under normal conditions but begins to cause problems when the system needs to be investigated, audited, or reconstructed.

When the balance is incorrect, there is no evidence of how it got there. The transaction history, when it exists, becomes a separate log with no formal link to the actual balance, which turns reconciliation into manual work, forces retroactive reconstruction before each audit, and adds the risk of inconsistency to any reversal. The structural weakness of this model only becomes apparent when the system needs to be thoroughly investigated, and by that point, the cost of lacking traceability has already accumulated.

What a Proper Ledger Must Have

A double-entry ledger has certain non-negotiable properties, and these properties reinforce one another.

• Atomicity: Each transaction either persists in its entirety or does not persist at all, with no visible intermediate states.
• Immutability: no entry is deleted or edited; errors are corrected with new entries, maintaining a complete and verifiable history.
• Traceability by operation: each transaction generates linked entries, with debits and credits recorded as a pair.
• Account hierarchy: Accounts are organized in a tree structure, and the balance of any node is derived from the entries in its child nodes.
• Multi-asset: A transaction can involve more than one asset without workarounds in the modeling.

With these properties, any balance can be derived from the journal entries, auditing is deterministic, and reversals are predictable operations.

The consequences of not doing this

A financial institution with a balance-based architecture faces the same problems, in order: occasional inconsistencies that do not balance, manual reconciliation that scales with volume, retroactive restatement before each audit, and difficulty answering simple questions such as what the balance of an account was on the 15th, at 2:23 p.m.

In regulated environments, the lack of traceability constitutes an operational risk: Bacen, external auditors, and custodial partners will request evidence of the origin of balances, and a number stored per line—without the transaction history that comprises it—does not meet this requirement.

What Lerian Built

Lerian’s core banking system has implemented double-entry bookkeeping from the outset as its fundamental data model. Each transaction generates linked entries; every balance is calculated from the journal entries; the history is immutable by design; and the account hierarchy is natively supported. Transactions are atomic by design, and the event model ensures that any historical state of the ledger can be reconstructed from the transaction records themselves.

The code is open source, which means that any engineer can audit the model, verify how the journal entries work, and confirm that the ledger’s properties are maintained in production. In regulated financial infrastructure, auditability is a requirement.

Read the documentation or view the code on GitHub.