Revenue Recognition for Ecommerce

The money is in your bank account, so it’s revenue, right? Not always. An ecommerce business can take a gift card order, a pre-paid subscription, and a marketplace payout in the same week and not have earned revenue on any of them yet.

Revenue recognition is the rule that decides when each of those sales counts, and for ecommerce the answer is rarely the day the cash arrives.

What is revenue recognition, and why isn’t getting paid enough?

Revenue recognition is the accounting rule for when a sale counts as revenue. Under ASC 606, the standard every US business follows, you recognize revenue when you deliver what the customer paid for, when control of the product passes to them. Getting paid earlier creates a liability that turns into revenue only once you deliver.

Three moments get mixed up here: the order, the payment, and the delivery, and only delivery earns revenue. Shopify and your payment processor record the sale the instant the cart is checked out, which is why your platform dashboard and your accounting revenue can disagree; the dashboard is counting orders and cash, while your books count what you’ve earned.

This matters because everything downstream, your margins, the base you owe sales tax on, and the revenue a buyer would pay for, is built on revenue landing in the right period.

It’s an accrual idea at heart, part of the same system as the ecommerce bookkeeping guide, and the choice between cash-basis and accrual books is its own topic in cash vs accrual accounting.

An order is a promise, a payment is a prepayment, and delivery is the sale. Revenue is earned when the customer gets what they paid for, which is why the cash can sit in your bank for weeks before it’s allowed to count as revenue.

The five-step model in plain ecommerce terms

The standard turns “when do I earn revenue” into five steps, and for a typical ecommerce order most of them happen on their own. You have a contract, a promise to deliver, a price, a way to split that price when there’s more than one promise, and revenue you recognize as each promise is delivered.

In ecommerce language the five steps read like this. There’s a contract the moment a customer places and pays for an order. There’s a performance obligation, the thing you owe them, usually the product plus any extras like expedited shipping or a future box.

There’s a transaction price, what they paid after any discount. If a sale carries more than one promise, you allocate the price across them. And you recognize the revenue as you satisfy each promise, which for a physical product means when it’s delivered.

For a single in-stock item shipped once, all five collapse into ship it, then count it. The steps only start to bite when money arrives before delivery, or a sale bundles more than one promise.

Table 1. The five steps of revenue recognition, in ecommerce terms.

Step	What it means for an ecommerce order	When it matters most
1. Identify the contract	The customer places and pays for an order	Automatic on every order
2. Identify the performance obligations	The promises you owe: the product, plus extras like expedited shipping, a warranty, or future boxes	Bundles, shipping, subscriptions
3. Determine the transaction price	What the customer paid, after any discount or coupon	Discounts, coupons, variable pricing
4. Allocate the price to the obligations	Split that price across the promises when there’s more than one	Bundles and subscriptions
5. Recognize revenue as each obligation is satisfied	Count the revenue when you deliver each promise	The step that sets the date, usually at shipment or delivery

When does an ecommerce sale become revenue?

For a standard ecommerce order you recognize revenue when the product ships or is delivered, when control passes to the customer, not the moment the order is placed and not when the payment is captured. The order and the payment can happen on Monday while the revenue belongs to Wednesday, the day it leaves your warehouse.

Whether revenue lands exactly at shipment or at delivery follows your shipping terms, but for most ecommerce brands it’s close enough to treat fulfillment as the trigger.

Walk one order through its life: the order is placed and it’s a promise with no revenue yet; the payment is captured and the cash is real but held as a liability until something ships; the order ships or is delivered and the revenue is earned; and if it comes back, the revenue is reversed.

Table 2. When common ecommerce sales become revenue.

Sale type	What triggers revenue	When it is recognized	Where the money sits until then
Standard in-stock order	The product ships or is delivered	At fulfillment, not at checkout	Deferred revenue between payment and shipment (often a day or two)
Marketplace order (your own goods)	The product ships or is delivered	At fulfillment; the gross sale is revenue, fees are an expense	Same as a standard order; the payout arrives later, net of fees
Pre-order or deposit	The item ships	When the product is delivered	Deferred revenue from payment until it ships
Gift card	The card is redeemed for product	On redemption; breakage over time	Deferred revenue until redeemed
Subscription box	Each box ships	As each shipment is delivered	Deferred revenue for prepaid terms, drawn down box by box
Membership or access plan	The period is delivered	Evenly across the period it covers	Deferred revenue, recognized across the term
Refund or return	A return is expected, then happens	Revenue is reduced at the sale via a reserve, trued up on the actual return	A returns reserve (refund liability) offsets revenue

Selling on a marketplace: Do you book gross sales or net payout?

If you sell your own products on Amazon or another marketplace, you’re the principal in the sale, so you recognize the full gross sale as revenue and record the marketplace’s fees as expenses. That makes your revenue larger than the payout that reaches your bank.

You’d record only the net amount if you were an agent, arranging someone else’s sale without ever holding the goods, which isn’t the typical brand.

Booking only the net payout as revenue is one of the most common ways ecommerce revenue goes wrong; it understates the top line, hides the fee stack, and throws off every margin and benchmark built on revenue.

The plain test for being the principal: you’re responsible for fulfilling the order, you carry the inventory and its risk, and you set the price, all of which describe a brand selling its own goods.

The payout that lands is the gross sale minus fees minus any reserve, and splitting a marketplace settlement back into revenue, fees, and tax is its own job, covered in multi-channel ecommerce accounting.

On a marketplace, your revenue is the sticker price the customer paid, while the deposit the platform sends is that amount after its fees. Booking only the deposit as revenue makes a healthy brand look thin and buries fees you could be managing.

Gift cards, pre-orders, and deposits: Cash you can’t count yet

Money you collect before you deliver, a gift card, a pre-order, or a deposit, is deferred revenue, a liability on your balance sheet, and it becomes revenue only as you deliver the product it’s owed against. It’s real cash you can spend, with product you still owe for it, so it hasn’t been earned.

Take the cases quickly. A gift card is deferred revenue when it’s sold and turns into revenue when it’s redeemed for product; the slice that’s never redeemed, called breakage, is recognized over time in line with your real redemption pattern, so it isn’t booked all at once or left on the books forever.

A pre-order or a deposit is deferred revenue until the item ships, which is why a big pre-order launch can fill your bank account without adding revenue that month. These live on the balance sheet as a liability, set up in your chart of accounts, and they show up on your financial statements as deferred revenue.

The month-to-month entries that move money out of the liability and into revenue as you deliver are their own walkthrough in the deferred revenue guide.

A full bank account after a gift-card holiday or a pre-order launch is a liability you now owe product against, and the revenue shows up later, as the cards get redeemed and the orders ship. The cash comes first and the revenue follows it.

How subscriptions earn revenue over time

A subscription is a promise to deliver over time, so you recognize its revenue over time as you deliver, rather than all at once when the customer pays. If a customer pre-pays for six monthly boxes, that cash is deferred revenue up front and turns into revenue one box at a time as each ships. A month-to-month plan earns each month’s revenue as that month is delivered.

Ecommerce subscriptions come in two shapes, and they earn revenue a little differently. A physical subscription box is earned as each shipment goes out, tied to delivery like any other product.

A membership or access plan, a discount club or a content perk, is earned evenly across the period it covers, because the customer gets the benefit across the whole stretch.

The case brands most often get wrong is the annual pre-pay: twelve months of cash arrives in one month, while eleven months of it are still deferred revenue, and the recurring entries, proration, and mid-term changes are covered in the deferred revenue guide.

Here’s a simple worked example, and the figures are illustrative teaching numbers.

A customer pre-pays $180 for a six-month box subscription, so on day one the business records $180 of cash and a $180 deferred revenue liability, then recognizes $30 of revenue each month as a box ships, and the liability winds down to zero over the six months.

Table 3. One six-month subscription: how prepaid cash becomes revenue over time (illustrative numbers).

Point in time	Box shipped?	Revenue recognized	Deferred revenue remaining
At sign-up (Day 1)	No, cash collected only	$0	$180
Month 1	Yes	$30	$150
Month 2	Yes	$30	$120
Month 3	Yes	$30	$90
Month 4	Yes	$30	$60
Month 5	Yes	$30	$30
Month 6	Yes	$30	$0

Refunds and returns: Revenue you have to un-count

Because some orders come back, revenue isn’t final at the moment of sale. The accrual-correct treatment estimates the revenue that will be returned and reduces recognized revenue for it in the same period as the sale, holding a returns reserve, then trues it up as actual returns arrive. It keeps a launch month from looking better than it really was.

There are two ways this gets handled. A brand new or very small business often records each refund as it happens, netting it against revenue in whatever month the return lands, which is easy to run but pushes the cost of a return into the wrong period.

The accrual-correct approach reserves for expected returns in the period of the sale, using the brand’s own return rate, so revenue isn’t overstated the month of a big launch and then dented later.

Your own ecommerce return rate is what sizes the reserve, and refunds and the reserve appear as contra-revenue at the top of the P&L, which is walked through in how to read your ecommerce P&L.

A sale isn’t fully earned until its return window has closed. Reserving for returns up front keeps a launch month honest and stops the following month from taking a hit that belonged to the first.

How to get revenue recognition right in your books

You keep revenue recognition right by recording each sale on the date you deliver it, holding prepaid money as a liability until then, and reserving for returns, and your accounting software can handle most of it once it’s set up correctly. The routine looks like this:

1. Put your books on the accrual basis: Revenue then lands when it’s earned rather than when the cash moves, which is the setup the rest of this depends on.
2. Recognize a standard order at fulfillment: Book the revenue when it ships or delivers, so the sale lands in the period you delivered it rather than at checkout.
3. Hold every prepayment as deferred revenue: Gift cards, pre-orders, deposits, and subscriptions go to a liability account first and move to revenue as you deliver.
4. Book marketplace sales gross: Record the full sale as revenue and the platform’s fees as expenses, then reconcile the payout back to those two.
5. Reserve for returns in the period of the sale: Size it with your own return rate, and true the reserve up as actual returns come in.
6. Reconcile revenue every month: Tie your booked revenue to your platform and processor, and treat any figure that only matches by accident as a bookkeeping problem to fix.

Frequently asked questions