Summarise the article with your AI
Here you can read:
Marketplaces reconcile twice per transaction cycle: inbound collections from buyers and outbound payouts to sellers, across multiple PSPs with different settlement schedules and fee structures. Disparate settlement cycles, fee structures, and late chargebacks create significant cash flow visibility challenges. FCA safeguarding rules necessitate strict, recurring reconciliations to ensure financial stability and compliance.
What multi-PSP reconciliation is, and why a marketplace has to do it twice
For most businesses, PSP reconciliation is straightforward: match what customers paid against what the PSP collected and what landed in the bank account. A marketplace operator, however, functions differently from a standard merchant by mediating between thousands of buyers and sellers. This structural difference fundamentally alters the treasury workflow.
Round one matches inbound money, verifying buyer payments against collected and settled funds across multiple PSPs.
Round two matches outbound money, verifying the liabilities owed to sellers against actual payouts, net of commissions.
If a provider deducts an undisclosed fee, this shortfall must be factored into seller payouts to prevent the operator from disbursing uncollected funds. Under the FCA's safeguarding rules payment firms must perform internal and external reconciliations at least once each reconciliation day. At high transaction volumes, automating reconciliation across payment platforms becomes a structural necessity.
The four money flows a marketplace has to match
Complete reconciliation means matching four distinct flows:
1. Buyer payment to PSP capture
A buyer pays and the PSP captures the payment. The order system records it. The transaction must match the internal order system precisely, despite varying transaction IDs across different providers.
2. PSP capture to PSP settlement
The provider settles a net amount, deducting interchange, scheme, and processing fees. This may arrive days later in a file format unique to that PSP. The gap between capture and settlement can vary by provider: T+1, T+2, T+3 or longer.
3. Marketplace float to seller liability
Between funds clearing into the account and disbursing them to sellers there is a liability on the balance sheet, tracked seller by seller, order by order.
4. Marketplace payout to seller bank credit
The marketplace has to pay each seller, potentially through another PSP or bank rail, incurring its own fees and settlement time, possibly in a different currency.
Each flow generates its own record. As the Bank for International Settlements has noted, digital money resides in siloed proprietary databases, and the separation of messaging, reconciliation and settlement leads to delays. The reconciliation challenge is matching all four flows, across all PSPs, every day, at transaction level.
Why every PSP breaks reconciliation in a different way
Each provider makes internally consistent choices that complicate consolidated treasury data.
| Dimension | How PSPs differ | Reconciliation problem it creates |
|---|---|---|
| Settlement cycle | T+1 to monthly schedules | Funds from the same business day arrive on different dates |
| Settlement file format | CSV, JSON, proprietary XML, SFTP batch, API push etc. | Normalisation is required |
| Transaction ID schema | Each PSP assigns its own reference | Mapping the PSP's reference back to the internal order ID requires a maintained cross-reference table; any gap breaks the audit trail |
| Fee presentation | Some PSPs deduct fees from gross before settlement (net settlement); others invoice separately (gross settlement) | Mixing both can create accounting misclassifications |
| FX conversion timing | Some PSPs convert at time of transaction; others at time of settlement | The exchange rate embedded in the settlement file may not match the rate in the internal records, creating phantom gains or losses |
| Refund and chargeback handling | Some PSPs offset refunds against the next settlement batch; others create separate credit entries | Timing mismatches may require backdated corrections. |
Fees, FX and the margin that leaks between them
Every headline rate hides a complex fee stack. Transactions incur interchange fees, which the UK Interchange Fee Regulations cap at 0.2 per cent for domestic consumer debit and 0.3 per cent for credit. Scheme fees, processor markups, and hidden FX spreads further erode margins.
For global marketplaces, navigating multi-currency accounting is complex when inbound and outbound conversions utilise completely different rates.
Modern treasury platforms with PSP reconciliation capabilities decompose these fee layers automatically, flagging variances that exceed tolerance thresholds and enabling multi-currency accounting that traces every conversion.
What the settlement gap does to the cash position
Thee settlement gap is the delay between purchase and bank clearing. With multiple providers, this creates a rolling, overlapping arrival pattern. Processing, for example £50 million in monthly volume with a 2.5-day settlement lag leaves approximately £4 million in transit. The settlement gap creates three problems:
1. Cash forecasting errors
If a cash forecast reflects bank balances rather than earned-but-unsettled revenue, the forecast will systematically understate available liquidity.
2. Seller payout timing mismatch
Sellers expect quick payment, but PSPs settle on their own schedules. A marketplace either holds sufficient liquidity to bridge the gap, tying up working capital, or can choose to delay seller payouts.
3. Month-end distortion
If settlement batches straddle month-end, funds earned in month M may not appear in the bank until month M+1. Without an accruals entry, both P&L and cash flow statements for month M will be understated.
Deloitte's 2024 Global Corporate Treasury Survey found that 49 per cent of treasurers now prioritise creating scalable treasury operations, up from 39 per cent in 2022, with particular focus on treasury accounting and bank administration. The settlement gap is exactly the kind of problem driving that shift. Good cash positioning requires visibility into earned-but-unsettled amounts, not just cleared balances.
Chargebacks and refunds after the seller has already been paid
Chargebacks severely disrupt reconciliation because they arrive late, often incurring a £10 to £25 processing fee. By the time a dispute is finalised, the seller has usually been paid, leaving the marketplace with an unsecured exposure. The accounting remedy requires reversing the income, recording the loss, and separately tracking the fee. Refunds present similar timing mismatches, reducing future settlement batches rather than the current day's ledger.
Who signs off the journal entry at month end
Month-end close for a multi-PSP marketplace requires sign-off from people who rarely talk to each other: the payments team who understand PSP settlement files, the finance team who own the general ledger, and often the treasury function who manage the float.
Typical journal entries at month end include:
- Revenue recognition entries: gross transaction value for each PSP, posted to revenue, with corresponding accounts receivable representing settlement not yet cleared to bank.
- Fee expense entries: for each PSP, processing fees posted to expenses or payables.
- FX revaluation entries: earned-but-unsettled amounts in foreign currency marked to closing exchange rate, with movement going to foreign exchange gain or loss.
- Chargeback reserve provision: if you hold a rolling reserve, the monthly movement is posted as chargeback expense and chargeback reserve liability.
Who signs off these entries? In practice, payments operations prepares the reconciliation, matching PSP files to internal order data and flagging unmatched items. The financial controller or head of accounting reviews the reconciled data and prepares the bank reconciliation and journal entries. The treasury manager validates the float positions and FX revaluation. CFO or financial controller sign-off is required before entries are posted if variances exceed a materiality threshold.
One reconciliation flow for money in and money out
Treating inbound and outbound reconciliation as separate workflows guarantees discrepancies. A robust process standardises files, matches inbound records, decomposes fees, calculates net seller liability, verifies available cash, and posts accurate ledger entries.
A typical, robust reconciliation flow can follow six steps:
1. Normalise
Ingest settlement files from all PSPs and transform them into a single standardised schema.
2. Match inbound
Match normalised PSP records to internal order records at transaction level. Flag unmatched items.
3. Decompose fees
For each matched transaction, calculate expected fees per contract and compare to actual fees. Any variance exceeding threshold is a break requiring investigation.
4. Calculate seller liability
For each settled order, compute the seller's net entitlement: gross order value minus marketplace commission, minus fees passed through, minus open disputes.
5. Compare to available cash
Before initiating seller payouts, validate that aggregate payable to sellers does not exceed aggregate funds settled from PSPs and available in the bank account.
6. Post and close
Post all reconciling entries to the general ledger: revenue, fees, FX adjustments, seller payables and settlement gap accruals. Submit for controller and CFO review.
For marketplace operators, the choice is clear: continue running reconciliation as disconnected manual processes across multiple PSPs, or invest in unified treasury infrastructure that treats reconciliation as a single automated workflow from buyer payment to seller payout to general ledger entry.
