Stripe bookkeeping starts with payouts, fees, refunds, and a clearing account. Use this guide to reconcile Stripe in QBO or Xero without guesswork now.
A $4,237.18 deposit hits the bank. The description says "STRIPE TRANSFER." No invoice matches. No single charge matches. You pull up Stripe Dashboard and find 47 charges, 3 refunds, and $127.43 in processing fees — all bundled into one net payout that landed as a single bank transaction.
If you've managed even one client with a Stripe account, you've lived this. And unlike Square or PayPal, where deposits are relatively straightforward, Stripe groups dozens of transactions into net payouts, deducts multiple fee types before depositing, and applies refunds to future payouts instead of the original one. The result: your bank balance is correct, but your books are wrong unless you know exactly how to break each payout apart.
This hub is the complete reference for Stripe bookkeeping. It covers why deposits don't match, how to record Stripe transactions correctly in QBO and Xero, where every fee type belongs in your chart of accounts, and how to build a reconciliation workflow that scales across multiple clients. Whether you're setting up your first Stripe client or managing a dozen, the payout-period method covered here is the same approach used by every major Stripe accounting tool — but you don't need a tool to use it.
Stripe bookkeeping starts with the payout, not the bank deposit. A payout is a bundle of charges, refunds, fees, disputes, adjustments, and timing differences. Record the gross activity, route fees and refunds to the right accounts, and use a Stripe clearing account so the net payout matches the bank. If you only categorize the bank feed deposit as revenue, gross sales, fees, refunds, and margins are all wrong.
Step | Source data | Bookkeeping move | Review trigger |
|---|---|---|---|
Pull payout detail | Stripe payout and balance activity | Group charges, fees, refunds, disputes, adjustments | Missing payout or unusual reserve |
Build summary entry | Payout-period report | Gross revenue, fee expenses, refund contra-revenue, clearing account | Multi-currency or pending dispute |
Match bank deposit | Bank feed | Clear Stripe clearing to bank | Net deposit does not tie |
Review exceptions | Refunds, disputes, adjustments | Confirm account treatment before close | Low confidence or new pattern |
Most payment processors deposit close to what they charge. Stripe doesn't. It collects charges throughout the day, holds them in a pending balance, deducts processing fees and any refunds, then sends you the net amount — sometimes two days later, sometimes a week. Your bank sees one deposit. Stripe Dashboard shows 47 individual transactions that make up that deposit.
This creates a fundamental bookkeeping problem. If you categorize the bank feed deposit as revenue, you've recorded the net amount instead of gross. You've missed the fee expense entirely. And if there were refunds in that payout, you've understated those too. The P&L is wrong in two directions at once, and the error compounds every month.
Stripe also charges at least five distinct fee types: standard processing fees (2.9% + 30 cents per US transaction), international card surcharges, dispute and chargeback fees ($15 each regardless of outcome), Stripe Connect platform fees, and subscription fees for products like Radar and Billing. Each one belongs in a different account on your financials. Lumping them into a single "Stripe Fees" expense account — which is what most QBO files have — hides operational signals and distorts your gross margin. A spike in dispute fees means something different from a spike in processing fees, and you can't see the difference if they're in the same bucket.
Unlike Square (which deposits individual transactions by default) or PayPal (which shows each sale separately in the bank feed), Stripe's bundled payout structure makes it the most complex payment processor to reconcile. The upside: once you learn the payout-period method, the complexity becomes manageable — and the same approach works whether you're doing it manually or using automation.
The core insight behind Stripe reconciliation is simple: stop trying to match individual transactions to bank deposits. Instead, match payouts to bank deposits.
Every Stripe payout is a collection of balance transactions — charges, refunds, fees, and adjustments — that settle together. Stripe's API groups them by payout ID, and the net of all those balance transactions equals the bank deposit amount to the penny. When you build one summary journal entry per payout, you get a single JE that matches a single bank deposit. The clearing account zeros. No mysteries.
Here's how it works in practice. Stripe holds charges in a pending balance. When payout day arrives (daily, weekly, or on your custom schedule), Stripe takes all the balance transactions since the last payout, nets them together, and sends one deposit to your bank. That payout contains the gross charges, minus processing fees, minus refunds, minus disputes, plus any adjustments. Your journal entry mirrors this structure: debit the clearing account for gross revenue, credit revenue. Debit fee expense accounts for each fee type. Credit contra-revenue for refunds. Debit bank for the net deposit. Credit clearing for the net. The clearing account zeros, and you move on to the next payout.
A2X built an entire company around this approach — it's the validated method for Stripe accounting. The difference between tools isn't the method (they all use payout-period grouping). It's how much manual work you're still doing to get there.
For a real example: a client running a SaaS with daily Stripe payouts generates roughly 20 payouts per month. Each payout contains 30 to 100 balance transactions. Manually pulling each payout report, identifying the fee breakdown, building the journal entry, and verifying the clearing account zeros takes 30 to 45 minutes per payout. That's 10 to 15 hours per month for one client. With the payout-period method automated, the same 20 payouts resolve in under an hour — most of that time is reviewing the exceptions, not building the entries. The complete reconciliation workflow walks through every step, from pulling the payout report to handling the edge cases that trip up most bookkeepers.
Stripe's fee structure is more complex than most bookkeepers realize. Processing fees are the obvious one — 2.9% plus 30 cents per domestic card transaction. But that's just the start.
Dispute fees hit you $15 per chargeback, win or lose. If a customer disputes a $50 charge, Stripe holds $50 and charges you $15. If you win the dispute, you get the $50 back but you've still eaten the $15 fee. These should live in their own "Dispute Fees" expense account because a spike in chargebacks is an operational signal — buried in general processing fees, you'd never see it.
Refunds are where most bookkeepers make the biggest mistake. A refund isn't a fee. It's a reversal of revenue. When you refund a customer, the correct entry is a debit to contra-revenue (like "Sales Refunds") and a credit to the clearing account. If you book refunds as expenses, you're overstating gross revenue and creating a phantom expense that distorts both lines of the P&L. The detailed GL mapping for every Stripe fee type covers the exact account names, types, and number ranges for QBO setup.
Connect and subscription fees add more complexity. If your client uses Stripe Connect (common for marketplace and platform businesses), the platform fee is a separate line from processing fees and typically belongs in a "Platform Fees" or "Marketplace Commission" expense account. Stripe Radar, Billing, and Atlas subscription charges are fixed monthly costs — they go in "Software Subscriptions" or "SaaS Expenses," not in processing fees. Mixing fixed subscription costs with variable processing fees makes it impossible to calculate the true per-transaction cost of accepting payments.
The COGS versus operating expense debate for processing fees depends on the business model. For e-commerce and product businesses, processing fees scale directly with revenue — they're cost of revenue. For service businesses, operating expense works fine. Either approach is defensible. Consistency is what matters. Pick one, document it, and apply the same treatment across all clients in the same industry. A bookkeeper managing 10 Stripe clients should have this decision documented once and applied uniformly, not decided ad hoc each month.
The payout-period method is the same regardless of which accounting platform your client uses. The mechanics of setting it up differ.
In QuickBooks Online, the standard approach is a clearing account set up as "Other Current Asset." You create sub-accounts for Stripe Processing Fees (as an expense or COGS) and Stripe Refunds (as contra-revenue). Each payout gets a journal entry that flows through the clearing account. The step-by-step QBO setup walks through creating the accounts, building the journal entry line by line with real dollar amounts, and verifying the clearing account zeros after each payout.
In Xero, the workflow looks different but achieves the same result. Xero uses bank rules for categorization rather than manual journal entries. You create the clearing account as a Current Asset, connect Stripe as a bank feed or import the payout CSV, and configure bank rules to split each payout into its component parts — gross revenue, fees by type, and refunds. The Stripe + Xero integration guide covers the platform-specific setup, including batch reconciliation for high-volume months and multi-currency handling.
For bookkeepers managing clients across both platforms (which is most of us), the accounting framework is identical. Learn the payout-period method once, and you apply the same thinking in QBO or Xero. The only difference is where you click.
One common pitfall in QBO: relying on the bank feed alone. The bank feed deposits the net payout amount. If you categorize that as revenue, you've understated gross revenue, missed the fee expense, and created a balance sheet error that compounds every month. For a client processing $50,000/month through Stripe with 2.9% fees, that's $1,450/month in fee expense that never appears on the P&L. Over a year, that's $17,400 in missing expenses — enough to materially affect the tax return. By year-end, the CPA preparing the return has to unwind 12 months of incorrect entries. The clearing account prevents this entirely.
Manual Stripe reconciliation works. For a client with fewer than five payouts per month (typical for a small business on weekly payouts), the clearing account journal entry takes 30 to 45 minutes per payout. That's two to three hours per month — manageable when it's one or two clients.
The math changes when you're managing multiple Stripe-connected clients. Three clients with 10 payouts each per month means 30 journal entries. At 30 to 45 minutes each, that's 15 to 22 hours of manual reconciliation per month. At a $100/hour bookkeeper rate, that's $1,500 to $2,200 in labor on one payment processor.
Automated tools — A2X, Synder, and Growthy among them — all use the payout-period approach. They pull payout data from Stripe's API, split each payout into its component balance transactions, categorize fees by type using Stripe's reporting_category field, and generate the summary journal entry for each payout period. The clearing account zeros automatically.
The difference between tools isn't the method. It's what happens when something doesn't fit the pattern. A refund applied to a future payout. A dispute with a pending outcome. A currency conversion that creates a rounding difference. These exceptions are where manual reconciliation burns time and where automation tools diverge. Some flag exceptions for manual review. Growthy uses confidence scoring on each payout component — so you're reviewing the 13 items that need judgment, not re-checking the 234 that were straightforward.
Understanding the manual method isn't wasted effort even if you automate. When an automated entry looks wrong, you need to know what "right" looks like. The bookkeeper who can build the clearing account journal entry by hand catches automation errors that the bookkeeper who only clicks "approve" will miss.
Stripe bookkeeping is the process of recording Stripe charges, refunds, fees, disputes, and payouts so gross revenue, fee expense, contra-revenue, and bank deposits all tie out.
Stripe sends net payouts. One deposit can include many charges, processing fees, refunds, disputes, and adjustments. The bank sees one net transfer, while Stripe reporting shows the underlying balance transactions.
Not always. Processing fees can be one account, but dispute fees, platform fees, subscription fees, and marketplace commissions often deserve separate accounts because they explain different business problems.
In QBO, bookkeepers commonly set it up as an Other Current Asset. The clearing account receives gross Stripe activity and then clears when the net payout lands in the bank.
The accounting framework is the same. The setup differs because Xero uses account codes and bank reconciliation workflows differently than QBO. The payout-period method still applies.
Automate when payout volume, refund activity, disputes, or multi-client workload makes manual journal entries recurring work. Keep the manual method documented so exceptions can still be reviewed.
Stripe is the hardest processor to reconcile because the difficult entries have no obvious right answer: a net deposit that spans two days, a $3,847.92 payout with refunds from last month, a fee type you've never seen before. Growthy flags instead of guessing on those entries — it posts 85% automatically and surfaces the rest for your review. Built by a CPA firm partner who's closed Stripe month-ends by hand. Categorizes automatically. You review and approve.
Growthy is bookkeeping software, not a CPA firm. This content is educational, not professional advice. Full disclaimer.
Related: The $4,237.18 Problem, How to Record Stripe in QBO, Stripe Fees GL Mapping, Stripe Reconciliation Guide, SaaS Accounting Hub
Free during alpha. Read-only access. You review every sync.
Request Early Access
Stripe refunds and chargebacks look similar in payouts but hit the books differently. Use the right entries, reserve logic, and fee treatment here now.
A practitioner comparison of A2X, Synder, Bookkeep, Acodei, native Stripe-QBO sync, and Growthy for Stripe reconciliation, with pricing, model breakdowns, and a decision table.
Payout-level summary journal entries vs. individual transaction booking in Stripe: when each method works, where individual booking breaks, and why most bookkeepers land on the summary approach.
Stripe Connect splits one payment into three parties. Most bookkeepers record it wrong. Here's the correct journal entry for application fees, destination charges, and connected account payouts.
Step-by-step guide to connecting Stripe with Xero: clearing account setup, bank rules, payout reconciliation, and fee handling for bookkeepers managing Xero clients.
End-to-end guide to reconciling Stripe using the payout-period method: pull reports, build journal entries, clear the clearing account, and handle exceptions.
Stripe charges five distinct fee types, each with different GL treatment. Here's the complete chart of accounts mapping bookkeepers actually use.
That Stripe deposit hitting your bank account isn't a single sale. Here's the exact math behind why Stripe deposits never match your invoices, and how to fix it.
Step-by-step guide to recording Stripe transactions in QuickBooks Online using the clearing account method, with real journal entry examples and a manual vs. automated comparison.
Stripe bookkeeping starts with payouts, fees, refunds, and a clearing account. Use this guide to reconcile Stripe in QBO or Xero without guesswork now.