Chapter 007: The Chart of Accounts

Section 2: Accounting Foundations for Banking · Chapter 007 of 100

A finance transformation consultant asks for the bank's chart of accounts and receives four spreadsheets, all different, none versioned. Six months later the new GL goes live with duplicated codes, postings to summary accounts, and segment reports nobody trusts. Every one of those failures traces to this chapter's subject: the chart of accounts is the DNA of bank accounting, and subledger-to-GL design is where transformations live or die.

1. Chapter opening

The chart of accounts (CoA) is the complete, governed list of ledger accounts with their hierarchy, definitions and posting rules. Subledgers hold contract-level truth (each loan, each deposit); the general ledger holds the summarised, controlled, reportable truth. The accounting hub and posting models connect them. This chapter teaches CoA design, the subledger/GL boundary, the rules engine, and the three posting models — real-time, memo-plus-batch, end-of-day — with the controls each demands.

2. Learning objectives

By the end of this chapter you will be able to:

1. Describe a CoA hierarchy (class → group → account) and the purpose of dimensions.
2. State what belongs in a subledger vs the GL, and who owns each side of the boundary.
3. Explain how an accounting rules engine turns business events into journals.
4. Compare real-time, memo-plus-batch and end-of-day posting models with their control needs.
5. List CoA governance rules: versioning, approval, blocking, and mapping maintenance.
6. Spot classic design failures: summary postings, code duplication, dimension gaps.

3. Business context

CoA decisions outlive systems: account codes persist through core replacements, mergers and regulatory changes, and financial statement balances map back to them; prudential returns and ratios also require risk, contractual and other non-GL attributes. A merger that keeps three CoAs creates years of mapping risk; a CoA without product dimensions makes profitability reporting guesswork; postings to non-postable hierarchy parents compromise account drill-down; controlled aggregation into postable leaf accounts can remain fully auditable. For BAs and developers, the CoA plus the rules inventory is the true functional specification of bank accounting — screens and feeds are just delivery mechanisms.

4. Finance and accounting view

4.1 CoA structure

A typical bank CoA uses classes 1–8 (convention varies by jurisdiction and vendor; verify locally): 1 Assets, 2 Liabilities, 3 Equity, 4 Income, 5 Expenses, 6 Off-balance-sheet/contingent, 7 Regulatory/memo (varies), 8 Intercompany or statistical. Within each class: groups (for example 11 Loans, 12 Treasury assets), then leaf accounts (110010 Mortgages–principal, 110011 Mortgages–accrued interest, 110019 Mortgages–ECL allowance). In this example hierarchy, posting is allowed only to designated postable leaves; summaries aggregate upward for statements. Account classes and hierarchy design are conventions, not a universal banking requirement. Dimensions attach at posting time and drive segment reporting, FTP and regulatory splits (resident/non-resident, maturity bands).

4.2 Subledgers and the GL: the boundary contract

The boundary contract: every GL balance for a subledgered account must tie to its subledger total (daily auto-match, timing, currency and valuation differences explicitly bridged; matching tolerances and escalation depend on approved policy, not write-off permission). Breaks age, escalate and block close sign-off — never auto-plug.

4.3 The accounting rules engine

The engine's mapping table answers, per event type × product × attributes: which journal template fires, which leaf accounts debit/credit, which dimensions derive from where, which value-date rule applies, which reversals pair with it, and which rule version was used (rules themselves are effective-dated — each event records the effective rule version; changes apply prospectively or to legacy contracts under approved policy, not necessarily the origination version for life). Rule changes follow SDLC: requirement, Finance sign-off, build, regression against historical events (parallel replay proving the new rule changes only intended journals), approval, release.

4.4 Posting models

Real-time GL posting: low posting latency where the architecture supports it, but close design must handle 24/7 posting across period boundaries and strict idempotency. Memo-plus-batch (cards, cheques, bulk): memo entries reserve funds intraday; GL batch posts later; the memo-clearing control proves nothing lingers. End-of-day aggregates (accruals, ECL, valuations, FTP, allocations): efficient bulk, but intraday blindness needs flash estimates for trading and liquidity. Most banks run all three simultaneously — per product, per event type — and cut-off rules (Booking Date, Value Date and Reporting Date) decide which calendar day each posting claims.

5. Product and customer impact

Posting models shape customer experience directly: real-time postings power instant balance updates and push notifications; memo holds explain "pending" transactions; batch windows explain why pending card transactions may settle later according to scheme, acquirer and issuer processing calendars. Dimension design shapes statements and app analytics (spending categories derive from posting dimensions). Failed post-to-GL with successful customer update — or vice versa — is the nightmare split-brain scenario; design must make customer-facing and ledger updates atomic or explicitly reconciled.

6. Regulatory and supervisory view

Supervisors examine CoA governance (change control, dormant-code blocking, post-to-summary prevention), subledger-to-GL reconciliation effectiveness (aged breaks are findings), and rules-engine validation (model-risk treatment where engines compute ECL/valuations — Section 11). FINREP/COREP mappings sit on top of the CoA; every mapping change needs version control and parallel-run proof because it moves reported cells. External auditors walk from CoA through rules to journals as their core walkthrough.

7. Systems and data view

Reference architecture: product processors → event bus (immutable, replayable) → accounting hub (rules engine + journal factory + validation) → GL (period-controlled, immutable when posted) → finance mart (snapshots for reporting) → returns engines. Interfaces carry event IDs, rule versions and full dimension sets; the hub rejects (never half-posts) invalid journals to an exception queue with reason codes and replay. Master data (CoA, dimensions, mappings) is effective-dated and environment-promoted like code. Data lineage (Section 20) is simply this chain made queryable: report cell → mart snapshot → journal → rule version → event → source contract.

8. End to end process

Onboarding a new product's accounting: (1) Finance defines required leaf accounts/dimensions and extends the CoA through change board; (2) BA documents events and expected journals (Double-Entry Accounting from the Bank’s Perspective patterns + product specifics); (3) engine team builds and versions rules; (4) testers replay historical lookalike events plus edge cases (amendments, reversals, holidays, multi-currency); (5) parallel run against expected journals with zero unexplained differences; (6) go-live with hypercare reconciliation watch; (7) mapping extended to FINREP/COREP with QA; (8) ownership and RACI registered (Who Owns the Numbers?). Skipping step 5 is how transformations produce restatements.

9. Controls and risks

10. Practical examples

Example A — The unallocated swamp. Fee postings arrive without product dimension for six weeks after a release. "Unallocated fee income" grows to 3 million; segment reports understate cards profit; FINREP mapping guesses. Fix: hub rejects dimension-less journals from day one (fail to exceptions, loudly), and release checklists include dimension verification.

Example B — Merger mapping. Two banks merge with different mortgage codes. Mapping table 1:1 looks clean until auditors find forbearance flags live in different attributes — mapped balances agree, but asset-quality splits mislead for a year. Lesson: map attributes and flags, not just balances; reconcile distributions, not only totals.

11. Diagrams

Figure 1. Chart of accounts and dimensions.

Figure 2. Subledgers, rules and GL reconciliation.

Figure 3. Three posting models and their controls.

12. Tables

Table 1 — Subledger inventory for a typical bank

Table 2 — CoA change request checklist

13. Illustrative bank case study

The transformation that posted to summaries. A bank's new GL went live with summary accounts left postable "temporarily" to hit the date. Within two quarters, 12% of expenses sat at summary level — drill-down dead, product profitability approximate, auditors qualifying reconciliations. Remediation took longer than the original delay would have: leaf-code rebuild, journal re-sourcing, restated comparatives. Lesson: temporary accounting compromises at go-live become permanent data damage; block summary postings from day one. (Fictional training case; no specific bank or event is asserted.)

14. BA, developer, tester and operations guidance

• BA: Demand the CoA extract, rules inventory and dimension catalogue before writing finance requirements; specify expected journals per event including dimensions and dates.
• Developer: Read CoA and rules as versioned reference data, never literals; validate leaf-only posting and mandatory dimensions in the hub; expose rule version on every journal.
• Tester: Test code blocking (summary/dormant codes rejected), dimension-missing rejection, rule-version effective dating, and subledger–GL tie-out with seeded breaks.
• Operations: Own the daily tie-outs and exception queues; trend unallocated buckets and break ageing — both predict close failure weeks ahead.

15. Common mistakes

1. Letting postings hit summary accounts "just this once."
2. Creating duplicate codes instead of reusing governed ones.
3. Shipping interfaces without mandatory dimensions.
4. Changing rules without versioning or parallel replay.
5. Reconciling totals while ignoring distribution shifts (Example B).

16. Key takeaways

1. The CoA is governed master data: hierarchy, leaves-only posting, dimensions, versioning.
2. Subledgers hold contract truth; the GL holds reported truth; daily tie-out proves they agree.
3. The rules engine centralises event-to-journal logic with versions and regression proof.
4. Real-time, memo-batch and end-of-day models coexist — each with its control price.
5. Transformations fail at the boundary: map attributes, prove with parallel runs, register owners.

17. References and verification notes

• IFRS Foundation: IFRS 9: classification depends on business model and contractual cash flows; initial recognition and directly attributable costs follow IFRS 9. This is the IFRS track, not US GAAP CECL.

• CoA class numbering and memo/contingent treatment vary by jurisdiction, vendor and national GAAP adaptations — confirm against the bank's accounting manual and local framework before implementation.

• Subledger–GL reconciliation expectations reference supervisory reporting-control guidance (EBA/PRA/Fed/RBI as applicable) and ISA 500-level audit evidence concepts; verify the current applicable sources.

• Account codes and amounts are illustrative training fictions.