Tally's import diagnostics are terse by design. You get a line or two, often without saying which voucher caused it, and sometimes you get a summary that looks like nothing happened at all.
Almost every failure falls into one of three layers, and knowing which layer you are in cuts the search enormously. Either the connection never reached Tally, or it reached Tally but the request was not understood, or the request was understood and the data inside it was rejected. Work outward in that order and most problems resolve in minutes.
Then there is a fourth case, which is not an error and is the one that costs people real time. It is covered at the end, and it is the reason you should never trust the counter Tally hands back.
Layer 1: the request never reached Tally
If nothing at all appears to happen, or you get a connection refused or timeout, the problem is almost never your XML.
Tally listens over HTTP on a local port, and it only listens when you have explicitly told it to. In TallyPrime this lives under the connectivity settings as the option to act as a server, and the default port is 9000. If that is off, nothing is listening, and every import tool will report some flavour of "cannot connect".
- Confirm Tally is actually running, with a company loaded, on the machine you are importing to.
- Confirm the server option is enabled and note the port. It is 9000 unless someone changed it.
- Open http://localhost:9000 in a browser on the same machine. If Tally is listening you get a response rather than a connection error. This one check separates a Tally problem from a network problem in about five seconds.
- If Tally is on another machine, use its IP rather than localhost, and check the Windows firewall on the Tally machine is allowing that port inbound.
- If more than one Tally is running, be certain which one holds the port. Only one process can.
Pro tip
Test with the browser before you test with the tool. If localhost:9000 answers and your import still fails, you have proved the problem is in layers 2 or 3 and you can stop investigating the connection entirely.
Layer 2: Tally answered, but did not understand the request
The signature here is a response that comes back quickly and says something like unknown request, or complains about the envelope rather than about your data.
This means the connection is fine and the XML structure is wrong. The usual causes are structural rather than accounting: a mismatched request type, a missing or wrong company name, or an encoding problem.
The company name is the most common one. Tally routes an import to a company by name, and the name must match what is open, exactly. Trailing spaces, a changed financial year suffix or a renamed company will all produce a request Tally cannot place. If you have several companies open, being explicit about which one is the target matters.
Encoding is the second. Indian party names carry characters that break if the declared encoding and the actual bytes disagree, and the failure often looks like a malformed XML complaint rather than anything to do with text.
Layer 3: the data itself was rejected
These are the useful errors, because they tell you something true about the books. Four cover most of what you will see.
The ledger does not exist
Tally matches a ledger by name, exactly, and will not guess at a near match. Anything it cannot place gets rejected or parked. This is by far the most common data-level failure on a bank import, and it has its own article: why imported entries land in Suspense.
The voucher does not balance
Debits and credits must agree exactly, to the paisa. Rounding a split three ways and losing a paisa is enough for Tally to refuse the voucher. If a whole batch fails this way, suspect the rounding logic rather than the data.
The date falls outside the period
A voucher dated outside the company's current financial year will not post. This bites hardest in April and in the weeks after a year end, when a statement legitimately spans two financial years and half the file silently belongs to the other one.
A required master is missing
Inventory vouchers need the stock item to exist. GST vouchers need the tax ledgers configured with the right type of duty. The error usually names the missing thing, which makes these the easiest of the four to fix once you read it carefully.
Important
Do not fix a rejected batch by letting a tool create the missing masters automatically. It clears the error and quietly fills the company file with near-duplicate ledgers that no future import will match either. Creating a master should always be a decision you make.
The case that is not an error: the counters lie
This is the one worth remembering, because it will otherwise cost you an afternoon.
We have measured Tally ERP 9 reporting CREATED = 0 on an import where the vouchers had in fact been written into the company. The response looked like a complete no-op. Re-running the import on that basis is how people end up with duplicates on top of a job that had already succeeded.
So treat the summary counters as a hint and nothing more. The only reliable confirmation that an import worked is reading the data back out of Tally. Query the company for the vouchers you just sent, over the period you sent them for, and see what is actually there.
One related detail that surprises people: when you query Tally, the period you ask for governs what comes back. Ask for the wrong range and you will get an empty result for vouchers that exist perfectly well, which looks identical to an import that failed. If a read-back comes back empty, widen the period before concluding anything.
Pro tip
Build the read-back into your process rather than treating it as debugging. Import, then immediately query the same period and compare the count and the total against what you sent. It takes seconds and it is the only check that actually proves anything.
Re-running an import safely
Sooner or later you will need to send the same batch again, and the question is whether you get duplicates.
Tally deduplicates on a remote identifier carried on the voucher, not on the voucher number. Send a voucher with an identifier Tally has seen before and it updates that voucher in place instead of adding a second one. Send it without a stable identifier and you get a duplicate, no matter what voucher number you put on it.
This has a consequence worth knowing: the voucher numbers you supply are largely ignored. Tally applies its own numbering according to the voucher type configuration. If you have been carefully generating sequential numbers and wondering why they do not appear, that is why.
Deletion works the same way. A voucher can be removed by referring to it by that same identifier, which is what makes a genuine undo possible at all.
The practical upshot: before you re-run anything, find out whether your tool sets a stable identifier per voucher. If it does, re-running is safe and idempotent. If it does not, re-running will double your data, and the counters will not warn you.
A short diagnostic order
When an import fails and you do not yet know why, this order finds it fastest.
- Open localhost:9000 in a browser. No answer means it is the connection, and nothing else matters yet.
- Check the company name in the request matches the open company exactly, including spacing.
- Read the first data error carefully and fix that one voucher by hand in Tally. If it posts manually, the problem is in the file. If it does not, the problem is in the company setup.
- Check the voucher dates against the company period, especially near a year end.
- Read the data back for the period you imported, and compare the count and total against what you sent. Do this even when the import reported success, and especially when it reported nothing.
Conclusion
Work outward: connection, then envelope, then data. Most Tally import failures are in the first two layers and are not accounting problems at all.
And whatever the summary says, read the data back. A reported zero does not mean nothing was written, and an empty query result does not mean the import failed. The books are the only thing telling the truth.
Greenote builds the voucher XML for your Tally version, sets a stable identifier per voucher so a re-run updates rather than duplicates, and shows you every line before anything is written. See how the statement to Tally flow works, or the 7 voucher types it builds.
Start a free trial and test it against a real company.
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.
