Payment Payout Reconciliation: Sales Are Not the Deposit

Reconcile payment-processor activity with bank deposits using transaction IDs, fees, refunds, payout timing, currencies, and an explicit opening-to-closing balance.

In this article

A payment-processor payout rarely equals the sales total for the same calendar day. Fees, refunds, disputes, settlement timing, and earlier activity can change the deposit. Reconcile the processor balance and the bank payout as connected records rather than forcing daily sales to match a bank statement line.

Stripe's balance summary documentation distinguishes balance activity from payout-specific reconciliation. Use the report that matches your question and check the current export definitions for your provider. The examples here are invented bookkeeping exercises, not accounting advice for a specific business.

Choose the reconciliation question

There are two common questions: how the processor balance changed over a period, and which transactions make up a particular payout. They use related data but need not select the same transaction dates.

A period balance review starts with opening balance, includes the relevant activity and payouts, and arrives at closing balance. A payout review starts with a specific payout identifier and follows the transactions assigned to it. Don't mix those selection rules midway through the calculation.

Record the report type, account, currency, timezone, and date range. A one-day shift at the boundary can make two correct reports look inconsistent. Use the provider's defined transaction and settlement fields rather than assuming every displayed date means the same thing.

Build a balance bridge

Consider an invented period with a $1,000 opening processor balance, $5,000 in sales, $150 in fees, $200 in refunds, and $4,000 paid out. Under these simplified assumptions:

text
Closing balance = 1,000 + 5,000 - 150 - 200 - 4,000
Closing balance = $1,650

The example deliberately excludes other possible adjustments. If the actual account has disputes, reserves, conversions, taxes, or corrections, include the relevant documented activity. Do not force an unexplained difference into a generic fee line.

Keep gross, fee, and net fields consistent with the export's definitions. Some reports present fees as positive deductions, while others use signed values. Inspect a known synthetic or already reconciled transaction to confirm the sign convention before summing thousands of rows.

Follow a payout by identifier

Resolve the payout ID in the provider's supported report. Compare its amount and currency with the bank receipt and any bank reference. A similar date and rounded amount are weaker identifiers, especially when several payouts occur close together.

Check whether the payout was pending, paid, failed, or returned according to the provider's actual status model. Do not count a queued payout as cleared bank cash. A failed payout can create another balance movement that needs its own record.

If the bank amount differs, inspect bank charges and conversion evidence where applicable. Do not assume the processor omitted sales until the relevant settlement and bank records have been compared.

Handle refunds and disputes explicitly

Link each adjustment to its original transaction where the export supports that relationship. A refund processed this week can relate to a sale from an earlier period. That is one reason a current payout need not resemble current gross sales.

Track the status and timing of disputed funds without assuming that every dispute is final. Follow the provider's records and the business's accounting policy. Keep sensitive customer and payment details out of shared troubleshooting sheets unless they are necessary and authorized.

Do not delete apparently duplicate rows based only on amount and customer name. Two legitimate transactions can share those values. Use stable transaction IDs and understand whether a report intentionally includes several records for one payment's lifecycle.

Keep currencies separate

Reconcile each currency using the relevant amounts and conversion records. Adding dollars, euros, and yen into one total produces no meaningful cash result. A report's settlement currency can differ from the customer's charged currency.

For a converted payout, retain the source amount, destination amount, and the actual rate or conversion transaction supplied by the provider. Avoid reconstructing the result using today's exchange rate. The conversion occurred under a particular transaction and time.

Our foreign-currency invoice guide covers planning exposure. Payout reconciliation is a historical evidence task: it should explain what actually happened, not replace missing records with a forecast.

Investigate the residual difference

After matching known components, list unresolved items with their identifiers and next action. Typical categories include a report-boundary mismatch, pending balance, missing adjustment, duplicate import, or bank timing. Use these as investigation labels, not as assumed explanations.

Retain the original export and prepare any cleaned data separately. Check row counts and totals before and after transformations. If a spreadsheet import changes identifiers or numeric precision, resolve that before relying on the final balance.

CSV Viewer can inspect a redacted export, and JSON Diff can compare structured report manifests. Neither accesses the processor or proves that a payout cleared. Keep authoritative transaction evidence in the approved financial system.

Conclusion

Reconcile balances by period and payouts by their identifiers. Preserve fees, adjustments, currencies, and timing instead of expecting sales to equal a deposit. A useful reconciliation ends with a supported balance bridge and explicit unresolved items, not a forced zero difference.

Advertisement
Payout Reconciliation: Sales vs Bank Deposits | Duck Cloud