Skip to content

Architecture

A sub-ledger records financial movements at a finer grain than the general ledger, and rolls up into it. You need one as soon as a single general-ledger account has to answer questions about individual customers. Which for any institution holding client money is immediately. The GL knows the institution owes ten million pounds to customers; the sub-ledger knows which customers, and that distinction is the entire product.

The general ledger exists for financial reporting: it is the institution's own books, structured for accounts, auditors and regulators looking at the entity. It is deliberately coarse. Putting a million customer balances into GL accounts makes the GL unusable for its actual purpose and still does not give you the per-customer behaviour a banking product needs.

The sub-ledger holds the per-customer, per-account, per-instrument detail and reconciles to a small number of GL control accounts. The reconciliation between them is not a report you produce. It is a continuous invariant, and the moment the sub-ledger total stops matching its control account you have a defect, not a discrepancy to investigate at month end.

Multi-entity and multi-currency operations are where the structure earns itself. A bank operating through several legal entities needs postings attributable to the right entity for reporting while remaining a single coherent view for the customer, and that is only tractable if the two layers are separate concerns, not one flattened schema.

The failure mode is discovering you need one after launch. Retrofitting a sub-ledger means reconstructing per-customer history from a GL that never held it, and the answer is usually that it cannot be reconstructed. Only approximated, which is not something you can put in front of an auditor.

Bring us the hard part.

Forty-five minutes with the people who would actually run the build.