A customer pays you $1,000 through Stripe. Two days later $970.70 lands in your bank account. Your P&L says revenue was $1,000. Your bank statement says $970.70. Your 1099-K at year end says $1,000. All three are correct, and if your books only know about one of them, they are wrong.
This is the single most common thing we fix when a startup with Stripe revenue moves its books to us. The problem is not the arithmetic. It is that a Stripe payment is three transactions pretending to be one.
One charge, three amounts
For every charge Stripe records a balance transaction with three numbers: the gross amount the customer paid, the fee Stripe kept, and the net that moved into your Stripe balance. For a $1,000 card payment at 2.9% + 30 cents, that is $1,000 gross, $29.30 fee, $970.70 net.
The payout is a fourth thing. Stripe batches the net amounts sitting in your balance and sends them to your bank, on a schedule you chose, in lumps that bear no relationship to individual charges. A Tuesday payout of $4,812.15 is Friday's, Saturday's and Sunday's net charges minus Sunday's refund.
So the bank deposit is not revenue. It is money moving from one account you own (your Stripe balance) to another account you own (your bank). Treating it as anything else is where the trouble starts.
The three-line entry
Here is how one charge is booked in our ledger. Every Stripe and Shopify sale posts as a three-line journal entry (the same treatment covers Shopify payouts, which carry their own fee and net fields):
| Line | Account | Amount |
|---|---|---|
| Revenue | Sales | 1,000.00 credit |
| Processing fee | Merchant fees | 29.30 debit |
| Net to balance | Stripe balance (a bank account) | 970.70 debit |
The Stripe balance is itself a bank account in the chart of accounts. That one modelling decision is what makes everything downstream reconcile. Revenue is recognised at gross, so it matches invoices and the 1099-K (and it is the figure accrual books will defer when a customer prepays). Fees are an expense you can see and benchmark. And the balance account holds exactly what Stripe says it is holding.
The payout then posts as a transfer: Stripe balance down, bank account up, no revenue and no expense. When the bank deposit arrives through the bank feed, our transfer matcher pairs it with the payout leg by amount and date and the two cancel.
The double-count, and the triple-count
Before we modelled it this way, our categorisation model was told to treat payouts as income. That is the natural reading of a deposit labelled "STRIPE PAYOUT", which is all the bank feed says about it, and it is what most bookkeeping tools and most founders doing their own books do.
The result counts the same dollar three times. The charge is booked as revenue once, correctly. The payout is booked as "Service Income" a second time. Then, because the payout leg was categorised rather than left as a transfer, it can never be matched, so the bank-side deposit is booked as revenue a third time.
The books will show revenue somewhere between two and three times actual. It is a cousin of the pending-then-posted duplicate: the bank still balances, so nothing complains. The bank still reconciles, because cash in equals cash in, which is why this survives for months. It surfaces when someone compares the P&L to Stripe's own dashboard, or when a tax preparer asks why revenue is 2.9x the 1099-K.
We now keep payouts out of the categorisation model entirely. They are not revenue, not an expense, and not a candidate for categorisation at all. A payout that fails or is cancelled returns funds to the balance and is handled as the reversal of a specific payout, matched by Stripe's own source id.
The other balance transaction types
Charges and payouts are most of the volume, but Stripe emits a dozen other types, and each has a home:
- Refunds go to a contra-revenue account ("Refunds given") with the customer attached, not to a negative sale. Over twelve months across our clients, rules, humans and the model agreed on that treatment in more than 99% of about 1,300 refund decisions.
- Disputes and chargebacks are refunds with a fee attached; the fee is a merchant fee.
- Stripe fees billed separately (monthly Radar, Billing, invoicing fees) are pure-fee transactions where gross equals fee equals net. They post as a two-line expense, not a three-line sale.
- Stripe Capital repayments reduce a loan liability. They are not an expense, and they are not a fee, though they arrive looking like one.
- Transfers to a connected account under Stripe Connect are payments to a third party, not a move to your own bank.
The pending-fee problem
One detail that bit us: Stripe reports a charge while it is still pending, and at that moment the fee and net fields can be empty. If you book on first sight, you post the gross amount to the balance account with no fee line. When the charge settles a day later the fee appears.
Our sync now re-splits any entry that was posted gross once fee data arrives (one of the things that happens on our side of a month-end close, not yours): net stays on the balance account, the fee moves to the expense line. It only rewrites when a fee newly appears or the status flips, so settled entries are never churned.
What to check in your own books
Three questions catch most of it:
- Does your chart of accounts have a Stripe balance account? If deposits go straight from "Stripe" to revenue, the fees are invisible and the payouts are probably double-counted.
- Does revenue on the P&L for last year match the gross volume on your 1099-K within refunds? If it is much higher, look for payouts booked as income.
- Is there a merchant fees line, and is it roughly 3% of card revenue? If it is zero, fees are netted inside revenue and your gross is understated.
The 1099-K reports gross. Your bank shows net. Your books should show both and the fee that explains the difference.
Common questions
Is a Stripe payout revenue?
No. A payout moves money from your Stripe balance to your bank; the revenue was recorded when the customer paid. Booking the payout as income counts the same money twice, and the bank deposit can make it three times. Treat the Stripe balance as a bank account and the payout as a transfer between two accounts you own.
Why does my 1099-K not match my bank deposits?
The 1099-K reports gross processed volume. Your bank receives net: gross minus Stripe's fees, batched into payouts on Stripe's schedule, less refunds. Books that record gross revenue, a separate fee expense and the net to a Stripe balance account reconcile to both figures.
How should Stripe fees be booked?
As an expense on their own line, usually merchant or processing fees, never netted out of revenue. For a $1,000 charge at 2.9% plus 30 cents that is $1,000 revenue, a $29.30 fee and $970.70 to the Stripe balance. Netting hides the fee and understates gross revenue against the 1099-K.
Tools that go with this
- SaaS accounting: revenue recognition and tax - how gross revenue, fees and deferred revenue fit together for subscription businesses
- E-commerce accounting: bookkeeping, inventory and sales tax - the Shopify version of the same three-line problem, plus sales tax
- Startup tax deadline calendar - the 1099-K and 1099-NEC dates the gross figure feeds into