Banking General Ledger and Subledger Architecture Modernization
Separating the Book of Record From the Detail Behind It
General ledger modernisation programmes usually begin with a complaint about the close and end up somewhere more interesting. The close is slow because reconciliation between product systems and the ledger is manual. Reconciliation is manual because the ledger holds summarised entries whose composition nobody can reconstruct. And the chart of accounts has grown to forty thousand accounts because every time someone needed a new analysis dimension, the answer was another account code.
Those three symptoms have one cause: the general ledger is being asked to be both the book of record and the analytical detail store. Banking general ledger modernization is mostly the work of separating those two jobs and putting a reconciliation between them.
What is the right division between subledger and general ledger?
The subledger holds the detail and the ledger holds the balances, with a guaranteed relationship between them.
| Concern | Subledger | General ledger |
|---|---|---|
| Transaction-level detail | Yes, complete | No |
| Customer and account identity | Yes | No |
| Product attributes | Yes | No, as dimensions at most |
| Balances by account and dimension | Derived | Yes, authoritative |
| Accounting rules application | Yes, at posting | No |
| Multi-basis valuation | Yes, per basis | Balances per basis |
| Audit trail to source event | Yes | Via subledger reference |
| Consolidation and statutory reporting | No | Yes |
Why should the general ledger be thin?
Because a ledger holding transaction detail becomes slow, enormous, and impossible to change.
Every additional attribute pushed into the ledger increases its volume, lengthens the close, complicates the chart of accounts, and makes any future change harder because more consumers depend on the structure. A thin ledger with rich subledgers gives you fast period-end processing, analysis at whatever granularity the subledger holds, and the freedom to change analytical structures without touching the book of record. The discipline is the same one that separates a system of record from a reporting store anywhere else in an estate.
How many accounts does your chart of accounts contain, and what do the extra ones encode?
How should posting work?
Through a posting rules engine driven by business events, with accounting rules held as configuration.
A product system should emit business events, not journal entries. A posting engine then applies accounting rules to those events to produce entries, which keeps the accounting policy in one reviewable place rather than distributed across product codebases. That separation has three practical benefits: finance can change an accounting treatment without a product release, the same event can produce entries under several accounting bases, and the rules are testable independently of the systems that generate the events.
Why do accounting rules belong in configuration?
Because they change for accounting reasons and are owned by finance rather than engineering.
When accounting rules live inside product code, every treatment change becomes a development request in a queue prioritised against product features, and the rule itself becomes invisible to the people accountable for it. Held as configuration with version history, approval, and effective dating, the rule is auditable and the change is a controlled finance activity. Multi-basis reporting also becomes tractable, since the same event can be evaluated by several rule sets, which is exactly what a bank reporting under more than one framework needs, as discussed in this guide to GAAP versus statutory accounting differences.
How do you keep posting deterministic?
By making the rules a pure function of the event and the rule version, with both stored.
Store every posted entry with the event that produced it and the rule version applied, so any balance can be decomposed into its contributing events and any entry can be explained. That reproducibility is what allows a restatement to be executed with confidence, and it removes the recurring situation where a control account holds a balance nobody can attribute. The calculation-side equivalent of this discipline is set out in interest accrual and fee calculation engines.
How should the chart of accounts be designed?
Dimensionally, with dimensions as separate attributes rather than encoded in account codes.
The recurring failure is a chart where the account code concatenates entity, product, cost centre, currency, and sometimes geography, so every new combination requires a new account and the count grows multiplicatively. Model dimensions explicitly instead: a natural account describing what the balance is, plus dimensions for entity, product, business unit, currency, and whatever analysis is required. Then reporting slices by dimension rather than by pattern-matching account codes, and adding an analysis dimension does not multiply the chart.
Why does the encoded approach eventually fail?
Because it is a dimensional model implemented in string concatenation.
A forty-thousand-account chart is not a rich chart, it is a small set of natural accounts crossed with several dimensions, expressed in the only mechanism the original system offered. The costs are real: mapping errors, inconsistent code structures across entities, reports built on substring logic, and a migration problem whenever the structure changes. Where you inherit such a chart, build the dimensional model alongside and map into it rather than attempting a big-bang re-chart, since the historical comparability requirement makes wholesale renumbering painful.
How do you handle multiple accounting bases and currencies?
Through parallel valuation from one event set, not through separate ledgers to reconcile.
Banks commonly report under a primary framework plus local statutory requirements, and sometimes under a regulatory basis as well. Two approaches exist: maintain separate ledgers per basis and reconcile them, or maintain one event set and apply several valuation rule sets to produce parallel balances. The second is materially better, because differences between bases become explainable as rule differences rather than appearing as unexplained breaks between systems. Currency works similarly: hold transaction currency and functional currency, apply translation as a rule with the rate and date recorded, and keep the translation reproducible. The multi-framework reporting problem is described in this guide to accounting standards and reporting requirements.
Do differences between your accounting bases appear as documented rule differences or as reconciliation breaks?
How do you reconcile subledger to general ledger?
Continuously, with automated control totals and a break workflow rather than a period-end exercise.
The reconciliation between subledger detail and ledger balances is the control that makes a thin ledger safe. Run it continuously rather than at period end: compare control totals per account and dimension after every posting cycle, alert on differences immediately, and route breaks to an owner with an ageing target. A difference found on the day it arises usually has an obvious cause, while the same difference found three weeks later during close is a blocker investigated under time pressure with several candidate explanations. Automating this is the single highest-return item in most ledger programmes, and it directly shortens the close, which is the subject of financial close automation.
What granularity should be posted?
Summarised to the ledger, transaction-level in the subledger, with the link guaranteed.
Posting every transaction to the general ledger gives perfect traceability and a ledger too large to close quickly. Posting only summaries gives a fast close and a ledger nobody can explain. The workable answer is summarised posting with a guaranteed reconciliation to transaction-level subledger detail, so any balance can be decomposed on demand without the ledger carrying the volume. Decide the summarisation dimensions deliberately, since they determine what can be analysed without a subledger query, and revisit them when reporting needs change rather than adding accounts.
How does this connect to risk and regulatory reporting?
Through granularity, because risk measurement needs attributes the ledger does not hold.
Regulatory and risk reporting frequently needs detail the general ledger was never designed to carry: repricing dates, behavioural classifications, counterparty attributes, and instrument characteristics. The Basel Committee's standards on interest rate risk in the banking book require economic value of equity and net interest income measures with detailed behavioural assumptions, none of which is derivable from ledger balances alone. So the subledger, not the ledger, is where risk and regulatory reporting should source detail, with the ledger providing the control total that proves completeness. Designing for that from the start avoids the common outcome where three systems produce three versions of the same figure, which is the failure described in reporting the same thing differently.
How do you migrate without losing comparability?
With mapped history, a parallel period, and an explicit position on restatement.
A ledger migration threatens the ability to compare periods, which is the thing finance functions care about most. Map historical balances into the new structure, run both structures in parallel for at least one full reporting cycle including a period end, reconcile at account and dimension level, and decide explicitly whether history will be restated in the new structure or preserved in the old with a bridge. Document the bridge, because analysts will ask about apparent movements caused entirely by structural change. The migration mechanics follow the patterns in core banking data migration, and the comparison discipline in parallel runs and dual-ledger validation.
How should delivery be sequenced?
Dimensional model, then posting rules, then reconciliation, then multi-basis, then migration.
| Phase | Duration | Deliverable |
|---|---|---|
| Dimensional model and chart design | 2 to 3 months | Natural accounts plus dimensions, mapping from the existing chart |
| Posting rules engine | 3 to 5 months | Event-driven posting, rules as versioned configuration |
| Subledger detail store | 3 to 4 months | Transaction-level detail with event lineage |
| Continuous reconciliation | 2 months | Automated control totals, break workflow, ageing |
| Multi-basis valuation | 3 to 4 months | Parallel balances from one event set, documented rule differences |
| Currency translation | 1 to 2 months | Functional currency, recorded rates, reproducible translation |
| Migration and parallel run | 4 to 6 months | Mapped history, full-cycle parallel, documented bridge |
Continuous reconciliation is worth pulling earlier than its position suggests, because it delivers immediate close improvement and it exposes the data problems the rest of the programme will otherwise discover late.
Which metrics matter?
Chart size and growth, reconciliation breaks and ageing, close contribution, posting rule change lead time, and decomposition capability.
Report account count and its growth rate, since a chart that keeps growing indicates dimensions still being encoded. Track subledger to ledger breaks with ageing, targeting same-day resolution. Measure the ledger's contribution to close duration specifically, separating it from other close activities. Report lead time for an accounting rule change, which shows whether rules genuinely live in configuration. And measure decomposition capability, meaning the share of ledger balances that can be decomposed to transaction detail automatically, because that number determines whether the thin ledger is safe or merely opaque.
General ledger modernisation is rarely about the ledger. It is about giving the detail somewhere better to live, moving accounting rules into a place finance can own, and making the reconciliation between them automatic so that a difference is a same-day fix rather than a period-end investigation.
Frequently Asked Questions
What problem does general ledger modernisation solve?
Three related symptoms: a close that takes too long, insufficient granularity for analysis, and a chart of accounts that has grown to encode dimensions it was never meant to hold.
What should the general ledger hold?
Balances by account and dimension for reporting, and nothing else. Transaction-level detail, product attributes, and customer identity belong in subledgers.
Why should the general ledger be thin?
Because a ledger carrying transaction detail becomes large and slow to close, and every consumer that depends on its structure makes future change harder.
Where should accounting rules live?
In a posting rules engine as configuration, not embedded in product system code, so an accounting change is a rule change reviewed by finance rather than a development request.
Why does embedding dimensions in account codes fail?
Because every new analysis dimension multiplies the account count. A chart with fifty thousand accounts is a dimensional model implemented in string concatenation.
How should multi-GAAP be handled?
Through parallel valuation from one event set rather than separate ledgers that must be reconciled, so differences are explainable as valuation rules rather than as breaks.
Why must subledger to GL reconciliation be continuous?
Because a difference found at period end is a close blocker, while the same difference found the day it arises is a routine fix with an obvious cause.
How do you get analytical granularity without exploding the ledger?
Post summarised entries to the general ledger and keep transaction-level detail in the subledger, with a guaranteed reconciliation between them.
