Stripe Deposits Double Counted? How to Fix Your Books

8 min readPipeSheets Team

Here is the shape of the problem: you import your Stripe transactions into your accounting tool so every sale is recorded. Your bank feed also imports every deposit that lands in your checking account, and those deposits are the Stripe payouts, which are the same sales arriving as cash. If both get categorized as income, every dollar of Stripe revenue hits your books twice. Your profit looks roughly double what it should be, your tax estimate balloons, and nothing obviously looks wrong because every individual entry is a real transaction.

The fix has two parts. First, adopt the right mental model: Stripe payments are your revenue, and Stripe payouts arriving at the bank are transfers of money you already earned, never income. Second, clean up the entries that were already double counted, which means identifying which bank deposits are Stripe payouts and recategorizing them from income to transfers. This guide covers why the double count happens, how to confirm you have it, the cleanup, and the bank rules that prevent it from coming back.

Why Stripe deposits get double counted

Two imports, one pot of money

The root cause is almost always two data sources describing the same money. Source one is Stripe: a CSV import, an integration, or manually entered sales invoices, recording each charge as revenue. Source two is your bank feed, recording each payout deposit. Neither source is wrong; the deposit really happened and the charges really happened. But the deposit is composed of those same charges, so booking both as income counts the money twice. This is the classic trap for anyone who connects both Stripe and their bank account to QuickBooks or Xero and lets the defaults categorize everything.

Gross charges vs. net payouts

A subtlety that hides the problem: the two numbers do not match, so the duplication is not obvious. A customer pays you $100; Stripe takes roughly $3.20 in fees; the payout deposits $96.80. If you booked $100 of revenue from the Stripe side and $96.80 of income from the bank side, you did not exactly double your revenue, you recorded $196.80 on $100 of real sales. Because the deposit never equals any single charge, and payouts batch many charges together, a line-by-line eyeball comparison finds no duplicates. The books are wrong by the sum of your net payouts, and the discrepancy only surfaces when someone asks why the margins look implausibly good.

Refunds and disputes compound the mess. A refund reduces a future payout, so the bank side quietly nets it out, while the Stripe side may still show the original charge at full value unless the refund was imported too. A ledger that double counts income and only single-counts refunds is wrong in two directions at once, which is why the error rarely reconciles to a tidy round number and why people chase it for hours before realizing the whole classification scheme, not any single entry, is the problem.

Payout batching and timing lag

Stripe batches charges into payouts and deposits them on a rolling schedule, typically a couple of business days behind the sale. A Tuesday deposit contains the weekend's sales; a payout initiated in late March lands in early April. This lag does two damaging things. It breaks any attempt to match deposits to same-day sales, which is how people convince themselves the deposit must be separate money. And it smears the double count across month boundaries, so March is overstated by charges and April is overstated by the deposits of those same charges, making month-over-month comparisons useless for spotting the problem.

How to confirm your books are double counted

Three checks, in increasing order of rigor:

The margin sniff test: if revenue in your books is roughly 1.9 to 2 times what Stripe's Dashboard reports for the same period, you are double counting. The ratio is just under 2 because the bank-side duplicates are net of fees.
The income-account scan: open your income account transaction list and look for deposit entries whose payee or memo is Stripe. Any bank-feed deposit from Stripe sitting in an income account is a duplicate, because the underlying charges are already booked.
The payout cross-check: export your Stripe payouts for the period and your bank statement. Every payout should appear in the bank feed once, categorized as a transfer, not income. Sum the payouts that were categorized as income; that sum is the size of your overstatement.

The tell, in numbers (one month):

  Stripe Dashboard gross volume:        $10,000.00
  Stripe fees:                             $320.00
  Payouts to bank:                       $9,680.00

  Books: income from Stripe import:     $10,000.00
  Books: income from bank deposits:      $9,680.00
  Books: total revenue recorded:        $19,680.00   <-- wrong

  Correct revenue:                      $10,000.00
  Correct fee expense:                     $320.00
  Overstatement to remove:               $9,680.00

The reconciliation model that prevents it

Treat Stripe like a bank account, because functionally it is one: money accumulates there and periodically moves to checking. Set up a 'Stripe balance' account in your books. Revenue is recorded gross from Stripe data into that account, fees are recorded as a processing-fee expense out of it, and a payout is a transfer from the Stripe balance account to your checking account. A transfer touches no income account, so when the bank feed shows the deposit, it matches the transfer and adds nothing to revenue. Your income statement shows $10,000 revenue and $320 of fees; your bank shows $9,680 arriving; everything ties and nothing is counted twice.

This model also fixes a second, quieter error: recording only the net deposits as revenue. That understates revenue and hides your processing fees entirely, which misstates expenses and can misstate tax reporting, since gross receipts are generally what gets reported. Gross revenue plus explicit fees is the model accountants expect, and Stripe's balance activity export gives you exactly those columns: gross, fee, net, per transaction.

You do not need per-transaction bookkeeping to run this model. A perfectly serviceable version is a monthly summary journal: one entry per month recording total gross Stripe revenue, total fees, and total refunds, sourced from the balance activity export, with every payout deposit matched as a transfer. Smaller businesses often land here because it keeps the books accurate without importing thousands of individual charges. The essential invariant is the same either way: exactly one source records revenue, and bank deposits from Stripe never touch an income account.

Cleaning up a ledger that is already double counted

Work through the affected period in this order:

Export the payouts list from Stripe for the whole affected period. This is your authoritative list of every deposit that reached the bank, with dates and amounts.
Export or filter your bank-feed transactions for the same period, and isolate deposits from Stripe. Match them to the payout list by amount and date, remembering the two-business-day lag.
Recategorize every matched deposit from income to a transfer from the Stripe balance account. In QuickBooks and Xero this is editing the category on the bank transaction, not deleting it; the deposit is real, only its classification was wrong.
Verify the Stripe side is booked gross with fees. If your Stripe import recorded net amounts as revenue, rebuild it from the balance activity export so revenue is gross and fees are an expense.
Re-run the totals: books revenue should now equal Stripe gross volume for the period, fee expense should equal Stripe's fees, and the Stripe balance account should carry only the small float of not-yet-paid-out charges.
If prior periods were already closed or filed with inflated revenue, take the size of the overstatement to your accountant before adjusting; amending versus adjusting-forward is their call.

The matching step is where the spreadsheet work lives, and it goes much faster with clean inputs. Stripe exports and bank exports disagree on everything: column names, date formats, description text with inconsistent casing and stray whitespace. Running both files through PipeSheets first, trimming whitespace, normalizing headers to snake_case, dropping the unneeded columns, and standardizing the description casing with a case transform, gives you two tidy files whose rows you can actually line up in a spreadsheet. PipeSheets does the cleanup and prep; the matching itself is a sort-and-compare job in Excel or Sheets.

Preventing it: bank rules in QuickBooks and Xero

Once the model is in place, automate the classification so the double count cannot quietly return. In QuickBooks, create a bank rule that matches deposits whose description contains Stripe and records them as transfers from the Stripe balance account, and stop accepting the feed's suggestion to add them as income. In Xero, do the same with a bank rule mapping Stripe-described statement lines to the Stripe clearing account. On the revenue side, pick exactly one mechanism to record Stripe sales, whether an integration or a monthly summary journal from the balance activity export, and make sure it books gross revenue and fees. One revenue source, deposits always transfers: with those two rules the books stay right without anyone remembering to be careful.

The same model applies to every processor, not just Stripe. PayPal, Square, and Shopify Payments all follow the identical pattern: gross charges, deducted fees, batched net deposits. If you take payments through more than one of them, give each its own clearing account and its own bank rule, because a ledger that fixes Stripe but books PayPal deposits as income has the same disease in a different account.

It is worth a calendar reminder to spot-check one month per quarter: pick a month, compare books revenue to Stripe's Dashboard gross volume, and confirm they match within the timing lag. The double count is easy to reintroduce, for example when a new bank account gets connected or a bookkeeper changes, and a five-minute quarterly check catches it before it contaminates a year.

Double-counted Stripe deposits feel alarming because the books are badly wrong, but the failure is mechanical, not mysterious: two feeds described the same money and both got called income. Reclassify the deposits as transfers, book revenue gross with fees, add the bank rule, and the numbers snap back to reality, and stay there.