Freelancers and small business
Your Stripe payout is net cash, not your sales total
Your customers paid $250, but the bank shows a $222 Stripe deposit. That can be right: compare the payments, refunds and fees included in that payout, rather than expecting the deposit to equal your sales total.
By AnyStatement
Published , 8 min read
You need an explanation that connects the customer payments to the bank receipt. This guide shows how to build it from Stripe's own reports and leave any unexplained difference visible. It is Stripe-specific, not a rule for every payment processor. It doesn't decide revenue recognition or tax treatment; your accountant makes those decisions for your business and jurisdiction.
A customer payment and a bank deposit are different records
If you start with the invoice and jump straight to the bank statement, you miss what happened inside Stripe. There are four records to connect, and each answers a different question.
- A charge identifies the customer payment. Keep its reference so you can connect it to the invoice or order you're checking.
- A balance transaction records an effect on your Stripe balance. Charges, refunds, fees and payouts can all affect that balance. It has its own ID, separate from the underlying charge or refund.
- A payout moves funds from your available Stripe balance to your bank. An automatic payout can contain funds from multiple transactions.
- A bank receipt is the deposit actually recorded by your bank. Its amount and posted date are the bank-side evidence you need to find.
Stripe's payout reconciliation guide describes the charge, balance transaction and payout relationships. Its Bank reconciliation documentation then separates the payout amount from the amount received in the bank. Keeping those records separate prevents a payout from being mistaken for another customer payment.
The balance transaction is particularly useful when the numbers differ. Stripe's Balance Transaction reference defines net as gross amount minus fee. A positive net amount increases your Stripe balance; a negative one decreases it.
Use the payout report, not just the month's sales export
You need the transactions belonging to one payout, not every payment made during the month. For automatic payouts, Stripe's Payout reconciliation report groups the included activity into settlement batches.
- Open the Payout reconciliation report and choose a date range that includes the payout's estimated arrival date. Widen the range if you aren't sure, because the report isn't grouped by the bank's posted date.
- Find the payout in the Payout reconciliation section and download the Itemized CSV. That gives you the underlying payments, refunds, disputes, fees and other balance transactions, rather than only a total.
- Keep the payout ID, balance transaction ID, reporting category, currency, gross, fee and net columns. Include charge or source IDs and payout references where available so you can trace an unfamiliar row without guessing from its amount.
Save the original download and note the report's date range and time zone. Those details matter when someone tries to reproduce your total later. Stripe's column guide identifies automatic_payout_id as the link between a balance transaction and its automatic payout.
Check the currency before comparing those figures with your sales export. The payout report defines gross, fee and net in the currency named by its currency column. Its separate customer_facing_amount can be in the customer's original currency, which need not be the payout currency. Use the payout-currency figures for this check, and keep different currencies in separate totals.
For manual payouts, don't manufacture that link. Stripe says it can't identify the transactions included in a manual payout because you choose the amount and timing; it gives a similar warning for instant payouts. The Balance summary report is the alternative for reconciling activity through the Stripe balance. It includes activity and payouts during the selected period, but does not associate payments with payouts. The payout report also supports a platform on manual payouts when its connected accounts use automatic payouts; that is a specific exception, not manual-payout matching for everyone.
How $250 in charges becomes a $222 payout
Here is a fictional USD example. Payout A contains two customer charges, one refund and $8 of fees. The $3 and $5 fee amounts are invented for the arithmetic, not a quote of Stripe's prices. A separate $10 credit adjustment belongs to payout B, as identified by its payout reference in our example records.
| Record | Payout | Gross less fee | Net |
|---|---|---|---|
| Charge 1 | A | $100.00 - $3.00 | $97.00 |
| Charge 2 | A | $150.00 - $5.00 | $145.00 |
| Refund | A | -$20.00 - $0.00 | -$20.00 |
| Payout A total | A | $250.00 - $20.00 - $8.00 | $222.00 |
| Credit adjustment | B | $10.00 - $0.00 | $10.00 |
For A, the calculation is $250 - $20 - $8 = $222. Adding the three net amounts gives the same result: $97 + $145 - $20 = $222. These are two ways of checking the same activity, not two sets of transactions to enter into your books.
The simple gross-minus-refunds-minus-fees explanation works here because those are A's only ingredients. In your report, retain any other categories actually included in the payout. A charge export alone cannot explain an adjustment that it never contained.
You can copy this small practice CSV into a spreadsheet. It is a teaching layout, not a Stripe import file. The refund is already negative, and fees are positive amounts to subtract.
record,payout,gross_usd,fee_usd
charge_1,A,100.00,3.00
charge_2,A,150.00,5.00
refund_1,A,-20.00,0.00
adjustment_1,B,10.00,0.00With the header in row 1, =SUM(C2:C4)-SUM(D2:D4) returns 222 for A. Row 5 belongs to B and stays out of that calculation. In a real report, use the payout IDs to establish membership before you choose which rows to total. Adjacent rows aren't evidence that transactions belong together.
If you total the exported net column instead, don't subtract the fees again. That would turn $222 into an incorrect $214. And if you are working from API data rather than the report CSV, check the units: the Balance Transaction API uses the smallest currency unit, while the report's gross, fee and net columns use major units. For USD, 22,200 cents is $222.00.
January 31 and February 2 can both be right
In the same fictional example, payout A is initiated on January 31. Its estimated arrival is February 2, and the bank actually posts $222 on February 2. The charges in its batch were made in January. None of those dates needs changing to make the records agree.
Stripe's payout timing instructions say the report groups payouts by estimated arrival date, not bank posting date. Weekends, holidays and bank processing can affect arrival, and report data can become available after the payout arrives. Our dates illustrate a month boundary; they are not a promised two-day payout schedule.
| Payout | Initiated | Payout amount | Payout reference |
|---|---|---|---|
| A | January 31 | $222.00 | DEMO-A |
| B | February 3 | $10.00 | DEMO-B |
Here is the separate fictional bank extract for the destination account, also in USD. The references are invented for this exercise, not examples of Stripe's reference format. This extract contains only one deposit:
posted_date,reference,deposit_usd
February 2,DEMO-A,222.00A January-only bank statement therefore won't contain A's receipt. Carry the reference into your review of February instead of describing it as missing January sales. Also check what a date column means: in Stripe's Bank reconciliation report, payout_date means expected arrival, not initiation, while bank_receipt_date is the actual bank date.
The bank extract totals $222, and its DEMO-A reference matches payout A. The two payout records total $232, leaving B's $10 without a matched receipt. It does not make A wrong, and the lack of a DEMO-B receipt in this extract does not tell us whether B failed, is still travelling or needs a later statement.
A matching amount is a start, not the whole check
Once the batch adds up, compare it with the actual bank line. Check the destination account and currency, then the amount, reference and date. This keeps a convenient same-sized deposit from closing the wrong payout.
Stripe's Bank reconciliation field guide describes a matching_key shared between payouts and bank statements. The payout report also offers a payout_reference_token. Preserve these where your records provide them, but don't assume the entire description will survive: Stripe's report documentation says banks can truncate, inconsistently display or omit payout statement descriptors.
If the reference isn't visible, inspect the payout detail and the bank's full transaction detail. Record what you could match and what is still uncertain rather than inventing a reference. In our example, A has an explained batch and a linked $222 receipt. B remains open until its own bank evidence is found.
Don't rename an unexplained difference as a fee just to reach zero. Keep its amount, affected payout and the question that needs answering in a statement review log. A total that balances can still contain the wrong rows, which is why the reference checks matter as much as the arithmetic.
Stripe has a bank-matching report too, with limits
Before building a recurring spreadsheet job, see whether Stripe already offers the bank-side match for your account. Its Bank reconciliation report is different from the Payout reconciliation report: after you link the bank account and approve access, it matches Stripe payouts to bank deposits and shows received amounts, receipt dates and reconciliation statuses. It also separates monthly activity from cash actually received in the bank.
As documented when checked on October 17, 2026, this feature is limited to direct US-based Stripe accounts using an automated payout schedule. It excludes Stripe Connect accounts, accounts outside the United States, and manual or instant payouts. Those restrictions describe this bank-linking feature, not the availability of every Stripe report.
Even when it is available, read the exceptions. Stripe says data rendering can be delayed and that you are responsible for checking accuracy and completeness. Its example also distinguishes a paid payout from a reconciled bank receipt. A payout status is not a reason to skip the bank evidence.
Send your bookkeeper the explanation, not two unexplained totals
A useful handoff lets the next person reproduce the $222 without asking you to find everything again. Send the original itemized report, the payout details and the relevant bank evidence through your agreed secure channel. Add a short note with the report period, time zone, currency and account alias, plus the source references for each match. Full customer addresses and card details don't belong in a summary worksheet just because an export offers them.
Fictional handoff: Payout A contains $250 of charges, a $20 refund and $8 of fees, giving $222. It was initiated January 31 and arrived February 2, as expected. The bank receipt and payout both carry reference DEMO-A. The separate $10 credit adjustment belongs to payout B, initiated February 3, with reference DEMO-B. No bank receipt is matched to B in the supplied extract. Please review its status and bank evidence, and confirm the adjustment's accounting category.
Before posting anything, ask the bookkeeper which charges, refunds and fees are already recorded. The task is to explain and match the payout, not add the same customer payments again. Let them decide the ledger entries and period treatment; unresolved delivery questions should go to Stripe or the bank with the payout reference and supporting records.
For the bank side, use a native CSV export if the bank provides one for the dates you need. If older statements are available only as PDFs, AnyStatement can extract the bank rows; compare them with the original using the bank CSV checks. Neither a bank export nor PDF extraction supplies the missing charge and fee detail. That still has to come from Stripe.
We opened all five linked Stripe documentation pages on October 17, 2026. None displayed an update date; October 17 is our check date, not a date supplied by Stripe. We checked the fictional amounts, payout membership, bank-side total and equivalent spreadsheet calculation with Python Decimal. We did not run the formula in Excel, download reports from a live Stripe account or test a bank connection.