What is banking general ledger testing?

Banking general ledger testing verifies that financial events from banking products and services are recorded in the correct general ledger accounts, for the correct amounts and accounting dates, and in line with the bank's posting rules. It checks that entries balance, remain traceable to their source transactions and reconcile with relevant subledgers and control totals.

What banking general ledger testing covers

A general ledger (GL) holds the bank's accounting entries, organised by accounts and often by dimensions such as legal entity, branch, product, currency or cost centre. Testing checks the rules that translate business events into accounting entries, as well as the processing that stores and reports those entries.

A typical scope includes:

• Posting rules: whether each event maps to the required debit and credit accounts, including fees, interest, reversals and suspense handling.
• Amounts and precision: whether amounts, currency conversions and rounding follow configured rules.
• Accounting dates: whether transaction date, value date and posting date affect accounting periods as specified, including for backdated events.
• Completeness and uniqueness: whether expected entries are present and duplicate postings are prevented.
• Data integrity and traceability: whether entries retain the correct source reference and accounting attributes through interfaces, batches and reports.
• Reconciliation: whether GL totals agree with the relevant product subledger, source system or control totals.

The GL is distinct from a product subledger. A deposit subledger, for example, may hold customer-level account activity, while the GL records summarised or mapped accounting entries. A reconciliation checks the relationship between them; it does not, by itself, prove that each entry used the correct account or accounting treatment.

How to test posting behaviour

Start with approved accounting rules, a chart of accounts, expected posting mappings and defined date and currency behaviour. These are preconditions for reliable expected results. Test data should represent the products, currencies, account statuses and event types in scope, with suitable opening balances and reference data.

For each scenario, trace an event from its source through posting to the GL and any reconciliation output. Assert the debit and credit accounts, amount, currency, accounting dimensions, dates, source identifier and posting status. Where processing is asynchronous or batch-based, verify both the final result and the handling of retries, rejects and partial failures.

A balanced journal is necessary, but it is not sufficient. Incorrect accounts can still produce a balanced journal. Likewise, a matching end-of-day total can conceal a missing entry offset by an incorrect or duplicated one. Use transaction-level assertions alongside aggregate control totals and reconciliation checks.

Practical example: a deposit fee

Assume an approved rule says a £5 monthly account fee is recognised as fee income and reduces the customer's deposit liability. For a test account with sufficient funds, trigger the fee event and verify that the GL receives a £5 debit to the deposit liability account and a £5 credit to the fee income account, with the expected currency, posting date and source transaction reference.

Then check that the customer subledger reflects the £5 reduction and that its control total reconciles to the relevant GL balance. Submit the same event again if the interface supports retries. The system should follow its duplicate-handling rule, such as rejecting the repeat or treating it idempotently, without creating an unintended second fee. The expected outcome depends on the bank's specified posting and retry rules.

Failure modes and investigation

Common defects include missing or duplicate journals, incorrect account mappings, wrong accounting dates, signs reversed, rounding differences, lost source references and entries posted to suspense accounts without the expected exception handling. Reconciliation breaks can also arise from timing differences, failed interface messages, stale reference data or configuration drift between test and production-like environments.

When a check fails, compare the source event, transformation or posting rule, GL entry and reconciliation extract. Confirm that the test used the intended configuration and period, and distinguish a genuine accounting defect from an incomplete batch or expected timing difference. Preserve the inputs, system state, journal identifiers and assertion results so the failure can be reproduced.