Complete Ecommerce Accounting Guide for Marketplace Sellers in India

1. Why marketplace accounting is different

Offline trading books usually start with your invoice and end with your bank receipt. Marketplaces insert several layers between those points:

• Order vs shipment vs settlement dates rarely line up, so accrual timing matters.
• Fees (commission, shipping, closing, storage, advertising) arrive in separate lines and may or may not affect taxable value the way sellers expect.
• Returns and replacements reverse economics after the original sale was recognised.
• TCS is collected by the marketplace and must be matched GSTIN-wise to credits and books.
• Multi-warehouse / multi-GSTIN operations create inter-state movements (including IXD-style transfers) that ordinary sales import tools ignore.

Teams that treat Seller Central or Seller Hub exports as “sales invoices” understate this complexity. The trustworthy unit of marketplace accounting is the settlement, not the order confirmation screen.

There is also a people problem: the operator who downloads reports, the accountant who posts Tally, and the CA who files GSTR often work from different extracts. Without a shared settlement source of truth, each person “fixes” numbers locally. Those local fixes become permanent drift. Ecommerce accounting software for India has to enforce one pipeline from report → books, not three competing Excel versions.

Finally, volume changes the risk profile. A seller at a few hundred orders can survive manual vouchers. At 3 Lakh+ orders/month, a 0.2% mis-post rate is already hundreds of wrong lines. Controls (company verification, GSTIN segregation, exception queues, rollback) matter as much as mapping rules.

2. Settlement-first thinking

A robust process mirrors how money actually moves:

1. Marketplace activity — sales, returns, fees, adjustments.
2. Settlement file — the marketplace’s statement of what it will pay and what tax lines it reports.
3. Bank remittance — cash landed in your account.
4. Accounting books — Tally vouchers with GST breakup, inventory and ledgers your CA recognises.

Settlement-first also changes how you talk about “automation.” Importing an order CSV is not automation if fees, TCS and GSTIN splits are still hand-edited every fortnight.

Practically, settlement-first means your chart of accounts must distinguish revenue, recoverable TCS, marketplace payables/receivables, and fee expenses. If everything lands in “Amazon Sales,” you will never reconcile. Design ledgers with your CA once, then let software post into that structure repeatedly. That is how 500+ specialist ecommerce accountants keep multi-client books reviewable.

What “good” looks like at month-end

You should be able to answer, for each marketplace and GSTIN: what settled, what remitted, what remains open, what TCS was reported, and which vouchers in Tally explain those amounts. If any answer requires a new pivot table from scratch, the process is not yet settlement-first.

3. GST, TCS and mismatch risk

Marketplace GST work fails in predictable places:

• Wrong IGST vs CGST/SGST treatment when GSTIN or place-of-supply logic is wrong.
• HSN / rate differences between listing data and books.
• TCS that does not reconcile GSTIN-wise against settlement and credit statements.
• Period cut-offs where settlements straddle months.

Automated GST reconciliation means matching settlement GST and TCS to accounting entries and flagging exceptions early—not hoping the bank total “looks close enough.” For Flipkart and Amazon sellers, this is the difference between a calm filing week and notice-driven fire drills.

Treat exceptions as first-class work. A queue of HSN mismatches is healthier than silent posting. Silent posting produces books that “balance” and still fail when compared to marketplace tax reports. KartManage’s approach is to verify rates and flag SKU/HSN issues during reconciliation so corrections happen before GSTR preparation.

Ecommerce operator reporting (including tables that reference supplies through operators) also depends on clean outward-supply data in books. Your tax professional still owns the return, but they cannot invent quality from messy ledgers.

See also: TCS reconciliation for marketplace sellers and GST compliance for marketplace sellers.

4. Multi-GSTIN and inventory movement

Growth across states usually means more than one GSTIN. That forces:

• GSTIN-wise segregation of orders, fees and payments
• Tally company or cluster mapping per GSTIN
• Stock transfers to fulfilment centres with e-way bill / e-invoice where required
• IXD-style inter-state movements with matched purchase and sales entries

Spreadsheets collapse here because every transfer is a paired accounting event, not a note in a logistics tracker. KartManage supports multi-GSTIN ecommerce accounting and stock transfer workflows so inventory and tax stay aligned.

Related reading: Multi-GSTIN ecommerce accounting, E-way bill stock transfer to Tally.

5. COGS and margin truth

Marketplace P&Ls lie when COGS is estimated in Excel while inventory lives elsewhere. Prefer inventory-driven COGS in Tally:

• Keep purchase rates and stock items clean.
• Post sales/returns with stock impact.
• Keep marketplace fees in expense ledgers—not buried inside COGS.
• Review negative stock and unmapped SKUs before calling margin “final.”

When vouchers reconcile to settlement files and inventory movements, gross margin becomes something a CA can defend. Guide: Ecommerce COGS calculation.

6. Getting data into Tally safely

Many Indian sellers still use XML export/import. It works until volume, partial imports, duplicates or wrong-company posts appear. A safer pattern:

1. Enable Tally HTTP access.
2. Verify the target company before any sync.
3. Pilot one GSTIN / one settlement period.
4. Review sample vouchers with your CA.
5. Scale; use report-driven rollback if a correction is needed.

Also decide B2C vs B2B posting style: consolidated B2C can reduce load; B2B often needs order-wise detail for compliance.

7. A practical monthly close checklist

1. Download Amazon and Flipkart sales, settlement, fee and transfer reports for the closed period.
2. Confirm GSTIN mapping and Tally company targets.
3. Import and review exception queues (HSN, SKU, tax type).
4. Sync vouchers via HTTP; spot-check sales, fees, TCS and stock transfers.
5. Reconcile settlement totals to bank remittances.
6. Clear COGS/inventory exceptions.
7. Hand settlement-aligned books to your CA for GSTR preparation.
8. Archive report versions used for the close (audit trail).

High-volume teams (3 Lakh+ orders/month) should treat this as a calendarised process, not an end-of-month scramble.

8. Building your accounting stack

A clear separation of tools reduces pain:

• Marketplaces — selling, ads, logistics (Seller Central / Seller Hub).
• KartManage — settlement accounting bridge: GST/TCS, multi-GSTIN, IXD, stock transfers, Tally HTTP sync.
• Tally — statutory books, inventory valuation, CA review.
• CA / tax tools — return filing and advisory.

Do not expect a TDL add-on designed for single-GSTIN, low-volume sellers to behave like a settlement engine for pan-India FBA/FBF operations. Choose tools by failure mode: wrong company, wrong GSTIN, unreconciled TCS, unposted FC transfers.

9. Common mistakes to avoid

• Booking GMV as sales and ignoring fee/TCS lines until bank credit arrives.
• One spreadsheet for five GSTINs.
• XML imports with no rollback plan.
• Posting to Tally without company verification.
• Calling books “done” before settlement–bank–ledger matching.
• Mixing advertising and closing fees into COGS.
• Ignoring stock transfers until physical stock and books diverge in an audit.

How to recover if you are already behind

Pick one closed settlement period and one GSTIN. Rebuild that slice end-to-end with verified Tally posting. Do not attempt a six-month catch-up in one night. Once one period reconciles—settlement, bank, TCS, sample vouchers—repeat forward. KartManage demos often start exactly this way: your raw downloads, one controlled pipeline, proof before full history.

If prior years are messy, separate “clean going forward” from “historical cleanup.” Mixing both usually produces neither. Your CA can advise which historical gaps are material for notices versus which can be documented and closed.

Who owns which step?

Seller / ops: timely report downloads, GSTIN master data, warehouse/FC movement inputs.

Accountant / KartManage operator: import, exception clearance, Tally sync, settlement–bank matching.

CA: return strategy, ISD/GSTR decisions, audit responses, chart-of-accounts design.

Clarity here prevents the classic failure mode where everyone assumes someone else reconciled TCS. Document owners in your monthly checklist.

10. FAQs