A card processor usually pays the merchant a net settlement rather than sending one bank credit for every customer transaction. Finance therefore needs to bridge gross card sales through refunds, chargebacks, fees and reserves to the exact payout received in the bank.
Start with gross captured card transactions
Use the processor's transaction report for the same settlement period, not the till's headline sales alone. Authorised payments can later be voided, refunded or fail to capture, so gross settled sales can differ from checkout activity.
Separate currencies and business entities where the merchant uses more than one settlement account. One combined provider dashboard can hide which legal company actually earned the sale.
Subtract refunds, chargebacks and other balance movements
Refunds and chargebacks reduce the merchant balance but represent different business events. Add each as a separate reconciliation line. Also include reserve holds, reserve releases and manual account adjustments where the processor uses them.
Do not post the net bank credit as revenue. A £97,000 payout can represent £105,000 sales, £4,000 refunds, £2,000 fees and £2,000 chargebacks, and management needs all four numbers.
Record processing fees separately from revenue
Merchant service charges, gateway charges and other processor fees should be visible as payment costs. Whether the provider deducts them from each payout or invoices them separately changes the bank mechanics but not the economic expense.
Compare effective fee rate over time. A rise can reflect pricing, transaction mix, international cards or higher refunds. Reconciliation data is the foundation for understanding which factor changed.
Use the processor's payout reconciliation report
Stripe recommends its payout reconciliation report for matching automatic payouts to the balance transactions included in each payout. Worldpay similarly provides settlement and reconciliation views in its merchant dashboard.
Use the provider's payout ID as the link between bank and merchant ledger. That is stronger than trying to match by date and amount alone, especially when several payouts settle on the same day.
Separate settlement speed from payout schedule
Stripe's August 2026 guidance distinguishes settlement speed, which determines when transaction funds become available, from payout schedule, which determines when available money is sent to the bank. A delay can arise at either stage.
Cash forecasting should therefore use provider availability and payout settings, not assume every Monday sale hits the bank on Tuesday. New or higher-risk accounts can also have longer settlement patterns.
Resolve unmatched payout differences daily or weekly
High-volume merchants should not wait until month-end to investigate every settlement. Frequent reconciliation catches missing payouts, unexpected fees and duplicate refunds while provider data is still easy to retrieve.
Keep an exception queue with owner and target date. A £50 difference can be immaterial individually but repeated unexplained adjustments can hide a configuration or integration problem.
Worked example: the merchant processes £250,000 of captured sales. During the same payout cycle it records £8,000 of refunds, £3,000 of chargebacks, £5,500 of fees and a £10,000 reserve hold. The expected payout is £223,500 before any other adjustments. That bridge should exist before finance sees the bank credit.
For multi-day payout batches, store the provider's cut-off timezone and settlement dates. A transaction at 11:30pm can fall into a different payout from the till day, creating false differences if finance matches only calendar date.
Reconcile merchant balances still held at the processor as well as payouts already received. Month-end cash can exist in three places: bank, available processor balance and pending or reserved processor funds. Management reporting should distinguish them.
Set a formal month-end ownership rule for processor balances. Finance should identify which transactions have settled to the processor but not yet reached the bank, which amounts are reserved, and which are still pending capture. Without that bridge, management can double-count cash by treating both the bank payout and the processor balance as available funds.
For businesses with several acquirers, create one reconciliation template and require each provider to feed the same core fields: gross sales, refunds, disputes, fees, reserves, payout ID and bank date. Standardising the output makes provider comparison easier and reduces the chance that one acquirer's unusual report format hides an exception.
Assign ownership for payout exceptions by category. Finance can investigate fee and bank differences, customer service can resolve refunds, and payments operations can handle processor reserves or disputes. One reconciliation owner should still track the exception to closure so it does not disappear between teams.
Editorial Verdict
Card reconciliation starts with gross customer transactions and ends with the exact net payout in the bank. Every refund, chargeback, fee and reserve movement should explain the bridge between those points.
Use provider payout IDs and reconciliation reports, separate settlement timing from payout schedule and resolve exceptions frequently. A net bank credit is cash evidence, not a complete sales ledger.
Sources
- Stripe UK, Payouts explained, updated August 2026: https://stripe.com/gb/resources/more/payouts-explained
- Stripe UK, Payout reconciliation reports: https://support.stripe.com/questions/payout-reporting-options?locale=en-GB
- Worldpay UK, Dashboard reconciliation and settlements: https://worldpay.com/en-GB/products/dashboard
- Stripe UK, Payment processing best practices: https://stripe.com/gb/guides/payment-processing