Stripe Payout CSVs for Accounting: Gross, Fees, Net, and Matching Transfers to Deposits

9 min readPipeSheets Team

To reconcile Stripe to your bank, you match each payout by its arrival date and net amount, not by individual charge dates. Stripe batches many charges, refunds, and fees into a single transfer, so your bank statement shows one round-ish deposit while Stripe shows hundreds of line items. The fix is to pull Stripe's Payout reconciliation report, group every transaction under its payout ID, sum gross minus fees to get net, and match that net figure to the deposit on your bank CSV. This post walks through which report to export, how to normalize the gross/fee/net columns, and how to flag the rows that will never match cleanly.

This is the reconciliation workflow, not the import-format conversion. If you just need Stripe data shaped for a QuickBooks or Xero bank feed, that's a different job. Here the goal is answering one accountant's question: does the money Stripe says it sent equal the money that actually landed in the bank, and if not, why?

Which Stripe report do you actually need?

Stripe's Reports section (Dashboard, then Reports) offers several financial reports, and picking the wrong one is the most common reason reconciliation stalls. Three reports matter here, and they answer different questions.

The three reports and what each one is for:

Balance summary: your starting balance, ending balance, and a high-level roll-up of activity for a date range. It's the accountant's control total, useful for a monthly overview but too coarse to match individual deposits.
Balance change from activity: a detailed breakdown of everything that moved your Stripe balance except payouts, grouped by reporting category (charges, refunds, disputes, adjustments, fees). Use this to explain revenue and fees, not to match deposits.
Payout reconciliation: the one you want. It breaks down the automatic payouts that hit your bank account during the date range and lists the transactions inside each settlement batch, grouped by reporting category. This is what ties a bank deposit back to its underlying charges and fees.

Rule of thumb: if your question is 'what is this specific deposit made of,' use the Payout reconciliation report. If your question is 'how much revenue and fees did we book this month,' use Balance change from activity. Do not try to reconcile deposits from the Balance summary alone; it does not itemize down to the bank-line level.

Why the payout arrival date, not the charge date, matches the bank

This trips up almost everyone new to Stripe accounting. A customer is charged on the 3rd. The funds are not immediately available; they sit in your pending balance and become available after Stripe's payout schedule (commonly a rolling delay of a couple of business days for many accounts). Stripe then sweeps the available balance into a payout that arrives at your bank on, say, the 6th. Your bank statement records the deposit on the 6th.

So a single deposit dated the 6th can contain charges from the 3rd, 4th, and 5th, minus a refund from the 2nd, minus per-transaction fees. If you try to match on charge date, nothing lines up. You have to match on the payout's arrival date and its net amount. In the itemized report, the field that tells you when funds became available is available_on, and the payout's effective date is what corresponds to the bank deposit.

The two date columns you must not confuse:

created: when the charge, refund, or fee occurred. This is the transaction date, useful for revenue recognition, useless for matching the bank deposit.
available_on: when the funds settled into your available balance and therefore became eligible for the payout. This is the date that ladders up to the deposit.

How to group charges, refunds, and fees under one payout

The itemized Payout reconciliation export gives you one row per balance transaction, not one row per payout. Each row carries an identifier tying it to the payout it belongs to (the automatic payout ID) plus a reporting_category telling you what kind of line it is. Reporting categories you'll see include charge, refund, payout, fee, dispute, and adjustment-style categories like currency conversion. To get the net of a payout, you sum the gross and fee columns for every row sharing the same payout ID.

The three money columns behave consistently once you know the sign convention: gross is the transaction's full amount before Stripe's cut, fee is what Stripe took, and net is gross minus fee. Refunds and disputes carry negative gross. When you group by payout ID and sum net, the total should equal the amount of the payout row itself, which in turn should equal your bank deposit.

One payout, its component rows (itemized Payout reconciliation export, simplified):

balance_transaction_id, created,     available_on, reporting_category, currency, gross,   fee,   net,    automatic_payout_id
txn_1A, 2026-08-03 14:02, 2026-08-05, charge,   usd,  120.00,  3.78,  116.22, po_9Q
txn_1B, 2026-08-03 16:41, 2026-08-05, charge,   usd,  84.00,   2.74,  81.26,  po_9Q
txn_1C, 2026-08-04 09:12, 2026-08-05, refund,   usd, -40.00,   0.00, -40.00,  po_9Q
txn_1D, 2026-08-04 09:12, 2026-08-05, fee,      usd,   0.00,   0.30, -0.30,   po_9Q
txn_1E, 2026-08-05 00:00, 2026-08-06, payout,   usd, -157.18,  0.00, -157.18, po_9Q

Sum of net for charges/refunds/fees (txn_1A..1D) = 116.22 + 81.26 - 40.00 - 0.30 = 157.18
The payout row (txn_1E) moves -157.18 out of the balance.
Bank deposit on 2026-08-06 should read +157.18.

That reconciliation, sum of component nets equals the payout equals the bank line, is the whole job in one equation. Everything else is cleaning the CSV so the equation can actually run.

Cleaning the export before you reconcile

Stripe's CSVs are cleaner than most, but a few things reliably break spreadsheet math. Amounts are fine as decimals, but the moment someone opens the file in Excel, payout IDs like po_9Q survive while any all-numeric IDs can get reformatted, and timestamps can shift with the local timezone. The reconciliation only works if gross, fee, and net are real numbers and the payout ID is treated as text.

The cleanup checklist before you pivot or match:

Confirm gross, fee, and net are numeric, not text. A stray currency symbol or a thousands separator turns the column into strings and your SUM returns zero.
Keep automatic_payout_id and every transaction ID as text so nothing gets truncated or converted to scientific notation.
Standardize empty cells. Stripe leaves fee blank on some rows; decide whether blank means 0 and normalize it so the math doesn't propagate blanks.
Normalize the header names to a consistent style (lowercase, no stray spaces) so your formulas and any downstream tool reference them reliably.
Trim whitespace from category and ID columns; a trailing space makes po_9Q and 'po_9Q ' group as two different payouts.
Check the timezone. Stripe report timestamps are typically UTC; if you compare to a bank statement in local time, a late-night charge can appear to belong to the wrong day.

This prep is where a dedicated cleaning pass saves the most time. In PipeSheets you can run a Quick Clean to trim whitespace, standardize nulls, and normalize headers in one pass, then preview the before/after with detected column types so you can confirm gross, fee, and net actually parsed as numbers before you export a clean CSV. Because it doesn't mangle leading zeros or reformat IDs the way Excel does, the payout IDs stay intact for grouping.

Matching Stripe payouts to the bank CSV

Once each payout has a clean net total, you match it against the bank export. Bank CSVs vary by institution, but you're looking for the deposit line whose amount equals the payout net and whose date equals the payout arrival date. The descriptor usually contains 'STRIPE' plus a short reference. Build a small matching sheet: one row per payout with payout ID, arrival date, and net; one row per bank deposit with date, amount, and descriptor; then match on date and amount.

Bank side vs Stripe side, aligned for matching:

BANK (deposits only)
date,       amount,  descriptor
2026-08-06, 157.18,  STRIPE TRANSFER ST-A1B2
2026-08-07, 402.55,  STRIPE TRANSFER ST-C3D4

STRIPE (payout net, grouped by payout id)
arrival_date, net,     automatic_payout_id
2026-08-06,   157.18,  po_9Q     -> matches bank line 1
2026-08-07,   402.55,  po_9R     -> matches bank line 2
2026-08-08,   88.10,   po_9S     -> NO bank line yet (in transit)

Which unmatched rows are normal and which are problems

A clean reconciliation still leaves a few rows unmatched, and knowing which are benign keeps you from chasing ghosts. Flag every payout without a bank match and every bank line without a Stripe match, then triage.

Common reasons a row won't match, and what to do:

Pending or in-transit payout: Stripe created the payout but it hasn't landed at the bank yet. Expected near period-end. Carry it forward; it matches next statement.
Timing across the period boundary: a payout arriving on the 1st shows in next month's bank statement. Match it in the correct period rather than forcing it into this one.
Disputes and chargebacks: a dispute pulls funds out (negative gross) and often adds a dispute fee. It reduces a later payout, so the deposit is smaller than the charges suggest. This is correct, not an error.
Refunds landing in a different payout than the original charge: a refund issued after a charge already paid out reduces a subsequent payout. Group by payout ID, not by original charge.
Currency conversion: if you settle in a different currency, the converted amount won't equal the sum of original charge amounts. Reconcile on the settlement-currency net.
Instant payouts and advances: instant payouts and advance operations change when funds settle and carry their own fees, so they won't line up with the standard automatic-payout schedule.
Manual bank adjustments or fees: a bank-side wire fee or reversal that Stripe never saw. Investigate as a true exception.

Pro tip: a persistent penny-level mismatch across many payouts is almost always a rounding or number-parsing issue, not a real discrepancy. Recheck that fee and gross parsed as numbers and that you aren't summing a column Excel silently stored as text.

A repeatable monthly process

Reconciliation gets fast once it's the same steps every month. The point is to make the Stripe side and the bank side speak the same language, payout net and arrival date, before you try to match anything.

The monthly reconciliation run:

Export the Payout reconciliation report (itemized) for the period from Stripe's Reports section.
Clean the file: numeric gross/fee/net, IDs and dates as text, standardized nulls, normalized headers, trimmed whitespace.
Group rows by automatic_payout_id and sum net to get each payout's total; confirm it equals the payout row.
Export the bank statement CSV and isolate deposit lines with a Stripe descriptor.
Match Stripe payout net and arrival date to bank deposit amount and date.
Flag unmatched rows on both sides and triage: pending, timing, disputes, refunds, currency, or a real exception.
Reconcile the control total against the Balance summary for the period as a final check.

The math never changes: component nets roll up to a payout, the payout equals the bank deposit, and anything left over has a specific, explainable cause. Get the export clean first, and the matching is arithmetic. PipeSheets handles the cleaning and prep, standardizing the columns, headers, and null values so gross, fee, and net add up, and hands you a tidy CSV to reconcile against your bank.