Tally XML import errors: voucher rejected

Reading the import log

After an import, Tally reports how many vouchers were created, altered and rejected. The rejected count is the one that matters, and the log names them by number rather than by cause — so the diagnosis is done by looking at the file.

A count of zero created and everything rejected usually means the envelope itself is wrong, not the vouchers. A handful rejected out of many means specific rows.

Cause 1: the voucher does not balance

Every voucher carries two or more ledger entries, and they must sum to zero. Tally will not post a voucher that does not — which is the correct behaviour, and better than QuickBooks, which accepts an unbalanced IIF and leaves the books unbalanced instead.

The sign convention is where this goes wrong. Tally writes a debit as a negative amount and a credit as a positive one, which is the opposite of how most systems represent a bank transaction. A converter that passes its own signs straight through produces vouchers whose two entries have the same sign, and every one of them is rejected.

The ISDEEMEDPOSITIVE flag on each entry has to agree with the sign of its amount. Disagreement is rejected as readily as an imbalance.

Cause 2: the ledger cannot be resolved

Tally matches ledgers by name. Depending on the import settings, an unknown name is either rejected or — worse — created.

Cause 3: the envelope is malformed

If nothing imports at all, the XML is likely unparseable. The usual culprit is an unescaped character from a transaction description — an ampersand in "AT&T", or angle brackets around a reversal note.

Those must be written as &, < and >. One unescaped ampersand anywhere in the file makes the whole document invalid, and Tally reports it as a generic import failure rather than pointing at the character.

Checking a file before importing it

1. 1Open it in a browser. A browser will render valid XML as a tree and show a parse error with a line number if it is not — the fastest structural check available.
2. 2Search for a bare & that is not part of &, <, >, " or '.
3. 3Pick any voucher and add up its AMOUNT values. They must come to zero.
4. 4Check every LEDGERNAME against your chart of accounts, character for character.

Create, alter, and accidental duplicates

Each voucher carries an ACTION attribute. Create makes a new voucher; Alter modifies an existing one matched by its master ID.

Tally does not deduplicate Create vouchers. Importing the same file twice produces two complete sets, with no warning — the format has no equivalent of a FITID, so there is nothing for Tally to match on. Check the voucher register for the period before re-importing anything.

Dates, and the company they land in

Tally dates are eight digits, YYYYMMDD, with no separators. Anything else is rejected. This is one of the few places where a rigid format is a mercy: there is no ambiguity to misread, and a malformed date fails loudly rather than landing in the wrong month.

A voucher dated outside the open financial year is also rejected. If a whole statement was refused and the file looks well-formed, check the period against the company’s year before looking further.

The import goes into whichever company is currently open in Tally, regardless of what the envelope names. Confirm the right company is loaded before importing, because there is no undo.