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.
Related
Segments
- Neobanks and digital banking
- Banking-as-a-Service and card issuing
- Business banking
- Accounting and invoicing
- AP/AR automation and treasury
- International transfers
- Crypto exchanges and wallets
- Robo-advisors and wealthtech
- Earned wage access
- Spend management and corporate cards
- Subscription billing and revenue management
- Debt collection and loan management software
Guides
- How to test ledger reconciliation against settlement files and bank statements
- How to reconcile camt.053 statements: format, batch entries, reversals, and MT940 mapping
- How to test Same Day ACH cutoff times and settlement timing across time zones
- How to test payment idempotency
- How to test banker's rounding in payment and ledger code
Scenarios
- After a reconciliation incident reaches customers or your partner bank
- Adding embedded payments to a vertical SaaS platform
- QA before a partner bank integration goes live
- QA bottlenecks slowing fintech releases
- Sponsor bank compliance audit of a live programme
- Switching payment processors without losing payments
- Preparing for technical due diligence before a funding round or acquisition
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
| ID | Scenario | Expected ledger entries | Amount (XTS) | Expected reconciliation result |
|---|---|---|---|---|
| REC-01 | Processor settlement file repeats the settlement line for one capture | Dr Processor receivable / Cr Merchant payable, posted once | 120.00 | Break: the second settlement line has no matching capture and is flagged as a duplicate |
| REC-02 | Partial refund on a capture that settled the day before | Dr Merchant payable / Cr Processor receivable | 45.50 | Match: the refund line matches the refund entry and the original capture stays settled |
| REC-03 | FX rounding difference between the capture amount and the settled amount | Dr FX rounding expense / Cr Processor receivable | 0.01 | Match with a rounding entry when the difference is inside the configured tolerance |
| REC-04 | Processor fee line missing from the settlement file | Dr Processing fee expense / Cr Processor receivable | 2.90 | Break: net settlement is lower than gross captures and a missing fee exception opens |
| REC-05 | Chargeback reversed after the merchant wins representment | Dr Processor receivable / Cr Chargeback liability | 80.00 | Match: the reversal line clears the open chargeback entry |
| REC-06 | Refund request retried after a timeout, with the same idempotency key | Dr Merchant payable / Cr Processor receivable, posted once | 30.00 | Break: the settlement file has two refund lines for one refund entry, and the second line is flagged as a duplicate refund |
| REC-07 | Partner bank credits the payout one business day after the expected value date | Dr Partner bank cash / Cr Processor receivable | 1,000.00 | Match 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?
How does payment reconciliation work?
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