A reconciliation exception is an unmatched or mismatched record surfaced during payment reconciliation. Two records that should align, such as a processor settlement entry and its corresponding bank credit, or a PSP payout file and an internal ledger entry, do not match on a key field such as amount, currency, identifier, or date. The exception is a signal. It does not, on its own, confirm that the underlying transaction contains a genuine error.
Exceptions fall into six recurring patterns: timing gaps, amount mismatches, FX variance, missing bank credits, missing PSP records, and duplicates. Some indicate financial loss or a data failure that requires immediate investigation. Others are temporary discrepancies that auto-resolve once a counterparty record arrives. Understanding which type you are dealing with determines how quickly a finance team closes its reconciliation cycle and where investigative effort should be focused.
The Six Types of Payment Reconciliation Exceptions
The table below covers the exception types that appear most frequently in payment operations, along with their typical cause and how automated reconciliation systems handle each one. Similar exception categories appear across reconciliation vendors and PSP documentation, including Modern Treasury, Stripe, GoCardless, and Adyen; the classification below follows one vendor’s payment reconciliation architecture guide.
| Exception Type | Cause | Typical Resolution |
|---|---|---|
| Timing gap | Authorized but not yet settled (T+1 or T+2 settlement lag) | Auto-resolve after the settlement window passes |
| Amount mismatch | PSP settled amount differs from the captured amount | Manual review: may indicate fee miscalculation or PSP error |
| FX variance | FX rate difference between internal record and PSP settlement | Auto-resolve if within tolerance; escalate if above |
| Missing bank credit | PSP settlement file shows payout; bank has no corresponding credit | Escalate: funds may be held, account details may be incorrect, or fraud |
| Missing PSP record | Internal transaction not in PSP settlement file | Investigate: transaction may be pending, duplicated, or failed |
| Duplicate | The same transaction ID appears in multiple settlement files | Auto-flag for PSP dispute: potential double-billing |
Each exception type carries a different level of urgency. A timing gap within a processor’s stated settlement window is expected and operationally benign. A missing bank credit or a confirmed duplicate requires immediate escalation.
Timing Gaps: Settlement Cycles, Not Errors
A timing gap occurs when a payment is authorized but has not yet appeared in a processor’s settlement file. Card networks and payment service providers typically settle on a T+1 or T+2 cycle, meaning funds authorized on Monday may only appear in a settlement file on Tuesday or Wednesday. During that window, the internal transaction record exists but the counterpart settlement record does not, producing an apparent mismatch with no financial consequence.
Timing differences are the most common cause of reconciliation breaks across payment operations, and most auto-resolve once the settlement window closes. A well-configured reconciliation system carries these items forward to the next settlement period rather than flagging them as exceptions requiring manual review. Timing gaps require escalation only when they remain open beyond the processor’s stated settlement window, at which point they may indicate a failed settlement batch or a processing error at the PSP level.
Amount Mismatches and Fee-Related Exceptions
An amount mismatch occurs when the settled amount from a PSP or processor does not match the captured transaction amount in a company’s internal records. The most common causes are PSP fee deductions embedded inside net settlement figures, refund or chargeback adjustments applied without a corresponding internal record, and rounding differences in fee calculations across card schemes.
PSP reconciliation involves matching settlement files against internal transaction records field by field, which is where amount mismatches most frequently surface. A related exception category appears in fee reconciliation: when processors apply interchange rates or processing fees that differ from contracted terms, the settled net amount does not match the expected amount based on the agreed fee schedule. Amount mismatches require manual review in most cases because they may indicate a billing error, a processor discrepancy, or a revenue leakage event that the finance team needs to investigate and potentially recover.
FX Variance: Currency Conversion Differences at the Transaction Level
FX variance occurs when a payment is processed in one currency and settled in another, and the exchange rate applied at settlement differs from the rate recorded internally at the time of authorization. For fintechs and payment companies processing cross-border transactions, FX variance is a structural feature of multi-currency payment flows, not an error in the underlying transaction.
Settlement timing creates legitimate FX variance. A transaction authorized at a given exchange rate on Monday may settle at a marginally different rate on Wednesday, producing a small discrepancy between the internal record and the settlement file. Reconciliation systems handle this using configurable tolerance thresholds, for example within 0.01% or a fixed ceiling such as $0.05, whichever is smaller. Exceptions within the threshold auto-resolve with the variance logged for audit. Exceptions above the threshold escalate for review, as a large FX variance may indicate an incorrect rate application or an undisclosed currency conversion fee charged by a correspondent bank.
Missing Bank Credits and Duplicates: The Exceptions That Require Escalation
A missing bank credit occurs when a PSP settlement file records a payout, but no corresponding credit appears in the bank account. This exception requires immediate investigation. Possible causes include funds held by the processor, incorrect beneficiary account details, a banking error, or fraud. One vendor’s payment reconciliation architecture guide assigns missing bank credit exceptions a 4-hour response SLA in its severity-based routing model, reflecting how tightly some reconciliation systems are configured to treat this exception type given the financial exposure of leaving it unresolved. Response windows for this category vary by organization and system configuration; a 4-hour SLA is not a universal industry benchmark, but it illustrates how seriously well-run reconciliation environments treat this exception type.
Duplicate exceptions occur when the same transaction identifier appears in multiple settlement files. Stripe’s analysis of duplicate payments identifies duplicates as a direct source of cash loss and reconciliation complexity: extra payments introduce mismatches across bank statements, subledgers, and vendor accounts, slowing month-end close and increasing manual investigation volume. Finance teams route duplicates to a PSP dispute queue rather than processing them through standard reconciliation, because leaving a confirmed duplicate unresolved produces direct financial loss through overpayment to the processor.
Why Most Exceptions Do Not Signal Genuine Errors
A reconciliation exception is a flag, not a finding. The break signals that two records do not match on a key field. It does not determine whether funds have been lost, whether a billing error has occurred, or whether the underlying transaction failed. Many exceptions are transient: they arise because two systems record the same financial event at different times, in different formats, or with slightly different values due to rounding or currency conversion.
The Modern Treasury State of Payment Operations 2025 report, conducted with Harris Poll across 500 US financial decision-makers, found that 88% of companies report problems with payment operations, with data quality errors (25%) and high rates of reconciliation errors (23%) among the most commonly cited shortfalls. These figures reflect the structural nature of exceptions in multi-source payment environments, not a failure of individual transactions. In a well-run reconciliation environment, the majority of exceptions resolve automatically, either by the arrival of a counterpart record, by a tolerance rule clearing an FX or rounding variance, or by the system matching a delayed settlement on the next cycle.
What determines operational risk is not the presence of exceptions but the volume, type, and age of those that remain unresolved.
What High Exception Volumes Reveal About Data Quality and Operational Cost
A high exception volume is more often a data quality signal than a matching logic failure. Reconciliation systems generate large exception queues when upstream data is inconsistent: truncated transaction identifiers prevent matching engines from linking records, missing timestamps block time-window comparisons, and non-normalized file formats from different PSPs produce apparent mismatches between records that describe the same event.
The operational cost of unresolved exceptions is measurable. The 2025 AFP Treasury Benchmarking Survey found that when a US organization discovers a discrepancy during bank account reconciliation, it takes an average of 6.1 business days to resolve it. For organizations with annual revenue below $1 billion, that figure rises to 8.2 days. Each exception that extends into multi-day investigation delays the close cycle, distorts general ledger balance accuracy, and increases the time required to produce audit-ready records.
Resolving exception volume at the data ingestion layer produces more durable results than expanding manual review capacity. Rexi ingests data from banks, processors, ledgers, and ERPs, normalizes it to a unified data model, and applies matching logic before surfacing exceptions. The exceptions that reach the queue are the ones that require a finance team’s judgment, not items that a consistent data pipeline would have matched automatically.
Dig deeper: Why Reconciliation Exceptions Multiply at Scale
Frequently Asked Questions
What is a payment reconciliation exception?
A payment reconciliation exception is an unmatched or mismatched record found during reconciliation. It appears when two records that should align do not match on a field such as amount, currency, identifier, date, or settlement reference. The exception is a signal that needs review; it does not automatically prove that money is missing, a customer was charged incorrectly, or the transaction failed.
What are the main types of payment reconciliation exceptions?
The most common types are timing gaps, amount mismatches, FX variance, missing bank credits, missing PSP records, and duplicates. Each type has a different cause and risk level. Timing gaps and small FX differences are often temporary or expected. Missing bank credits and duplicates usually require faster escalation because they can point to cash movement, posting, or payment processing issues.
Are timing gaps real reconciliation errors?
Timing gaps are often not real errors. They occur when one system records the payment before another system reports settlement or bank credit. Card payments and PSP payouts may settle on later cycles, so the internal record can exist before the external record appears. The key is to track the gap against expected settlement windows and escalate only when it remains unresolved beyond tolerance.
When should a reconciliation exception be escalated?
An exception should be escalated when it suggests cash risk, duplicate movement, fraud exposure, or a control failure. Missing bank credits, confirmed duplicates, unresolved amount mismatches outside tolerance, and records that age beyond the expected settlement window need faster review. Small timing gaps or known FX variance may be monitored or auto-resolved if they fall inside approved rules.
Why do most exceptions not signal genuine financial errors?
Most exceptions are caused by timing, formatting, fees, rounding, FX conversion, or data normalization issues rather than actual financial loss. The reconciliation process flags a mismatch because two systems describe the same event differently or at different times. The finance team’s job is to classify the exception, determine whether it is benign or material, and document the resolution path.
What does high exception volume reveal about data quality?
High exception volume often reveals upstream data quality problems. Missing transaction identifiers, inconsistent timestamps, non-normalized provider files, and incomplete settlement fields make matching harder even when the underlying transactions are valid. When the same exception patterns repeat, the issue is usually not only analyst capacity; it is the structure and cleanliness of the data feeding the reconciliation process.
