This guide lays out the working model of ecommerce accounting that marketplace sellers operate under. Read it with a real order in mind and the concepts become concrete quickly.
Why an order is not a sale
A sale is one economic fact. An ecommerce order is a bundle of facts: the sale, the charges the marketplace applies, the GST on several components, TCS or TDS, and later a refund, a settlement and a payout.
The marketplace reports these facts across different feeds and different times. Accounting for ecommerce therefore means decomposing each order into its events and mapping each event to its accounting treatment.
The event map of an order
| Event | Accounting treatment |
|---|---|
| Order and sale | Revenue at selling price |
| Commission, fees, logistics | Selling or operating expenses |
| GST on sale and charges | Output / input tax per head |
| TCS / TDS | Tax collected / tax deducted ledger positions |
| Refund and return | Revenue and charge reversals; stock-in |
| Settlement | Receivable movement against orders |
| Payout | Bank against settlement receivable |
| Inventory out | COGS and stock movement |
| Stock transfer | Movement between warehouses |
Keep this map. Every entry in a clean ecommerce close is one of these lines, traceable to an order.
Order-wise accounting
Account per order, not per day. Each order produces its own revenue ledger line, charge lines, tax lines, settlement receivable and COGS movement. Summaries at month-end hide nothing but also answer nothing.
The defining property: the journal entries refer to the marketplace order, so the books can always be questioned down to a specific transaction and the settlement report will agree by construction.
GST-wise accounting
Marketplace tax data must be restated per head: output GST by rate on sales, input GST on charges, GST on refunds, and TCS and TDS mapped to the marketplace’s own filings. Aggregate tax totals are not enough — returns, input credits and TCS statements are reconciled per head and per rate.
Warehouse-wise accounting
Inventory moves between warehouses and fulfilment centres, and a transfer is not a sale. Capture source and destination per movement, recognise COGS against the shipping warehouse, and post stock transfers between warehouse ledgers so the ERP mirrors physical movement.
Settlement and payout accounting
A settlement pools many orders into a net payable. Track settlement receivables per marketplace, match payouts to bank deposits, and resolve the residue — unanticipated charges, refunds, TCS/TDS, corrections — until marketplaces, books and bank agree. This is the reconciliation discipline described in its own guide.
Posting into your ERP
The ERP is the system of record and it expects structured postings. Order-wise accounting becomes ERP posting by mapping each line to ledger accounts, tax heads, warehouse masters and GST structures in Tally, SAP or Zoho. Detailed posting — not a monthly sales summary — is what keeps the ERP trustworthy.
Where DeepEcom fits
DeepEcom automates this entire chain: it connects marketplaces, decomposes their data into order-wise events, reconciles settlements and payouts, builds GST-wise, warehouse-wise accounting, and posts the result into your ERP. The ERP remains your system of record.