Chapter 006: Double-Entry Accounting from the Bank’s Perspective

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

A developer building a payments interface asks: "Why can't I just update the balance? Why do I need to send a debit and a credit?" Double-entry records recognised financial events with equal debit and credit totals, allowing arithmetic equality to be checked. Separate controls establish completeness, correct recognition and measurement. This chapter teaches double-entry the way a bank lives it — postings, journals, trial balance — and introduces the journal entries behind core banking products.

1. Chapter opening

Double-entry bookkeeping records each recognised financial event through journals with equal debits and credits across ledger accounts. Non-posting events, such as opening an unfunded account or reserving funds at card authorisation, do not automatically create a GL journal. Journal balancing supports arithmetic integrity; it does not prove that all events were captured or that recognition, account selection, measurement and period are correct. Reconciliation, source completeness checks and independent review provide that further evidence. This chapter covers the five account types, debit/credit rules, the anatomy of a journal, worked entries for deposits, loans, payments and fees, reversals, and how machines enforce balance at scale.

2. Learning objectives

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

1. State the debit/credit rules for assets, liabilities, equity, income and expenses without hesitation.
2. Write balanced journals for deposit-taking, loan disbursement and repayment, fee collection and interest accrual.
3. Explain what a trial balance proves — and what it cannot prove.
4. Describe how banks reverse and correct entries without breaking the audit trail.
5. Specify what a developer must send (accounts, amounts, dimensions, references) for a posting to succeed.

3. Business context

Financial events create journals when recognition criteria are met: a funded deposit, a loan disbursement or a recognised card transaction. Opening an unfunded savings account is a non-posting master-data event; authorising a card can reserve available funds before clearing creates the accounting entry. Business consequences follow directly: a mis-coded journal misstates product profit, regulatory templates and tax; an unbalanced interface breaks the close; a correction that erases the original or lacks authorisation and a traceable reason destroys evidence; a controlled adjusting journal can be valid without reversal. Finance transformation programmes succeed or fail on posting design — the accounting rules engine (Accounting Rules Engines) encodes exactly the logic taught here.

4. Finance and accounting view

4.1 The five account types and the rules

Memory aid: debits increase assets and expenses; credits increase liabilities, equity and income. Contra-accounts and unusual balances must be interpreted in context. The accounting equation always holds: Assets = Liabilities + Equity, and over a period, profit (income minus expenses) flows into equity.

4.2 Anatomy of a journal

A journal carries: header (journal ID, source system, posting date, value date, period, reference/event ID), lines (account code, debit or credit amount, currency, dimensions such as product/branch/cost centre), and controls (balanced totals, maker-checker status, original-journal link and correction method, including a reversal link where applicable). Automated journals add: rule version that generated them, and the business-event ID for lineage. A journal that does not balance is rejected, never parked half-posted — atomicity is non-negotiable.

4.3 Worked entries for core banking products (fictional currency units)

Deposit of 5,000 cash into a savings account: Dr Cash 5,000 / Cr Customer savings deposit 5,000. (Asset up, liability up.)

Monthly savings interest of 8 accrued: When interest is earned, Dr Interest expense 8 / Cr Accrued deposit interest payable 8. At contractual capitalisation, Dr Accrued interest payable 8 / Cr Customer savings deposit 8. Direct credit to the customer deposit is appropriate when accrual and capitalisation coincide; do not book expense twice.

Loan disbursement of 10,000 to the borrower's current account: Dr Loan asset 10,000 / Cr Customer current account 10,000. (Figure 2 — no P&L effect.)

Monthly loan repayment of 500 (400 principal, 100 interest): Assume the 100 interest was already accrued: Dr Customer current account 500 / Cr Loan principal 400 / Cr Accrued interest receivable 100. If it was not accrued, credit interest income for the earned amount instead; never do both. (Liability down; asset down; collection of already accrued interest leaves income unchanged.)

Card interchange fee of 2 earned: Dr Scheme receivable 2 / Cr Fee income 2. (Asset up, income up; cash arrives at settlement — Card and Merchant Settlement Accounting.)

Day-one expected-loss provision of 60 on a new loan (IFRS 9 preview, Section 9): Dr Impairment charge 60 / Cr Loss allowance (contra-asset) 60. (Expense up; net loan asset down without touching the gross receivable.)

4.4 Reversals and corrections

Banks never delete postings. Correction methods: full reversal (mirror-image journal linked to the original) then repost correctly; or a supported adjusting journal for an error or estimate change. Corrections carry the original reference, a reason code, authorisation, and post in the correct period — a backdated correction to a closed period needs a controlled prior-period process, not a quiet edit (Booking Date, Value Date and Reporting Date and Daily, Monthly and Annual Close). A cancellation reverses any applicable accounting entries if permitted; an instruction cancelled before posting has no GL journal to reverse (Payment Exceptions).

4.5 What the trial balance proves — and doesn't

The trial balance lists every GL account's debit or credit balance; equality of the two columns proves arithmetic integrity (recorded debit and credit balances agree). It does not prove correct account selection (a loan posted as a deposit breaks nothing arithmetically), correct period, correct entity, or completeness of missing events. Hence reconciliations, cut-off controls and substantiation exist alongside it (the accrual/date/close lessons and Balance Sheet Substantiation).

5. Product and customer impact

Customers see balances, not journals — but journal design decides what customers experience: interest posted overnight vs instantly (accrual engine timing), fees appearing with clear narratives (journal description fields feed statements), reversals showing as separate lines rather than vanishing history (evidence for disputes). Chargeback handling, overdraft interest, and early-redemption charges are all journal patterns with customer-communication consequences; product owners should review posting narratives as part of UX.

6. Regulatory and supervisory view

Supervisors assume double-entry discipline and test its operation: journal approval populations, segregation (maker ≠ checker), privileged-posting monitoring, and period-end manual-journal spikes (a classic earnings-management red flag). Prudential returns reconcile to GL trial balances — FINREP validation starts from the same debit/credit integrity (The Regulatory Reporting Landscape). US GAAP vs IFRS differences (for example, netting, impairment timing under CECL vs ECL) change which journals arise, not the double-entry principle itself.

7. Systems and data view

At scale, humans don't write journals — engines do: product processors emit business events; the accounting rules engine maps event + product + attributes → journal template (account codes, dimensions, value-date logic); the GL posts atomically or rejects with a reason code; failures route to an exception queue with replay. Design rules for developers: idempotency keys on event IDs (replayed events must not double-post), govern and version account mappings wherever they are implemented, in a processor or a separate hub, mandatory dimensions validated at entry, and full reversal linkage preserved in data, not just screens.

8. End to end process

Illustrative debit-card issuer model, where scheme purchase and interchange legs are recorded gross: (1) authorisation — memo-post/hold, no GL movement yet; (2) clearing — Dr Scheme receivable / Cr Fee income for interchange, Dr Customer account / Cr Scheme payable for the purchase; (3) settlement — Dr Scheme payable / Cr Cash (nostro), Dr Cash / Cr Scheme receivable; (4) exception path — chargeback entries depend on dispute stage, provisional credit policy and scheme recovery; they do not automatically reverse a settled purchase. Four stages, multiple journals, one event ID chaining them — the lineage auditors and BAs trace.

9. Controls and risks

10. Practical examples

Example A — The missing leg. An interface posts Dr Loan 10,000 but the Cr leg fails validation (closed branch code). Correct behaviour: whole journal rejected, event queued, alert raised, nothing half-posted. Wrong behaviour seen in weak systems: partial post leaves the trial balance out — a severity-1 incident.

Example B — Replay storm. A payment hub retries 2,000 events after an outage. With idempotency keys, 2,000 duplicates are detected and ignored; without them, balances double and customer accounts chaos follows. Testers: replay/duplicate testing is mandatory for every posting interface (Section 20).

11. Diagrams

Figure 1. Debit and credit from the bank view.

Figure 2. Loan disbursed to an internal account.

Figure 3. A balanced illustrative trial balance.

12. Tables

Table 1 — Journal cheat sheet for common events

Table 2 — Contra-accounts beginners meet

13. Illustrative bank case study

The suspense account that hid a fraud. A branch balanced its books daily for months while 2 million leaked — the postings balanced because stolen cash was debited to a vague "clearing" account nobody reconciled. Discovery came only when a new controller aged the suspense ledger. Lessons: balanced books prove arithmetic, not honesty; every suspense and clearing account needs an owner, an ageing limit and daily review (Nostro, Clearing and Suspense Reconciliation); and auditors specifically target round-number, Friday-afternoon and manual journals to vague accounts. (Fictional training case; no specific bank or event is asserted.)

14. BA, developer, tester and operations guidance

• BA: Write expected journals (accounts, debit/credit, amounts, dimensions, dates) into every finance user story; they are clearer than prose and directly testable.
• Developer: Emit event IDs built for idempotency; validate balance, accounts and dimensions before posting; return structured rejection reasons; never auto-correct and repost silently.
• Tester: Build a journal oracle per scenario (happy path, reversal, partial, backdated, multi-currency); tie subledger, GL and trial balance independently.
• Operations: Monitor rejection queues and suspense ageing as frontline controls; a growing queue is tomorrow's misstatement.

15. Common mistakes

1. Debiting deposits when customers deposit (deposits are liabilities — credit them).
2. Booking loan disbursement as income (it's asset-for-liability exchange, P&L zero).
3. Deleting or editing posted journals instead of recording a linked, approved correction.
4. Confusing cash receipt with revenue recognition (accrual timing differs — Accruals, Deferrals and Accounting Periods).
5. Assuming a balanced trial balance means correct accounting.

16. Key takeaways

1. Debits increase assets and expenses; credits increase liabilities, equity and income.
2. Every event posts a balanced journal or nothing posts at all.
3. Core product events (deposit, lend, repay, fee, provision) are small journal patterns you must write fluently.
4. Corrections use linked, approved reversals or adjusting journals while preserving the original postings.
5. The trial balance proves arithmetic equality; reconciliations and controls provide further evidence of completeness and correct accounting.

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.

• Double-entry mechanics underpin IFRS and US GAAP alike; account presentation follows IAS 1 (IFRS) or Reg S-X/ASC 210 (US GAAP) — verify the framework applicable to the entity.

• IFRS 9 ECL preview entries here are simplified; full staging, measurement and write-off mechanics are in Section 9.

• All amounts are fictional training figures; account codes shown are illustrative, not any bank's real chart of accounts.