PSP reconciliation is the process of matching payment service provider settlement files against internal transaction records, bank statements, and ledger entries to confirm that every payment authorized through a PSP has settled correctly and been recorded accurately. The core challenge is that PSP settlement reports rarely align cleanly with internal records. Fees, refunds, chargebacks, timing differences, and identifier mismatches create gaps between what a fintech expects to receive and what the PSP actually delivers.
For fintechs and payment companies relying on PSP-processed transactions as their primary revenue channel, unresolved PSP reconciliation breaks translate into cash flow risk, reporting inaccuracy, and regulatory exposure. A settlement amount that does not match the internal ledger is an undetected loss until it is investigated and closed.
How PSP settlement files are structured
A PSP settlement file is a report delivered by a payment service provider that details which transactions have been settled, what amounts were transferred to the merchant’s bank account, and what deductions were applied before settlement. Settlement files typically contain transaction IDs, authorization references, capture dates, gross transaction amounts, fee line items, chargeback deductions, rolling reserve holds, and the net deposit amount transferred to the bank.
PSPs deliver settlement files in different formats and on different schedules depending on the provider. Stripe delivers daily settlement reports with itemized fee breakdowns at the individual transaction level. Adyen aggregates settlements across multiple currencies before reporting, which means the net deposit figure reflects currency conversions and batch aggregations that must be reconstructed before matching can begin. Every successful transaction is registered in a Payment Account that also shows the respective fees and the amount available to the account holder. Finance teams must account for each provider’s file format, settlement schedule, and fee structure before automated matching can operate accurately. For a complete overview of the software that handles PSP reconciliation at scale, see payment reconciliation software for fintech and payment companies.
Why PSP settlement amounts differ from authorized transaction totals
The net settlement amount a PSP deposits into a merchant’s bank account is almost never equal to the gross value of authorized transactions for the same period. Four categories of deductions occur between authorization and settlement:
- Transaction and interchange fees. PSPs deduct processing fees, interchange fees payable to card-issuing banks, and scheme fees payable to card networks before calculating the net settlement amount. Fee rates vary by card type, payment method, and transaction volume, which means fee reconciliation is a separate matching exercise on top of transaction matching.
- Refunds and partial refunds. Refunds reduce net settlement in the period the PSP processes them, which may differ from the period the original transaction settled. Partial refunds create further complexity because the refunded amount must be linked back to the original transaction and deducted accurately from the expected settlement.
- Chargebacks. PSPs deduct chargeback amounts and chargeback fees from net settlement. Because chargebacks can be filed weeks after the original transaction, chargeback deductions may appear in a settlement file for a different reporting period than the transaction they relate to.
- Rolling reserves. Processors hold a percentage of gross settlement as a rolling reserve against future disputes. Reserve deductions reduce the net deposit and are released on a schedule that rarely aligns with the settlement period of the original transaction.
These deduction categories mean the gross-to-net reconciliation calculation is never straightforward. The amount of funds received in a bulk settlement can differ from the amount stated in the report because fees, refunds, and reserve holds are netted before the deposit is calculated. For fintechs operating across multiple currencies, processing transactions in multiple currencies increases reconciliation complexity when the exchange rates applying to incoming and outgoing flows vary, adding a FX conversion layer on top of the fee deduction calculation.
The most common causes of PSP reconciliation breaks
PSP reconciliation breaks occur when automated matching tools cannot link a settlement record to an internal transaction record. The most common structural causes are:
- ID mapping failures. PSPs assign their own settlement IDs and batch references that rarely match internal transaction IDs, authorization IDs, or capture IDs. When no shared identifier links the PSP record to the internal record, matching requires a secondary strategy based on amount, settlement date, and counterparty.
- Timing differences between authorization and settlement. A transaction authorized on one date may appear in a PSP settlement file two or three days later depending on the provider’s batch settlement cycle. During this gap, the authorized transaction appears as an open item in the internal ledger that cannot be confirmed as matched or written off.
- Net versus gross amount mismatches. Internal systems typically record the gross authorized amount. PSP settlement files report the net amount after fee deductions. Matching gross against net triggers a false exception unless the matching rule accounts for expected deductions.
- Missing or delayed settlement files. The lack of a correlation between the transaction created on a gateway and the settlement received in a bank account means missing files cannot be detected automatically without a delivery monitoring layer that tracks expected file arrivals against actual receipts.
Dig deeper: Processor Reconciliation
What manual PSP reconciliation cannot sustain at scale
Experienced finance professionals devote most of their time to entering, verifying, cross-checking, and matching data rather than focusing on analysis. For fintechs processing high volumes of PSP transactions, manual reconciliation using spreadsheets or SQL scripts cannot sustain the matching volume, the fee deduction logic, or the exception tracking required to close the reconciliation cycle on time.
Spreadsheet-based PSP reconciliation breaks in predictable ways. Manual file import introduces data formatting errors that compound across cycles without detection. Unmatched records accumulate in a review queue with no escalation logic, no age tracking, and no assignment to an owner. Managing high transaction volumes across multiple systems creates operational complexity and regulatory exposure, while automation reduces the risk of undetected discrepancies. Finance teams that replace manual PSP matching with automated reconciliation shift from data aggregation to exception investigation, which is where their judgment is actually needed. As KPMG notes, a reconciled transaction-level foundation supports faster close, auditability, trusted reporting, and future AI-enabled finance operations. At volume, automated PSP reconciliation is not an efficiency improvement. It is the only viable control.
Rexi matches PSP settlement files against internal transaction records and ledger entries, applying separate matching rules for gross amounts, net amounts, and fee line items to reduce the volume of false exceptions that manual processes generate.
Dig deeper: Multi-Provider Payment Reconciliation
How Rexi handles PSP reconciliation
Rexi ingests PSP settlement files via API, CSV, and SFTP, separating settlement records, fee line items, refund entries, and chargeback deductions into distinct record types before matching begins. The Reconciler agent applies separate matching rules for gross amounts, net amounts, and fee line items, reconstructing the gross-to-net calculation per settlement period to confirm that deductions match the agreed fee schedule. Records where the calculation fails to reconcile are passed to the Investigator agent, which identifies whether the break is a timing difference, a fee overcharge, or a missing refund credit, before the Categorizer routes the exception to the right reviewer by type. The Auditor agent logs the gross-to-net reconstruction and each match decision into an audit trail accessible without engineering support.
Frequently Asked Questions
Does PSP reconciliation work differently for Stripe than for Adyen?
Yes. Stripe delivers daily settlement reports with itemized fee breakdowns at the individual transaction level, which allows direct transaction-by-transaction matching against internal records. Adyen aggregates settlements across multiple currencies before reporting, meaning the net deposit figure reflects currency conversions and batch aggregations that must be reconstructed before matching can begin. Reconciliation software handling both providers must apply different ingestion and matching logic for each settlement file format to produce accurate results without manual transformation steps between providers.
How long does it take to reconcile a PSP settlement file manually?
Finance teams reconciling PSP settlement files manually typically spend several days per reconciliation cycle as transaction volumes grow, with most of that time consumed by importing and formatting settlement data, mapping PSP transaction IDs to internal records, and investigating amount differences caused by fee deductions or timing differences. Automated PSP reconciliation reduces the matching cycle significantly by handling ingestion, standardization, and matching without manual intervention, leaving finance teams to focus on exceptions that require human investigation.
How is PSP reconciliation different from bank reconciliation?
PSP reconciliation matches settlement records from payment service providers against internal transaction records and ledger entries to confirm that the PSP has settled transactions correctly and deducted fees accurately. Bank reconciliation automation matches bank statement entries against internal ledger entries to confirm that the net deposit from the PSP has arrived in the bank account in the expected amount. PSP reconciliation operates at the provider level; bank reconciliation operates at the account level. A break in PSP reconciliation frequently produces a corresponding break in bank reconciliation because the net deposit the PSP reported does not match what the bank received.
What causes a PSP net deposit to be lower than expected?
A PSP net deposit is lower than expected when the provider has deducted fees, refunds, chargebacks, rolling reserve holds, or FX conversion losses before calculating the settlement amount. Fee deductions cover transaction fees, interchange fees payable to card networks, scheme fees, and any platform fees specified in the merchant agreement. Refund and chargeback deductions may appear in a settlement period that differs from when the original transactions were processed, creating timing mismatches between internal records and the PSP file. Finance teams must reconstruct the gross-to-net calculation from the PSP settlement file to confirm that all deductions match the agreed fee schedule before the reconciliation can be closed.
How does PSP reconciliation connect to payout reconciliation?
PSP reconciliation addresses the inbound side of the payment cycle: confirming that funds collected through payment service providers have settled correctly and arrived in the merchant’s bank account. Payout reconciliation addresses the outbound side: confirming that funds paid out to sellers, partners, or beneficiaries match internal payout records and processor settlement files. For fintechs and marketplaces that both collect through PSPs and pay out to third parties, both reconciliation workflows are required and must be linked at the transaction level to produce a complete picture of money movement across the payment stack.
