Common Errors Importing Amazon Data into Tally (Fixed)
Most Amazon-to-Tally imports fail in one of about eight predictable ways. Knowing the failure catalogue in advance turns a frustrating afternoon into a five-minute fix, so here are the errors we see most often, what causes each, and the durable fix — not just the workaround.
The error catalogue
| Symptom | Usual cause | Durable fix |
|---|---|---|
| Vouchers rejected on XML import | Ledger or voucher-type name in the XML doesn't exist in the company | Create masters first, or use a tool that validates masters before export |
| Wrong tax type (IGST where CGST/SGST expected) | Ship To State compared against wrong seller state | Drive the split from the Seller GSTIN state code in the MTR itself |
| Totals off by a few rupees | Row-level rounding re-aggregated differently | Preserve the MTR's own tax amounts; round at invoice level once |
| Turnover suddenly doubled | Overlapping files imported twice | Duplicate-safe import keyed on invoice identifiers |
| Vouchers on wrong dates | Date format misread (DD-MM vs MM-DD) | Explicit date parsing; verify a known invoice after first import |
| Refunds booked as sales | Transaction Type column ignored | Branch on Shipment/Refund/Cancel before voucher creation |
| One voucher per row instead of per invoice | No grouping by invoice number | Group multi-SKU rows before generating vouchers |
| Import silently partial | Tally rejected some vouchers, nobody read the response | Count vouchers after import and compare with expected |
Master-data errors: the biggest family
TallyPrime imports XML through its local HTTP interface or the Import Data menu, and in both routes a voucher referencing a nonexistent ledger, stock item, or voucher type fails. Manual fixes devolve into whack-a-mole: import, read errors, create a ledger, repeat. The systematic fix is a pre-flight check — before generating XML, verify every ledger the batch will touch exists (sales, duties, party, fees, TCS/TDS receivables), and create what is missing deliberately with correct GST configuration. TallySutra performs this validation at upload time and lists missing masters as exceptions with suggested configurations, rather than letting Tally bounce the batch — see the features page for how the exception queue works.
Tax-split and rounding errors: silent but dangerous
Rejected vouchers announce themselves; wrong-but-accepted vouchers do not. The two silent killers are recomputed tax splits and re-rounding. The MTR already tells you, per row, the IGST or CGST/SGST amounts Amazon computed on the actual invoice — an importer should preserve those figures, not recompute from rates, or paise-level differences accumulate across thousands of rows into visible GSTR-1 mismatches. The verification habit that catches both: after every import, compare Tally's taxable value and tax-ledger totals with the MTR column sums, rate-wise. Two minutes, every time.
Process errors: duplicates and partial imports
The remaining family is procedural. Amazon revises reports, people re-download overlapping ranges, and an import that half-succeeded gets re-run — all of which mint duplicate vouchers unless your pipeline is idempotent, a topic deep enough that we gave it its own article. Partial imports are the mirror image: Tally accepted 900 of 1,000 vouchers, the response scrolled past, and the books are quietly short. The rule for both: every import run ends with a count comparison — expected vouchers versus created vouchers — and any difference gets named before the session ends.
A checklist that prevents the whole catalogue
- Validate masters exist before generating XML.
- Derive tax type from Seller GSTIN state vs Ship To State; never assume.
- Preserve the MTR's tax amounts; round once per invoice.
- Group rows by invoice number; branch on Transaction Type.
- Import through a duplicate-safe pipeline keyed on invoice identity.
- Reconcile counts and totals after every run.
Every item on that list is mechanical, which is why we built them into the TallySutra Amazon to Tally pipeline as non-optional behaviour: files are validated at upload, exceptions surface before export, and re-imports never double-post. The desktop Gateway then pushes the verified batch to TallyPrime and reports exactly what was created.
Turn the fixes into a runbook
The catalogue above is worth converting into a one-page runbook that lives next to your import process: the pre-flight master check, the state-code rule, the rounding policy, the grouping and Transaction Type logic, and the post-import count reconciliation, each as a line item someone ticks. The runbook matters most at handover moments — a new accountant, a CA's junior taking over a client, the founder finally delegating the books — because import errors cluster precisely when an experienced pair of hands is replaced by an unwritten process. If a step cannot be written down simply, that step is a candidate for automation rather than documentation; the mechanical majority of this list is exactly what conversion tools encode so the runbook shrinks to review the exceptions and verify the counts.
Frequently asked questions
Tally accepted my XML but the GSTR-1 view shows transactions as incomplete — why?
Accepted vouchers can still lack GST-relevant details: a party without a state, a duty ledger not configured as IGST/CGST/SGST, or a missing place of supply push transactions into Tally's incomplete or mismatch buckets. Fix the master configuration rather than the vouchers, then the report reclassifies. A pre-import master check with correct GST configuration prevents this class entirely.
How do I recover from a double import that has already happened?
First quantify it: compare voucher counts and sales totals against the MTR to find the affected range. Then remove the duplicate set — Tally allows deletion of vouchers, and the duplicates are identifiable by repeated invoice references on the same dates. After cleanup, verify totals against source files again, and switch to a duplicate-safe import process so the incident cannot recur.
Is it safer to import a large month in small batches?
Batching helps diagnosis, not correctness — a correct pipeline imports ten thousand rows as reliably as a hundred. If you are importing manually, smaller batches make it easier to localise a failure and to verify counts. With a validated, duplicate-safe pipeline, batch size stops mattering, and one upload per report per month is the simplest routine.
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