TL;DR: A Stripe payout is not a sale — it is a net number that bundles gross charges, refunds, processing fees, chargebacks, and sometimes sales tax, all on different timelines. If you book the deposit as revenue, your top line is wrong and your fees disappear. The fix is to split every payout into its parts. This post shows the wrong way, the manual split-entry way, the rule-based QuickBooks/Xero way, and the auto-categorization way with Prosper.
Why a Stripe payout is not a sale
The single most common Stripe bookkeeping mistake is treating the deposit that lands in your bank as revenue. It feels right — money came in, so it must be a sale. But a Stripe payout is a net settlement figure. It is what is left after Stripe nets your gross charges against refunds, processing fees, chargebacks, disputes, and occasionally tax that Stripe Tax collected on your behalf.
Here is a real-shaped example. Over three days you collect $5,000 in gross charges. One customer refunds a $150 plan. Stripe takes its fee — roughly 2.9% + $0.30 per charge, which on this batch works out to about $162. A chargeback from last month claws back $80. The payout that hits your Mercury or Brex account is $4,608. If you book $4,608 as revenue, you have understated your top line by $392 and made roughly $242 of fees and refunds vanish from your books entirely.
That gap is not academic. Your gross revenue drives your run-rate math, your investor updates, and — when your CPA reviews the year — the number they reconcile against your Stripe 1099-K. Stripe reports gross processing volume to the IRS, not your net payouts. If your books say $4,608 and Stripe's 1099-K says $5,000, that mismatch is exactly the kind of thing that turns a quiet year-end into a back-and-forth.
The five things hiding inside one payout
Before you can categorize a payout, you have to know what is inside it. Stripe nets these components together, and each one belongs in a different place in your books. They also do not happen on the same day — a charge from Monday, a refund from Wednesday, and a chargeback from three weeks ago can all settle into Thursday's payout.
The components you will see in a typical payout breakdown:
- Gross charges — the full amount customers paid. This is your actual revenue and the number that matters most.
- Refunds — money returned to customers. This reduces revenue (or hits a contra-revenue account), not an expense.
- Processing fees — Stripe's cut, usually 2.9% + $0.30 per transaction. This is a payment processing expense, often filed under cost of revenue.
- Chargebacks and disputes — forced reversals plus a $15 dispute fee. These reduce revenue and add a fee expense.
- Sales tax (if you use Stripe Tax) — tax collected from customers that you owe to the state. This is a liability, not revenue, and should never touch your income.
The wrong way (and why it is so tempting)
The wrong way is to let your bank feed do the work. Plaid syncs the $4,608 deposit into QuickBooks or Xero, the software suggests a category, you click 'Sales,' and move on. Thirty seconds per payout, no Stripe dashboard required. For a founder closing the books at 11pm on a Sunday, the appeal is obvious.
The problem compounds quietly. Your revenue is understated by every fee and refund. Your processing fees — which can run several hundred dollars a month on real volume — never get recorded, so you lose a legitimate business expense. Sales tax you collected gets booked as income, which inflates revenue and leaves a tax liability sitting invisible on your books. And when a customer asks for a receipt or your CPA asks why gross revenue does not tie to the 1099-K, you have no answer.
There is a lazier-but-acceptable version some founders use: book the net deposit as revenue, then make one big monthly journal entry to gross up sales and break out fees. It is better than nothing, but it smooths over refunds and chargebacks and makes any single month hard to audit. If you are going to touch the numbers anyway, it is barely more work to do it per payout and actually be right.
The manual right way: the split entry
If you are doing this by hand, every payout becomes a split transaction. The cash that hit your bank is the net, but the entry behind it has multiple lines. Pull the payout in Stripe Dashboard → Balance → Payouts, open the one you are recording, and look at the breakdown. Stripe shows you gross, refunds, fees, and adjustments for that exact payout.
In double-entry terms, the example payout above becomes: debit Cash $4,608, debit Stripe Fees $162, debit Refunds (contra-revenue) $150, debit Chargebacks $80, and credit Revenue $5,000. The debits and the credit both total $5,000, the entry balances, and your books now show full gross revenue with every cost broken out where it belongs. If you collected sales tax, that splits off into a Sales Tax Payable liability instead of revenue.
Done faithfully, this is the gold standard — your books match Stripe line for line. Done at scale, it is brutal. At a handful of payouts a month it is twenty minutes. At daily payouts across a few hundred transactions, it is a part-time job, and it is the kind of repetitive work where one fat-fingered number throws off a reconciliation you then spend an hour hunting down.
The rule-based way: QuickBooks and Xero
Both QuickBooks Online and Xero let you build bank rules that fire when a transaction matches a pattern. A rule can catch any deposit from 'Stripe,' assign it to a category, and split it by fixed percentages. This is the standard intermediate setup, and for a steady subscription business it gets you most of the way there.
The honest limit is that rules are static and a Stripe payout is not. A percentage-split rule assumes your fee ratio and refund rate are constant. The month a big customer refunds, or a chargeback lands, or your fee percentage shifts because of international cards or a pricing change, the rule quietly books the wrong split and you do not notice until reconciliation. Rules also cannot see inside the payout — they only see the net number from the bank feed, so they are guessing at the breakdown, not reading it.
The common upgrade is a connector like Stripe's own QuickBooks app, or third-party tools such as A2X or Synder, which read the actual Stripe payout breakdown and post a correct split entry. These work well and many founders are happy with them. The trade-off is another $20 to $60 a month on top of your accounting subscription, another integration to babysit, and a setup that assumes you already run QuickBooks or Xero. As of mid-2026, that connector-plus-accounting-software stack is the most common 'real' way founders solve this.
The auto-categorization way: how Prosper handles it
Prosper connects to your bank through Plaid and to Stripe directly, so it reads the payout breakdown instead of guessing from the net deposit. When that $4,608 lands, Prosper already knows it represents $5,000 gross, $150 in refunds, $162 in fees, and an $80 chargeback, and it categorizes each piece automatically — revenue as revenue, fees as a processing expense, refunds as contra-revenue, tax (if you run Stripe Tax) as a liability.
The part that saves the most time is what it does not ask you to look at. Instead of reviewing every payout, you review the exceptions — the payouts that do not fit the normal pattern. A month with an unusually large refund, a new chargeback, a fee that drifted because of a card-mix change: those surface for your attention. The clean, routine payouts stay categorized in the background. This exception-based review is the whole point — your time goes to the handful of transactions that are actually unusual, not the hundred that are not.
Prosper is $29/mo, flat, with the Stripe handling included rather than sold as a separate connector. In our experience that lands below the typical QuickBooks-plus-Stripe-connector stack, though what you save depends on your plan and volume. To be clear about the boundary: Prosper categorizes and reconciles, but it does not file your taxes or decide tax treatment. Your CPA reviews the books and decides how anything contested gets handled — the goal is to hand them numbers that already tie to Stripe so there is nothing to untangle.
Which approach fits where you are
There is no single right answer — there is the right answer for your volume and how much of your own time you want to spend on this. The manual split entry is correct at any scale; it just costs you hours that grow with your transaction count. Rules and connectors fit founders already committed to QuickBooks or Xero. Auto-categorization fits founders who would rather not run a spreadsheet ritual every month.
A rough guide to match the method to the situation:
- A few payouts a month, comfortable with journal entries: the manual split entry is fine and free.
- Steady volume, already on QuickBooks or Xero: bank rules plus a Stripe connector like A2X or Synder.
- Growing volume, refunds and chargebacks that move month to month: auto-categorization with exception-based review so you only check what is unusual.
- Whatever you choose: reconcile to Stripe's gross number, not your net payout, so your books tie to the 1099-K.
Prosper is bookkeeping software and does not provide tax or legal advice. Consult a qualified professional for tax advice. Results vary based on transaction volume, data quality, and workflow setup.