Guide
What is payment reconciliation? Matching every record of a payment.
Payment reconciliation confirms that every record of a payment agrees: your instruction, the provider’s status, the provider’s settlement file, and your bank statement.
Last updated:
Explore Flominzo ReconPayment reconciliation, in short
Payment reconciliation is the process of confirming that every record of a payment agrees. It compares what your system instructed, what the payment provider says happened, what the provider settled with you, and what your bank statement shows. When the records agree within agreed tolerances, the payment is matched. When they do not, the difference becomes an exception that someone must explain.
For a business that moves money for other people, reconciliation is how you know that a payment you marked as paid was actually paid, paid once, for the right amount, and settled.
Which records must agree?
A single payout usually leaves four kinds of record. They come from different organisations, arrive at different times, and prove different things.
| Record | Produced by | Typical format | What it proves |
|---|---|---|---|
| Instruction | Your own system | Transaction database, ledger | What you asked for |
| Status claim | The payment provider | API response, webhook | What the provider says happened |
| Settlement | The payment provider | Daily CSV, settlement report | What the provider will settle with you |
| Bank movement | Your bank | ISO 20022 camt.053 or camt.052, MT940 | Whether cash actually moved |
In Flominzo these are the four evidence grades: INTERNAL, CLAIM, SETTLEMENT, and CASH. For the question “did money move?”, cash outranks settlement, settlement outranks a claim, and a claim outranks your own records.
Why is a provider’s paid status not enough?
An API response and a webhook from the same provider are two channels of one organisation. When they agree, they only show that the provider is consistent with itself. They cannot prove that cash moved.
Proof needs an independent witness, normally your bank, through the settlement that pays for the payout. That is why a payment should not be treated as finished just because a provider reported it as paid. The financial closure guide explains the full set of conditions.
How does matching work?
Good reconciliation is deterministic. The same evidence under the same rules always gives the same answer. Matching uses three kinds of rule:
- Correlation keys: the idempotency key, the provider’s reference, your own client reference, amount and currency, beneficiary identifier, and a time window.
- Tolerances: agreed limits for fee rounding, exchange-rate rounding, and timing around cutoffs. Every use of a tolerance is logged.
- Expectations: which evidence each payment should receive, from which source, and by when. Without an expectation, a missing file looks the same as no problem at all.
Rules, tolerances, and expectations should be versioned configuration with an owner, so a result can always be explained by the rule that produced it.
What are the most common breaks?
| Break | What it looks like |
|---|---|
| API and file disagree | The API says paid, but the daily file leaves the payment out or shows a different amount. |
| Claims disagree | The API says paid while a webhook says failed, or the reverse. |
| Missing file | A settlement file does not arrive by its cutoff, and nothing notices. |
| Reversal after success | A payment reported as paid is reversed days later. |
| Fee or FX mismatch | The fee or rate the provider applied differs from the quote you booked. |
| Duplicate | A timeout is retried and the provider pays twice for one instruction. |
| Orphan | The provider reports a payout you never instructed, or you instructed one it never received. |
| Unexplained position | Your balance at a provider does not match its statement, and no single payment explains why. |
A worked example
A customer sends GBP 200.00 and the recipient should receive GHS 1,250.00 to a mobile-money wallet.
- The provider accepts the payout with reference P-889 and later reports it as paid, through both its API and a signed webhook.
- The next morning the provider’s daily file arrives. It lists 4,112 payouts, but not P-889.
- The settlement report and the bank debit match that file exactly, so P-889 was not settled.
- The cutoff was midnight in the provider’s time zone and the payout completed before it, so this is not a timing difference.
The payment is claimed as paid but not settled. The right response is to raise a settlement exception and query the provider with the evidence attached. The sender should not be refunded yet, because the recipient may well have been paid, and the payout must not be sent again. When the provider sends a corrected file that includes P-889, the exception is resolved with that evidence and the payment can match.
Illustrative example. The amounts and references are invented to show the method.
Reconciliation at three levels
- Payment level: each part of a payment is checked against the evidence it should have received.
- Settlement level: each settlement’s lines are checked against the payments it covers, the bank movement, and your ledger.
- Position level: your balances at each provider, in each currency, are checked against the provider’s statements and your bank.
How Flominzo Recon applies this
Flominzo Recon reads your existing transaction records and the independent evidence around them, starting read-only while your current systems keep running. It matches each payment by rule, raises owned exceptions for every break, and keeps the original evidence behind every decision.
Sources
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