QUICK ANSWER
A Shopify payout does not match your bank deposit because the payout is a net figure. Shopify deducts processing fees, refunds issued during the period, chargebacks and adjustments before the money is sent, and a single deposit can span several days of sales. Revenue is the gross figure before any of that. The two were never the same number, and making them agree is the wrong goal.
Why does my Shopify payout not match my bank deposit?
Because one is gross and the other is net, and the gap between them is everything Shopify took out on the way. The deposit that lands in your account has already had processing fees deducted, refunds issued during that settlement period removed, chargebacks taken off, and sometimes a reserve held back. It may also cover sales from more than one day.
This matters because the instinct, when a bookkeeper says the numbers do not agree, is to ask them to make the numbers agree. That request produces worse books rather than better ones. The right question is not how to reconcile the deposit to revenue, but how to take the deposit apart so that each piece lands where it belongs.
What is actually inside a single payout?
Six components, and a given payout may contain any combination of them. This is the anatomy to work from when you open a settlement file for the first time.
- Gross sales for the orders in the settlement period, before anything is deducted.
- Shipping and handling charged to the customer, which is revenue and not a recovery of your shipping cost.
- Sales tax collected on those orders, which is money you are holding on someone else’s behalf rather than income.
- Processing and platform fees, deducted by Shopify before the transfer.
- Refunds issued during the period, which may relate to orders from a previous period entirely.
- Chargebacks, adjustments and any reserve held or released.
Notice that the fifth item breaks the tidy mental model most people start with. A refund inside this week’s payout can belong to a sale from six weeks ago. If your books treat the payout as a self-contained unit, that refund reduces this period’s revenue rather than the period that earned it, and your month-over-month comparisons quietly stop meaning anything.
Where should each piece actually be posted?
Gross sales go to revenue. Shipping charged to the customer goes to revenue, as its own line rather than folded into product sales, because the margin on shipping is usually negative and you want to be able to see that. Sales tax collected goes to a liability account, not to revenue, because the money is not yours. Processing and platform fees go to an expense account. Refunds go against the product and the period they relate to. Chargebacks go to their own expense line so you can see whether they are trending.
The deposit itself then becomes what it always was: a cash movement that happens to be the arithmetic result of all of the above. When the books are built this way, the bank reconciliation is the easy part, because the deposit figure falls out of the detail rather than being reverse engineered into it.
What breaks when the deposit is booked as revenue?
The profit figure survives, which is precisely why the error persists for years. Booking the net deposit as revenue understates revenue and understates expenses by exactly the same amount, so the bottom line is roughly right and nobody investigates.
What does not survive is every ratio above that line. Gross margin is wrong, because the cost side is missing the fees. Your effective processing rate is invisible, so you cannot tell whether a payment provider change saved you anything. Channel profitability cannot be calculated, because the fee structures differ by channel and you have buried them. And your sales tax liability is sitting inside revenue rather than on the balance sheet, which means the filing position has to be reconstructed from settlement files every period.
There is a growth consequence too. A business that cannot see its real fee percentage cannot tell whether scale is making it more or less efficient. Revenue doubles, fees more than double because the mix shifted toward a more expensive channel, and the only visible signal is that profit did not keep pace. The cause is legible in properly built books and invisible in these.
How do I fix books that were built this way?
Three steps, and the second is the one that determines whether the fix holds. First, decide how far back you are going. A single fiscal year with intact settlement records is usually a few weeks of work. Several years, or periods where the settlement data is no longer downloadable, is a different scope and should be priced before it is started.
Second, rebuild the chart of accounts and the settlement mapping before touching historical data. If the mapping is wrong, a re-import simply reproduces the problem faster. This is where tools such as A2X earn their place: the software pulls the settlement detail and splits it, but the accuracy comes from how the accounts are mapped underneath it rather than from the connection existing. We hold a 99.7% zero variance rate on those tie-outs, which is a statement about mapping discipline rather than about software.
Third, close the current month properly before going backwards. It is tempting to start with the oldest period, and it is the wrong order. Getting the current month right establishes the pattern, gives you a working baseline, and means that if the historical cleanup takes longer than expected you are at least not falling further behind while it runs.
Frequently asked questions
Should my bookkeeper reconcile the payout to my Shopify revenue report?
No, not directly. The payout is a net cash figure and the revenue report is gross. The correct reconciliation is from the settlement detail to the general ledger, with the deposit falling out as the cash result.
Do I need A2X to do this properly?
Not strictly, but at meaningful volume the manual alternative is hours of work every month and the error rate climbs. What matters more than the tool is whether the chart of accounts and the mapping were built for an ecommerce business.
What about a refund for an order from a previous month?
It should be posted against the product and, where it is material, against the period that recorded the sale. Netting it against the current month’s revenue makes both months wrong.
How do I know if my books have this problem?
Look at your profit and loss statement. If there is no payment processing fee expense line, or the figure there looks too small for your volume, the fees are almost certainly buried inside net revenue.
NEXT STEP
Transcounts keeps the books for Canadian Shopify and Amazon sellers and ties payouts to cash with a 99.7% zero variance rate on A2X reconciliations. The $99 Ecommerce Diagnostic reviews how your payouts are currently posted and reports back within seven business days. The fee is credited against onboarding if you proceed.
