Verifying Tally Data After a Bulk Import
The import finished. The progress bar is gone. This is the most dangerous moment in bulk data work — the temptation to move on. An import can complete and still be wrong: partially accepted, doubled up, mapped to the wrong ledgers, or dated into the wrong period. Fifteen minutes of structured verification catches essentially all of it while the context is fresh and the fix is cheap. Here is the routine.
Minute one: counts
Before anything else, compare three numbers: rows in the source report, vouchers your tool generated, and vouchers TallyPrime accepted (shown in the import statistics). Any gap between generated and accepted means rejections — usually missing masters, surfacing as LINEERROR entries in the import log. Track down every rejected voucher now; a partially imported batch silently understates sales and GST, and our LINEERROR guide shows how to fix and re-import only the failures without duplicating the successes.
Write the three numbers down every time — source rows, generated, accepted — in the batch log or even a running sheet. The habit takes ten seconds and builds the dataset that answers awkward future questions: when a total is challenged in month six, the log shows exactly which batches were verified and what their counts were on the day.
Minutes two to five: totals that must tie
| Tally figure | Must equal | Where to look |
|---|---|---|
| Period sales total | Gross sales in the marketplace report | Sales register / Day Book filtered by type |
| Credit note total | Returns and refunds in the report | Credit note register |
| Fee journals total | Deductions in the settlement summary | Journal register or party ledger |
| Receipts total | Actual payouts credited to bank | Bank ledger for the period |
| Party ledger closing balance | Marketplace's own unsettled balance | Marketplace party ledger |
The last row is the strongest single test: if the party ledger's residual matches what the platform says it still owes you, the whole batch is almost certainly coherent.
Minutes six to ten: spot checks
Totals can tie while details are wrong, so open five vouchers across the batch — first, last, and three from the middle — and check each against its source row: date, party ledger, GST rate split, stock item and quantity, narration references. Then run the trial balance and confirm it still balances and nothing landed in unexpected ledgers (a sudden Suspense balance is a mapping error announcing itself).
Vary which five vouchers you open from batch to batch, and bias toward the unusual: the largest voucher, a return, a voucher with many line items. Uniform sampling of the easiest rows verifies the part of the pipeline least likely to break. If any spot check fails, stop treating it as one bad voucher — assume the whole class of similar rows is wrong until proven otherwise, because mapping errors never come in ones.
Minutes eleven to fifteen: duplicate detection
Duplicates come from re-imported files, overlapping report downloads, and retry-after-error habits. Three quick probes:
- Day Book voucher count for the period vs the expected count — double entries roughly double it.
- Party ledger scanned for identical amount pairs on the same dates.
- Any order ID from the narration searched across the period — it should appear exactly once per event type.
Prevention beats detection: TallySutra's re-imports are duplicate-safe — the Gateway tracks what each company has already received and skips it — so a re-processed report or a second click cannot double your sales. The Gateway also validates the open company before posting, eliminating the wrong-company variant of this problem, and only ever posts CA-approved batches. See the import safeguards.
When verification fails: restore, do not patch
If counts are badly off or mappings were wrong across the batch, resist the urge to fix in place — hand-editing hundreds of vouchers introduces its own errors. Restore the pre-import backup you took (you took one — if not, read the backup guide before your next run), correct the root cause, and import again cleanly. Books rebuilt from a clean run are trustworthy; books patched by hand are a permanent asterisk. Finish by running the GST-side checks in our GST verification guide, and file the batch as verified with the counts you recorded — your CA will thank you at year end. A verified-batch discipline also changes conversations with clients: instead of assurances, you have counts, and counts end arguments.
Frequently asked questions
What is the single fastest check that a marketplace import is correct?
The marketplace party ledger's closing balance. If it equals the platform's own unsettled balance for the same date, sales, returns, fees, TCS and receipts are almost certainly all present and un-duplicated.
The import statistics show fewer vouchers accepted than sent. What now?
Some vouchers were rejected — check the import log for LINEERROR entries, fix the missing masters or bad data, and re-import only the failed vouchers. Never re-run the whole file, which duplicates the accepted ones.
I found duplicates from a double import. Delete or restore?
If the duplicates are few and clearly identifiable, deleting them works. If a whole batch went in twice or entries have mixed with manual work, restoring the pre-import backup and re-running once is safer than surgery.
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