In traditional ERP, accounts receivable maintains its own truth. So does accounts payable, fixed assets, and inventory. Reconciling them to the general ledger is a scheduled ritual every finance team knows well. There’s a different model: subledgers that don’t maintain their own truth because they’re derived from the same source as the GL itself.
The subledger is one of accounting’s oldest concepts. The general ledger records aggregate balances by account. The subledger keeps the detailed transactions that make up those balances — the individual invoices behind the AR balance, the individual bills behind the AP balance, the individual assets behind the fixed asset balance. Post accurately from the subledger to the GL, and they agree. Fail to post completely or correctly, and they don’t.
That relationship — subledger as detail, GL as summary, posting as the mechanism that connects them — is the source of one of the most persistent problems in financial operations. It’s also a design choice, not a law of nature.
The traditional architecture and its failure mode
In most ERP systems, the AR module and the GL are separate components. The AR module maintains a running record of open invoices, partial payments, credit memos, and outstanding balances by customer. The GL maintains account-level balances. When AR events occur — an invoice is issued, a payment is received — the AR module records the detail and generates a posting entry to the GL. The posting is the mechanism of synchronization.
When everything works, the AR subledger balance equals the AR account balance in the GL. When postings fail, run in batches that haven’t completed yet, or contain errors, they don’t. The gap between the subledger and the GL is exactly the kind of discrepancy that reconciliation processes are designed to catch — and that close processes are designed to resolve before the books can be locked.
This is a well-understood problem with well-understood solutions. The solutions exist because the architecture requires them.
Views instead of sources
A different architectural choice: the subledger is not a separate data store that posts to the GL. It’s a filtered view of the GL itself, scoped to the transactions that affect specific accounts or business objects.
In this model, when an invoice is created, one thing happens: a set of validated journal entries posts to the universal ledger. Those entries carry metadata — customer ID, invoice number, due date, line-item detail — that makes them queryable in any way the application needs. The AR “subledger” is a query against those entries filtered to AR accounts, grouped by customer, sorted by due date. It’s not a separate record. It’s the same record viewed through a different lens.
The consequences are straightforward. If you query the AR subledger and the AR account in the GL, they will always agree — not because they’ve been reconciled, but because they’re the same data. You cannot have an AR subledger balance that doesn’t match the GL because there is no AR subledger balance. There’s one balance, and the subledger view and the GL view are both reading it from the same source.
The technical requirements
This architecture requires that the journal entry be the atomic unit of every financial transaction. You can’t create an invoice without posting a journal entry. You can’t receive a payment without posting a journal entry. The business event and the ledger event are the same event, happening at the same time, governed by the same validation.
This is harder to build than the traditional model. It requires a very clean separation between the ledger (where the financial truth lives) and the application modules (where the business processes live), with strict rules about which direction data can flow. The modules drive journal entries to the ledger. They never write directly to account balances. The ledger is the source and the modules read from it.
The practical benefit is that every view of the financial data — the AR aging report, the AP dashboard, the GL trial balance, the income statement, the consolidation — is drawing from the same underlying records. They can’t disagree, because they have no independent state to disagree with.
What finance teams actually experience
For a controller or CFO, the most tangible effect of this architecture is the disappearance of a class of problems. Month-end no longer includes reconciling AR to the GL. It can’t be out of balance because balance is a property of the system, not a result of a process. The question “why doesn’t the subledger tie?” goes away because the question stops having a valid premise.
The close process becomes shorter not because you’ve automated reconciliation, but because there’s nothing to reconcile. The audit evidence is simpler not because the documentation is better, but because the trail is unbroken from business event to ledger entry to financial statement.