Why Your E-commerce Group’s Revenue Figures Don’t Agree — And How to Standardise Recognition Across Entities

Priya is the group controller for a four-entity e-commerce business. The group runs a direct-to-consumer Shopify store in Australia, an Amazon UK seller account, a wholesale division that supplies independent retailers, and a fulfilment warehouse that ships stock on behalf of the other three entities. Every month, Priya consolidates the four sets of accounts into a group P&L and presents revenue to the board. And every month, the board’s first question is some version of the same thing: “Why is this number different from what we see in the channel reports?”

The answer, which Priya has been unable to give cleanly for the better part of a year, is that the four entities are measuring revenue in four subtly different ways. The Shopify store recognises revenue at the moment of dispatch, before the customer has received anything. The Amazon entity records the net amount that lands in its bank account after Amazon has deducted its fees — not the gross sale price the customer paid. The wholesale division recognises revenue when it invoices the retailer, including on shipments sent on consignment that the retailer can return unsold. And the fulfilment warehouse charges the other three entities a per-order handling fee, which shows up as intercompany revenue in its accounts.

None of these policies is necessarily wrong on its own. Together, they produce a consolidated revenue figure that is partly gross, partly net, partly premature, partly deferred, and partly intercompany — and which therefore cannot be compared meaningfully against any single benchmark, budget line, or prior-year figure. The board is right to question it.

Why Revenue Recognition Is Harder for E-commerce Groups Than for Other Industries

For a traditional single-entity business selling goods from a physical store or a single website, revenue recognition is relatively straightforward: goods are transferred, the customer pays, revenue is recognised. The complexity that e-commerce groups face comes from operating across multiple channels simultaneously, each with its own commercial structure, and from doing so through separate legal entities that may have adopted different policies independently.

Four specific recognition problems appear repeatedly in multi-entity e-commerce consolidations. Each one is addressable, but each requires a different fix — and the fixes must be applied consistently across all entities before the consolidated revenue figure can be trusted.

Problem 1 — Gross vs Net: The Marketplace Fee Question

When a customer buys a product through a marketplace such as Amazon, Etsy, or eBay, the customer pays the full sale price to the marketplace. The marketplace deducts its fees — referral fees, fulfilment fees, advertising costs — and remits the net amount to the seller. The question is: which figure is revenue?

Under IFRS 15 and most equivalent standards, the answer depends on whether the entity is acting as a principal (it owns the goods and bears the risk of sale) or as an agent (it is facilitating someone else’s sale). A typical Amazon third-party seller is acting as a principal — it owns the inventory, sets the price, and bears the inventory risk. This means revenue should be recognised at the gross sale price, with marketplace fees shown separately as a cost of sale or selling expense.

Where e-commerce entities go wrong is in recording only the net remittance from the marketplace. This is administratively simpler — it matches the bank deposit exactly — but it understates revenue and distorts gross margin, because the marketplace fee disappears into the difference between the gross sale and the net receipt rather than appearing as a visible cost line.

Amazon sale — gross vs net treatment comparison

Customer sale price:                         £100.00
Amazon referral fee (15%):                  £15.00
Net remittance to seller:                   £85.00

Net recognition (wrong for a principal):
  Revenue:                                   £85.00
  Marketplace fees visible:                £0.00

Gross recognition (correct for a principal):
  Revenue:                                   £100.00
  Marketplace fees (cost):                 £15.00

  Net margin impact: identical — but revenue is correctly stated

For Priya’s group, the consolidated revenue figure was understated by every Amazon referral fee the UK entity had ever booked as a net entry rather than a gross sale. At 50,000 orders per year with an average fee of £12, that is £600,000 of revenue that was invisible in the group P&L — present in the gross margin calculation but absent from the top line.

The correcting journal to restate a net-recorded period to gross:

Dr Marketplace Fees Receivable / Clearing     £X
Cr Revenue                                       £X

Grosses up revenue from net-recorded marketplace sales; corresponding fee is recognised as cost of sale

Principal vs agent is a judgement call, not a rule. Some marketplace arrangements genuinely make the entity an agent — for example, if the marketplace sets the price, holds the inventory risk, and the entity merely earns a commission. In those cases, net recognition is correct. The key question is: who bears the risk of the sale not completing and the inventory not being sold? If it’s the entity, gross recognition applies. Seek advice if the arrangement is ambiguous.

Problem 2 — Timing: Dispatch, Delivery, and the Return Window

Revenue from the sale of goods is recognised when control of the goods passes to the customer. The question of exactly when control passes — and therefore when revenue should be recorded — is where e-commerce groups most commonly diverge across entities.

The Shopify store in Priya’s group recognises revenue at dispatch, on the grounds that legal title transfers when the goods leave the warehouse. The Amazon UK entity, following Amazon’s seller guidance, considers the sale confirmed only once the delivery is recorded — typically three days after dispatch. A third approach, used by some e-commerce businesses with high return rates, is to defer a portion of revenue until the return window has closed, on the basis that the customer still has a contractual right to reverse the transaction.

All three approaches have accounting logic behind them. The problem is that they produce different revenue figures for the same commercial events. In December, when dispatch-to-delivery spans the month-end date, the Shopify store and the Amazon entity will report different revenue for goods shipped in the last week of the month — one will include them, the other won’t. Scaled across a busy trading month, this timing difference can run to hundreds of thousands of dollars in consolidated revenue.

The standard test is not “when did we ship it?” or “when did the customer receive it?” — it is “when did control transfer?” Control includes the right to direct the use of the goods and obtain substantially all the economic benefits. For most e-commerce sales with standard carrier terms, control transfers at dispatch. But where goods are shipped on a “sale or return” basis or where the seller has a significant return obligation, recognition may need to be deferred.

The fix for Priya’s group is a group-level revenue recognition policy that specifies, for each channel and business model, exactly when revenue is recognised. Once that policy is written and applied consistently, the timing difference between entities disappears — because they are all applying the same test to the same commercial events.

Problem 3 — Consignment Stock That Is Not Revenue Yet

Priya’s wholesale division ships stock to independent retailers and invoices them at the point of shipment. For most of these shipments, this is correct — the retailer takes title on delivery and the sale is complete. But for a subset of the wholesale business — roughly 20% by value — the retailer is taking the stock on consignment: they pay only for what they sell, and return the remainder unsold at the end of the season.

On a consignment arrangement, the goods have left Priya’s warehouse but control has not transferred to the retailer. The entity still owns the inventory. No revenue should be recognised at the point of shipment. Instead, the stock should remain on the group balance sheet as inventory held by a consignee, and revenue should be recognised progressively as the retailer reports sales through.

When the wholesale entity invoices at shipment for consignment goods, it overstates revenue by the full value of unsold consignment stock held by retailers at period end. It also understates closing inventory on the consolidated balance sheet. The correcting entry:

Dr Revenue                                               $X
Cr Deferred Revenue (Consignment)                    $X

Defers revenue on consignment goods not yet sold by the retailer at period end

Dr Inventory — Consignment Stock Held by Retailers   $X
Cr Cost of Sales                                          $X

Reinstates inventory cost on consolidated balance sheet for goods still owned by the group

The practical implication for close is that the wholesale entity must obtain a consignment stock report from each retailer at month end — confirming what has been sold through and what remains. Without this report, the deferred revenue calculation cannot be made accurately. Building consignment reporting into the retailer relationship from the outset (rather than trying to retrofit it at month end) is significantly easier than the alternative.

Problem 4 — Intercompany Fulfilment Revenue That Inflates the Group Top Line

Priya’s fulfilment warehouse charges a per-order handling fee to the Shopify store and the Amazon entity. In the warehouse entity’s accounts, this shows up as revenue. In the Shopify and Amazon entities’ accounts, it shows up as a fulfilment cost. At the entity level, both entries are correct.

At the group level, both must disappear. The warehouse has not earned revenue from an external customer — it has earned it from a sibling entity. The Shopify and Amazon entities have not paid a cost to an external supplier — they have paid one to a sibling. In the consolidated group P&L, neither the revenue nor the cost should appear. The elimination journal:

Dr Fulfilment Revenue — Warehouse entity               $X
Cr Fulfilment Cost — Shopify / Amazon entities        $X

Eliminates intercompany fulfilment charges — both lines disappear from consolidated P&L

This is a standard intercompany elimination and follows the same logic as any other intercompany trading elimination. What makes it easy to miss in e-commerce groups is that the fulfilment entity is often treated as an operational cost centre rather than a trading entity, and the intercompany charges are not formally documented in a way that flags them for elimination. If the warehouse entity’s revenue is not on the consolidation team’s radar as an intercompany item, it will survive into the group P&L as apparent external revenue — inflating the group top line and distorting gross margin, because the corresponding cost is eliminated while the revenue is not.

For a comprehensive reference on intercompany elimination types and the journals that apply to each, see our complete guide to intercompany eliminations and our explanation of why intercompany eliminations are required.

Consolidating multiple e-commerce entities shouldn’t mean reconciling forever

BrizoConsol pulls actuals from your accounting systems, maps intercompany transactions for elimination, and produces a clean consolidated P&L across all your entities — with the revenue recognition policy you set, applied consistently.See It In Action

How to Write a Group Revenue Recognition Policy for an E-commerce Group

The root cause of all four problems above is the same: each entity adopted a revenue recognition approach independently, without reference to a group-level policy. The solution is equally consistent: write one policy, apply it across all entities, and enforce it at the point of budgeting and monthly close.

A group revenue recognition policy for an e-commerce multi-entity group does not need to be a long document. It needs to answer four specific questions for each entity and each sales channel the group operates:

Question	Why It Matters	Answer to Specify
Principal or agent?	Determines gross vs net recognition for marketplace channels	State the conclusion for each channel (Amazon, Shopify, wholesale) and the reasoning
When does control transfer?	Determines the recognition timing point — dispatch, delivery, return window close	Specify the trigger event for each channel; note any exceptions for high-return SKUs
How are returns and refunds treated?	Determines whether a provision for expected returns is required at period end	Specify the return provision method and the rate applied (e.g., trailing 90-day return rate by channel)
Which transactions are intercompany?	Identifies what must be eliminated before the group P&L is presented	List all intercompany flows — fulfilment charges, management fees, intercompany stock transfers — and confirm they are on the elimination schedule

Once the policy is written, it needs to be reviewed at the start of each budget year to confirm it remains appropriate — particularly if the group has opened new channels, entered new markets, or changed its commercial terms with marketplace platforms. A policy that was correct for a Shopify-only group may need updating when that group adds an Amazon seller account with different fee structures and return terms.

The policy should also be used as the basis for the group chart of accounts, so that the revenue line items in every entity’s accounts map cleanly to the consolidated P&L structure. For guidance on how to design that structure, see our post on how to design a common chart of accounts for multi-entity groups.

Pre-Close Checklist: E-commerce Group Revenue

With the recognition policy in place, the monthly close process for revenue needs a specific set of checks before the consolidated P&L is presented. The following checklist addresses the four problem types above and the most common variations that appear in practice.

1. Confirm gross recognition for marketplace channels. For each entity selling through a marketplace (Amazon, Etsy, eBay), confirm that revenue is recorded at the gross customer sale price, with marketplace fees shown as a separate cost line. If the entity has recorded net remittances, calculate and post the grossing-up entry before consolidating.
2. Apply the group timing policy consistently. Confirm that all entities have recognised revenue using the same trigger event (typically dispatch, or delivery where the group policy specifies it). For sales processed in the last five business days of the period, check whether dispatch and delivery cross the month-end date and confirm the treatment is consistent.
3. Calculate the consignment stock deferral. Obtain consignment stock reports from all retailers holding goods on consignment at period end. Defer revenue on the unsold balance and reinstate inventory cost on the consolidated balance sheet.
4. Identify and eliminate all intercompany revenue. List all revenue recorded by entities whose customers are other group entities. Confirm the corresponding cost has been recorded by the buying entity in the same period and for the same amount. Post the elimination journal for each intercompany flow.
5. Check the returns provision. For channels with a significant return rate, confirm that a provision for expected returns has been calculated using the agreed method (e.g., trailing return rate applied to the current period’s dispatches) and that the provision is consistent with the prior period’s basis.
6. Reconcile consolidated revenue to channel data. After applying all adjustments, reconcile the consolidated revenue figure to the group’s channel-level sales data (Shopify analytics, Amazon Seller Central reports, wholesale order management system). Any unexplained difference warrants investigation before the numbers go to the board.

Step 6 is the one most e-commerce groups skip, and it is the one that would have caught Priya’s problem earliest. The channel data is the closest thing an e-commerce group has to an independent revenue verification — it comes from the platform directly, before any accounting treatment has been applied. A consistent reconciliation between the accounting system and the channel report is one of the most effective controls available to an e-commerce group finance team.

For more on how to structure the broader monthly close process across a multi-entity group, see our multi-entity month-end close checklist. And for the broader context of what good financial consolidation looks like for e-commerce groups beyond revenue, see our guide to financial consolidation for e-commerce groups.

What Standardised Revenue Recognition Actually Changes

When Priya’s group applied the fixes above — grossing up the Amazon entity, aligning the dispatch timing policy, deferring consignment revenue, and eliminating the warehouse fulfilment charges — the consolidated revenue figure changed. In some months it went up (because the Amazon gross recognition added revenue that had been netted away); in others it went down (because consignment deferrals removed revenue that had been recognised prematurely). The gross margin percentage stabilised, because marketplace fees became visible as costs rather than hidden in a net revenue figure.

More importantly, the board stopped questioning the number. Once the methodology was documented, consistent, and reconciled to channel data, the revenue figure became a starting point for a conversation about performance rather than the subject of the conversation itself. That shift — from defending the number to using the number — is what a properly constructed group revenue recognition policy delivers.

Get a consolidated P&L your e-commerce board will trust

BrizoConsol consolidates actuals across your e-commerce entities, applies intercompany eliminations, and surfaces a clean revenue figure — with the audit trail to show exactly how it was built. Start Free Trial