Payment reconciliation software
Payment reconciliation software. Every payment matched, or explained.
Payment reconciliation software matches your records to provider, settlement and bank evidence. What it must do, a buyer’s checklist, and build vs buy.
Last updated:
Book a Recon demoWhat payment reconciliation software does
Payment reconciliation software compares every record of a payment - your instruction, the provider’s status, the provider’s settlement file, and your bank statement - and turns each difference into an exception that someone must explain. Good software does this by rule, keeps the original evidence, and never treats a payment as finished just because a provider said it was paid.
It matters most to businesses that move money for other people: remittance companies, payout platforms, payment service providers, marketplaces, and the finance teams behind them. When several providers, currencies, and cut-offs are involved, spreadsheets and end-of-month checks find problems late, and often without the evidence needed to resolve them.
Flominzo calls the goal 100% reconciliation: every payment ends either matched against independent evidence - the provider’s records, the settlement file and the bank statement - or as an open exception with an owner and a reason. None is silently assumed paid.
A buyer’s checklist
Use this list to compare any payment reconciliation software, including ours. Each row is a situation that payment operations teams meet in practice.
| Capability | Why it matters | How Flominzo Recon handles it |
|---|---|---|
| Three-way matching | Your records, the provider’s claims, and settlement or bank cash come from different organisations and prove different things. | Each payment is matched against internal, claim, settlement, and cash evidence by rule. |
| Evidence grades | An API response and a webhook from one provider are not independent proof. | Cash outranks settlement, settlement outranks a claim, and a claim outranks your own records. |
| Owned exception queue | A difference nobody owns is a difference nobody fixes. | Every break becomes a typed exception, such as API_CSV_DISAGREEMENT, with an owner and its evidence. |
| Unknown outcomes | A timeout is not a failure. Retrying it can pay the recipient twice. | UNKNOWN is never terminal. It is resolved by a status lookup, settlement evidence, or a recorded human decision. |
| Expected evidence | A missing file looks the same as no problem unless something expects it. | Each source declares what should arrive and by when. A late file raises FILE_MISSING. |
| Late evidence reopens | A reversal days later changes the answer. | A closed payment or day reopens, and the earlier decision stays in the history. |
| Read-only start | Replacing systems to get reconciliation turns a quick win into a long project. | Starts with read-only transaction sources while your current systems keep running. |
| Statement formats | Bank data arrives in several formats and layouts. | Parsers for ISO 20022 camt.053 and camt.052, SWIFT MT940, and configured CSV layouts. |
| Explainable decisions | Auditors, partners, and your own finance team will ask why. | Every decision keeps its evidence, the rule version, and the person or rule that made it. |
Why matching two records is not enough
Many teams start by comparing their own database with the provider’s API. That shows whether the provider agrees with you, but not whether cash moved. An API response and a webhook are two channels of the same organisation; when they agree, the provider is only consistent with itself.
Proof needs an independent witness, normally the settlement file that pays for the payout and the bank movement behind it. That is why payment reconciliation software should hold all the records of a payment together, rank them by how much they prove, and keep a payment open until the stronger evidence arrives. The payment reconciliation guide walks through a worked example.
Build, buy, or keep the spreadsheet?
Every approach below can work at some stage. The question is where each one stops working for a business that moves money through several providers.
| Approach | Works well when | Where it tends to break |
|---|---|---|
| Spreadsheets and manual checks | Volume is low, with one provider and one currency. | Late files, reversals, and timeouts are found days later, and decisions leave no audit trail. |
| ERP or accounting modules | You match bank lines to invoices and journal entries. | They rarely model payment attempts, provider claims, unknown outcomes, or settlement files. |
| In-house scripts | An engineering team can maintain the rules for each provider. | Each new provider, file layout, or format change becomes a code change, and evidence is often not retained. |
| General reconciliation tools | You need to match two datasets with configurable rules. | Without payment lifecycle states, a timeout or a reversal looks like an ordinary mismatch. |
| Reconciliation built for money movement | You move money for others through several providers. | It still needs connecting to your records and evidence, which is where an integration team helps. |
How Flominzo Recon meets the checklist
Flominzo Recon reads your existing transaction records and the independent evidence around them. Matching rules, tolerances, and expectations are versioned configuration with an owner, so the same evidence under the same rules always gives the same answer.
- Start read-only. Connect transaction sources, provider files, and bank statements without changing how payments run today.
- Run alongside. Compare results with your current process for representative business days before relying on them.
- Keep people in control. Agents read, correlate, investigate, and draft explanations. They never close an exception, accept a settlement, or write off a difference on their own.
- Close with proof. A payment or business day closes only when the required evidence agrees, and reopens when later evidence changes the answer.
What it looks like day to day
Reconciliation software should change the rhythm of the work, not just produce a monthly report. With Flominzo Recon, operations and finance teams work from three views of the same records.
- Open payments: every payment still waiting for the evidence it should receive, with the source that is late and the time it was due.
- The exception queue: breaks grouped by class, such as a missing callback, a settlement mismatch, or a reversal after success, each with an owner and the original records attached.
- Day closure: a business day closes only when nothing is left unexplained. If a late file or a reversal arrives afterwards, the day reopens and shows what changed.
Because the same exception classes recur, a fix can often be written once as a versioned rule, re-run against the affected payments, and closed with evidence. The reconciliation backlog use case shows that process step by step.
What to ask any vendor
- Which evidence do you treat as proof that cash moved?
- What happens to a payment whose outcome is unknown after a timeout?
- How do you notice a settlement file that never arrived?
- Can a closed day reopen when late evidence arrives, and is the earlier decision kept?
- Can we start read-only, without replacing our payment stack?
- Which bank statement formats do you parse today, and how is a new layout validated?
- Who can close an exception or write off a difference, and is every decision recorded?
- What does AI do in your product, and what is it never allowed to do?
How pricing works
Pricing depends on the flows, providers, and volumes you connect. Most teams start with one payment flow reconciled alongside their current process, then expand.
See how we chargeQuestions
Is payment reconciliation the same as bank reconciliation?
No. Bank reconciliation matches ledger entries to bank statement lines. Payment reconciliation follows each payment through the provider’s claims and settlement files before the bank, so you can tell which payment a bank difference belongs to.
Do we need to replace our payment systems?
No. Flominzo Recon can start with read-only transaction sources and the evidence you already receive. Your current systems keep their jobs while reconciliation runs alongside them.
What does 100% reconciliation mean?
It means every payment ends either matched against independent evidence - the provider’s records, the settlement file and the bank statement - or as an open exception with an owner and a reason. None is silently assumed paid.
Can AI close exceptions automatically?
No. Agents help investigate and explain. A person, or a deterministic rule your team has approved, makes each financial decision, and the decision is recorded with its evidence.
Which bank statement formats can it read?
The parsers cover ISO 20022 camt.053 and camt.052, SWIFT MT940, and configured CSV layouts for provider and settlement files. Each format is validated against the actual files your banks and providers produce before it is relied on.
Let’s make it specific to you.
Bring your systems, payment flows, and questions. We’ll help define the next step.
Talk to the team