Processor reconciliation is the process of matching payment processor reports against internal transaction records, settlement files, fee schedules, and bank deposits. The core challenge is that processors format, net, and deliver data in ways that do not map directly to internal records. Fee netting reduces gross settlement amounts before funds reach the bank. Batch aggregation combines hundreds of individual transactions into a single deposit. Timing differences between processing dates, settlement dates, and posting dates create a third layer of mismatch. Without a reconciliation layer between them, processor figures and ledger figures will rarely agree.
What processor reconciliation covers beyond settlement matching
Processor reconciliation spans several distinct data types, each requiring separate matching logic:
- Settlement reports. The gross transaction amounts captured during a processing period, before fees and adjustments are deducted.
- Fee reports. Interchange fees, scheme fees, gateway fees, and acquirer markups deducted before net settlement is paid out.
- Chargeback and refund reports. Adjustments that reduce net settlement and must be matched back to the original transaction records in the internal ledger.
- Reserve reports. Rolling reserve balances held back by the processor, reconciled against expected release schedules and internal ledger entries. Reserve reconciliation tracks held funds and expected release dates as a separate open item workflow within the broader processor reconciliation process.
- Bank deposits. The actual funds received in the settlement account, which should match net settlement after all deductions have been applied. Bank reconciliation automation verifies this final layer independently, confirming that funds moved from the processor reached the bank in the expected amount.
Each report arrives separately, on its own schedule, in its own format. A payment company reconciling against Stripe, Adyen, Worldpay, Fiserv, and Checkout.com must handle each processor’s data structure independently. Cross-source matching cannot occur until that normalization is complete.
Why processor data requires transformation before matching can occur
Payment processors deliver reconciliation data through SFTP file drops, CSV exports, processor APIs, and webhooks, on schedules that vary by processor and by report type. Settlement files may arrive daily while fee reports arrive monthly. ACH batch files specify the effective date on which transactions are intended to post, and a single file can contain transactions that hit different accounts on different dates. Card network processors use a different structure: the funding date is set in the acquirer’s time zone, which can differ from the transaction date or the internal posting date recorded in the ledger.
These format differences mean raw processor data cannot be compared directly against internal transaction records. The processor assigns its own transaction ID, capture ID, and settlement ID to each event. The internal ledger records the same transaction with a merchant reference ID. The posting date in the ledger may differ by one or more days. Before any matching can occur, both data sets must be normalized into a common schema that maps processor identifiers to internal identifiers and aligns date fields across time zones and delivery formats. Rexi normalizes processor data from Stripe, Adyen, Worldpay, Fiserv, and Checkout.com into a unified schema before matching begins, mapping processor transaction IDs to internal merchant reference IDs and aligning date fields across time zones.
Why fee netting, batch aggregation, and timing cause most processor discrepancies
Most processor reconciliation discrepancies originate from three structural causes, not data entry errors.
Fee netting means that processors deduct interchange fees, scheme fees, and acquirer markups from gross transaction amounts before paying out net settlement. Under IC++ pricing, merchants are charged the interchange fee, the scheme fee charged by Visa or Mastercard, and a pre-negotiated acquirer markup, all deducted before net settlement is transferred. Interchange fees vary by card type. If the processor’s fee schedule differs from the one recorded internally, the net settlement amount will not match the expected figure, and the difference surfaces as an unmatched settlement that must be investigated against the processor’s fee report.
Batch aggregation groups multiple individual transactions into a single combined bank deposit. When a processor pays out a batch of 500 transactions as one deposit, the internal ledger must match that deposit against 500 separate transaction records, requiring one-to-many matching logic. If any transaction in the batch carries a refund, chargeback, or fee deduction, the batch total changes without the deposit record showing which individual transaction caused the difference. The finance team must work back through the batch to find the break.
Timing differences between processing dates, settlement dates, and bank posting dates produce open reconciliation items that appear as discrepancies until all three dates align. A transaction authorized on Monday may be captured on Tuesday, settled by the processor on Wednesday, and posted to the bank account on Thursday, potentially in a different time zone. Each event appears in a different system with a different date stamp, representing the same transaction but not matching without explicit date-mapping logic.
Why unresolved processor discrepancies become write-offs
When processor discrepancies are not identified and investigated promptly, they age into unresolved items that finance teams eventually write off as unexplained variances. Around 2 to 5 percent of all payments result in enquiries on any given day, and operations teams spend an average of 3 to 4 minutes investigating each one. At high transaction volumes, that burden accumulates quickly. A fee mismatch of a few basis points across millions of transactions represents meaningful revenue leakage that must be caught and recovered before the close cycle ends.
Processor discrepancies also have a time limit. Processors set dispute windows and data retention periods that restrict how far back a payment company can investigate and recover funds. Catching and classifying discrepancies at the point they occur is the difference between a recoverable exception and a write-off.
Dig deeper: Multi-Provider Payment Reconciliation
How to handle incomplete or delayed processor data
When processor data does not arrive on schedule, the reconciliation system faces a classification problem before it can route the exception correctly. A missing settlement file can mean one of two things: the file is delayed and will arrive within the processor’s normal delivery window, or it is genuinely missing and requires escalation. Treating a genuine missing settlement as a routine timing difference lets it age past the processor’s dispute window, at which point recovery becomes significantly harder.
The practical difference is in how the exception is held. A delayed file is tracked as an open item against the expected delivery date, with the system checking each processing cycle for its arrival. Automated reconciliation platforms maintain audit trails across payment flows and accelerate the identification of settlement variances, allowing finance teams to classify a delayed file separately from a genuinely missing one without relying on manual investigation. A genuinely missing settlement triggers a separate workflow: finance teams contact the processor, document the expected settlement amount, and record the escalation in the audit trail. Both paths require different documentation for audit purposes, and the classification must be made at detection, not at period close.
Dig deeper: Payment Reconciliation Software for Fintech and Payment Companies
How Rexi handles processor reconciliation
Rexi ingests settlement files, fee reports, chargeback data, and reserve reports from processors including Stripe, Adyen, Worldpay, Fiserv, and Checkout.com via SFTP, API, and CSV, standardizing all inputs into a unified schema alongside internal transaction records. The Reconciler agent handles one-to-many batch matching to link aggregated deposits against individual transaction records and validates fee deductions against the agreed fee schedule to separate documented charges from unexplained variances. Missing or delayed processor files are tracked as expected deliveries rather than classified as breaks, giving the Investigator and Categorizer agents the context needed to route each exception correctly. The Auditor agent logs every match decision, fee validation, and exception resolution into an audit trail finance teams can access without engineering support.
Frequently Asked Questions
How is processor reconciliation different from PSP reconciliation?
PSP reconciliation focuses on matching records from a payment service provider against internal transaction records and ledger entries, with particular attention to gross-to-net settlement differences caused by fees, refunds, and chargebacks. Processor reconciliation is broader, covering all processor types including card acquirers, payment gateways, and card networks. It also extends to fee schedules, reserve balances, chargeback reports, and bank deposits beyond settlement files. The terms are often used interchangeably, but processor reconciliation typically implies a more complete view of the entire processor relationship across all report types.
Why does net settlement from a processor differ from gross transaction volume?
Processors deduct interchange fees, scheme fees, acquirer markups, chargeback fees, and refund adjustments from gross transaction totals before paying out net settlement. Under IC++ pricing, each fee component is charged separately at rates that vary by card type, transaction type, and geography. When the internal ledger records gross transaction amounts without accounting for these deductions, the expected bank deposit will differ from the actual one. The difference must be reconciled against the processor’s fee report to confirm whether the variance is fully explained by documented fees or represents a genuine discrepancy.
What happens when a processor settlement file does not arrive on schedule?
When a processor does not deliver an expected settlement file by the scheduled cutoff, the reconciliation system flags it as an open exception and tracks it against the expected settlement date. Finance teams must determine whether the delay is caused by a processor outage, a changed delivery schedule, or a genuine missing settlement. The exception stays open until the file arrives and is processed, or until the team escalates to the processor and documents the outcome. Exceptions that exceed a defined aging threshold should trigger escalation before the close cycle ends.
How do you reconcile a processor that aggregates settlements across multiple currencies?
When a processor aggregates settlements across multiple currencies into a single report, the reconciliation system translates each currency amount into the base currency of the internal ledger before matching can occur. The exchange rate the processor applies at settlement may differ from the rate recorded internally, producing FX discrepancies that require separate matching against the processor’s FX fee report. Reconciliation software handles this by normalizing all amounts to a common currency at ingestion, then tracking FX differences as a distinct exception category separate from fee or amount mismatches.
How often should processor reconciliation run?
Processor reconciliation should run daily at minimum for payment companies and fintechs processing significant transaction volumes. Most processors deliver settlement files daily, and delaying reconciliation allows discrepancies to accumulate across multiple settlement cycles, making individual breaks harder to trace. For payment companies with high intraday volumes, running reconciliation continuously against real-time webhook data reduces the lag between a discrepancy occurring and being detected, limiting investigation time and reducing the risk that unresolved items age past the processor’s dispute window.
