Meesho to Tally Import Errors and How to Fix Them
Every Meesho supplier who moves from manual entry to imported vouchers meets the same handful of errors, and the difference between a smooth month-end and a lost weekend is knowing which failure you are looking at. This is a field guide to the errors that actually occur when Meesho report data goes into TallyPrime, whether via hand-built spreadsheets, generic converters, or a dedicated importer, and the fix for each.
Import-stage failures
Error 1: Duplicate vouchers after a re-import
Symptom: sales doubled for a period; party ledger balance inflated. Cause: the same GST sales report, or an overlapping date range, was imported twice, and nothing checked Sub Order No against already-posted vouchers. Fix: identify duplicates by Sub Order No (each should map to exactly one sales voucher), delete the extras, and switch to a duplicate-safe process. Prevention is structural: TallySutra keys every import on Sub Order No and silently skips rows already converted, which makes re-downloading a corrected report a non-event rather than a hazard.
Error 2: Tax split does not sum to invoice value
Symptom: import rejects rows, or Tally shows vouchers where Taxable Value plus IGST/CGST/SGST misses Total Invoice Value by paise or by a lot. Cause: paise-level rounding when a spreadsheet reprocessed the export, or the file was edited, or a column was mapped to the wrong ledger. Fix: always work from the unedited panel export; if you must transform data, keep amounts as exact values, not formulas that re-round. Rows that genuinely fail arithmetic in the source belong in an exception list and, if material, a Meesho support ticket, not in your books. This validation is exactly what an exception queue exists for.
Error 3: "Ledger does not exist" on Tally XML import
Symptom: TallyPrime rejects the XML naming a missing ledger. Cause: the voucher references a ledger, a new GST rate's sales account, RTO Expenses, TCS Receivable, that was never created in the company, or is spelled differently. Fix: create the ledger with the exact name (or align the mapping to the existing name) and re-import; Tally matches ledgers by name, and "Sales @ 5%" versus "Sales @5%" are different ledgers to it. Fix the master data once and freeze the naming convention; the chart of accounts in our bookkeeping guide is a sane baseline.
Reconciliation-stage failures
Error 4: RTO and Return rows with no original sale
Symptom: credit notes fail because there is no matching sales voucher to reverse. Cause: the sale happened in a period you never imported, or the sale row was skipped by an earlier error and the reversal now arrives orphaned. Fix: import the missing earlier period first (duplicate-safety makes this safe), then re-process the reversals. Orphans that persist after that are genuine data questions for Meesho support. Never book a reversal without its sale; it corrupts both turnover and the party ledger.
Error 5: Bank reconciliation will not tie
| Observation | Root cause | Fix |
|---|---|---|
| UTR total exceeds bank credit | Negative recovery rows excluded | Include recoveries in the UTR group |
| Receipt exists, no bank credit | Statement window included a future cycle | Match receipts to actual Payment Dates |
| Small persistent differences | Commission GST split posted inconsistently | Re-check net-vs-inclusive commission posting |
The full matching procedure is in the payout reconciliation guide; the summary is that Final Settlement Amount grouped by UTR, recoveries included, must equal the bank line.
Error 6: Books disagree with the GST portal
Symptom: TCS credit on the portal differs from your TCS Receivable; or operator-reported turnover differs from your GSTR-1. Cause: usually timing, returns and RTO reversing TCS in a different month, or missed reversal postings. Fix: reconcile at sub order level against the payment statement's TCS column before accepting credits, and involve your CA on persistent gaps. Portal-facing actions are yours and your CA's; an importer prepares the books that make those actions defensible.
The pattern behind all six
Every error above is either missing validation, missing idempotency, or missing master data, and all three are process properties, not bad luck. A pipeline that validates arithmetic before posting, quarantines failures in an exception queue with CA approval, and keys imports on Sub Order No simply cannot produce most of this list. That is the case for automating the transcription layer: not speed, though you get that too, but the elimination of whole error classes. Whichever tooling you choose, test it on one real month and try to trigger these six failures deliberately; the ones it prevents by design are the ones you will never debug again.
Frequently asked questions
I imported the same Meesho report twice. How do I clean up?
Identify the duplicates by Sub Order No: each sub order should map to exactly one sales voucher, so list vouchers per sub order and remove the extras, then re-verify the party ledger against unsettled sub orders. Going forward, use a duplicate-safe import keyed on Sub Order No, which skips already-posted rows and makes overlapping date ranges and re-downloads harmless.
Why does TallyPrime reject my imported XML with ledger errors?
Tally matches ledgers by exact name, so a voucher referencing any ledger that does not exist in the company, or is spelled even slightly differently, fails on import. Create the missing ledgers or align the import mapping to your existing names, then re-import. Freezing a naming convention for sales, tax, fee and receivable ledgers eliminates this class of error permanently.
Should I fix bad rows in the Meesho export file before importing?
No. Editing the export breaks its value as an audit-grade source and usually introduces new rounding errors. Rows that fail validation should be excluded from posting, logged as exceptions, and investigated: most are timing artefacts resolved by importing an adjacent period, and genuine data errors belong in a Meesho support ticket. Import unedited files; handle problems in the exception layer.
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