Stripe payout differs from sales: trace the itemized report

For an automatic Stripe payout, use the Itemized payout reconciliation report, not the sales total for the day the bank credited the deposit. The report groups the payout by its estimated arrival date. An actual bank posting can fall on another date, and reconciliation data can become available after the money arrives.

Official reference.

Find the payout population

1. Open Payout reconciliation in the authorized Stripe account.
2. Choose dates containing the payout’s estimated arrival; widen the interval if necessary.
3. Locate that payout and download Itemized CSV for the complete payout, rather than only one transaction category.
4. Retain automatic_payout_id, balance_transaction_id, currency and the exported gross, fee and net values. Compare the summed net with the actual bank credit in the same currency and destination account.

The report includes more than charges: refunds, disputes and other balance movements can explain why sales and cash differ. Preserve each balance event and its payout membership. Do not allocate a refund to the month of the original sale simply to make that month’s bank total agree.

Disputes and retries need their own identities

A dispute can have zero, one or two associated balance transactions for withdrawal and reinstatement. Keep the dispute and charge references in your supporting record, then use the actual balance-event and payout identifiers. The documented itemized CSV does not promise a dispute_id column. A won dispute does not prove that a particular bank credit has arrived; a later reinstatement belongs to its own actual payout. Stripe’s dispute object documents the balance-transaction relationship; the payout report specification lists its CSV fields.

When Failed payouts is present for the selected interval, inspect its itemized export. retried_payout_id can connect a failed payout with a later attempt. Two payout IDs for the same amount are not evidence of two bank receipts. Keep failure, retry and observed bank entries separate until the references establish their relationship. The payout report’s failed-payout section documents this retry reference.

Check a synthetic amount bridge

In the invented payout exercise, EUR 1,000 of charges less 30 in fees, 80 in refunds and 120 in dispute withdrawals produces 770. The failed attempt and its retry do not produce a second 770 receipt. A later 120 reinstatement belongs to a different payout. These arithmetic and identity controls test the example, not Stripe exports or bank compatibility.

POLD, PNEW and PNEXT are invented identities. The case supplies one bank observation for PNEW; it does not establish a bank receipt for the failed attempt or the later reinstatement.

Stop when the automatic-batch premise does not hold

For manual payouts, Stripe generally directs users to its Balance report; a platform on manual payouts with automatic connected-account payouts is an explicit exception. For instant payouts, the merchant controls timing and amount, so Stripe cannot identify the included transaction batch. Amount equality alone cannot supply that missing membership. Preserve an unresolved association instead of inventing one. See the Balance report and the payout-reconciliation limits for these manual and instant cases.

Related task.

For a PDF-only bank source, download LocalExtract. It processes one PDF locally to date,description,amount CSV; it does not access platform accounts or synchronize accounting records.

Official sources and scope

Documentation checked October 16, 2026. Official reference 1 — stripe-rec-full · Official reference 2 — stripe-balance-full · Official reference 3 — stripe-failures · Official reference 4 — stripe-dispute-md · Official reference 5 — stripe-categories · Official reference 6 — stripe-disputes