Skip to content

Money movement and financial logic

Ledger and reconciliation testing

Ledger and reconciliation testing checks that a fintech ledger records every money movement once, in balanced debit and credit entries, and that ledger balances match partner bank statements, processor settlement files, and card scheme reports. FintechAssuranceLabs delivers a double-entry invariant test suite, reconciliation test scenarios, a balance drift and rounding report, and audit trail completeness checks.

What ledger and reconciliation testing covers

Double-entry invariants

Each rule gets automated tests over generated captures, refunds, reversals, and retries:

  • Every journal balances. Debits equal credits per journal and per currency, so a journal that nets to zero only after FX conversion fails.
  • Posted entries do not change. A correction posts a reversing entry, and an update or delete of a posted row through the API, an admin tool, or a migration fails.
  • A balance equals the sum of its postings. A crash between the posting insert and the running balance update leaves them out of step, so tests stop the process between both writes.
  • One event posts once. A retried webhook or replayed message with the same event ID produces no second journal.

Bank statement reconciliation: camt.053 and BAI2

An ISO 20022 camt.053 statement reports an opening booked balance (OPBD), booked entries, and a closing booked balance (CLBD). The SIX camt.053 guideline (version 1.0, 28 February 2022) makes OPBD with CLBD mandatory, sends only booked (BOOK) entries in camt.053, and allows pending (PDNG) entries in camt.052 and camt.054. Tests check:

  • OPBD plus booked entries equals CLBD, and so does the ledger balance for that account and business date;
  • a pending camt.054 entry posts neither as final nor again when camt.053 books it;
  • a CRDT entry with the reversal indicator true, which that guideline defines as reversing an original debit, does not post as a new credit.

A BAI2 file wraps each account between an 03 identifier record and a 49 trailer. The 49 record carries the signed algebraic sum of all amounts in the account's records, and the 98 group and 99 file trailers sum the totals below them (Westpac BankRec BAI2 documentation). Tests send a wrong control total, a truncated 88 continuation record, and an 03 record without type code 015 (closing balance), and expect rejection of the whole file.

Real-time payment reconciliation works on intraday camt.052 and camt.054 messages, and the same booked entry arrives again in the end-of-day camt.053, so tests check the deduplication key from each bank's implementation guide. The camt.053 reconciliation guide and ISO 20022 testing requirements cover message rules.

Processor and scheme settlement files

A processor settlement file lists captures, refunds, chargebacks, and fees per batch, paid later as one net bank credit. Automated payment reconciliation matches each ledger entry to its settlement line and each payout batch to its bank credit. Injected cases: a file delivered twice under a new name, a missing fee line, a chargeback one batch after its capture, and a payout split into two bank credits. Rail file formats belong to payment rails testing.

Break classification

Test data injects one break per class, and each must get exactly one class:

  • Timing difference: a transfer booked before the bank cut-off appears on the next day's statement and must clear on the next run.
  • Missing in ledger: a bank fee debit has no ledger entry.
  • Missing at bank: a ledger payout never reaches the statement.
  • Duplicate: two ledger entries or two statement lines describe one movement.
  • Amount mismatch: the reference matches and the amount differs.
  • Orphan reversal: a return has no link to its original entry.

Boundary tests cover tolerances: an auto-match tolerance of 0.05 closes a one-cent loss per transaction as a match, and the drift and rounding report sums those residues per account.

FBO sub-ledgers and end-of-day balancing

In a US for-benefit-of (FBO) account programme, the sub-ledger records each end user's share. Where the bank's account records disclose the custodial relationship, pass-through deposit insurance requires each owner's interest to be ascertainable from the bank's records or from records kept in good faith and in the regular course of business by the depositor or a party keeping them for the depositor (12 CFR 330.5(b)(2)). The FDIC custodial accounts proposal (2 October 2024) would require reconciliation against beneficial ownership records no less frequently than at the close of business daily (proposed 12 CFR 375.3(b)(2) and (c)(3)(ii)). Status verified on 2026-09-16: comments closed on 16 January 2025, the Federal Register shows no final rule, and the proposal is not in force.

End-of-day tests check that the FBO statement balance equals end-user balances plus items in transit per business date, that entries after cut-off land on the next date, and that a return misallocated between two end users raises an item-level break although totals agree. The BaaS segment page lists the evidence partner banks request.

Audit trail and SOC 2 processing integrity

Criterion PI1.3 of the AICPA Trust Services Criteria states that the entity implements policies and procedures over system processing, and its 2017 points of focus include detecting and correcting production errors. Audit trail checks confirm that each correction keeps its actor, time, reason, and original entry; the SOC 2 testing requirements page lists what a service auditor samples.

Deliverables

  • Double-entry invariant test suite

    Automated tests that fail when a journal does not balance per currency, a posted entry changes, or a stored balance differs from the sum of its postings, run in CI by the engineering lead.

  • Reconciliation test scenarios against bank, processor, and scheme files

    Synthetic camt.053, BAI2, processor settlement, and scheme files with injected duplicates, missing lines, reversals, and timing differences, each with the expected match or break class.

  • Balance drift and rounding report

    A per-account and per-currency comparison of stored balances with balances recomputed from postings, listing each drift or rounding residue with its amount and source entries.

  • Audit trail completeness checks

    Checks that every reversal, manual adjustment, and break resolution records the actor, the time, the reason, and the original entry, in the form an auditor or partner bank samples.

How reconciliation tests fit your release process

  • On every merge. The double-entry invariant suite runs in CI on changes to posting code, the chart of accounts, and database migrations. An unbalanced journal, or a stored balance that differs from its recomputed postings, fails the build.
  • Nightly in staging. Reconciliation scenarios run against synthetic camt.053, BAI2, and processor settlement files generated from the day's test transactions, with injected breaks. Staging holds no production account data, and the file generators use synthetic account numbers and card references.
  • Before a release that changes money logic. A new partner bank or processor, a parser change, a new cut-off time, or a new posting rule triggers a replay of the full scenario set. The new balance drift and rounding report is compared with the report from the previous release, so a new residue shows up before production.
  • After release. Your operations team runs the first production end-of-day reconciliation. We hand over the break class checklist and read-only drift queries, so a break class that did not exist in staging is visible on the first business day.

Suites and file generators live in your repository and run in your CI. Each release leaves an evidence set stored with the change ticket: invariant results, scenario results with expected and actual break classes, the drift report, and audit trail check results. The same set serves SOC 2 change and processing integrity sampling and partner bank reviews.

Your team owns the chart of accounts, match tolerances, break resolution decisions, and production access. When a break has already reached production, the reconciliation incident scenario sets out the recovery sequence.

Sample deliverable

Sample, synthetic data

reconciliation test scenariosReconciliation test scenarios: card settlement and partner bank payouts
Reconciliation test scenarios: card settlement and partner bank payouts
IDScenarioExpected ledger entriesAmount (XTS)Expected reconciliation result
REC-01Processor settlement file repeats the settlement line for one captureDr Processor receivable / Cr Merchant payable, posted once120.00Break: the second settlement line has no matching capture and is flagged as a duplicate
REC-02Partial refund on a capture that settled the day beforeDr Merchant payable / Cr Processor receivable45.50Match: the refund line matches the refund entry and the original capture stays settled
REC-03FX rounding difference between the capture amount and the settled amountDr FX rounding expense / Cr Processor receivable0.01Match with a rounding entry when the difference is inside the configured tolerance
REC-04Processor fee line missing from the settlement fileDr Processing fee expense / Cr Processor receivable2.90Break: net settlement is lower than gross captures and a missing fee exception opens
REC-05Chargeback reversed after the merchant wins representmentDr Processor receivable / Cr Chargeback liability80.00Match: the reversal line clears the open chargeback entry
REC-06Refund request retried after a timeout, with the same idempotency keyDr Merchant payable / Cr Processor receivable, posted once30.00Break: the settlement file has two refund lines for one refund entry, and the second line is flagged as a duplicate refund
REC-07Partner bank credits the payout one business day after the expected value dateDr Partner bank cash / Cr Processor receivable1,000.00Match on the payout reference, with the value date difference logged as a timing item

Amounts use XTS, the ISO 4217 code reserved for testing. Account names are generic ledger accounts.

Questions

What is payment reconciliation?

Payment reconciliation is the process of matching each payment in a company's ledger with the corresponding line in a bank statement, processor settlement file, or card scheme report. Each difference becomes a break with a class, such as timing difference, duplicate, missing entry, or amount mismatch, and the break stays open until a ledger entry or a counterparty correction resolves it.

How does payment reconciliation work?

Payment reconciliation loads external records, such as a camt.053 or BAI2 bank statement and a processor settlement file, and matches each line to ledger entries by reference, amount, and date. Matched items close, and unmatched items become classified breaks for review. A final balance check compares the statement closing balance with the ledger balance for the same account and business date.

Scope your ledger and reconciliation testing

Send your ledger model, bank statement formats, and processor settlement files, and we return a test scope with the scenarios and evidence each flow needs.

Scope your testing