PSP reconciliation. Every provider’s claims checked against the cash.

PSP reconciliation, in short

PSP reconciliation is the work of proving that what each payment service provider says happened agrees with your own records and with the money that reached your bank. For every provider you use, it matches three things: each transaction to a line in the provider’s settlement report, each settlement to a movement on your bank statement, and your balance at the provider to the provider’s own statement.

The phrase is used in two ways. A platform or merchant reconciles the PSPs it pays in and out through. A PSP reconciles its own acquirers, payout partners and banks, and the settlements it owes its merchants. The method is the same in both cases, and so are the breaks.

The records each provider produces

Every provider gives you several versions of the same payment, at different times and with different identifiers. None of them is enough on its own.

Why reconciling several PSPs breaks

One provider is manageable in a spreadsheet. The second and third are where it stops working, because every provider differs in ways that a lookup formula cannot absorb:

• Identifiers: each provider has its own transaction, payout and settlement ids, and not all of them echo your reference back.
• Gross and net: most providers settle net of fees, refunds, chargebacks and reserves, so the bank line never equals the sum of your sales.
• Batching: hundreds or thousands of payments settle as one bank credit, so the match is many-to-one, not one-to-one.
• Timing: cut-offs, time zones and settlement cycles differ, so the same payment can belong to Tuesday in your ledger and Wednesday in the provider’s file.
• Vocabulary: “succeeded”, “paid”, “settled” and “completed” mean different things at different providers.
• Corrections: reversals, late refunds and corrected files change earlier days after you thought they were closed.

The three matches that make up PSP reconciliation

1. Transaction to settlement line. Every payment you instructed should appear exactly once in exactly one settlement, with the amount, currency and fee you expected. A payment in no settlement is missing; a payment in two is a duplicate.
2. Settlement to bank. The net of each settlement batch should equal one movement on your bank statement, within an agreed timing window. The arithmetic has to hold too: gross, minus fees, refunds, chargebacks and reserves held, plus reserves released, equals net.
3. Position to provider statement. Your running balance at each provider, in each currency, should equal the provider’s own balance. This catches what the first two miss: an adjustment the provider booked without a transaction behind it.

Run all three every day, and give each one an expectation: which file should arrive from which provider, and by when. Without an expectation, a file that never arrives looks exactly like a day with nothing wrong.

Normalise every provider into one model

The practical answer to provider sprawl is a single internal shape for settlement data. Each provider’s report is mapped into it once, and matching rules are written against the shared shape rather than against each provider’s columns.

Keep the original file as well as the mapped rows. When a provider disputes a number, you need the line exactly as they sent it.

A worked example: one settlement batch

Say a PSP settles Tuesday’s card payments on Thursday. The settlement report lists 1,200 payments with a gross of 48,600.00, and deducts:

Reconciliation checks that all 1,200 payments are ones you instructed, that none is also in Wednesday’s batch, that the fees match your contract rate, and that a credit of 44,713.00 reaches your bank on Thursday. If the bank shows 44,698.00, the 15.00 difference is not rounded away: it becomes an exception with an owner. Here it turns out to be a charge the bank took on the incoming credit, and it is recorded as that.

The reserve is tracked separately. The 2,430.00 held today should come back in a later batch as a released reserve, and your position at the provider stays explained until it does.

What to automate, and what stays with people

Matching should be deterministic: versioned rules, tolerances and expectations that give the same answer on the same evidence every time, so you can show an auditor why two records were matched. Everything that doesn’t match becomes an exception with a type, an owner, a due-by time and the evidence attached.

People keep the decisions: accepting a short settlement, writing off a difference, or changing a rule. An AI agent can help investigate, gather the records and draft an explanation, but it should never make those decisions. Read deterministic vs AI reconciliation for why.

When you are the PSP

A PSP reconciles in both directions at once. Money comes in from acquirers, schemes and banks; money goes out to merchants, sellers and payout partners; and in between sits a balance the PSP owes its merchants. Each of those needs its own proof:

• Inbound: each acquirer or scheme settlement against the transactions it covers and the bank credit, exactly as a merchant would do it.
• Merchant balances: each merchant’s balance built from its transactions, fees, refunds, chargebacks and reserves, and agreed with the statement the merchant sees.
• Outbound: each merchant payout against the payout provider’s status, its file and the bank debit.
• Funds held: the total owed to merchants against the money actually held for them, in each currency and account.

The last check is the one that matters most when something goes wrong. If the total you owe merchants and the money you hold for them drift apart, you need to know which merchant, which day and which transaction, not just the size of the gap.

A daily PSP reconciliation routine

1. Before the day starts: confirm every expected file arrived from every provider, and raise any that didn’t.
2. Match: run transaction-to-settlement, settlement-to-bank and position matching for yesterday.
3. Triage: sort exceptions by type, age and value, and give each one an owner.
4. Investigate: pull the provider’s record, the file line and the bank entry for each exception, and ask the provider about anything that is theirs to explain.
5. Decide and record: accept, correct or escalate each item, with the reason written down.
6. Close: close the day only when nothing is unexplained, and reopen it when a late file changes the picture.

Most teams find that steps 1 and 2 can run unattended, and that the time goes into steps 3 to 5. Good tooling shortens those by putting the evidence next to each exception, rather than in three portals and an inbox.

How Flominzo Recon applies this

Flominzo Recon reads each provider’s API claims, reports and settlement files, and your bank statements, as evidence with a grade: INTERNAL, CLAIM, SETTLEMENT or CASH. For the question “did money move?”, cash outranks settlement, and settlement outranks a claim. Rules, tolerances and expectations are versioned configuration with an owner, and every break maps to one of thirteen exception types, such as SETTLEMENT_MISMATCH, FILE_MISSING, DUPLICATE and ORPHAN.

That is what we mean by 100% reconciliation. 100% reconciliation means every payment is matched or explained, with evidence: it 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. Recon can start read-only, alongside the systems you run today. The providers, files and markets are agreed for your deployment.

Questions

Related guides