Schedule Your Reconciliation PoC Tests
Request a demo of Formance Reconciliation to schedule your PoC tests.
A payment service provider (PSP) changes its settlement file format after eighteen months. But the reconciliation script keeps running, the data lands in the wrong columns, and finance does not notice until month-end, when internal balances no longer match the bank's.
By then, treasury moves money based on unclear numbers, and support answers customer questions from a spreadsheet. The longer the problem goes unfixed, the harder it is to untangle and explain to auditors.
Most reconciliation software is built for month-end close, but payment infrastructure needs a reconciliation ledger, which is a continuously updated record that matches internal balances against what PSPs, banks, and custodians actually hold, and evaluating one requires a different sequence.
This buyer's guide picks up after the build-or-buy core ledger decision. It shows how to evaluate operational reconciliation software for payment infrastructure with a five-capability scorecard, a four-scenario proof-of-concept (PoC) plan, and a six-week evaluation timeline.
Why month-end reconciliation tools fail payment infrastructure
Month-end close software certifies periods inside the enterprise resource planning (ERP) system, while operational reconciliation continuously verifies that internal balances match what PSPs, banks, and custodians hold in real time.
If a vendor's demo focuses on month-end close inside the ERP, drop them early. That kind of software only checks the books against bank statements at set intervals so that finance can sign off on a period. Payment systems need continuous checks to ensure internal balances still match what outside providers hold right now.
Close workflows break even at the intended job. McKinsey reports that most institutions still reconcile and settle manually, and Gartner reports that over half of accountants make several errors per week under capacity constraints.
In a payment stack, the delay is the window where customer balances drift from PSP-held funds without anyone noticing, and manual close workflows have no mechanism to catch it before the next reporting cycle.
The 2024 Citigroup fine shows the cost of the always-on problem. On July 10, 2024, the Federal Reserve and OCC fined Citigroup $60.6 million for insufficient progress on data-quality management and internal controls first flagged in a 2020 consent order.
Four years later, Citi still lacked the compensating controls needed to manage ongoing data-quality risk. A month-end cadence lets a Citi-style failure persist, while a reconciliation ledger running continuously against provider balances would surface the same drift within hours and not at the next reporting cycle.
Three prerequisites exist for evaluating general ledger reconciliation software: name the system of record, confirm write-time correctness, and assign stakeholder ownership. Each is essential for the reconciliation software that sits between the general ledger and external providers.
When the ledger and a provider statement disagree, the written conflict policy determines which record wins. Without a written conflict policy, every vendor demo becomes a debate about internal architecture.
Double-entry conservation, idempotent postings, and ledger immutability are invariants that ensure ledger integrity. No reconciliation software can retrofit the invariants onto a ledger that accepts unbalanced or duplicate writes.
Finance owns the close, engineering owns write-path correctness, and compliance owns segregation evidence. Each stakeholder signs off on the criteria before a vendor sees them.
Reconciliation software sits between the operational core ledger and external providers, then feeds the ERP-side general ledger. The core ledger underneath does most of the work.
Formance is an open-source programmable core ledger that unifies fiat and digital assets with regulatory-grade traceability, purpose-built for teams running payment infrastructure at scale.
And, like Formance, if the ledger enforces double-entry conservation, idempotent postings, and immutability at write time, reconciliation becomes a verification exercise rather than a forensic reconstruction of what each posting was supposed to be.
Five capabilities separate operational reconciliation from close software. They are canonical normalization of provider data, idempotent ingestion, bi-temporal matching, continuous drift detection, and mismatch routing with compensating corrections.
Each becomes a pass/fail row on the scorecard further down in this guide.
Ingestion must convert external provider formats into one canonical event model and reject structurally broken files at validation. Validation must reject a settlement file missing its currency column before ingestion. You should also test a partially parseable file to confirm ingestion produces no partial rows or unexplained drift.
Vendor question: how does the software handle a new PSP schema, and who owns the mapping?
Ingestion must handle duplicate webhooks and provider retries without creating duplicate postings, with idempotency held as a data-layer invariant where the posting is written.
Vendor question: where in the stack is the idempotency key enforced, and can we see the schema?
Match against the effective date rather than the system clock to reduce timing-only alerts from in-flight settlements. Bi-temporal accounting tracks both when an event was recorded and when it was effective. You should also consider temporal queries on third-party data for the underlying execution model.
Vendor question: can we query balances at any prior effective date without replaying history? Can you include a payout initiated Friday and settled Monday as the test case?
Drift detection must run continuously along two axes, a pattern worth naming as the two-axis drift check. Internal drift, where the ledger and sub-ledger state diverge, and external drift, where the ledger diverges from provider-held balances.
The required control is an always-on alert when the sum of customer balances exceeds what the provider holds, and account structure (like naming each PSP boundary as its own account, shown below) decides whether that comparison is even possible.
The Numscript example below shows how Formance mechanically catches this drift, both internal and external.
Provider A is modeled as its own account, @psp:provider_a:settlement, so every settlement posting from that PSP hits a named boundary account. Formance then reads the balance of @psp:provider_a:settlement and compares it directly against Provider A's external statement on a schedule you set.
If the two disagree, that is the drift, and the alert fires on the next reconciliation run without anyone reconstructing which posting belongs to which provider.
// PSP_SETTLEMENT
// Event: Provider A settles USD 2,400,000 into the platform's operating treasury
send [USD/2 240000000] (
source = @psp:provider_a:settlement allowing unbounded overdraft
destination = @treasury:operating
)
set_tx_meta("event_type", "psp_settlement")
set_tx_meta("settlement_id", "stl001")
Naming the account @psp:provider_a:settlement lets drift detection compare that account's balance directly against Provider A's external statement.
Vendor question: what is the detection latency between a drift event and an alert?
Every mismatch must route to one of three lanes: automated adjustment, a finance queue, or an investigation queue. Routing rules must be configurable in the software, and corrections must happen through compensating postings that preserve the original posting and the history of what the system recorded as audit evidence.
Vendor question: can you show the traceability record for a corrected mismatch from detection to resolution?
A two-week PoC is built around four adversarial scenarios: replaying a settlement webhook, feeding a malformed settlement file, posting a backdated correction, and forcing a sub-ledger mismatch.
These tests tell you more than any feature matrix, and each one converts directly into a requirement in the contract.
This test checks whether one real-world settlement gets recorded as one posting, even when the provider sends the same webhook multiple times.
PSPs retry webhook deliveries whenever they don't get an acknowledgment, and those retries can turn a single settlement into five identical HTTP calls. Webhook duplication is a classic ledger anti-pattern, and this test surfaces the failure in an afternoon.
Pass: one posting with one idempotency record.
Check whether validation rejects broken input at the door, or lets misreads through that show up days later as unexplained drift. Hand the software a file it should refuse and confirm the rejection.
Pass: the file is rejected at validation with a clear error, and nothing partial makes it into the ledger.
Confirm the ledger can answer both "what did we know then" and "what is true now" without rewriting history. Query Friday's balance twice; once as of a record-time cutoff before the Monday correction, and once after.
Pass: the earlier query excludes the correction while the later query includes it.
This PoC ensures the sum of customer balances equals what the provider is actually holding. Inject a phantom credit into a customer sub-ledger without a matching movement in the omnibus account, and time how long the software takes to detect it.
Pass: the alert fires within the stated service-level objective (SLO).
POC test 4 matches the shape of the Aviva client-money segregation failure. The FCA fined Aviva Pension Trustees UK and Aviva Wrap UK £8.2 million after internal reconciliation deficiencies let client-money under-segregation peak at £74.4 million.
General ledger reconciliation software that cannot detect a forced mismatch in a PoC will not detect a real one in production, and the tests are vendor-neutral.
A six-week evaluation forces the shortlist, PoC, and scoring into a fixed schedule, so engineering hours go only to serious contenders.
Use these elements to structure the evaluation: filter questions, a fixed timeline, cost axes, reference calls, and the documents to request before signing
Five questions cut the longlist to two or three candidates:
Any evasive answer is a cut.
Start with the longlist and filter questions in week 1, then narrow to a shortlist and run demos in week 2. Weeks 3 and 4 are the four-test PoC mentioned above. In week 5, score the results with finance and compliance in the room. Week 6 is decision and negotiation.
Price candidates across four axes: implementation effort, ongoing engineering maintenance, per-event or per-volume fees, and self-hosted infrastructure if you run it yourself. Model all four axes together: a low per-event fee often hides implementation and self-hosted infrastructure costs that dominate year one. Vendors typically quote one and let the other three surface after signing.
Reference calls are the last check before you commit engineering hours to a PoC. Source references from teams running comparable payment stacks. An engineering lead running a three-PSP stack outranks any published ranking. On the call, ask two questions: what broke, and what the reference customer would do differently.
Before signing, request three documents: the deployment topology diagram for your chosen model, the SOC 2 Type II report, and the source-code inspectability terms. Engineering teams can read the data model and run the system before any sales conversation, which is a useful benchmark for what "inspectable" should mean. These three map to the last three rows of the scorecard below.
Lift the table below into your evaluation doc as-is. The scorecard consolidates the five capabilities, the four PoC acceptance criteria, and the three pre-signing document requests into one artifact: one row per decision, one column for the evidence that scores a pass, and a final go/no-go tied to the week-6 milestone.
| Scorecard | Category | Evidence that scores a pass |
| Canonical normalization of provider data | Capability (pass/fail) | New-schema handling demonstrated; mapping owner named |
| Idempotent ingestion and duplicate-safe postings | Capability (pass/fail) | Data-layer idempotency key, schema shown |
| Bi-temporal matching on effective dates | Capability (pass/fail) | Balance retrievable at any prior effective date |
| Continuous drift detection, internal and external | Capability (pass/fail) | Stated, tested detection latency |
| Mismatch routing and compensating corrections | Capability (pass/fail) | Detection-to-resolution trail produced on request |
| Replay the same settlement webhook five times | PoC acceptance | One posting, one idempotency record |
| Feed a malformed settlement file | PoC acceptance | Structured rejection, no partial state |
| Post a correction on Monday with a Friday effective date | PoC acceptance | Earlier record-time cutoff excludes correction; later cutoff includes it |
| Sum sub-ledger balances against omnibus, force a mismatch | PoC acceptance | Alert within SLO |
| Deployment topology diagram | Document request | Diagram for your chosen model |
| Source-code inspectability terms | Document request | Source-access terms in writing |
| SOC 2 Type II report | Document request | SOC 2 Type II and resilience documentation |
| Go/no-go | Decision | Every row green by end of week 6 |
Once the scorecard is filled in, the shortlist narrows to vendors that have these requirements.
Formance Reconciliation is one of them. It uses policy-based matching rules to compare aggregate ledger balances with external provider records at configurable intervals, with bi-temporal cut-off logic for precise historical reconciliations and source-agnostic ingestion that normalizes data from any bank, PSP, or digital asset rail.