Tally Ledger Setup for E-commerce Sellers
Most marketplace accounting problems in TallyPrime are really ledger problems. If the chart of accounts is set up once, correctly, every later step — importing sales, booking fees, reconciling settlements, filing GST — becomes mechanical. Skip it, and every import run dies in a pile of rejected vouchers, because TallyPrime refuses any voucher that references a ledger it cannot find. Here is the setup that works for Amazon, Flipkart and Meesho sellers.
The core ledger list
| Ledger | Group (under) | Used for |
|---|---|---|
| Amazon Seller Services / Flipkart / Meesho (one per marketplace) | Sundry Debtors | Party ledger — sales accrue here, payouts clear it |
| Online Sales — B2C (optionally per marketplace) | Sales Accounts | Revenue from marketplace orders |
| Marketplace Commission | Indirect Expenses | Referral and closing fees |
| Shipping and Fulfilment Fees | Indirect Expenses | Weight handling, FBA/Easy Ship charges |
| Advertising — Marketplace | Indirect Expenses | Sponsored ads deducted from settlements |
| Output CGST / SGST / IGST | Duties & Taxes | GST on your sales |
| Input CGST / SGST / IGST | Duties & Taxes | GST charged on marketplace fee invoices |
| TCS Receivable (GST) | Current Assets | Tax collected at source by the operator under Section 52 |
| Marketplace Rounding | Indirect Expenses | Paise differences in settlements |
Whether you keep one sales ledger or split by marketplace and GST rate is a reporting choice — splitting makes GSTR-1 tie-outs easier, one ledger keeps the P&L compact. Ask your CA which fits your filing workflow before you lock it in.
Grouping decisions that matter later
- Marketplaces are debtors, not banks. The settlement cycle (sale, fees, TCS, payout) plays out inside the party ledger. Booking sales straight to bank hides receivables and makes reconciliation impossible.
- Separate fee heads beat one lump. A single Marketplace Charges ledger works, but separate commission, shipping and advertising ledgers let you actually see what each channel costs.
- GST ledgers must match how you file. Output and input tax ledgers under Duties & Taxes with the correct tax type, so Tally's GST reports pick them up.
Naming conventions for automation
TallyPrime's import matches ledger names as exact text. Amazon Seller Services and Amazon Seller Services (spot the trailing space) are different ledgers, and the mismatch surfaces as a rejected voucher with a LINEERROR — see our LINEERROR troubleshooting guide. Three rules prevent nearly all of it: pick one canonical name per ledger and never edit it casually; avoid trailing spaces and double spaces; and if you rename a ledger, update every mapping in your import tool the same day. Boring discipline, large payoff.
Opening balances deserve a moment too. If you are moving to this structure mid-year, bring the marketplace party ledgers in with their true unsettled balances as on the cutover date — the platform's own balance report is the source — and let your CA sign off the figures. Starting a party ledger at zero when the marketplace actually owes you three lakhs guarantees the ledger never reconciles, and the error gets blamed on every import that follows. The same applies to TCS Receivable: carry in the credit already sitting with the department, or the asset understates from day one.
Finally, resist merging fee ledgers later just to tidy the P&L — merged history breaks year-on-year comparisons and any saved mappings pointing at the old names. If a restructure is truly needed, do it at year start, update the mappings the same day, and run a small test import before the first real batch.
One-time setup, then map once
Because Tally will not auto-create masters during voucher import, the workflow every importer should follow is: create the ledgers above once, then map your marketplace report columns to those exact names. TallySutra does the mapping step interactively — when it converts an Amazon, Flipkart or Meesho report and meets a fee type or party it has not seen, it asks you to map it to an existing Tally ledger rather than guessing, and remembers the answer for every future import. Batches only export as TallyPrime XML after your CA approves them, so an unmapped ledger never turns into a bad posting. The same discipline applies to inventory: stock items must exist before sales vouchers reference them, which is covered in our SKU mapping guide. For the bigger picture of what gets automated after setup, see the solutions overview.
A 30-minute setup checklist
- Create one party ledger per marketplace under Sundry Debtors.
- Create sales ledgers (decide: single, or per marketplace / GST rate).
- Create commission, shipping, advertising and rounding expense ledgers.
- Create output and input GST ledgers with correct tax types.
- Create the TCS Receivable ledger under Current Assets.
- Run one small test import and confirm zero rejections.
Frequently asked questions
Should each marketplace get its own party ledger in Tally?
Yes. Amazon, Flipkart and Meesho settle separately, on different cycles, with different fee structures. One party ledger per marketplace under Sundry Debtors keeps each settlement traceable and makes payout reconciliation straightforward.
Do I need separate sales ledgers for each GST rate?
It is optional but useful. Separate ledgers per rate (and optionally per marketplace) make GSTR-1 verification much faster. Confirm the structure with your CA, since it should mirror how your returns are prepared.
What is the TCS Receivable ledger for?
Marketplace operators collect tax at source under GST Section 52 and deposit it against your GSTIN. Booking it to a Current Assets ledger tracks the credit you claim after accepting it on the GST portal. Your CA should confirm the treatment.
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