Because the deposit is net, and it is never going to match your gross sales.

That isn’t a bug in the connector or a mistake in the setup. Marketplaces don’t pay per order — they batch a period’s activity, subtract everything they’re owed, and send what’s left. A thousand dollars of sales arrives as a smaller number, on a different day, covering a period that doesn’t align with your month.

Everything that goes wrong in e-commerce bookkeeping follows from people trying to make those two figures agree, or from giving up and booking the deposit as income.

The equation

Every marketplace payout resolves to the same shape:

Gross sales − refunds − chargebacks − processing fees − platform fees − sales tax payable + shipping income + adjustments = net payout

Your books need every one of those lines. The bank shows only the last one.

A worked example. A payout covering $1,000 of gross sales and $160 of shipping income, less $80 of sales tax collected, $60 of platform and processing fees and a $40 refund, lands in the bank as $980.

A $1,000 sale reaching the bank as $980. Every deduction is an accounting entry of its own; the bank shows only the last line.
View data
LineAmountWhere it goes
Gross sales$1,000Revenue
Refunds−$40Contra-revenue
Fees−$60Processing expense
Sales tax collected−$80Liability — remitted, not income
Shipping income+$160Revenue
Net to bank$980Cash movement only

What should be in the books:

LineAmountWhere it goes
Gross sales$1,000Revenue
Shipping income+$160Revenue
Refunds−$40Contra-revenue
Fees−$60Processing expense
Sales tax collected−$80Liability — remitted, not income
Net to bank$980Cash movement only

Signs shown explicitly because the direction is the point: shipping income adds, everything else subtracts. $1,000 + $160 − $40 − $60 − $80 = $980.

Book the $980 as sales income and three things happen simultaneously:

  • Gross sales are understatedby $180 — you booked $980 of revenue against $1,160 of actual sales income, and that gap widens with every fee and refund
  • Fees vanish. They’re netted inside a revenue figure, so nobody can see what the platform costs
  • Refunds disappear entirely, so returns rate is invisible
  • Sales tax is booked as incomewhen it’s money held on behalf of a tax authority

The profit and loss still balances. It’s simply describing a business that doesn’t exist.

Then timing makes it worse

Even with the components split correctly, the dates don’t line up. Payout schedules follow the platform, not your calendar:

PlatformPayout cadence
Shopify PaymentsRolling schedule
AmazonEvery 14 days
StripeConfigurable
PayPalOn demand

None of them match the sale date, and none match month-end.

Amazon settlements routinely span two calendar months. A settlement period running 25 September to 8 October contains sales belonging to two reporting periods and arrives as one deposit. Splitting it is not optional if the monthly numbers are to mean anything.

The related trap: reconciling by order date rather than by payout. A sale made on the last day of the month may not reach the bank until the next one. Reconcile by order date and the books look wrong even when the arithmetic is right.

Reconcile by payout. Always.

Shopify is harder than Amazon

Counterintuitive, and it comes down to one thing: a Shopify store can run several payment processors at once.

Shopify Payments, PayPal, Stripe, Klarna, Afterpay — each creates its own independent payout stream, on its own schedule, depositing separately into the bank. None align with each other, and none align with the calendar month.

So a single month’s Shopify sales can arrive as four or five unrelated deposit streams, each net of different fees, each on a different cadence. Amazon at least gives you one settlement report per period.

What this means practically: each processor needs its own clearing account and its own reconciliation. A PayPal deposit doesn’t belong in the same reconciliation as a Shopify Payments deposit, even though both are Shopify sales. Blending them is how the trail is lost.

The fix is a clearing account

One structural change resolves most of this.

Don’t post sales to the bank. Post them to a clearing account, and move cash out of it when the payout lands.

The sequence:

  1. Create a clearing account per payout stream. “Shopify Payments Clearing”, “Amazon Settlement Clearing”, “PayPal Clearing”. One per processor, not one for e-commerce.
  2. When sales occur, post gross sales to revenue, refunds to contra-revenue, fees to expense, sales tax to liability — with the net going to the clearing account, not the bank.
  3. When the payout lands, match the bank deposit against the clearing account. It’s a transfer, not income. The income was already recorded.
  4. At month end, the clearing account should be zero— or exactly equal to sales that have occurred but not yet been paid out.

That last point is the whole control. The clearing balance is the amount the marketplace owes you. If it’s zero when it shouldn’t be, or a number nobody can explain, something is being posted wrong — and you find out this month rather than at year end.

It also solves the period problem. Revenue is recognized when the sale happens, cash moves when the payout arrives, and the two are allowed to be in different months without anything looking broken.

The one-minute check

The fastest way to know if e-commerce books are wrong

Take gross sales from the P&L for a month. Take gross orders from the marketplace’s own report for the same month. If they don’t broadly agree, the books are recording payouts rather than sales — and margins, tax, returns rate and channel profitability are all built on that.

The single fastest way to know whether a client’s e-commerce books are wrong.

Take gross sales from the profit and loss for a month. Take gross orders from the marketplace’s own report for the same month. Compare.

If they don’t broadly agree, the books are recording payouts rather than sales, and everything downstream — margins, tax, returns rate, channel profitability — is built on that.

It takes a minute and it’s the first thing worth doing on any inherited e-commerce file.

Cash basis doesn’t survive contact with this

A structural point that’s rarely made directly.

Marketplace payment rails are built on a lag between the sale and the cash. Sales occur, the platform holds the money, deductions accumulate, and a net figure arrives days or weeks later. Modeling that properly needs revenue recognized at the sale and the marketplace balance carried as a receivable until the payout arrives — which is accrual treatment, and it’s ordinary GAAP.

A surprising number of sellers run cash-basis books on top of accrual-required rails, then live with the resulting noise because nobody has explained where it comes from. Their monthly revenue swings with payout timing rather than with trading, and reserve holds look like lost sales.

Before it’s a bookkeeping task

If a client is on cash basis and selling through marketplaces, that’s a conversation before it’s a bookkeeping task.

Summary-level or order-level?

The configuration question every connector asks and most people answer by accident.

Summary-level posts a per-settlement or daily total, split into its components. The books stay clean and small, reconciliation is straightforward, and per-order detail stays in the sales platform where it already lives.

Order-level posts every transaction into QuickBooks. Full detail, and for a high-volume seller a very large number of records the business will never query there.

Summary-level is right for most clients, because QuickBooks is the accounting system rather than the order management system. Order-level earns its place when QuickBooks genuinely is being used to manage orders.

What matters is that the choice is made deliberately, and that whichever is chosen, the components are still split. A summary posting that lands as one net figure has the same problem as the bank deposit.

On connectors: purpose-built settlement tools exist for this — A2X and Link My Books are the most established — and specialist practitioners put pricing in the region of $50 to $300 per month per channel depending on volume. Whether that’s worth it depends on volume and how much manual splitting it replaces. Verify current pricing directly.

The short version

  • The deposit is net and will never match gross sales. It isn’t supposed to.
  • Gross sales − refunds − chargebacks − processing fees − platform fees − sales tax + shipping income + adjustments = net payout. Your books need every line; the bank shows one.
  • Booking the net deposit as income understates gross sales, hides fees, hides refunds, and books sales tax as revenue.
  • Payout cadences follow the platform, not your month. Amazon settlements routinely span two calendar months.
  • Reconcile by payout, never by order date.
  • Shopify is harder than Amazon because several processors can pay out independently, each needing its own clearing account.
  • Use a clearing account per payout stream. It should return to zero, or to exactly what the marketplace still owes.
  • The one-minute check: gross sales on the P&L versus gross orders on the marketplace report. If they don’t agree, the books are recording payouts rather than sales.
  • Cash basis doesn’t work on accrual-required payment rails.

Frequently asked questions

Why doesn't my Shopify payout match my sales in QuickBooks?

Because the payout is net. It’s your gross sales minus refunds, chargebacks, processing fees, platform fees and sales tax collected, plus shipping income and adjustments. The deposit is meant to be smaller than gross sales. Reconciliation means breaking the deposit back into those components and proving each one, not matching the deposit to a sales figure.

How do I record Amazon settlements in QuickBooks?

Download the settlement report from Seller Central for the period matching the deposit. Split it by category — gross sales, refunds, Amazon fees, shipping income, reimbursements, reserves — and post each to its own account rather than combining them. Post the net to a dedicated Amazon clearing account, then match the bank deposit against that clearing account.

What is a clearing account and why do I need one for e-commerce?

A clearing account holds the value of sales that have occurred but haven’t yet been paid out. You post the sale to revenue and the cash to the clearing account, then clear it when the payout lands. This keeps revenue in the correct month regardless of payout timing, and the clearing balance tells you exactly what the marketplace still owes you. Use one per payout stream, not one for all e-commerce.

Should I reconcile by order date or payout date?

By payout. Sales, refunds and fees frequently fall in different reporting periods from the bank deposit — a sale on the last day of the month may not reach the bank until the next. Reconciling by order date makes the books look wrong even when the arithmetic is correct.

Can I just categorize the Shopify deposit as sales income?

No. Doing so understates gross sales, buries platform and processing fees inside revenue so nobody can see what the channel costs, makes refunds invisible, and records sales tax collected as income when it’s a liability. The P&L will still balance while describing a business that doesn’t exist.

Why is Shopify harder to reconcile than Amazon?

Because a Shopify store can run several payment processors simultaneously — Shopify Payments, PayPal, Stripe, Klarna, Afterpay — each with its own independent payout stream and schedule, none aligned with each other or with the calendar month. Amazon provides one settlement report per period. Each Shopify processor needs its own clearing account and its own reconciliation.

Do I need accrual accounting for marketplace sales?

Effectively yes. Marketplace payment rails put a lag between the sale and the cash, so proper treatment means recognizing revenue when the sale occurs and carrying the marketplace balance as a receivable until the payout arrives — standard accrual treatment. Cash-basis books on those rails produce revenue that swings with payout timing rather than with trading.

About the author
Sejal Jansari
Senior Accountant

QuickBooks Online ProAdvisor and Xero Certified Advisor. Leads delivery for US CPA firm engagements at Nimblechapps Finance.

LinkedInLast reviewed: August 3, 2026