PSP Reconciliation Failure Runbook: Break Types, Matching IDs, and Escalation Checklists

When a reconciliation break shows up, the question is never “did it fail?” — the question is which layer failed and why. This runbook covers the break taxonomy, the per-PSP matching IDs you need, and the escalation procedure for Stripe, Adyen, Checkout.com, and PayPal.

The AI and automation layer — exception triage, continuous close, LLM-assisted categorization — is covered in AI-powered payment reconciliation. This article is the failure taxonomy and operator runbook that sits beneath it.

What PSP Reconciliation Actually Means

Payment reconciliation at the PSP level is a three-way match:

1. Internal order ledger — what your system recorded as captured/settled
2. PSP settlement report — what the PSP says it processed and paid out
3. Bank statement — what money actually arrived in your bank account

Most reconciliation tooling stops at the two-way match: internal ledger vs PSP report. That check tells you whether your transaction records agree with the PSP’s records. It does not tell you whether the money arrived.

The two-way match has a specific blind spot: a payout reported by the PSP that never reached the bank. Bank-side failures — routing errors, beneficiary account issues, bank-level holds — can cause a payout to be marked as settled by the PSP while never landing. The only way to catch this is the third layer: matching the bank statement credit to the PSP payout ID or batch reference.

The Core Settlement Objects You Must Match

Before investigating any break, establish the matching-ID chain for your PSP. One bank credit typically corresponds to one payout batch, which covers many transactions. Tracing from the bank statement back through the PSP report to the individual transaction requires knowing which IDs link these layers.

Gross vs net settlement — establish this first for any PSP, before reconciling. Getting this wrong causes systematic mismatches across every transaction.

• Stripe: Net per-transaction. Each balance_transaction row includes the Stripe fee and the net amount. The fee is deducted at the transaction level; there is no separate invoice.
• Adyen: Net batch, with a monthly true-up. The settlement batch is net of per-transaction fees, but Adyen’s monthly Processing Invoice is reconciled in the following month’s batch as an InvoiceDeduction line — a deduction you will see in the next batch that relates to the prior month’s fees.
• Checkout.com: Contractually either net or gross with a separate invoice. Confirm which model applies to your contract. Under the gross model, your bank receives a gross amount and a separate fee invoice arrives periodically.
• Worldpay: Net settlement. Fees are deducted at the batch level; verify specifics with your contract and Worldpay’s merchant portal reporting.

Top Reconciliation Break Types

1. Timing gap / settlement lag

What it looks like: Transaction captured but absent from any settlement file for the current period.

Root causes: Normal T+N settlement delay. Stripe’s default settlement is T+2 business days in the US (longer in many other markets); Adyen settlement frequency depends on your contract (daily or weekly). A transaction captured late in the day may not appear until the next batch. Adyen consolidates Friday through Sunday into a single batch paid out the following week — exact payout day depends on the configured payout delay.

How to resolve: Age the open item. A timing gap is only a genuine break if the transaction has not appeared in any settlement file past your PSP’s stated T+N window. Set aging alerts at T+N+2 before treating it as a missing record.

2. Missing PSP record

What it looks like: Your internal ledger shows a capture; the PSP settlement report has no matching transaction.

Root causes: Capture failure (authorization succeeded but capture did not post); API error not reflected in the webhook; settlement file delivery failure; the transaction was voided or expired before settlement.

How to resolve: Query the PSP’s transaction status API using your internal reference. Check for void or expiry events. If the PSP confirms the capture succeeded, open a formal inquiry citing the transaction ID, capture timestamp, and amount.

3. Missing bank credit (payout reported but not received)

What it looks like: PSP settlement report shows a payout; no matching credit on the bank statement for the expected value date.

Root causes: Bank routing error; beneficiary account issue; bank-side hold; Stripe payout failure (Stripe has a dedicated Failed Payouts report that surfaces these explicitly). For Adyen, the MerchantPayout TX…XT reference should appear verbatim on the bank statement — absence means either a bank-side issue or a matching error on the bank statement search.

How to resolve: This is the most serious break type — treat it as a priority. Check Stripe’s Failed Payouts report first if using Stripe. For all PSPs, obtain the bank-level transfer reference (Stripe trace_id, Adyen TX…XT reference, Checkout.com Payout ID) and query your bank with that reference directly. Do not wait more than 2 business days before escalating to the PSP.

4. Amount mismatch

What it looks like: PSP record and internal record match on transaction ID and date but disagree on amount.

Root causes: Partial capture (order amount differs from captured amount); rounding in currency conversion; Checkout.com’s documented round-down-and-carry-forward mechanic, where payout amounts are rounded down to two decimal places and the remainder carries forward to the next payout.

How to resolve: Check whether a partial capture was intentional. For FX rounding differences below your tolerance band, book as a reconciling item with a rounding account. For Checkout.com, verify whether the discrepancy matches the carry-forward pattern by checking whether the difference reconciles across the preceding and following payouts.

5. Fee mismatch

What it looks like: Expected fee differs from the fee in the settlement report.

Root causes: Rate-card change not reflected in your expected-fee model; tiered pricing that triggered at a different threshold; Adyen’s InvoiceDeduction truing up the prior month’s fees in the current batch; gross-vs-net confusion (treating a gross settlement as net and expecting fees that were never in the PSP report).

How to resolve: For Adyen: look for an InvoiceDeduction line item in the current batch and match it to the prior month’s Payment Processing Invoice. For all PSPs: if a rate change is suspected, request the current rate card from your account manager and compare against what was applied. Gross-vs-net confusion is not a PSP error — update your expected-fee model.

6. FX mismatch

What it looks like: Your treasury’s expected settlement amount in the payout currency differs from what arrived.

Root causes: FX conversion rate applied at capture vs settlement date; the PSP and your treasury using different mid-market rate sources; FX fees charged on top of the conversion rate.

How to resolve: Checkout.com locks the FX rate at the time of capture and discloses the FX Rate Applied per row in the Financial Actions report — compare the disclosed rate against what your treasury expected. Note that Checkout.com charges an FX fee on refunds separately, and the original FX fee on the forward transaction is not returned when a refund is processed. For Stripe and Adyen, review your contract for whether FX conversion is at capture or settlement time, and what the markup is over mid-market.

7. Refunds and chargebacks crossing settlement periods

What it looks like: A refund or chargeback appears in the current settlement period with no matching original sale in the same batch.

Root causes: This is the expected behavior, not a bug. Refunds and chargebacks in both Adyen and Stripe post to the current payable batch, not the original sales-day batch. Adyen documents this explicitly in the Settlement Detail Report structure. Stripe debits disputes and the dispute fee immediately at dispute creation and holds the funds for the duration of the dispute — the debit does not wait for the chargeback cycle to close.

How to resolve: When reconciling, do not expect refunds and chargebacks to appear in the batch corresponding to the original sale date. Match refunds back to their original transaction ID; match chargebacks by dispute ID to the original payment. Hold open the original transaction as “subject to chargeback risk” in your ledger until the dispute resolves.

8. Reserve and deposit movements

What it looks like: Unexplained deductions or additions to the settlement amount that do not correspond to any transaction or fee.

Root causes: Rolling reserve hold or release; Adyen Deposit Correction (Adyen controls the deposit amount and recalculates it daily — DepositCorrection lines appear when the target deposit changes); Adyen ReserveAdjustment lines for rolling reserve deductions and releases; PayPal reserve movements (T2103 = reserve hold, T2104 = reserve release; PayPal applies rolling, minimum, and jumpstart reserve types).

How to resolve: Map every reserve and deposit line in the settlement report to a reserved-balance account in your ledger. Do not delete or ignore these lines. Rolling reserve deductions reduce your net payout but are not a loss — they are held funds with a release schedule. Booking them correctly requires a reserved-balance account that mirrors the PSP’s reserve register.

9. Negative balance / debit payout

What it looks like: Instead of receiving a bank credit, your bank account is debited by Stripe.

Root causes: Refunds, disputes, and adjustments have exceeded transaction volume in the current Stripe payout cycle, creating a negative Stripe balance. Stripe recovers this by pulling from the linked bank account. This is standard Stripe behavior — documented, and expected under high-refund or high-dispute conditions.

How to resolve: A Stripe debit payout appears as a bank debit, not a credit. Reconciliation logic must handle both credit and debit payout types from Stripe. If the debit is unexpected, review the balance_transaction report for the dispute and refund volume that created the negative balance. For persistent negative balance risk, review your reserve management strategy.

10. Duplicates and unknown transactions

What it looks like: A transaction in the PSP settlement report has no matching internal record, or two PSP records map to one internal record.

Root causes: Genuine processing duplicate (double-capture on the same authorization); an unknown transaction may indicate unauthorized use of your merchant credentials; reporting period overlap creating apparent duplicates; a webhook delivery failure causing your system to not record a transaction that the PSP did process.

How to resolve: Treat unknown transactions as a potential fraud signal and escalate immediately. Do not simply write them off. For suspected duplicates, query the PSP’s dispute/inquiry API to check whether the duplicate has already been identified. For webhook delivery gaps, compare the PSP’s transaction count for the period against your internal count before closing.

Operator Action Table

File and Report Checklist

Pull these reports per PSP before starting any reconciliation investigation:

Stripe:

• payout_reconciliation.itemized — every balance_transaction contributing to a payout
• ending_balance_reconciliation — transactions not yet included in any payout (the open/unsettled balance)
• Failed Payouts report — payouts that did not land at the bank
• Dispute report — active and resolved disputes with debit/credit amounts

Adyen:

• Settlement Details Report — per-transaction data including InvoiceDeduction, ReserveAdjustment, and DepositCorrection journal types
• Aggregate Settlement Details Report — batch-level summary for volume matching
• Payment Accounting Report — fee decomposition report: interchange, scheme fees, markup (not the source of InvoiceDeduction or reserve lines)

Checkout.com:

• Financial Actions by Payout ID — filter the Financial Actions report by Payout ID to get all rows contributing to one bank credit
• Settlement Breakdown / Payouts Report — payout-level summary with Payout IDs matching bank statement entries

PayPal:

• Settlement Report (SFTP, T-code format) — full transaction-level settlement data
• Case Report — active and resolved dispute/chargeback cases

What to Check Before Escalating to Your PSP

Most breaks resolve before escalation if you run through this checklist:

1. Confirm the time zone and sales-day cut-off your PSP uses. Stripe processes in UTC (APAC markets use local start-of-day); Adyen’s sales day is a configurable 24-hour window; Checkout.com settlements generate in the configured settlement time zone. Sales-day boundary mismatches between your ledger’s time zone and the PSP’s cut-off cause a large share of apparent timing breaks — confirm the PSP’s specific cut-off before concluding a transaction is in the wrong batch.

2. Confirm gross vs net. Verify your expected-fee model matches your PSP contract. If you are on a gross settlement model and calculating expected net, the systematic difference is not a PSP error.

3. Check for period true-ups. For Adyen, look for InvoiceDeduction lines before concluding a fee discrepancy exists. For Checkout.com with gross settlement, check whether a fee invoice arrived separately.

4. Check the correct payout period. Adyen consolidates Friday through Sunday sales into a single batch paid out the following week — reconciliation will see three days of transactions consolidated simultaneously. Stripe instant payouts are excluded from the standard payout reconciliation report.

5. Collect the full ID set. Before escalating, have: the PSP’s own transaction ID, the payout or batch ID, your merchant reference, the report name and row, the bank statement line with the payout reference, expected vs actual amounts, and the report timestamp.

Evidence to collect for escalation:

• PSP transaction ID + payout/batch ID + your internal order/merchant reference
• Report name, date, and row number
• Bank statement line with the bank transfer reference (Stripe trace_id, Adyen TX…XT, Checkout.com Payout ID)
• Expected vs actual amounts (both)
• UTC timestamps for the transaction and the batch
• Screenshot or export of the conflicting rows from both the PSP report and your internal system

Monitoring and Prevention

Match-rate KPI by layer. Track match rate separately at each layer: (1) internal vs PSP two-way match; (2) PSP payout vs bank credit. A degraded layer-2 match rate (PSP reports payout but no bank credit) signals a bank-side problem; a degraded layer-1 rate signals a PSP data quality or fee model issue.

Unreconciled aging buckets. Segment open items by age: 0–2 days (within normal settlement window), 3–5 days (alert), 6+ days (escalate). Different thresholds apply by PSP based on their settlement frequency.

Tolerance bands for FX and rounding. Set explicit tolerance bands — for example, sub-cent differences for FX rounding — and auto-book items within tolerance to a reconciling account rather than leaving them open. This prevents your exception queue from filling with systematic noise.

Alert on payout-failed events. Subscribe to Stripe’s payout.failed webhook. For Adyen and Checkout.com, set up portal alerts or API polling for failed payout statuses. A failed payout that sits undetected for days creates a cash-flow gap.

Store PSP IDs at capture time. The single highest-leverage prevention: persist the PSP’s transaction-level ID (balance_transaction for Stripe, pspReference for Adyen, Action ID for Checkout.com, Transaction ID for PayPal) in your own order database at the time of capture. Every reconciliation failure is easier to investigate when you can query your own ledger by PSP reference without depending on the PSP’s search API.

For automation patterns across these layers — deterministic matching engines, LLM-assisted exception triage, and continuous close architecture — see reconciliation automation with LLMs.

Common Mistakes

Reconciling by day totals. Under a rolling payout model, the transactions paying out today were captured days ago. Matching today’s bank credit to today’s transaction volume will never balance. Reconcile by payout ID, not by calendar day.

Assuming the refund appears in the original batch. It does not — for Adyen or Stripe. Refunds and chargebacks post to the current batch. Searching the original sales-day batch for a refund is a dead end.

Treating gross-vs-net as a discrepancy. If your PSP settles gross and you expected net, the systematic difference is your fee model, not a PSP error. Establish settlement model first; reconcile second.

Ignoring InvoiceDeduction lines. Adyen’s monthly fee true-up appears in the following month’s settlement batch. Operators who process the settlement file and stop at per-transaction matching will see an unexplained deduction every month until they build InvoiceDeduction handling.

Deleting or zeroing reserve lines. Rolling reserve holds are not lost funds. If you delete ReserveAdjustment lines from the settlement file, your ledger will show inflated income and miss the liability. Book them to a reserved-balance account and track the release schedule.

Assuming Stripe instant payouts behave like standard payouts. Instant payouts are excluded from Stripe’s payout reconciliation report and must be reconciled separately. Mixing the two produces a systematic reporting gap.

---

Scope Note

PSP-specific mechanics in this article are verified against official Stripe, Adyen, Checkout.com, and PayPal documentation as of June 2026. Worldpay’s publicly accessible report-level documentation is thinner than the other PSPs covered here — specifics on Worldpay report formats and field definitions are partially login-gated; the settlement model (net) is confirmed but report structure details should be verified via Worldpay’s merchant portal documentation.

Terminology varies by PSP — the matching-table ID mapping is illustrative. No third-party error-rate statistics are included because none reviewed during research traced to primary sources; quantitative claims here are sourced from PSP documentation only.

The AI and automation layer (exception categorization, continuous close, LLM triage) is intentionally excluded from this article — see the AI-powered payment reconciliation and reconciliation automation with LLMs articles for that coverage.

Related References

• AI-Powered Payment Reconciliation — exception triage, the continuous close pattern, and AI tooling that sits on top of the deterministic matching layer this runbook covers.
• Reconciliation Automation with LLMs — LLM architecture for exception categorization, fuzzy matching, and narrative generation in payment reconciliation workflows.
• Reading Your Processing Statement Line by Line — MDR stack breakdown and how to read the fee components that drive fee-mismatch breaks in PSP settlement reports.
• Chargeback Operations KPIs — the KPI framework for the dispute and chargeback layer that feeds into reconciliation as a break type.
• PSP Vendor Lock-in and Hidden Costs — contract-level mechanics including settlement terms, reserve structures, and fee escalation clauses that determine what to expect in settlement reports.

For term definitions — reconciliation, settlement, rolling reserve, netting, chargeback, and PSP — see the Payments Glossary.