Duplicate Vouchers in Amazon Tally Imports: How to Avoid
Of all the ways an Amazon import can go wrong, duplicates are the most expensive per incident: turnover doubles for the affected range, GSTR-1 no longer matches reality, and the cleanup means identifying and deleting hundreds of vouchers one by one. The frustrating part is that duplicates are almost never caused by carelessness — they are caused by reasonable actions performed with a pipeline that was never designed for repetition. Here is why they happen and how to make them structurally impossible.
The four ways duplicates get minted
| Scenario | Why it happens | Risk level |
|---|---|---|
| Overlapping date ranges | Re-downloaded reports cover part of an already-imported period | High |
| Re-import after partial failure | First run half-succeeded; second run re-posts the survivors | High |
| Amazon report revisions | Final MTR replaces an early version you already imported | Medium |
| Two people, one month | Seller and accountant both import the same file | Medium |
Notice that three of the four scenarios involve someone doing the right thing — getting final data, retrying a failure, being thorough. A safe pipeline must welcome repetition, not punish it.
Why duplicates hurt more than they look
- GST exposure: doubled sales inflate GSTR-1 turnover and output liability; the correction trail (amended returns, credit-note gymnastics) is far costlier than prevention.
- Broken reconciliation: settlement matching fails everywhere at once, because every order now matches two vouchers.
- Silent margins: doubled revenue against single fees makes the business look healthier than it is — until it suddenly doesn't.
The structural fix: idempotent imports
The engineering term is idempotency: running the same import twice must produce the same books as running it once. For Amazon data the natural identity key exists already — the MTR's Invoice Number (with Transaction Type and your GSTIN), and for settlements the settlement-id plus row identity. A duplicate-safe importer records every voucher it has created against these keys, and on any subsequent upload skips what exists, imports what is new, and reports both counts. This is exactly how TallySutra's re-import behaviour works: upload the revised MTR, the overlap is detected row-by-row, only genuinely new or changed invoices generate vouchers, and the run report tells you what was skipped. Report revisions and overlapping downloads become non-events — the features page covers the mechanism, and the audit trail of what was imported when is part of the security and data-handling design.
Process safeguards worth keeping anyway
- One pipeline per period. All imports for a month flow through one tool and, ideally, one pair of hands — automation does not fix two systems importing the same file.
- Voucher numbering from source. Carrying the Amazon invoice number as the voucher reference makes duplicates visible in Tally reports even if one slips through.
- Count reconciliation after every run. Distinct invoices in file versus vouchers created versus vouchers skipped — the three numbers must explain each other.
- Month locks. Once closed and CA-approved, lock the period in Tally so a stray import cannot rewrite history unnoticed.
Recovering when duplicates already exist
Quantify first: compare Tally sales totals against the MTR's summed values for each month to find the affected range. Identify duplicate pairs by repeated invoice references, delete the later copies, and re-verify totals. Then — the step people skip — change the pipeline, because a cleanup without a process change is a scheduled repeat. The wider catalogue of import failure modes and their fixes is in common errors importing Amazon data into Tally, and safe re-import behaviour is one of the core reasons the TallySutra Amazon to Tally pipeline exists at all.
How to test whether your current pipeline is actually safe
Claims about duplicate safety are cheap; the test is not. Take a Tally company you can experiment in — a copy of your data, never the live books — and import the same MTR file twice through your normal process. A safe pipeline reports the second run as skipped and the voucher count stays flat; an unsafe one doubles the month. Then run the harder variant: import a full month, then import a file covering just the last week of that month, simulating the overlapping-range scenario. Finally, simulate the revision case by importing an early copy of a report and then its final version. If any of the three tests mints duplicates, you now know your exposure precisely, and you know it from a sandbox rather than from a GSTR-1 mismatch. Fifteen minutes of deliberate testing beats months of hoping, and it is the single most useful due-diligence exercise before trusting any import tool — including ours — with your live books.
Frequently asked questions
Amazon revised last month's MTR after I imported it. What is the safe procedure?
With a duplicate-safe pipeline: download the revised file and re-import the whole thing. Unchanged invoices are skipped, new ones are added, and the run report shows the delta — no manual diffing. Without one: diff the two files yourself, import only the new invoice numbers, and verify counts afterwards. The first procedure takes a minute; the second is why idempotent imports matter.
Will Tally itself warn me about duplicate vouchers on XML import?
Not reliably in the way you need. Tally validates XML structure and masters, but two well-formed sales vouchers with similar contents can both import successfully. Duplicate prevention has to live in the layer that generates the XML, keyed on source identifiers like the Amazon invoice number, which is why the importer's design matters more than Tally's import screen.
Are duplicate credit notes as dangerous as duplicate sales?
Differently dangerous: duplicate credit notes understate turnover and over-reverse GST, which can mean short-paid liability — arguably worse in an assessment than over-declared sales. The same idempotency keys prevent both, since Refund rows carry the same invoice-level identity. Treat every voucher type in the import, sales and credit notes alike, as needing duplicate protection.
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