Most ERP systems treat the general ledger as a destination — a place where transactions land after traveling through other systems. What happens when you reverse that? When the ledger is the starting point, the rule-setter, the thing every financial event must pass through before it exists? The answer changes what financial software can actually guarantee.
The general ledger is supposed to be the authoritative record of every financial event in a company’s history. In most ERP systems, it is — in the same way that a courthouse is the official record of legal proceedings, while the actual proceedings happen somewhere else first. The events happen in other systems. They travel to the ledger afterward. The ledger records what was sent to it.
This architecture has been the standard for decades, and it works reasonably well when the systems sending transactions to the ledger are reliable, the integrations are clean, and the people managing the process are careful. When those conditions hold, the ledger is accurate. When they don’t — when a sync fails, when an exception slips through, when someone makes an adjustment in the wrong place — the ledger records something other than the truth, and the discrepancy exists until someone finds it.
The destination model
In a destination-ledger model, the AR module maintains its own records. So does the billing system. So does the AP module. Periodically — sometimes in real time, sometimes in batches — these systems post summarized entries to the GL. The GL receives what it’s sent. It doesn’t validate whether what it’s receiving reflects the underlying transactions accurately. It doesn’t know what it’s missing. It records what arrives.
This is why reconciliation exists. The AR subledger and the GL may both contain records of the same transactions, maintained separately, posted through different mechanisms. If they disagree, the reconciliation process is how you find out — and the investigation to determine which one is right can be genuinely difficult when the discrepancy is old.
The destination model makes the GL a downstream artifact. It’s the most important downstream artifact, but it’s still downstream. The financial truth lives in the source systems, and the GL reflects it to the degree that the posting process has worked correctly.
The constitutional model
A constitutional ledger is the reverse: the source of truth rather than the destination for it. Every financial event — every invoice, every payment, every accrual, every adjustment — must pass through the ledger before it exists as a recorded fact. The ledger doesn’t receive transactions; it governs them. Business rules are enforced at the point of entry, before the data persists anywhere.
This has a specific technical consequence: there’s no separate reconciliation process, because there’s no separate source. The AR balance isn’t a subledger that gets reconciled to the GL; it’s a view of the transactions in the GL that happen to affect AR accounts. The billing system isn’t a separate database that syncs to the ledger; it posts directly to the ledger, validated against the same rules that govern every other transaction.
The mathematical consequence is that reconciliation variance between the subledger and the GL is not a risk to be managed — it’s architecturally impossible. Not unlikely. Not well-controlled. Impossible. There is no subledger to disagree with the GL, because the subledger is the GL, filtered.
What this changes in practice
The practical difference becomes most visible at month-end. In a destination-ledger system, close involves reconciling the subledgers to the GL, posting any differences as adjustments, verifying that all batch jobs have run, and confirming that the final balances agree. In a constitutional-ledger system, close involves confirming that the transactions already in the ledger are complete and appropriately cut off. The reconciliation step doesn’t exist because the discrepancy can’t exist.
It also changes the audit trail. When every transaction is required to pass through the ledger at the moment of creation, the ledger contains a complete and continuous record of every financial event in order. There are no gaps created by failed posting jobs. There are no adjustments made “outside the system” that need to be explained later. The ledger is the story of what happened, not a summary of what was reported to it.
The engineering decision
This isn’t a product philosophy abstraction. It’s an engineering decision made at the database layer, before any application code runs. It requires designing the financial schema so that the ledger is the foundation and everything else is built on top — not alongside. It requires implementing validation at the layer that can’t be bypassed: not the UI, not the API, but the database itself.
That’s a harder path at the beginning. It constrains the architecture in ways that are sometimes inconvenient. It also produces a system that can make guarantees that a destination-ledger architecture structurally cannot.