The import finished. Tally reported no errors. Then you opened a ledger and found four hundred entries sitting under the wrong party, or dated in a year that closed eighteen months ago, or every one of them duplicated because the run was attempted twice.
This is a different problem from an import that fails. A failure stops and tells you something. A success that is wrong is silent, and it is silent inside a client's books. The question is no longer what went wrong, it is how to get back out - and Tally does not offer a way.
There is no undo, because there was never a batch
The instinct is to look for an import history and roll one back. There is not one, and the reason is structural rather than an oversight: Tally imports vouchers, not batches. Whatever sent them, an XML file or an ODBC bridge or a converter, handed Tally a set of individual vouchers and Tally recorded them as individual vouchers. From its side nothing distinguishes the four hundred that arrived at 4pm from the ones somebody typed last March.
So undoing an import is four separate jobs, and only one of them is deleting:
- Find out what actually landed, which is not the same as what the tool says it sent.
- Work out which of those vouchers came from this import and not from somewhere else.
- Delete them.
- Fix the cause, then import again without creating a second copy of everything.
Pro tip
Step two is the one that costs the afternoon. If you know before importing how you will identify these vouchers afterwards, the whole exercise takes minutes instead.
Do not trust the import result. Read it back.
Before deleting anything, establish what is genuinely in the company. The counters an import returns are not evidence.
This is not a complaint about any one tool. Tally's own import response is unreliable in both directions: it will report zero created for vouchers that landed perfectly well, and it will report a successful deletion for a voucher that is still sitting there. We have watched both happen on a live company, on more than one Tally version.
The only honest signal is the company itself. Open the Day Book, set the period to cover the statement's date range, and count. Sent 287 and the Day Book shows 287 new ones, the import landed. Shows 574, the run happened twice. Shows none, nothing landed, whatever the summary said.
Important
A tool that reports success by echoing Tally’s counters is quoting a number Tally does not stand behind. Judge every import by what you can read back.
The three imports actually worth undoing
Almost every wrong-but-successful import is one of three, and the right response differs for each.
Everything landed under the wrong ledger
Usually one ledger, and usually Suspense. The vouchers are right in date and amount and useless for reporting, because no party is attached to any of them. At four hundred rows, deleting and re-importing cleanly beats altering them one by one. The cause is worth reading separately: why imported entries land in Suspense.
The dates fall outside the open year
Here the vouchers are usually not in the company at all, which makes this the cheapest case: there is nothing to delete. Tally rejects a voucher dated outside the period the books are open for, and a partial run can leave a handful in and the rest out. Confirm in the Day Book before assuming either way. The error itself is covered in what each Tally import error actually means.
The same statement went in twice
The worst of the three, because both sets are individually correct. Nothing looks wrong on any single voucher. It surfaces as a bank balance showing exactly double the movement it should, or a party ledger where every entry appears in pairs a few seconds apart.
Deleting them, and the backup that comes first
Deletion is done from the Day Book: set the period, open the voucher, delete it. There is no recycle bin and nothing to walk back, so the backup is not ceremony.
Take a full company backup before the first deletion, not after the tenth. If your identification turns out to have been wrong, that backup is the difference between restoring in two minutes and rebuilding a month of entries by hand.
- Back up the company, and check the file was actually written before continuing.
- Open the Day Book and set the period to exactly the statement range, so nothing outside it can be caught by mistake.
- Filter to the voucher type you imported, so manually entered vouchers of other types stay out of view.
- Delete, reading the narration on each one rather than working down the list on autopilot.
- Re-count in the Day Book afterwards. What remains is what was genuinely there before the import.
Important
Never delete on a filtered view you have not checked. A period set one day too wide is how a client’s legitimate March entries leave along with the import you were trying to remove.
The trap on the second attempt
Most people fix the mapping, import again, and end up with two of everything, which is worse than where they started because now the wrong entries are mixed in with the right ones.
Whether that happens comes down to one thing: does the tool send a stable identifier with every voucher?
Tally supports a remote id on each voucher. When one is present and a voucher carrying that id already exists, Tally updates it in place instead of adding another. When it is absent, every run is a fresh set, and Tally has no way of knowing it has seen them before.
Pro tip
This is the question worth asking any converter before you let it near a client company: if I run the same statement twice, do I get one set of vouchers or two? A tool that cannot answer it clearly will answer it expensively.
What a re-import should look like
With stable identifiers the second run is uneventful. The tool sends the same 287 vouchers, Tally recognises every one and updates rather than duplicates, the Day Book count stays at 287, and the corrected ledgers are simply there. For the wrong-ledger case no deletion is needed at all, because the correction is an update to vouchers that already exist.
That is the difference worth designing for, and it is why Greenote sends an identifier with every voucher it pushes, and can remove what it sent from inside the app rather than leaving you in the Day Book. The undo lives where the import lives.
Three checks that make all of this unnecessary
None of these are clever. They are the checks that get skipped when a statement is due back to a client the same evening.
- Import one month first, never the full year. A wrong mapping then costs thirty vouchers to undo instead of four hundred, and you find out in ninety seconds.
- Open the period before you start. Confirm the company’s financial year covers the statement dates rather than discovering it partway through a run.
- Confirm the ledgers exist. Every party the statement names should already be a ledger, or the import will decide for you, and it will decide Suspense.
Pro tip
The one-month test is the highest-value habit in this article. Almost every import disaster is a full-year run of a mapping nobody checked.
Conclusion
An import that fails is an inconvenience. An import that succeeds and is wrong is a client's books quietly carrying entries nobody reviewed, and Tally will not help you find them again later. Read back what landed, back up before you delete, and never re-run a statement with a tool that cannot tell you whether you get one set of vouchers or two.
Greenote sends a stable identifier with every voucher, so a re-import updates instead of duplicating, and anything it put into Tally can be removed from inside the app. Try it free on one of your own statements.
Turn bank statements into Tally vouchers offline
Greenote reads 100+ Indian banks and posts clean vouchers straight into Tally, fully on your PC. No uploads, no cloud, no manual entry.
7-day free trial, no card required. Works with Tally Prime & ERP 9.
