A card or wallet payment taken at the table may reach the bank later, grouped with other activity and reduced by refunds or fees. Comparing one day's sales total with one bank deposit can therefore produce a difference even when both records are correct. The difference does not identify its cause on its own.
This guide reconciles one identified payout batch: the activity the provider says the payout settles, the amount the provider reports paying and the amount the bank confirms receiving. It does not cover cash forecasting, refund case handling, physical cash or supplier invoices. The figures are an original fictional example in INR, not provider data, a fee rate or a benchmark.
Identify one batch before adding anything
Write down the provider, the merchant account, the currency, the payout reference and the reporting cutoff you used to view it. A batch belongs to one account and one currency. Mixing two accounts, or two payouts that happened to post on the same day, makes any difference impossible to trace.
Take batch membership from the provider's own itemised record of what that payout settled, not from your sales report for the same date. A payout can include payments from several days, refunds of earlier sales, fees and other adjustments, and the provider decides what goes in. Some providers do not identify the transactions behind a payout at all, and some payout types are not batched in this way. If the record does not state membership, say so and stop; do not build a batch by guessing which sales it probably contains.
Choose one fee basis and keep it
Contributing activity can be presented in two ways. A gross basis lists each payment at its full amount and shows fees as separate debit rows. A net basis shows each payment after its fee has already been taken. Use only the basis the evidence actually shows, and confirm it in the record. If you take a net activity export and then also enter the separate fee lines, the fees are deducted twice and the batch looks short by exactly that amount.
Leave the payout itself out of the contributing rows. The payout is the result being explained, not one of the movements that produced it; entering it as a debit beside the activity cancels the batch to nothing.
Worked example: payout PB-021
In this fictional batch for one account in INR, the provider's itemised record shows payments of 1,800.00, one refund of 100.00 and fees of 34.00, on a gross basis with fees shown separately. Signed, those contributions sum to a net batch of 1,666.00. The provider reports a payout of 1,666.00, and the bank statement separately confirms a receipt of 1,666.00 with its own reference.
| Fictional record for PB-021 | INR | Source |
|---|---|---|
| Payments included in the batch (credit) | + 1,800.00 | Provider itemised payout record |
| Refund included in the batch (debit) | - 100.00 | Provider itemised payout record |
| Fees included in the batch (debit) | - 34.00 | Provider itemised payout record, gross basis confirmed |
| Net batch | 1,666.00 | Calculated from the three rows above |
| Provider-reported payout | 1,666.00 | Provider payout record |
| Provider minus batch | 0.00 | Calculated |
| Bank-confirmed receipt | 1,666.00 | Bank statement entry and reference |
| Bank minus provider | 0.00 | Calculated |
Three records, two comparisons
The net batch, the provider-reported payout and the bank receipt are three records from two different parties. Enter each from its own source rather than copying one figure into the other fields; a copied number will always agree and proves nothing. Provider minus batch checks whether the listed activity explains the payout. Bank minus provider checks whether what was reported as sent is what arrived.
In the example both differences are zero. That shows the three records agree for this batch at this cutoff. It does not confirm that every sale was recorded under the right payment method, that the fee was correct under your agreement or how the activity should be treated in the accounts. Those are separate questions with their own evidence.
Dates that do not line up
A sale, its settlement into a payout, the provider's expected arrival date and the bank's posting date can all differ. The cited provider documentation, for example, groups payouts in its report by estimated arrival date rather than the date the bank posts the deposit, and its reconciliation data can become available after the funds arrive. Record each date separately and state which one you used to select the batch.
If the bank receipt is pending, the payout failed or you cannot yet confirm the deposit, record that status and leave the receipt blank. A missing receipt is unavailable, not zero. Entering zero would create an apparent shortfall before you have established what actually arrived.
Keep what sits outside the batch separate
Several figures sound alike but measure different things: gross customer orders, payment attempts, payments the provider accepted, balance that has become available and money that has reached the bank. Activity accepted but not yet settled into this payout belongs on its own outside-batch list with its expected treatment, not in an unexplained adjustment that makes the batch balance.
The same care applies to refunds. The refund row in a batch is the amount the provider settled in that payout. A refund case in your adjustments register may be partly settled, settled in a different payout or still pending, so check the link between the two before assuming the amounts match.
When the records disagree
Record each difference with its direction, what was checked, the evidence, the reason found and who decided the outcome under which authority. Keep an unresolved difference visible with an owner and a next check date. A difference does not by itself indicate an error or fraud; it may come from a timing boundary, a different fee basis or activity that belongs to another batch.
This simple model assumes one positive payout. A net batch of zero or less, a collection taken from the business, currency conversion, a bank deposit that combines several payouts or a manual payout the provider cannot allocate needs a different method; record why the case falls outside the model rather than forcing it through. The reconciliation does not approve payments or refunds, and it does not decide accounting treatment.
Where the principle comes from
Stripe's documentation on its payout reconciliation report describes matching each payout received in the bank with the batch of payments, refunds, fees and other transactions it settles. It states that the report applies to eligible automatic-payout configurations, including a stated platform exception, and that it cannot identify the transactions included in instant payouts. It also groups payouts by estimated arrival date rather than bank posting date and lists activity not yet settled separately. Only those general distinctions are used here. Its settings, schedules and software steps are not applied, and nothing here describes how any other provider batches payouts.
Put it into practice
Your action checklist
Your progress saves in this browser. No sign-up needed.
0 of 9 complete
From reading to doing
Cashless settlement reconciliation
Open Cashless Settlements for one identified positive payout. Record the provider, account, currency, payout reference and reporting cutoff, then confirm batch membership and whether the activity is gross with separate fees. Enter up to 12 uniquely referenced contributing entries or evidenced, non-overlapping groups with credit or debit direction, amount and evidence; retain the complete itemisation and check every transaction is represented once. The sheet sums the signed contributions to the net batch. Enter the provider-reported payout with its evidence, then the separately confirmed bank receipt and its reference. Provider minus batch and bank minus provider appear only when the required inputs and scope confirmations are valid; a missing figure is never treated as zero. Amounts use two decimal places. The sheet does not model negative-balance collections, currency conversion, combined bank receipts or unallocated manual payouts, and a non-positive net calls for a review of whether the sheet applies, not a conclusion about error or fraud. Manual sections keep payout, payment and bank dates, status, outside-batch activity, reasons, authority and follow-up. It does not decide accounting treatment or approve any payment or refund.
Open the Cashless Settlements tab in the launch workbook. Keep a copy for your own business.
Download the free workbook See what’s inside the toolkit →Sources & further reading
- Payout reconciliation report (Stripe Docs) ↗
Retrieved 8 November 2026. Used only for the general principles of matching a payout to the batch of payments, refunds, fees and other transactions it settles; the report's scope of eligible automatic-payout configurations, including the documented platform exception and its inability to identify transactions in instant payouts; grouping by estimated arrival date rather than bank posting date; and separate treatment of unsettled activity. Settings, payout schedules, APIs, pricing and software steps are not applied, no other provider's batching is implied and no accounting definition is adopted. PB-021 and all figures are original fiction.
Published by Keystonne Grow. Product links connect to the Keystonne ecosystem; check the linked product or service for its current scope.