Payout reconciliation: why your payout differs from your sales

Your store shows €50,000 in successful payments, but the bank receives €44,600. Before you ask where the other €5,400 went, check whether those two numbers describe the same money.

A sales dashboard measures activity in your business. A processor payout reflects the transactions and adjustments included in a transfer. Comparing the two without matching their scope can make normal timing differences look like missing revenue, or hide an actual discrepancy inside an apparently reasonable deduction.

Payout reconciliation means tracing the bank deposit back to its payment activity and explaining every difference. This guide shows how to do that with a worked ecommerce example and a repeatable investigation process.

Start by separating sales, payments and payouts

Keep four sets of records available. Each answers a different question, so none should silently substitute for another.

For example, an order placed on Monday might be captured on Tuesday, included in a later settlement batch and deposited after that. A refund processed this week might relate to an order from last month. Filtering every system to “this week” does not automatically produce comparable totals.

Daily payouts also do not mean same-day access to every sale. Stripe distinguishes the payout schedule from settlement timing: the schedule controls when transfers are sent, while settlement timing controls when pending funds become available. Check the actual arrangement for each account instead of applying one assumed delay across your whole business.

Choose the right starting point for the investigation

If you are investigating one bank deposit, start with its processor payout or batch reference and work backwards. If you are closing a month, reconcile the processor balance over that period as well. These are related tasks, but they need different scopes.

For Stripe automatic payouts, the Payout reconciliation report connects a payout to its underlying balance transactions. Its date filter uses the estimated payout arrival date, which can differ from the bank posting date. For manual payouts, Stripe generally points merchants to its balance report; Instant Payouts also require the merchant to reconcile against transaction history rather than assume an automatic transaction-to-payout allocation.

Adyen's Settlement details report provides transaction-level settlement entries as well as items such as fees, invoice deductions and deposit or reserve adjustments. Keep those adjustment rows when importing the file. A report containing only sales cannot explain every movement in a payout.

Whichever provider you use, write down the merchant account, payout reference, currency, report time zone and date basis before doing the arithmetic. For a multi-MID business, reconcile each account and currency separately before combining the results.

A worked example: tracing €50,000 to a €44,600 payout

Illustrative data only. These are invented amounts to explain the method, not Paysight customer results, quoted processor prices or a standard reserve policy.

Assume one merchant account, one EUR settlement batch and no currency conversion or separate bank charge. You have already matched €50,000 of captured payments to this batch. The settlement file contains the following additional movements:

The bridge is:

€50,000 − €2,000 − €500 − €1,400 − €2,500 + €1,000 = €44,600.

Every euro in the difference has an explanation. The €1,400 is fees; the refund and disputed principal are separate deductions; the reserve movements explain another part of the cash difference. Calling the entire €5,400 “processing costs” would misstate what happened.

The matching work matters as much as the calculation. The refunds and dispute can relate to older sales even though they affect this batch. The reserve release belongs here because it is included in this payout, not because it came from the same sales cohort. Adyen's documentation, for example, explicitly identifies reserve adjustments as debit or credit entries.

If the bank instead received €44,500, the unexplained difference would be €100. Keep that amount open for investigation. Do not label it a fee simply to make the spreadsheet balance. Conversely, if you start from a processor's already-net payout amount, do not subtract the same refunds and fees again.

To evaluate pricing once the cash movements are understood, use our separate guide to calculating your effective payment processing rate.

Build a matching file that survives multiple processors

A useful reconciliation file should let a colleague reproduce your result without asking which dashboard filter you used. Keep the original exports unchanged and do the matching in a separate working file.

1. Identify the account and currency. Include the provider, merchant account or MID, legal entity and settlement currency. An amount without that context is not a reliable match.
2. Preserve the identifiers. Keep the order reference, processor payment reference, refund or dispute reference where relevant, balance-entry reference and payout or batch reference. Use the provider's documented relationships between them. Matching on amount alone is weak when many customers buy the same offer.
3. Keep each event's date. Preserve order, capture, balance-entry, payout and bank-posting dates where available, including the time zone. Do not rename all of them “transaction date.”
4. Keep gross, deductions and net distinct. Record the original entry type and sign before normalizing it. Separate monetary debits from explanatory fee columns so you do not count a deduction twice.
5. Record the outcome. Mark each item matched, awaiting its expected payout or unresolved. Add an owner and next review date to unresolved amounts.

For an illustrative €100 order captured as €60 and €40, expect two capture records rather than forcing a one-order-to-one-payment match. A later €20 refund is another event. Keep its relationship to the original payment instead of overwriting the order's history. Apply the same care when a subscription invoice has several failed attempts followed by one successful collection: attempts are not separate receipts of money.

When a payment and its settlement use different currencies, preserve both amounts. Stripe's Balance summary report, for example, reports transactions in settlement currency after any required conversion. Compare the payout with the bank amount in the same currency, and investigate conversion or bank charges separately when the receiving arrangement introduces them.

Investigate exceptions in a consistent order

1. Check whether you selected the correct batch

Start with the payout reference, account and currency. Then inspect the date range and time zone. If a captured payment is not in this batch, locate its expected destination or pending status rather than adding it to the payout total manually.

2. Look for an adjustment outside the sales export

Read the complete settlement file for refunds, disputes, fees, reserves and other credits or debits. Match each to supporting evidence. For an unfamiliar entry, use the provider's report definitions and the account's own statement or agreement; labels do not necessarily mean the same thing across processors.

3. Separate “not yet received” from “not explained”

A transfer with an identified payout reference and an expected arrival date is different from an unexplained reduction in its amount. Track both, but assign the right next step. For a delayed transfer, check its status and account-specific arrival expectation. For a numerical mismatch, identify the missing or duplicated entry.

4. Send a precise escalation

Give the provider the merchant account, payout ID, currency, expected amount, actual amount, relevant dates and unresolved references. Attach the relevant report rows and bank evidence through its approved support channel. A reproducible €100 discrepancy is far easier to investigate than “our dashboard says we are missing money.”

Close the period as well as the individual payout

Matching every deposit does not prove that every payment has reached the bank. Some funds can remain in the processor balance at the end of the month.

A period-level control is:

Opening processor balance + net activity excluding payouts − payouts = closing processor balance.

This follows the structure of Stripe's balance report. Use the provider's definition of the balance and account separately for funds held outside that reported balance.

For an illustrative period, €8,000 opening balance plus €46,100 net activity, minus €44,600 in payouts, leaves €9,500 at the processor. This is a separate period-level example, not an extension of the batch table. The €9,500 needs to be explained by the ending-balance records; it is not automatically overdue.

Keep an exception list with the amount, reason, expected resolution date and responsible person. Review unresolved items against the timing promised for that account. This gives you a practical way to notice when a normal timing difference has become an overdue payment.

Where Paysight fits into the workflow

Paysight's Payment CRM brings transactions, customer activity, subscriptions and reporting into one operational system. Its report builder lets teams examine transaction-level data and MID groups, helping them understand which activity they are investigating.

You still need the relevant processor settlement records and bank evidence to confirm a deposit. When evaluating your setup, check which identifiers and exports are available across the systems you use.

If your team is piecing together payment activity across several accounts, book a Paysight demo around those reporting needs. Bring an example of the reconciliation problem you want to solve so the conversation can focus on the data and workflow your team actually needs.