Inventory in ecommerce rarely sits in one place. It is distributed across warehouses and fulfilment centres, moves between them, and gets consumed from whichever location actually ships the order.
For accounting, that creates events that have nothing to do with selling.
Not every inventory event is a sale
| Event | Accounting treatment |
|---|---|
| Sale from a warehouse | COGS recognised, stock reduced at that warehouse. |
| Purchase into a warehouse | Stock and payable recorded at the receiving location. |
| Stock transfer out | Asset moves between warehouse locations. |
| Stock transfer in | Asset lands at the destination warehouse. |
| Return to stock | Inventory returns to a warehouse, reversing COGS where applicable. |
A stock transfer, in particular, is not revenue and not a cost. It is the movement of an asset between locations — yet if it is not recorded warehouse-wise, the ERP’s stock and the marketplace’s fulfilment data drift apart.
Why warehouse-wise detail matters
- GST data and inventory data both key off locations.
- Fulfilment costs are decided by which warehouse ships.
- P&L by warehouse is only possible if movement is coded to locations.
- Your ERP’s warehouse masters stay balanced with reality.
Aggregate it all into “total stock”, and none of the above is answerable.
How the accounting should represent it
Per order and per stock transfer, DeepEcom captures the source warehouse, destination, item, quantity and valuation. That becomes:
- COGS lines against the correct warehouse.
- Stock transfer entries between warehouse ledgers.
- Return-to-stock lines reversing cost where sales reversed.
For Tally, SAP and Zoho, posting respects the ERP’s warehouse master so the ERP mirrors physical movement.
The result
When accounting is warehouse-wise, “stock damage” and “stock transfers” are ordinary, auditable events instead of mystery adjustments. Multi-warehouse ecommerce stops being a reconciliation problem and becomes a routine part of the monthly close.