Your bank shows a $4,237.18 deposit from Stripe on March 17. Your client sold $4,612.00 across 32 transactions over three days. After refunds and fees, the payout hit the bank as one line. If your GL records $4,237.18 in revenue and closes the tab, you've lost three of the four moving parts — and created a reconciliation problem the next time someone asks about fee expense or refund volume.
Payment processor deposits are not revenue. They are the output of an equation: gross charges minus refunds minus fees equals net payout. To reconcile lump-sum deposits correctly, you have to reverse-engineer that equation using the processor's payout report. This article walks the method, shows the journal entries, and explains exactly where it breaks down at scale.
What is a lump-sum deposit from a payment processor?
A lump-sum deposit is the single bank transfer a payment processor sends for multiple transactions across a settlement window. Stripe, PayPal, and Square batch charges — typically over 2 business days for Stripe, weekly for PayPal, next business day for Square — and send one net amount: gross charges minus refunds minus fees. A $4,237.18 Stripe deposit might represent 47 transactions totaling $4,612.00 in gross charges, minus $187.00 in refunds and $187.82 in fees. To reconcile lump-sum deposits correctly, you decompose the deposit back into components using the processor's payout report, not the bank statement.
The decomposition of the running example. Bank shows $4,237.18 on March 17. The Stripe report shows:
The math: $4,612.00 − $187.00 − $187.82 = $4,237.18. The bank line is the output, not a sum. That's why payment processor deposits don't match what the client thinks they should. The deposit is a difference.
If your GL only records the $4,237.18, you've lost three of the four moving parts. No fee line when the CPA asks what processing cost last year. No refund total when the client wants dispute volume. No gross figure that ties to the Stripe dashboard. Lump sum deposit bookkeeping that stops at the bank line stops short of the work that matters.
The tempting approach: Stripe deposit hits the bank feed, you categorize it as revenue in QBO, match the bank line, move on. One entry. No clearing account. The month closes in minutes.
This works fine if you never need to explain the number. It fails in several predictable ways.
A March 14 refund against a March 11 charge hits the March 17 payout. Direct-to-bank books the negative as a March revenue reduction, but the original sale was already booked in last week's payout. February revenue is overstated, March revenue is understated. For a marketplace business with regular cross-period refunds, period-over-period numbers are quietly wrong every month.
Direct-to-bank records the net deposit as revenue. Fees are invisible — they never appear as an expense line anywhere in the GL. At year-end, the CPA cannot benchmark processing cost against industry norms, the client cannot see whether their effective rate is creeping up, and any fee analysis question requires manually pulling processor reports that were never reconciled into the books.
The clearing account payment processor pattern is the standard way bookkeepers honor that equation in QBO. Open a balance sheet account ("Stripe Clearing"), book gross sales into it, absorb fees and refunds, zero it out when the net deposit arrives. If the account doesn't zero, you have something real to investigate. Here's the method using the $4,237.18 running example.
When charges are processed (not when the payout arrives), debit Stripe Clearing and credit Sales Revenue for the gross amount.
12026-03-15 Stripe Clearing 4,612.002 Sales Revenue 4,612.003(gross charges for March 14-16 settlement window)
The Stripe report shows $187.00 in refunds. Two are against charges in this same window: clean. The third is the $23.47 against a March 11 charge already settled last week. That's the timing item we'll come back to. For now, record all three against clearing.
12026-03-15 Sales Refunds 187.002 Stripe Clearing 187.00
If your COA uses contra-revenue for refunds, that's the debit.
Book the $187.82 in Stripe fees as an operating expense, out of clearing.
12026-03-15 Processing Fees - Stripe 187.822 Stripe Clearing 187.82
When the $4,237.18 hits the bank on March 17, close the clearing account to cash.
12026-03-17 Bank — Operating 4,237.182 Stripe Clearing 4,237.18
Stripe Clearing now sits at zero: $4,612.00 − $187.00 − $187.82 − $4,237.18 = $0.00. The math works.
At month-end, pull the clearing balance. For fully-resolved payouts, it should be zero. Small balances are normal because in-flight items always exist (charges processed late on the last day, period-spanning refunds, disputes in flight). Anything you can explain in 5 minutes is fine.
What's not fine: a balance of $312 you can't trace. That's the signal something is off. Usually a missed refund, a fee that didn't tie, a Connect fee unbooked, or a duplicate JE. The clearing account is your audit trail. When float persists across periods, the balance sheet payment processor float deep dive covers what to do with it.
Stripe runs a rolling two-business-day payout. A charge processed on Monday settles Wednesday. When you're recording gross charges at charge date (not payout date), charges from the end of one period land in the clearing account while the payout arrives in the next period. This is normal and expected — the clearing account absorbs it. The balance at period-end represents in-transit charges that haven't paid out yet.
The $23.47 refund above, against a charge from March 11 (last week's payout), lands in this week's payout as a reduction. The original charge was recorded as March revenue in last week's clearing JE. The refund this week reduces the clearing balance but the original revenue credit is in the past. If you book the refund against current-period revenue, you're understating current revenue and have no record that a prior-period charge was refunded.
The clean fix: keep a refund log with original charge dates, match refunds to their source charge period, and document the cross-period item in the JE memo.
A chargeback on a $400 charge freezes $400 plus a $15 dispute fee. Funds disappear from the next payout and release weeks later. Partial wins return a percentage, full wins return everything, full losses return nothing. Each freeze and release is an unexplained variance until you trace it to the dispute timeline.
The fix isn't a JE. It's a reference document. Keep a running log of disputes per client with charge dates, amounts, filing dates, resolution dates. When clearing doesn't zero, the log is where you look first.
The clearing account method works perfectly at small scale. One client, one processor, 30 payouts a month: the workflow is clean and the entries are mechanical.
At 10 clients with mixed Stripe, PayPal, and Square stacks, the volume of payout cycles exceeds what one bookkeeper can reconcile manually without errors. Month-end close extends. Clearing accounts carry unexplained balances. The same 5-minute fix per payout becomes a Saturday of forensic work per client.
That's when automated payment reconciliation earns its keep. The method doesn't change. The tool executes it faster than you can, without the error rate that accumulates when you're closing 12 clients in the same week.
The clearing account method is not complicated. Gross sales hit clearing, refunds and fees absorb into clearing, and the net payout closes it to the bank. The account should zero per cycle. When it doesn't, you have a specific thing to investigate — not a general "something's off" feeling.
Start with one client's next Stripe payout. Set up the clearing account, run the four-line JE, and verify it zeros when the deposit arrives. The discipline you build on one payout applies to every processor and every client you add after that.
Lump-sum deposits have a specific failure mode: a tool that posts the net amount as revenue without decomposing the components. Growthy flags instead of guessing on the entries most tools get wrong — cross-period refunds, mixed-processor payouts, deposits where fees don't match any line in the report. The clearing account zeros per cycle. What doesn't zero gets a specific flag, not a vague "something's off." Built by a CPA firm partner. 85% first-import, categorizes automatically.
Free during alpha. Read-only access. You review every sync.
Growthy is dedicated to helping businesses of all sizes make informed decisions. We adhere to strict editorial guidelines to ensure that our content meets and maintains our high standards.
Stop chasing W-9s in January. Collect them before the first payment, track receipt, and handle the messy cases (refusal, foreign vendors, single-member LLCs).
Remittance advice tells you which invoices a payment covers. Here's how bookkeepers actually use it, and what breaks when it's missing.
