Why Shopify deposits never match your sales (and how to reconcile payouts instead)

Your Shopify deposit hits the bank: $4,812.67. Your sales dashboard says you did $5,400 that day. Nothing is broken — you are comparing two numbers that were never going to be equal. A payout is not a list of your orders. It is a batch of charges, refunds, fees, and chargebacks, netted together and paid on the processor's clock, not yours. The moment you stop matching the deposit to your sales and start reconciling the payout against its own report, this stops being a month-end nightmare and turns into arithmetic. Here is the method.

Why the deposit can't match your sales

A store owner on r/smallbusiness laid it out cleanly: a payout is not just a deposit. It folds in order payments, partial refunds, gift cards, discounts, chargebacks, shipping adjustments, and platform fees, all at once. Their one-line summary of the result is the line every ecommerce bookkeeper knows by heart.

The bank deposit never matches the gross order value.

That is not a bug in Shopify, your bank, or your bookkeeping. The deposit and your sales disagree for three structural reasons, and all three are working as designed.

The most useful answer in one r/Bookkeeping thread gets the first reason exactly right:

the mismatch is usually because QBO records the gross sale amount but your bank gets the net deposit after processing fees. if you're recording both and trying to match them 1:1 they'll never line up.

Right — and it does not stop at fees. Refunds, chargebacks, gift-card redemptions, and reserve movements stack on top, and the timing lag means the period never lines up either. So the fix is not a better lookup. It is changing what you match.

Reconcile the payout, not the order

Stop tying the bank deposit to your sales. Reconcile it against the payout report instead — the one Shopify exposes under Finance, Payouts, or the payout reconciliation report Stripe and most processors publish — keyed on the payout ID. The payout is the natural unit: it is what actually hit your bank, and it is the only record that already knows about every fee, refund, and chargeback bundled into that deposit. A commenter in that same nightmare thread, doing roughly 30,000 orders a month, described the alternative:

We have an accounting team that is manually reconciling each payout to all the orders every day and it is becoming a lot of pain.

Matching every payout back to every order by hand is the hard way, and it does not scale. The payout report already did that bundling for you. Your job is to verify it in layers.

The three layers, in order

A payout reconciliation is really three reconciliations stacked, and they get easier as you climb. Do them in this order.

Layer 1 — bank deposit to payout

Match each deposit in your bank feed to a payout on the report by payout ID, date, and net amount. This is a clean one-to-one match — exactly the kind of set difference a spreadsheet handles well — and it catches the bank-side problems first: a payout that never arrived, a deposit recorded twice, or one still in transit across a weekend.

Layer 2 — payout to its components

For each payout, confirm the arithmetic of the batch. Shopify's payout export gives you Amount, Fee, and Net columns; Stripe's payout reconciliation report breaks the batch into reporting categories with gross and fee. The identity you are checking:

  gross charges
  − refunds
  − chargebacks and dispute fees
  − processing fees
  ± balance adjustments
  ± reserve held / released
  ─────────────────────────────
  = net payout  (the bank deposit)

If that adds up, the deposit is explained in full — and you book it as a journal entry through a clearing account (next section), not as one lump of revenue.

Layer 3 — gross charges to recorded sales

Only this layer touches order-level data, and you do it by period, not by deposit. Sum the gross charges across every payout in the month, add what is still in transit at the cutoff, and tie that to the gross sales your storefront or ERP recorded for the same period. This is an accrual check: revenue belongs to the period of the sale, not the period the cash landed. Match the cash to the sale and you end up wrong in both months.

Use a clearing account so the two sides don't have to tie 1:1

The mechanism that makes all three layers work is a clearing account — a holding account that absorbs the netting and the timing. Record the gross sale into the clearing account when the order is placed. When the payout lands, move the net amount into the bank and route the fees, refunds, and chargebacks to their own accounts, which empties the clearing account for those orders. Gross sales and the net deposit never have to equal each other directly; the clearing account holds the difference until it resolves.

Multiple processors? One lane each.

Shopify Payments, Stripe, PayPal, and Amazon each settle on their own schedule, with their own payout IDs, fee structure, and report. They do not share a transaction ID, so there is no clean way to net them together — and you should not try. Give each processor its own clearing account and reconcile it in its own lane. A multi-channel seller named the per-processor tax of getting this wrong:

Stripe fees are netted out — I have to manually gross them back up.

Reserves make it worse: some processors hold back a slice of money you have already earned but cannot yet account for, so the in-transit balance in that lane is real and has to be tracked, not ignored. Keeping the lanes separate is what stops one processor's timing quirk from contaminating another's reconciliation.

Where the settlement tools fit

You do not have to build Layer 2 by hand. Tools like A2X and Link My Books read the settlement file and post a summarized journal — gross sales, fees, refunds — straight into QuickBooks or an ERP, which is exactly the per-payout journal above, automated. Synder is the one people reach for when a native accounting integration mis-imports. They are legitimate and they save real hours. Just read recommendations with clear eyes — in the nightmare thread, the top reply was a question:

Have you looked at A2X? I'm the Director of Operations at a boutique cloud based accounting firm called Accounting Elements and we use A2X to connect Shopify to our clients' books.

Useful, but it is a recommendation from someone whose firm runs on the tool, not a neutral verdict. And it helps to know what these tools do and do not do: they post clean numbers to your general ledger, which answers the accounting question. They do not tell you whether your store, your OMS, and your processor agree on what actually sold — that reconciliation is still yours, and it is the one auditors ask about.

A working sequence

1. Pull the payout report for the period and key it on payout ID (Shopify: Finance, Payouts; Stripe and others: the payout reconciliation report).
2. Layer 1: match each bank deposit to a payout by ID and net amount; resolve missing or duplicated deposits before anything else.
3. Layer 2: for each payout, confirm gross − refunds − chargebacks − fees ± adjustments ± reserve = net, and book it as a journal through a clearing account.
4. Layer 3: sum gross charges for the period, add what is in transit, and tie it to gross sales in your store or ERP on an accrual basis.
5. Check that the clearing-account balance equals payouts in transit plus reserves, and investigate only the remainder.

Run it in that order and "the deposits never match" stops being a mystery. It resolves into a fee line, a timing lag, and a short list of real exceptions — which is all it ever was. The deposit was never going to equal your sales. Reconcile the payout instead, and it does not have to.

← All writing