How to Account for Returns in a Multi-Entity E-commerce Consolidation — And Why Getting It Wrong Inflates Group Revenue

Tom is the group controller for a three-entity fashion e-commerce business. The UK trading entity runs the Shopify store and processes all customer sales and refunds. The EU fulfilment warehouse holds the inventory and ships orders on the trading entity’s behalf. A third entity in Australia handles clearance sales for end-of-season and returned-but-unsellable stock.

The group has a 24% return rate — typical for fashion — and manages several thousand returns every month. Tom has always known that the return accounting was “a bit messy” in the consolidated accounts, but it wasn’t until the group’s auditor queried a persistent intercompany receivable in the warehouse entity that anyone sat down to trace exactly what was happening.

What they found: every customer return was creating an intercompany accounting loop that nobody was eliminating. The UK trading entity processed the refund and reversed the revenue. The EU warehouse received the physical stock and reinstated it as inventory. But because those two entries sat in different legal entities, the consolidated accounts showed both a revenue reversal in the UK entity and an intercompany receivable in the warehouse — as if the group had written off income while simultaneously owing itself money. Over twelve months, the accumulated uneliminated intercompany balance from returns had grown to £218,000. The group’s consolidated net assets were overstated by that amount, and the monthly revenue figure had been quietly inflated each time a return was processed but not eliminated.

This is not an unusual situation. It is the standard outcome in any multi-entity e-commerce group where returns handling has been designed for operational efficiency rather than accounting completeness.

Why Returns Become a Consolidation Problem When Entities Are Separate

In a single-entity e-commerce business, a return is simple: the customer sends the goods back, the entity refunds the payment, reverses the revenue, and reinstates the inventory. All four entries sit in one ledger and net to zero.

In a multi-entity group where the trading entity and the fulfilment entity are separate legal entities, the same commercial event splits across two ledgers — and the two sides of the split create an intercompany balance that must be explicitly eliminated in the consolidation.

Here is how the split happens. The customer bought from the UK trading entity. The trading entity processes the refund: it pays the customer back (or authorises the payment processor to do so) and reverses the revenue and cost of sale in its own books. The physical goods, however, are returned to the EU warehouse — a different legal entity — which receives the stock and reinstates it as inventory in its own books. The warehouse is now holding stock that it received from the customer, but its books need to reflect that the corresponding value came from somewhere. It creates an intercompany receivable: the trading entity owes the warehouse for the returned stock.

At the group level, that intercompany receivable is not a real asset. The trading entity does not owe the warehouse money — they are under common ownership. The intercompany entry must be eliminated, just like any other intercompany balance. The difference from a standard intercompany sale or loan elimination is that returns happen in high volumes, in both directions, every single day — and in most e-commerce groups, no one has set up a systematic elimination process for them.

The intercompany problem created by returns is structurally identical to any other intercompany elimination — one entity has a receivable, the other has the corresponding payable, and both must disappear from the consolidated accounts. The reason it gets missed is that returns are treated as an operational process rather than an accounting event that spans legal entities.

The Three Journal Entries a Cross-Entity Return Requires

For a return to be correctly accounted for in a multi-entity consolidation, three sets of journal entries are needed: one in the trading entity, one in the warehouse entity, and one elimination journal in the consolidation.

Journal 1 — Trading Entity (the seller)

The trading entity processes the refund and reverses the original sale:

	DR	CR
Revenue (reversal of original sale)	£85.00
Returns Provision (if provision was held)	£85.00*
Refund Payable / Cash		£85.00
Intercompany Receivable — Warehouse	£52.00
		£52.00

* If a provision was held, the revenue reversal reduces the provision rather than hitting the P&L directly. The intercompany receivable records that the warehouse now holds stock worth £52 that belongs (economically) to the trading entity’s cost base.

Journal 2 — Warehouse Entity (the receiver)

The warehouse receives the physical goods and reinstates them as inventory:

	DR	CR
Inventory — Returned Goods	£52.00
Intercompany Payable — Trading Entity		£52.00

The warehouse holds the returned stock at its original cost to the group. The intercompany payable records that the warehouse owes the trading entity the value of the reinstated stock.

Journal 3 — Consolidation (elimination)

The intercompany receivable and payable created by the return must be eliminated:

	DR	CR
Intercompany Payable — Warehouse (in trading entity)	£52.00
Intercompany Receivable — Trading Entity (in warehouse)		£52.00

Eliminates the intercompany balance created by the cross-entity return — neither balance appears on the consolidated balance sheet.

After all three journals, the consolidated position is clean: revenue is reversed in the trading entity, the refund has been paid to the customer, the stock sits on the consolidated balance sheet in the warehouse entity, and no intercompany balance remains. This is the correct outcome. The problem in Tom’s group was that Journal 3 was never being posted — the intercompany receivable and payable were accumulating month after month without elimination.

Volume makes manual elimination impractical. A group processing 3,000 returns per month cannot eliminate each one individually at the transaction level. The practical approach is to aggregate return intercompany balances by entity pair at period end — the total intercompany receivable in the trading entity against the total intercompany payable in the warehouse entity — and eliminate the net balance in a single consolidation journal. This requires a reliable returns reconciliation schedule that both entities agree on before the close.

When the Returned Goods Are Damaged or Unsellable

The three-journal approach above assumes the returned goods can be restocked at their original cost. In practice, a portion of returns in fashion and consumer goods are damaged, used beyond what can be resold, or simply out of season by the time they come back. These need a fourth step: a write-down of the returned inventory to its net realisable value, or a write-off if the goods are unsellable.

Suppose 30% of Tom’s returned goods are unsellable. Of the £52 reinstated in the warehouse, £15.60 needs to be written off. The warehouse entity records:

	DR	CR
Cost of Sales / Stock Write-Off	£15.60
Inventory — Returned Goods		£15.60

Writes off unsellable returned stock at period end — this cost sits in the warehouse entity’s P&L, not the trading entity’s.

This creates a subtle but important analytical question: in which entity does the cost of unsellable returns sit, and does the group P&L make that visible? In Tom’s structure, the cost of damaged returns lands in the warehouse entity’s cost of sales — but the revenue reversal sits in the UK trading entity. In the consolidated P&L, both appear, but they may be on different cost lines depending on how the chart of accounts is structured. A group-level analysis of return costs needs to capture both the revenue reversal (trading entity) and the write-off of damaged goods (warehouse entity) to show the true cost of the group’s return rate.

For groups where the Australian clearance entity takes end-of-season and lightly damaged stock from the warehouse, a further intercompany transfer is needed — moving the goods at their written-down value from the warehouse to the clearance entity, with a corresponding intercompany elimination at consolidation. Each hop adds an elimination entry. The principle is the same at each step: match the intercompany receivable with the intercompany payable and eliminate both.

Returns in Foreign Currencies

Tom’s group adds a currency dimension that makes the return accounting more complex. The UK trading entity records the original sale in GBP. The refund is also in GBP. But the stock is now sitting in the EU warehouse, which reports in EUR. The intercompany receivable in the trading entity is denominated in GBP; the intercompany payable in the warehouse is denominated in EUR.

When those two balances are translated to the group’s presentation currency for the elimination, any movement in the GBP/EUR rate between the date of the original sale and the date of the return creates a translation difference. That difference is not a performance issue — it is a currency movement on the intercompany balance. Under IAS 21 and equivalent standards, it needs to be recognised appropriately: as a currency translation adjustment in equity if the intercompany balance is effectively part of the net investment in the foreign operation, or as a P&L currency gain/loss if it is a normal trading balance expected to be settled.

For most return-related intercompany balances — which are settled within the normal close cycle — the P&L treatment is typically correct. The practical implication is that the elimination journal must be prepared in the group’s presentation currency using consistent translation rates, and any residual difference after elimination must be identified and posted to the appropriate line rather than left as an unexplained consolidation difference.

High return rates shouldn’t mean high close complexity

BrizoConsol reconciles intercompany balances across all your entities — including those created by returns — flags mismatches before they accumulate, and eliminates them with a clear audit trail every period.See It In Action

How a Returns Provision Prevents Month-End P&L Distortion

Even with the intercompany elimination process in place, a high-return e-commerce group faces a P&L timing problem: returns from November’s Black Friday and Cyber Monday sales arrive back in January. If the group only reverses revenue when the physical return is processed, the November consolidated P&L looks too good (full revenue recognised, minimal returns) and January looks worse than the actual trading performance (return reversals hit the P&L against lower new sales). The swing between the two months can be material enough to mislead the board about underlying performance.

The accounting solution is a returns provision: an estimate, posted at the period end for each selling entity, of the revenue that will be reversed in future periods as a result of returns on current-period sales. The provision is calculated from the trailing return rate applied to current-period dispatches.

Returns provision — November close, UK Trading Entity

November dispatches (at selling price):          £1,200,000
Trailing 90-day return rate:                          22%

Returns provision required:                    £264,000

	DR	CR
Revenue	£264,000
Returns Provision		£264,000

Provisions for expected returns on November dispatches — reduces recognised November revenue to reflect the proportion that will be reversed

When the actual return is processed in December or January, it reduces the provision rather than hitting revenue directly — so the P&L impact has already been absorbed in the correct period. The provision is released to the extent that actual returns are lower than estimated, or increased if returns exceed the estimate.

The provision must be calculated and held in the selling entity — the one that recognised the revenue. It is not held in the warehouse entity. This keeps the provision correctly matched to the revenue it is adjusting, and means the elimination process for cross-entity returns (described above) operates on the actual physical returns, while the provision handles the timing smoothing in the revenue line.

The returns provision rate should be reviewed at least quarterly and updated when the return rate changes materially — for example, after a change in returns policy, a new product category with a different return profile, or a channel mix shift (Amazon returns tend to run higher than direct Shopify returns). Using a stale rate produces a provision that is systematically too high or too low, which is its own source of P&L distortion.

For the broader revenue recognition framework that a returns provision sits within, including how consignment goods and marketplace fee recognition interact with the provision calculation, see our post on why e-commerce group revenue figures don’t agree across entities.

How Returns Interact With the Unrealised Profit Elimination

Groups that transfer stock between entities at a markup — covered in detail in our practical guide to e-commerce group consolidation — face an additional complication when those goods are returned. If the fulfilment entity transferred stock to the trading entity at cost plus 15%, and the trading entity subsequently sells those goods to a customer who returns them, the returned goods come back into the group’s inventory at the transfer price — which includes an intercompany margin that was never realised externally.

When the warehouse reinstates the returned stock, it should reinstate it at the group’s original cost (the cost before the intercompany markup), not at the transfer price. If it reinstates at the transfer price, the consolidated inventory is overstated by the intercompany margin on every returned unit — a version of the unrealised profit problem applied to returned goods rather than closing stock.

Stage	Transfer Price (Warehouse to Trading Entity)	Group Cost	Customer Sale Price
Original stock transfer	£60.00	£52.17	—
Customer sale	—	—	£85.00
Customer returns goods	—	—	(£85.00)
Warehouse reinstates at transfer price	£60.00	—	—
Overstatement vs group cost	—	£7.83	— per unit

The fix is to reinstate returned goods in the warehouse at group cost (the cost before any intercompany markup), not at the transfer price. This requires the warehouse to know the original group cost of every returned unit — information that should be available from the inventory management system but often isn’t surfaced in the accounting system automatically.

Pre-Close Checklist for E-commerce Group Returns

The following checklist addresses the main return-related accounting failures in a multi-entity e-commerce consolidation. It should be run as part of the intercompany reconciliation step, before eliminations are posted.

1. Reconcile cross-entity returns by entity pair. For each entity pair where returns flow across (trading entity to warehouse, warehouse to clearance entity), produce an agreed schedule of the total returns value for the period. Confirm both entities have recorded the matching sides of every return before elimination is attempted.
2. Eliminate the intercompany return balance. Post a single consolidation journal eliminating the net intercompany receivable (in the entity that processed the refund) against the intercompany payable (in the entity that received the stock). Confirm no residual intercompany balance remains.
3. Write down damaged or unsellable returns. Obtain the damaged goods report from the warehouse. Post the write-down in the warehouse entity before consolidation. Confirm the write-down is classified consistently on the group chart of accounts (typically cost of sales or a separate “returns write-off” line, not revenue).
4. Check that returned stock is reinstated at group cost. Where stock was transferred between entities at a markup, confirm that returns are reinstated at the pre-markup group cost — not at the transfer price. Any overstatement of reinstated inventory inflates consolidated net assets.
5. Calculate and post the returns provision. For each selling entity, calculate the provision for expected future returns on current-period dispatches using the agreed trailing return rate. Confirm the provision is held in the selling entity and matches the prior-period provision adjusted for actual returns processed since.
6. Reconcile the provision movement. Confirm that actual returns processed in the period have been applied against the opening provision (not double-counted as both a provision release and a direct revenue reversal). The provision balance at period end should reflect only the expected returns on current-period dispatches not yet returned.

For groups running returns through a dedicated reverse-logistics entity or a separate clearance channel, each hop in the returns chain requires its own intercompany elimination. The checklist above applies at each stage. The key discipline is that no intercompany balance created by a return should appear on the consolidated balance sheet — if it does, it means an elimination was missed.

For guidance on the broader intercompany elimination process that this checklist plugs into, see our complete guide to intercompany eliminations and the intercompany reconciliation guide, which covers how to structure the pre-elimination matching step across all entity pairs.

What Tom Found When the Returns Were Properly Eliminated

When Tom’s group went back and eliminated the accumulated £218,000 intercompany return balance, two things changed in the consolidated accounts. The consolidated net assets fell by £218,000 — reflecting the removal of an intercompany receivable that should never have been there. And the monthly revenue figures for the prior twelve months were restated to be slightly lower, as the returns provision approach was backdated so that revenue in high-dispatch months was correctly reduced by the expected return rate.

The net effect on cumulative profit was approximately zero — the accumulated returns had already reduced revenue when they were physically processed; the restatement just moved that reduction to the correct period. But the monthly P&L profile changed substantially: November and December no longer looked like outlier-strong months followed by outlier-weak Januaries. The board finally had a P&L that showed what the business was actually doing, rather than a timing artefact of when returns were processed relative to when sales were recognised.

Getting returns accounting right in a multi-entity e-commerce consolidation is not a technically difficult problem. It is a process design problem — one that requires the finance team to treat every cross-entity return as an accounting event that spans legal entities, and to build the elimination step into the close as a non-negotiable checkpoint rather than an afterthought.

Close faster with intercompany returns handled automatically

BrizoConsol connects your e-commerce entities, reconciles intercompany balances including returns, and surfaces any mismatches before they become auditor findings. Start Free Trial