The CA's Guide to E-commerce Client Accounting
E-commerce sellers are now a standard part of most Indian CA practices, and their books behave differently from any other trading client. A marketplace seller does not raise invoices one by one, collect payments directly, or control the fees deducted from their revenue. Everything flows through Amazon, Flipkart or Meesho, arrives as bulk report files, and settles in lumps that rarely match the sales figure for the same period. This guide lays out a working method for taking on these clients without drowning in spreadsheets.
Why marketplace books behave differently
Three structural facts drive almost every accounting problem you will meet with these clients:
- The marketplace is the counterparty for cash. Customers pay the platform; the platform pays your client after deducting commission, shipping, collection fees and taxes. The bank statement shows net settlements, not sales.
- Returns and cancellations are constant. A sale recorded in July may be reversed in August, with the refund and fee reversal landing in a later settlement cycle.
- Data arrives as files, not documents. Order reports, settlement reports and fee statements are downloadable spreadsheets, each with its own layout per marketplace.
If you post from bank entries alone, you will book net receipts as income and understate both turnover and expenses. Under GST, that approach also makes it hard to tie books to the tax collected at source that marketplaces deduct and report. Treat the marketplace reports, not the bank statement, as the primary source, and confirm all tax positions with the current rules before filing anything.
The reports that actually matter
Every marketplace publishes many reports; only a few are load-bearing for accounting purposes.
| Report | Where it comes from | What it gives you |
|---|---|---|
| Order or sales report | Seller panel of each marketplace | Gross sales, order IDs, dates, values, tax breakup |
| Settlement or payment report | Payments section of the seller panel | What was actually paid, per order, with every deduction |
| Returns report | Seller panel | Refunds and reversals to net off against sales |
| Bank statement | Client's bank | Independent confirmation that settlements landed |
Ask the client for these on a fixed monthly schedule. A seller who sends you files ad hoc will always be the client whose books are three months behind.
Structuring vouchers in TallyPrime
The goal is books where turnover, marketplace fees and settlements are each visible on their own ledgers rather than netted into one figure. A workable ledger structure per marketplace includes a marketplace receivable ledger, a sales ledger, ledgers for each major fee head (commission, shipping, collection charges), and a returns ledger. Sales vouchers debit the receivable; settlement entries credit it, with fees booked to their expense ledgers so nothing disappears into a net amount. Doing this by hand for thousands of order rows is where most firms give up, which is exactly the step tools like TallySutra automate: it converts Amazon, Flipkart and Meesho report files into balanced TallyPrime vouchers with the fee heads already separated. The features page shows the voucher structure it produces.
Reconciliation is the control, not an afterthought
The core control for a marketplace client is settlement reconciliation: proving that every order either settled at the expected amount, was returned, or is still pending. Done at order level, it surfaces short payments, unexplained fees and missed refunds that summary-level checks smooth over. If you are new to the mechanics, start with our plain-language explainer on settlement reconciliation. The discipline to adopt from day one: no period is closed until the reconciliation for that period shows what is matched, what is pending, and what is an exception someone must resolve.
A workflow that survives growth
One client with three hundred orders a month is manageable in a spreadsheet. Ten clients across three marketplaces are not. Build the practice workflow around three habits: standardise the ledger structure across clients so any team member can read any file; make import duplicate-safe so re-running a report never double-posts; and put a review step between data import and posting to Tally, so a senior signs off before vouchers hit the client's books. TallySutra's CA workspace is built around exactly this loop, with a multi-client dashboard, an exception queue and a review-and-approve step before anything is posted. Start with one pilot client, prove the reconciliation ties out, then standardise. The firms that struggle are the ones that scale the client count before they scale the method.
Frequently asked questions
Should I record marketplace sales from the bank statement?
No. Bank entries show net settlements after fees and returns, so booking them as income understates turnover and hides expenses. Record sales from marketplace order reports and treat settlements as receipts against a marketplace receivable ledger.
How often should e-commerce client books be updated?
Monthly at minimum, aligned to the marketplace settlement cycles. Waiting until quarter-end multiplies unresolved returns and unmatched settlements, and makes reconciliation far harder than it needs to be.
Does TallySutra file GST returns for my clients?
No. TallySutra converts marketplace report files into balanced TallyPrime vouchers and reconciles settlements. GST filing remains your process, and tax positions should always be confirmed against the current rules.
TallySutra turns Amazon, Flipkart and Meesho reports into reconciled, reviewed TallyPrime vouchers — duplicate-safe, with every rupee traceable to its source row.
Book a 30-minute demo