See the five-stage pipeline run against your PSPs and bank feeds
Request a Formance demo to see idempotent ingestion, deterministic matching, and audit-ready outputs from day one.
Automated payment reconciliation is a pipeline that ingests provider settlement data, normalizes it into a single schema, matches it against core ledger postings, classifies exceptions, and records audit-ready results. It replaces manual, per-rail scripts with a single control that detects daily drift.
Teams operating across payment service providers (PSPs) and external accounts, including bank accounts and custodians, need reconciliation to separate benign timing gaps from real customer-funds risk. Finance and compliance depend on it, and engineering owns much of the failure surface.
Manual reconciliation breaks down the moment volume or provider count grows. Per-rail parsing scripts fail quietly when a provider shifts a CSV column, settlement timing gaps get papered over in spreadsheets until month-end forces a full recount, and exceptions pile up in email threads with no clear owner.
Each new PSP or bank account multiplies the number of disagreement paths engineers have to chase and the drift that accumulates from customer failures.
Manual payment reconciliation fails because settlement timing gaps compound across rails, provider formats fragment across standards, brittle parsing scripts break silently, reconciliation failure points multiply with every new provider, and undetected drift can escalate into shortfalls.
Every additional payment rail multiplies the points of reconciliation failure, and the resulting drift remains invisible until a full reconciliation forces it into view.
Settlement timing gaps cause your ledger and provider records to legitimately disagree at any given moment, and manual review cannot reliably tell a benign gap from a real break.
The Automated Clearing House (ACH) network settles four times daily, and roughly 80% of ACH volume settles in one banking day or less, but ACH returns can reference transactions from weeks prior.
Each rail added to the stack layers another timing model onto the month-end close. A manual process struggles to tell a benign timing gap from a real break at the moment it matters.
Standards-based bank statement formats fragment in practice, forcing parser updates whenever provider implementations shift versions. Camt.053 implementations span multiple versions, especially in remittance and statement-detail fields.
The ISO 20022 catalog lists multiple Camt.053 versions. The 2023 CGI-MP best practices made <FrToDt> and <StmtPgntn> mandatory. When provider implementations adopt that guidance, existing parsers will need updates to accept the newly mandatory fields.
Bespoke parsing scripts written per rail become single points of failure that break silently when provider formats change. PSP settlement reports can also require additional reporting steps, and when payout records and charge-level records arrive separately, reconciliation logic must connect them via reporting or lookup steps.
Engineers end up writing a bespoke script per rail, and each script is a single point of failure. A column swap or date-format shift can cause a custom script from 18 months ago to produce mismatches that nobody catches until finance tries to close the month.
Each new payment rail multiplies the points of reconciliation failure because providers differ in their status models and settlement cycles, and each added source creates new disagreement paths with every existing source. One system may treat an event as complete while another still has settlement work pending.
In common account reconciliation patterns, a marketplace processing through two PSPs, settling to three bank accounts, and paying out through a fourth provider has at least four external data sources that must agree with internal records. Each addition creates disagreement paths with every source already in the stack.
Silent data drift is when the internal ledger diverges from external provider records without triggering any alert. A discrete transaction error manifests as a rejected payment or a reversal message. Silent drift, by contrast, accumulates inside the timing-difference carve-out until someone forces a full reconciliation.
The Financial Conduct Authority's (FCA) safeguarding reforms reflect a related control objective: firms need records and reconciliation controls strong enough to identify and correct discrepancies before they result in customer-funds failures.
An automated reconciliation pipeline runs five stages: ingest provider data, normalize it, match it against ledger postings, classify exceptions for review or follow-up, and record the result.
Design each stage to preserve inspectable outputs that connect raw provider files to final reconciliation results.
Stage 1 pulls settlement reports from every connected provider and converts provider-native formats into a uniform data model before any matching runs.
Provider and account connections ingest settlement reports at configurable intervals through connected provider data sources. Beyond format conversion, ingestion should use rolling lookback windows long enough to catch late-settling records without duplicating earlier results. Ingestion should also use schema validation, so format changes fail validation rather than silently breaking downstream matching.
Formance's Connectivity module handles this stage with pre-built connectors for Stripe, Adyen, Wise, Banking Circle, Fireblocks, and other PSPs, banks, and digital asset providers, plus a generic connector framework for any provider not covered out of the box.
Matches apply a configurable rule set to compare normalized provider records against ledger postings, running deterministic exact matches first and applying configured checks only to the remainder.
Rule sets can key on amount and reference ID, or on counterparty and settlement date when those fields are more reliable.
A practical rule set performs exact matching first, using hash lookups on reference IDs and trace numbers, with additional configured checks applied only to the remainder. Keep deterministic and probabilistic matching separate because combining them into a single step makes behavior harder to reason about and increases the risk of false matches.
Make sure to configure cardinality in the matching rules. A PSP batch that settles as a single bank credit requires an N:1 rule that groups internal postings by batch key and matches the batch key sums.
Every unmatched item is assigned to one of five categories (missing credit, missing debit, amount discrepancy, duplicate posting, or timing offset), so each exception routes to the correct diagnostic path.
Classification matters because each category implies a different root cause and a different fix, and routing everything to one generic review path forces an operator to re-diagnose each item from scratch.
A classified output also exposes patterns because a gateway that keeps generating formatting-related exceptions becomes a candidate for a rule change.
Out-of-threshold exceptions route to operator review with both sides of the failed match and the evaluating rule already attached, so reviewers never re-pull provider reports. Configured policies auto-resolve exceptions inside defined thresholds, and everything else routes to review with context already attached.
A foreign exchange (FX) rounding difference within a configured small tolerance can be marked for a closing adjustment. An out-of-threshold exception routes to operator review, carrying both sides of the failed match (the ledger posting and the provider record), and the rule stage that evaluated it.
In the Formance Web Console, reviewers see the failed match decision and its supporting context without re-pulling provider reports.
The match decision, the rule that produced it, and the supporting records are preserved in an append-only, tamper-evident form an examiner can independently verify. Reconciliation applies policy-based matching rules between internal ledger records and external statements, with results available for audit and follow-up.
Idempotency, bi-temporality, immutability, and atomic multi-posting separate a reconciliation system you can trust from one you have to babysit.
Idempotency guarantees that reprocessing the same provider settlement report, whether due to a retry or a restart, produces exactly one set of postings.
Without idempotency, retries produce duplicate postings and inflated balances, a double-debit hazard sitting directly inside the reconciliation path. Use a stable deduplication key tied to the operation's result.
The provider's event ID is often the best candidate because it stays stable across retries even when providers re-render the payload and the bytes differ.
Bi-temporality means the ledger tracks both when events were recorded and when they were effective, so prior-period corrections carry the original value date without overwriting what the system believed on that date. Reconciliation routinely has to correct prior-period entries, such as an ACH return referencing a transaction from weeks ago, or a settlement deviation caught after close.
Without separate timestamps, a correction either rewrites history or leaves the earlier reconciliation result unexplainable. A correcting entry should carry an effective_at set to the original value date while its insertion timestamp reflects the wall-clock moment of correction.
Bi-temporal logic also handles precise cut-off reconciliations regardless of machine time. The ledger can then answer both what was true on a given date and what the system believed then.
Immutability means that reconciliation outputs cannot be silently edited after the fact, so auditors verify results directly against the ledger rather than trusting exported reports. Without immutability, the audit-ready promise of stage 5 evaporates.
An append-only, tamper-evident, hash-chained record removes that trust requirement. Each transaction's hash incorporates the previous transaction's hash, so altering any past posting corrupts every posting after it. Corrections use reversing postings rather than edits.
Atomic multi-posting guarantees that a reconciliation adjustment commits all its postings together or none at all. A reconciliation adjustment that moves a disputed amount from a pending account to an exceptions account is two postings. If the system crashes between them, the debit could commit while the credit fails, and the sum of balances no longer matches reality.
A partial write creates a new data drift in place of the one being resolved. Programmatically enforced double-entry accounting, where every transaction must sum to zero, prevents partial writes.
Automated reconciliation classifies every unmatched item into one of five exception categories (missing credit, missing debit, amount discrepancy, duplicate posting, or timing offset) so that each type routes to the appropriate diagnostic path.
A missing credit can indicate a missing provider event, such as when the processor confirms the charge, but the internal ledger never records it. A duplicate posting can point to a retry path without idempotency controls. A timing offset may clear itself once the settlement window closes. An amount discrepancy often traces to netted processor fees or mismatched FX rate sources. Treating all five categories as a single undifferentiated pile discards the diagnosis the pipeline has already made.
Once classified, each exception maps to a Formance’s Numscript template that atomically shifts value into an exceptions account, enforces double-entry accounting, and carries settlement metadata forward for audit. This ensures that the classification connects directly to an auditable ledger movement.
A PSP settlement report for January 15 credits $10,000 to @counterparties:paymentServiceProviders:a, but the ledger holds only $2,000 under @platform:paymentServiceProviders:a:payments:pending. A team can post the $8,000 discrepancy to a dedicated exceptions account when the match fails.
The posting moves the unreceived provider value out of the counterparty account and into an exceptions bucket that the finance team can age and alert on, which is why the source is the counterparty account (allowing unbounded overdraft because provider-reported value can precede any matching ledger credit) rather than the pending account.
In Numscript, USD/2 800000 denotes $8,000.00 at two decimal places:
// RECONCILIATION_EXCEPTION
// Event: record a PSP settlement exception for review
send [USD/2 800000] (
source = @counterparties:paymentServiceProviders:a allowing unbounded overdraft
destination = @platform:paymentServiceProviders:a:reconciliation:exceptions
)
set_tx_meta("event_type", "reconciliation_exception")
set_tx_meta("settlement_id", "stl001")
set_tx_meta("settlement_date", "2024-01-15")
The exceptions balance is a provider-reported value that the ledger has not yet received and is held where it can be queried. The $8,000 is now a first-class balance you can alert on and age, scoped to the exact provider account and settlement-date metadata where it appeared.
When the root cause surfaces, a compensating entry clears the exceptions balance, and the whole episode stays visible in the ledger's history.
Reconciliation can support drift detection and settlement error alerts, but teams still need defined ownership and escalation paths around those alerts.
Severity sets the clock because higher-severity exceptions, such as suspected duplicate payments, should have shorter escalation windows than low-risk date mismatches. Escalation must include the pipeline's existing context, so the finance team can act without re-pulling provider reports.
Without defined ownership and escalation paths, exceptions accumulate in email threads and spreadsheets until close.
Numscript templates like the one above are only useful when the underlying ledger enforces the primitives that make reconciliation trustworthy: idempotent postings, atomic multi-writes, and an immutable audit trail.