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.
Get Started with Growthy
Why Stripe Is Different From Every Other Payment Processor
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 Payout-Period Method: How Stripe Reconciliation Actually Works
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.
Where Every Dollar Goes: Stripe Fee Categories and GL Mapping
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.
QBO and Xero: Platform-Specific Setup Guides
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 vs. Automated: When Each Approach Makes Sense
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.
Explore the Full Guide
Growthy is bookkeeping software, not a CPA firm. This content is educational, not professional advice. Full disclaimer.
Get Started with Growthy
Related: The $4,237.18 Problem, How to Record Stripe in QBO, Stripe Fees GL Mapping, Stripe Reconciliation Guide