It's a Tuesday morning. You're reconciling a client's bank feed when $4,237.18 hits the screen under the description "STRIPE TRANSFER." You scan through their invoices. Nothing matches. You check their Stripe dashboard and see 47 individual charges: some from last Tuesday, some from last Friday, two refunds from the week before. The deposit doesn't match any single one of them.
You're not making an error. This is just how Stripe works.
Why don't Stripe deposits match my sales?Stripe bundles multiple charges into a single net payout before depositing to your bank. It deducts processing fees (2.9% + 30¢ per US transaction), subtracts any refunds from that period, and holds $15 per dispute. The bank deposit shows the net result of dozens of transactions. Not any individual sale. A $4,237.18 deposit might represent 47 charges, 3 refunds, and $127.43 in fees combined.
Key Takeaways
- Stripe payouts are net amounts, not individual transactions. Matching them to invoices one-for-one will never work.
- Three deductions reduce every deposit: processing fees, refunds (where Stripe keeps the original processing fee), and dispute holds ($15 each, win or lose).
- Manual reconciliation costs $400-600/month in bookkeeper time per Stripe-connected client at $100/hr across 4-6 hours of monthly work.
- The payout-period method works: group transactions by payout period, post one summary journal entry per payout, verify the clearing account zeros out.
- Pattern-learning tools cut this to 15-30 minutes by automating the grouping and journal entry generation, leaving you to review exceptions only.
The Deposit That Doesn't Match Anything
The $4,237.18 deposit is real. It came from a real month of Growthy's Stripe account, and it took longer to reconcile than it should have.
The bank description just says "STRIPE TRANSFER": no payout ID, no date range, no transaction count. You open Stripe's dashboard and see a list of individual charges: $149.00, $299.00, $149.00, $49.00. None of them are $4,237.18. You try adding a few together. Still nothing.
Here's what's actually in that deposit: 47 charges over a multi-day payout window, minus 3 refunds that happened to land in the same period, minus $127.43 in processing fees that Stripe already deducted before sending the money.
The worst moment in Stripe reconciliation isn't finding the problem. It's thinking you found the match, then realizing the number is off by exactly the amount of a refund that happened 3 days earlier. You go back, pull the refund, recalculate, and the number still doesn't land because there's a dispute fee you didn't see yet.
This is why Stripe is harder to reconcile than Square or PayPal. Square syncs individual transactions cleanly. Stripe deposits net amounts that can include anywhere from 10 to 150 transactions depending on your client's payout schedule and volume.
How Stripe Actually Moves Money
Stripe doesn't send you money immediately when a customer pays. It collects charges into a held balance, then periodically pays out the net amount to your bank.
Here's the flow: A customer pays $299. Stripe holds that in your Stripe balance (not your bank). At the end of the payout period (daily, weekly, or on a custom schedule depending on your client's settings), Stripe tallies up every charge, subtracts every fee and refund, and sends the resulting number to your bank account in a single transfer.
The technical term is a BalanceTransaction. Every charge, fee, refund, and adjustment that settles during a payout period gets grouped under that payout's ID. Your bank sees one number. Stripe's API shows you each component.
This is the insight that makes reconciliation work: you're not matching individual transactions to the bank deposit. You're matching the entire payout group to the deposit. The sum of all BalanceTransactions for a given payout ID should equal the bank deposit amount, to the cent.
If you skip this and try to match individual charges, you'll never tie out. The numbers just don't work that way.
The Three Things Stripe Deducts Before You See a Dime
Every Stripe deposit is smaller than your gross sales by at least three types of deductions. Each one hits the books differently.
Processing fees (2.9% + 30¢ per US transaction): This is the most consistent deduction. On a $299 charge, Stripe takes $8.97 before the money ever leaves their system. Across 47 transactions, those fees add up fast: $127.43 in the $4,237.18 example. These belong in a separate expense account, usually mapped to cost of revenue for product businesses or operating expense for service businesses.
Refunds (full customer amount, plus Stripe keeps the original fee): This is the one that trips people up. When you refund a customer $149, Stripe deducts the full $149 from your next payout. But the $4.63 processing fee from the original charge? That's gone. Stripe doesn't return it. So a $149 refund actually costs $153.63 in total: the refund itself plus the eaten fee. In the books, refunds are contra-revenue, not expenses. Getting this wrong distorts gross margin.
Dispute fees ($15 per dispute, regardless of outcome): Someone files a chargeback, Stripe immediately holds the transaction amount plus charges you $15. You can win the dispute and get the held amount back, but the $15 is gone either way. Dispute fees should live in a separate account. They're an operational signal. If that account starts growing, something upstream is wrong with your client's business.
Why This Takes 4-6 Hours a Month (Bobby's Math)
Three Stripe-connected businesses. Roughly 200 transactions per month each. That's 600 transactions across 3 accounts, sorted into payouts, matched to bank deposits, with fees and refunds accounted for individually.
At $100/hour bookkeeper rates, 4-6 hours of monthly reconciliation per Stripe client costs $400-600. And that's just one payment processor. Most businesses using Stripe also have PayPal, ACH, or credit card terminals. The hours add up before you've touched anything else.
The brutal part: the time doesn't scale well. Doubling a client's transaction volume roughly doubles the reconciliation time. There's no efficiency gain from doing more of it manually. You're still pulling payout reports, cross-referencing refunds, entering journal entries line by line. The 200th transaction isn't faster than the 1st.
This is the math that makes Stripe reconciliation a real business problem, not just an annoyance. For bookkeepers managing 5-10 Stripe clients, the hours are a meaningful chunk of monthly capacity.
The Payout-Period Approach That Actually Works
The fix is conceptually simple: stop trying to match individual transactions to the bank deposit. Match the entire payout to the deposit instead.
Here's how it works in practice:
Group by payout period, not by transaction. Pull the payout report from Stripe (Dashboard → Payouts → select the payout → export). Every transaction that settled in that payout period is listed with its type (charge, refund, fee) and amount.
Build one summary journal entry per payout. The entry has four components:
- Debit the Stripe Clearing account for the gross charge total
- Credit Revenue for the same amount
- Debit fee accounts (Processing Fees, Dispute Fees) for each fee type
- Credit the Stripe Clearing account for refunds (as contra-revenue)
- The net result: debit Bank for the deposit amount, clearing account zeros out
Verify the clearing account balance is zero. After posting the journal entry, your Stripe Clearing account should have a zero balance for that payout period. If it doesn't, something's missing: a refund you didn't catch, a fee that landed differently, a dispute hold that spans payouts.
This is the payout-period method. It's the same approach A2X built a business around validating — it works because it matches how Stripe actually settles money, not how you might wish it worked.
For a detailed step-by-step walkthrough including the exact journal entry format, see the complete Stripe reconciliation guide.
What Changes When Matching Is Automatic
The payout-period method works manually. It's just slow.
When the grouping and journal entry generation are automated, the process shifts from 4-6 hours to 15-30 minutes per month. Not because the method changes. The same payout-period logic applies, but the tedious parts (pulling payout reports, categorizing each transaction, calculating fee totals by type) happen without manual data entry.
Point Growthy at your Stripe payouts. It splits fees by type using Stripe's reporting_category field and generates clearing account journal entries automatically. Instead of reconciling 47 transactions, you review the exceptions: items where the pattern learning flagged something that needs human judgment. In a typical month, that's 10-15 items instead of 600.
The confidence scoring is the part that changes the workflow most. Instead of manually checking every transaction, you see a score on each payout component. High confidence means the entry is clean. Flagged items mean something looks off: a refund that doesn't match a known order, a fee that's higher than expected, a dispute hold that opened and closed in the same period.
For bookkeepers managing multiple Stripe clients, this is where the capacity math inverts. 15-30 minutes per client instead of 4-6 hours means you can handle more clients without adding hours, or deliver better work on the clients you have.
If you want to understand how to record Stripe transactions in QuickBooks using the clearing account method, that's the next piece to read.
Growthy is bookkeeping software, not a CPA firm. This content is educational, not professional advice. Full disclaimer.
Get Early Access
Related: How to Record Stripe in QBO, Stripe Reconciliation Guide
