Guide
What is payout reconciliation? Proving every payout paid and settled.
Payout reconciliation checks each payout against the provider’s status, its settlement file and your bank statement, so every payout is proven paid once.
By Sanjay Singh, Founder · Last updated:
Explore Flominzo ReconPayout reconciliation, in short
Payout reconciliation is the process of proving that every payout you instructed was paid once, for the right amount, to the right recipient, and settled with the provider that carried it out. It compares your own instruction with the provider’s status, the provider’s settlement records, and the movement on your bank statement or prefunded balance. When all of them agree within agreed tolerances, the payout is matched. When they do not, the difference becomes an exception with an owner.
Payout reconciliation is a specific case of payment reconciliation. It matters most for businesses that pay out on behalf of others: payout platforms, marketplaces, payroll and supplier-payment services, remittance companies, and PSPs that settle with merchants.
Which records does a payout leave?
A payout is described by four kinds of record. Each comes from a different place and proves something different, which is why no single one of them is enough.
| Record | Source | Typical format | What it proves |
|---|---|---|---|
| Your instruction | Your payout system and ledger | Transaction database, ledger posting | What you asked for, and when |
| Status claim | The payout provider | API response, status lookup, signed webhook | What the provider says happened |
| Settlement record | The payout provider | Daily transaction report, settlement file, balance statement | What the provider charged you for, including fees |
| Cash movement | Your bank | ISO 20022 camt.053 or camt.052, MT940 | Whether money actually left your account |
For the question “was this payout really paid?”, the bank movement outranks the settlement record, the settlement record outranks the provider’s status claim, and the status claim outranks your own record. Your own record remains authoritative for what you intended.
Which keys match a payout to its evidence?
Matching should be deterministic: the same evidence under the same rules always gives the same answer. These are the keys a payout reconciliation usually relies on.
| Key | Where it comes from | Why it matters |
|---|---|---|
| Idempotency key | Your system, sent with the instruction | Ties every attempt and retry to one logical payout. |
| Client reference | Your system, echoed by the provider | Lets you find the payout in the provider’s reports. |
| Provider reference | The provider’s response or webhook | The provider’s own identifier, used in its files. |
| Amount and currency | Instruction, claim, and settlement line | Detects partial payouts, fee deductions, and FX differences. |
| Beneficiary identifier | Instruction and provider record | Confirms the right account, wallet, or card was paid. |
| Business date and cut-off | The provider’s declared settlement calendar | Places the payout in the right settlement and statement. |
| Settlement batch reference | Settlement file and bank narrative | Links a group of payouts to one bank movement. |
What are the common payout breaks?
Every break should become a typed exception, so it can be counted, owned, and resolved by rule rather than rediscovered each morning. These are the exception types Flominzo uses, as listed in the documentation.
| Exception | What it looks like in a payout |
|---|---|
MISSING_CALLBACK | The provider accepted the payout, but no webhook or status change arrived in its declared window. |
API_CSV_DISAGREEMENT | The API says paid, but the daily file leaves the payout out or shows a different amount. |
SETTLEMENT_MISMATCH | The payout is claimed as paid with no settlement line, or the settlement total differs from the bank movement. |
REVERSAL_AFTER_SUCCESS | A payout reported as paid is returned days later, for example because the account was closed. |
FEE_FX_MISMATCH | The fee or exchange rate the provider applied differs from the one you booked, beyond tolerance. |
ORPHAN | The provider reports a payout you never instructed, or you instructed one it has no record of. |
DUPLICATE | Two provider references or two settlement lines exist for one payout attempt. |
FILE_MISSING | The settlement file or statement did not arrive by its cut-off. |
UNKNOWN_UNRESOLVED | A payout stayed unknown beyond the lookup window, so money sits in transit. |
Prefunded or postpaid: how does settlement change the check?
How you pay the provider for payouts decides which settlement evidence you reconcile against.
| Prefunded | Postpaid | |
|---|---|---|
| How it works | You deposit funds with the provider; each payout draws down that balance | The provider pays out first and collects from you later, often daily |
| Key evidence | The provider’s balance statement and your top-up transfers | The settlement file and the bank debit that pays it |
| Main check | Opening balance, plus top-ups, minus payouts and fees, equals closing balance | Settlement lines equal the payouts they cover, and the total equals the bank debit |
| Typical risk | Unexplained balance drift and top-ups still in transit | Payouts missing from a batch, or fees netted without notice |
Many operators use both models across different providers, so the settlement model belongs in each provider’s configuration, not in code.
A worked example
A payout platform holds a prefunded USD balance with one provider. The opening balance is USD 50,000.00. During the day it instructs payouts totalling USD 12,400.00, with an agreed fee of USD 1.00 per payout on 62 payouts, so USD 62.00 in fees.
- Every payout receives a provider reference, and the provider reports all 62 as paid through its API and webhooks.
- The expected closing balance is USD 50,000.00 minus 12,400.00 minus 62.00, which is USD 37,538.00.
- The provider’s balance statement shows a closing balance of USD 37,523.00, a difference of USD 15.00.
- Payment-level matching shows that all 62 payouts appear in the provider’s transaction report with the right amounts. The difference is not a missing or duplicated payout.
- The fee lines show that ten payouts were charged USD 2.50 instead of USD 1.00. Ten times USD 1.50 explains the full USD 15.00.
The payouts themselves are matched. The fee difference is raised as FEE_FX_MISMATCH against the provider’s settlement, with the fee schedule and the ten fee lines attached, and it stays open until the provider issues a credit or a person approves a recorded decision. Nothing about the recipients changes, and nothing is sent again.
Illustrative example. The amounts, counts, and fee are invented to show the method.
How do you run payout reconciliation?
- Declare expectations per provider: which callbacks, files, and statements each payout should produce, and by which cut-off.
- Keep the raw evidence: store each response, webhook, and file with a hash and its source before interpreting it.
- Match at payout level: use the keys above to link each payout to its claim and settlement line.
- Match at settlement level: check each settlement’s lines against the payouts it covers and the bank movement.
- Match at position level: check each balance with each provider, in each currency, against its statement.
- Raise owned exceptions: every break gets a type, an owner, and the evidence behind it.
- Close with reasons: a payout closes only when its evidence agrees, and later evidence can reopen it.
How Flominzo Recon applies this
Flominzo Recon reads your payout records and the independent evidence around them, starting read-only while your existing payout systems keep running. It matches payouts, settlements, and positions by versioned rules, raises a typed exception for every break, and keeps the original evidence behind every decision. Agents help investigate and draft explanations; resolving an exception or accepting a settlement stays with a person or an agreed rule. Where Flominzo Payouts carries out the payout, the same payment record serves execution and reconciliation.
Questions
Is payout reconciliation the same as bank reconciliation?
No. Bank reconciliation checks your ledger against your bank statement. Payout reconciliation also checks each payout against the provider’s status and settlement records, so it can explain which payout a bank movement or balance change belongs to.
How often should payouts be reconciled?
At least as often as the provider settles, which is usually daily. Payout-level matching can run as evidence arrives, while settlement and position checks run when each file or statement is due.
What should happen when a payout’s status is unknown?
Look it up with the provider and wait for settlement evidence. Do not send it again. The guide to duplicate payouts and unknown status explains the safe sequence.
Can we start without replacing our payout stack?
Yes. Reconciliation can begin read-only, with your transaction records, provider reports, and bank statements, while your current systems keep carrying out payouts.
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