Ecommerce Accounting: Payouts Are Not Revenue

Ecommerce accounting goes wrong in a specific and predictable way: the money that arrives in your bank is not the money your store recorded, and nobody can explain the difference. The store says one number, the payout says another, and somebody spends a day a month working out why.

The gap is not an error. It is everything that happens between a customer paying and cash landing, and if your books do not model those steps, they will never reconcile.

Why the numbers never match

A customer pays a hundred. Your processor takes its fee. A refund from last week is deducted. A chargeback and its fee come off. A rolling reserve holds back a percentage if you are in a higher risk category. The remainder is batched with other days and paid out on the processor's schedule, not yours.

So one payout covers several days of orders, minus several kinds of deduction, arriving after the sales it relates to. The store's revenue figure and the bank deposit will never be the same number, and treating the deposit as revenue is the single most common mistake in ecommerce bookkeeping. It understates both revenue and expenses, which quietly misstates your margin.

The correct shape: record gross revenue at the sale, record processing fees as an expense, record refunds against revenue, and treat the payout as a transfer rather than income.

Sales tax, which is the part that becomes a problem later

In the United States, economic nexus means you can owe sales tax in a state where you have no premises and no staff, purely because you sold enough there. Thresholds are set per state, they differ, and they change.

Three consequences worth internalising. You have to know your sales by state, which means your order data needs to be reportable that way from the beginning. Tax collected is not revenue, it is money you are holding for a state, and spending it is a problem you discover at filing. And the obligation starts when you cross a threshold, so the first you hear of it is usually after the fact.

Marketplace facilitator rules mean marketplaces often collect and remit on your behalf, which helps and also means those sales are treated differently from your own store's. Rules vary by state and change, so verify current thresholds against the state's own guidance rather than a summary. Above the smallest scale, this is worth an accountant rather than an article.

Inventory is an asset until it sells

Stock you have bought is not an expense yet. It becomes cost of goods sold at the moment it sells, and until then it sits on the balance sheet.

Getting this wrong makes a profitable month look terrible because you restocked, and a bad month look fine because you did not. It also makes margin per product unknowable, which matters more than the monthly figure, because it decides what to buy and what to promote.

Landed cost is the detail people skip: what you paid the supplier, plus freight in, duties and any per-unit handling. Cost that excludes shipping to your warehouse understates cost of goods and overstates margin on exactly the products where freight is heaviest.

Timing, and why it matters more than it sounds

Cash accounting records money when it moves. Accrual records it when it is earned or incurred.

For a store holding inventory, cash accounting is actively misleading: a large stock purchase makes a strong month look like a loss, and a month spent selling that stock looks unusually profitable. Accrual matches the cost to the sale, which is the only way margin means anything.

Deferred revenue is the related case. Pre-orders and subscriptions are cash you have received for something not yet delivered. It is a liability until you deliver, not revenue, and treating it as revenue makes a growing subscription business look better than it is right up until churn.

What a workable setup looks like

Orders sync to your accounting system as invoices, gross, with tax separated. Processor fees import as expenses. Payouts import as transfers and reconcile against the orders they cover. Refunds appear as credit notes rather than negative sales. Inventory purchases go to the balance sheet and move to cost of goods at the point of sale.

Then the monthly job is reviewing what did not match rather than working out what everything was.

Most of that is configuration in tools that already exist. The part that is not configurable is whether your store's data can answer the questions at all: sales by state, cost at the time of sale, refunds tied to their original orders.

Where we fit, and where we do not

The order data is what accounting needs and ours is shaped for it: gross and tax separated, refunds as their own records rather than adjustments, line-level cost captured at the time of sale so margin is a fact rather than a reconstruction, and everything readable by state over the API. That is what makes a sync to an accounting system a mapping exercise instead of a data-cleaning project.

Where we are the wrong answer: we are not accounting software and do not file anything. We do not calculate sales tax rates, which is a job for a dedicated tax service that tracks thousands of jurisdictions. And nothing here is tax or accounting advice. Above the smallest scale, an accountant who knows ecommerce will save you more than they cost.

The short version

Stop treating payouts as revenue. Record gross, expense the fees, deduct refunds, transfer the payout. Keep tax collected separate from your money and know your sales by state before a threshold finds you. And capture cost at the time of sale, because margin you cannot compute is margin you cannot manage.