What is general ledger and subledger reconciliation testing?

General ledger and subledger reconciliation testing verifies that accounting entries and balances recorded in a detailed subledger agree with the corresponding control accounts and balances in the general ledger. It checks that transactions transfer completely, accurately and in the correct accounting period, and that differences can be identified and investigated using traceable evidence.

What the reconciliation checks

A subledger records detailed activity for an accounting area, such as customer receivables, loans, deposits or fixed assets. The general ledger (GL) holds accounts used to produce the organisation's overall financial records. A control account in the GL represents the total for a related subledger population.

Testing compares the two records at the level defined by the accounting design. That may mean comparing individual postings, batch totals, period-end balances or a combination. The expected relationship must be clear: which subledger accounts map to which GL accounts, how debit and credit signs are represented, and which dates and currencies apply.

Reconciliation testing also checks the path between systems. A transaction may pass through a source application, an interface or posting service, and a ledger. Failures can arise from omitted or duplicated messages, incorrect account mappings, rounding, timing differences, rejected postings or inconsistent treatment of reversals.

How to test it

Agree the reconciliation rules before preparing test data. Confirm the control-account mapping, posting status, accounting date, currency and reconciliation cut-off. Ensure the test environment contains the required configuration and that opening balances are known. If the process is asynchronous or batch-based, define when processing is complete and how late or rejected entries are handled.

Create data that exercises normal and failure paths. Include valid postings, multiple transactions in a batch, a reversal, a duplicate or retry, an invalid mapping and a transaction with an accounting date near the period boundary. Check the source transaction, subledger entry, interface or batch record, GL journal and reconciliation output. Where the application supports exception handling, verify that a mismatch is reported with enough detail to trace its cause and that correction or rerun follows the intended controls.

Compare values using the system's documented sign, precision and rounding rules. An unexplained tolerance can conceal real defects. Any permitted difference should have an explicit accounting basis, such as a defined rounding method, and should be tested at its boundary.

Practical example

Suppose a receivables subledger posts three invoices of £120, £80 and £50 to one control account. The expected subledger total is £250, and the corresponding GL control-account balance should reflect the same £250 receivable under the system's debit and credit conventions.

A test can verify that all three invoices appear once in the subledger, their postings map to the intended control account, and the GL journal total agrees after the batch completes. Then suppress one interface message in a controlled test, or use a supported rejection path. The reconciliation should show a £50 difference, identify the affected posting or batch, and avoid presenting the incomplete result as reconciled. After the missing entry is processed, rerun the reconciliation and verify that the difference clears without duplicating any posting.

Interpreting results

A matching total alone does not prove that every transaction is correct. An omitted debit and an unrelated duplicate credit could offset each other. Where transaction-level data is available, test both aggregate totals and the underlying posting population. Check counts, identifiers, account mappings, dates and status as well as amounts.

A successful outcome means the comparison follows the agreed accounting rules, all expected postings are accounted for, and any permitted differences or exceptions are visible and traceable. Keep evidence of the input population, reconciliation parameters, output, exceptions and any rerun so that failures can be reproduced and investigated.