An e-commerce marketplace audit concentrates on three areas specific to the platform model: whether revenue is correctly presented gross (as principal) or net of the amount passed to the seller (as agent), which turns on who controls the goods before transfer to the customer rather than on how the money physically flows; reconciliation of cash-on-delivery collections against third-party courier settlement reports, since COD cash sits with a logistics partner before it reaches the marketplace's bank account; and the adequacy of the return and refund provision, which for a high-return-rate marketplace category can be a larger number than it looks if estimated on a stale historical rate.
Principal versus agent: the revenue presentation question
Under Ind AS 115, a marketplace that merely facilitates a sale between a third-party seller and a buyer — without ever controlling the goods, without inventory risk, and without setting the final price — recognises revenue net, as its commission alone. A marketplace that takes on inventory risk, controls pricing, or is primarily responsible to the customer for fulfilment is acting as principal and should recognise the full sale value as revenue with cost of goods sold against it. Many marketplaces operate hybrid models — some categories on a pure marketplace basis, others where the platform holds its own inventory through a related seller entity — and the classification needs to be made category by category, not for the business as a whole.
| Indicator | Points toward |
|---|---|
| Platform never takes title to goods; seller ships directly | Agent — net revenue |
| Platform sets or materially influences the final selling price to the customer | Principal — gross revenue |
| Platform bears inventory risk (owns unsold stock, bears obsolescence) | Principal — gross revenue |
| Platform is the party the customer holds responsible for a defective product | Principal — gross revenue |
Where a marketplace routes a meaningful share of GMV through a related-party seller entity to justify gross revenue presentation, test the substance of that relationship and the actual allocation of inventory risk rather than accepting the corporate structure at face value.
Cash-on-delivery reconciliation
COD collections are physically received by a courier or logistics partner on the marketplace's behalf, then remitted on a settlement cycle that lags the sale, often by one to two weeks. This creates a specific reconciliation that doesn't exist for a prepaid-only business: sales recorded versus COD collected per courier reports versus cash actually remitted to the bank, with timing differences at every stage.
- 01Obtain courier-wise COD collection and remittance reports, not a summaryEach courier partner settles on its own cycle. A single blended reconciliation across partners hides which specific partner is behind on remittance.
- 02Match order-level COD sales to order-level courier collection confirmationAn order marked delivered in the marketplace's system but with no matching collection confirmation from the courier is either a collection failure or a reconciliation gap, and either needs investigation.
- 03Age the COD-in-transit balanceAmounts collected by courier but not yet remitted to the bank should age out within the normal settlement cycle. Balances ageing well beyond that cycle point to a recovery problem with that specific courier partner.
- 04Confirm cash lost to RTO (return to origin) or failed delivery isn't sitting unresolvedA failed COD delivery means no cash was ever collected against a booked sale — this needs to flow through as a cancelled order, not remain as an open receivable indefinitely.
The returns provision
Categories like apparel and footwear routinely see return rates well above other categories, and a provision built on a stale blended historical rate across all categories will misstate the provision for high-return categories specifically. The provision needs to reflect expected returns on sales made close to period end that haven't yet completed their return window, computed category by category.
- Segment the historical return rate by product category, not as a single blended percentage across the platform.
- Confirm the return window used in the provision matches the platform's actual stated return policy for each category.
- Test whether refunds are issued as cash, store credit or wallet balance — a wallet-credit refund is a liability on the balance sheet, not a cash outflow, and needs to be tracked as such.
- Check for seasonal spikes (post-sale-event periods) where the return rate is structurally higher than the annual average used in the provision.
This is practical guidance written for audit teams, not an authoritative statement of any standard or statute. Standards, forms and timelines change. Check the current text issued by the ICAI and the relevant authority before relying on anything here in an audit file.
Related resources
- Revenue, receivables & cut-offRevenue recognition testing in a statutory auditThe transfer-of-control test that governs when a sale is recognised, the misstatement patterns that recur in practice, and what evidence ties a recognised sale to an underlying document.
- Bank, cash & treasuryBank reconciliation audit procedure for statutory auditWhat a BRS must reconcile, the red flags that separate a timing difference from a cover-up, and how many months you actually need to review.
- Revenue, receivables & cut-offAuditing sales returns and credit notesWhy post-year-end credit notes are a classic overstatement signal, how to match them to the original invoice, and the GST reporting implications auditors should check.
- Revenue, receivables & cut-offMatching dispatch, invoice and ledger for revenue testingThe sales-side mirror of the purchase three-way match: what breaks it in practice, and why the unmatched population should be sized by value, not count.
Free tools, no signup
Each one reads a file entirely in your browser — or, for two of them, just answers a few questions — and nothing is ever uploaded.
- Purchase register checkDuplicate payments, round-sum amounts, weekend-dated invoices, incomplete records.
- GSTR-2B reconcilerMatches your purchase register against GSTR-2B — missing invoices either side, amount mismatches.
- Bank reconciliation checkerMatches your cash book against a bank statement — what's outstanding on each side.
- Fixed asset register checkDuplicate asset codes, missing location or useful life, negative net book value.
- Payroll red-flag scannerBank accounts shared across employees, and records missing an ID, PAN or salary.
- CARO applicability checkerAnswer a few questions about the company and see which CARO 2020 clauses likely apply.
- MSME payment delay checkerMSME-flagged invoices paid — or still unpaid — beyond the 45-day Section 22 limit.
- Related-party transaction screenerTransactions above a threshold you set with no approval reference, grouped by counterparty.
- Depreciation useful life checkerCompares a useful life in use against the Schedule II, Part C indicative figure.
- Materiality calculatorOverall and performance materiality against PBT, revenue, assets or equity, with reasoning shown.
- Sample size calculatorStatistical sample size for a test of controls or a substantive test of detail.