Why Tally XML Imports Fail: Every Common Error and Its Actual Cause

Tally rejects an import with almost no context about which row broke it. This is a field guide to the failures that account for nearly every rejected file, and how to prevent each one.

The Diagnostic Problem

Tally imports XML, and when the import fails it tells you remarkably little about where. You get a count of what was accepted, sometimes a terse message, and a file of several thousand rows to search by hand. The practical consequence is that people stop trusting bulk import and go back to keying entries manually, which is exactly the work the import was supposed to remove. Nearly every failure traces to one of a small number of causes, and all of them are detectable before you ever open Tally.

Ledger Names That Do Not Exist

This is the single most common cause. Tally matches ledgers by name, exactly — including spacing, punctuation and case in the way the master was created. "ABC Traders Pvt Ltd" and "ABC Traders Pvt. Ltd." are two different ledgers as far as the import is concerned, and if the second does not exist the voucher has nothing to post against. The fix is to reconcile your source sheet against the actual ledger master before converting, not to guess at the format. Export the ledger list from Tally and validate every name in the sheet against it.

Dates That Are Really Text

Excel is happy to hold a date as a text string that looks identical to a real date on screen. Once it reaches the converter, "01-04-2026" as text may be read as a different day, a different month, or rejected outright depending on the locale assumed. It also silently breaks sorting, so the problem is often first noticed as vouchers appearing in the wrong period rather than as an import failure. Format the column as a date in the source, confirm the cells right-align, and be explicit about day-month order rather than relying on the default.

Vouchers That Do Not Balance

Every voucher must have debits equal to credits across all its lines. A multi-line entry that is out by even a rounding paisa will be rejected, and in a file of hundreds of compound entries the offending one is not obvious. This usually comes from a formula that rounded one side differently from the other, or a line that was deleted from the sheet without adjusting the counterpart. Validate the balance per voucher before conversion — it is a trivial check to run and it catches the error while you still know which entry you were editing.

Voucher Types That Are Not Configured

The voucher type named in your data must already exist in the company you are importing into. Custom types — a specific class of journal, a named sales voucher — live in the company master, and a file built for one client will fail against another that never had that type created. This is a frequent cause of an import working perfectly in testing and failing in production, because the test company and the live company were configured differently.

Encoding and Special Characters

Ampersands, angle brackets and quotes are structural characters in XML. A ledger named "Smith & Co" will break the file unless the character is escaped, and a stray non-printing character pasted in from a PDF or an email can invalidate the document without being visible in the sheet. A converter should handle escaping for you; the failure mode to watch for is a file that was hand-edited after conversion, which is where unescaped characters usually get reintroduced.

The Pre-Import Checklist

Before running any bulk import: take a backup of the company, because a partial import is far harder to unwind than to prevent. Import into a copy of the company first and check a sample of entries against the source. Confirm the period is open and not locked by a closing entry. Verify the ledger names against the live master, not against last month's. Check that every voucher balances. Confirm dates are real dates. Five minutes of this saves an afternoon of reversal.

When the Import Half Works

The worst outcome is not a rejected file, it is a partially accepted one — some vouchers posted, some not, and no clear record of which. If this happens, do not re-run the same file hoping it completes; you will duplicate everything that succeeded the first time. Reconcile what actually landed against the source, build a corrected file containing only the missing entries, and import that. This is precisely why importing into a test company first is worth the extra step: a partial import there costs nothing.