What you are seeing
Voucher totals do not match!
Tally is stricter than most accounting software about what it will accept, and that is a virtue: a rejected voucher is visible, where a silently mis-posted one is not. The difficulty is that Tally names the failed voucher more readily than the reason. Nearly every rejection comes down to one of four things, and each can be checked in the file before you import it.
First: are you using the right import?
TallyPrime has two separate ways to bring bank activity in, and a lot of “import errors” are a file sent down the wrong one. The Bank Statement import (Alt+O → Bank Statement) takes CSV, Excel or MT940 files downloaded from a supported bank’s portal. TallyHelp states that PDFs, and CSV or Excel files converted from PDF or by any third-party software, cannot be imported there, and that an edited statement shows “Not a valid format”.
Vouchers in XML go through Alt+O → Transactions. In Tally ERP 9 the same route is Gateway of Tally → Import of Data → Vouchers. If you see “Not a valid format” on a converted file, nothing is wrong with the file; it is in the wrong door.
| Message or symptom | Likely cause | Fix |
|---|---|---|
| Not a valid format | Converted or edited file sent to the Bank Statement import | Import XML through Alt+O → Transactions |
| Voucher totals do not match! | Debit and credit sides of a voucher differ | Correct the amounts or ISDEEMEDPOSITIVE flags |
| Referenced master is missing | A ledger named in the voucher does not exist | Create the ledger, or point the voucher to an existing one |
| Nothing imported, no specific message | XML cannot be parsed, often a bare & | Escape special characters and re-import |
| Vouchers counted as errors | Any of the above; details in Tally.imp | Read Tally.imp before changing anything |
| Everything imported twice | Same file imported again | Delete the duplicates; import each file once |
Most rejections come down to an unbalanced voucher, so a converter that writes both ledger entries for every voucher removes the larger of the two causes before the file reaches Tally.
Reading the result: Tally.imp and the Exceptions report
After an import, Tally reports how many vouchers were created and how many had errors. The detail goes to Tally.imp, a log file in the folder where TallyPrime is installed. For more detail, turn on Alt+O → Configuration → Enable detailed log (tally.imp) before importing.
Recent TallyPrime releases also record exceptions instead of stopping. By default the import records them and carries on; the Import Configuration offers stopping at the first exception, or ignoring exceptions, instead. Recorded exceptions appear under Alt+O → Exceptions. Vouchers under exception are left out of your books and reports until they are resolved, and a resolved voucher is saved as a new voucher with the next available number.
Read the counts as a diagnosis. Everything failed usually means the envelope or the whole file is wrong. A handful failed out of many means specific rows, and those rows have something in common, often the same ledger name or the same unusual narration.
Cause 1: the voucher does not balance
Voucher totals do not match!
Dr. XXXX Cr XXX Diff: XEvery voucher carries two or more ledger entries, and TallyHelp’s import guidance is that the totals of debit and credit values must be equal. Tally will not post a voucher that does not balance, which is the correct behaviour, and better than software that accepts an unbalanced file and leaves the books out instead.
The sign convention is where this goes wrong. In Tally’s XML a debit is written as a negative amount with ISDEEMEDPOSITIVE set to Yes, and a credit as a positive amount with ISDEEMEDPOSITIVE set to No; Tally’s own sample vouchers show exactly that. Most systems represent a bank transaction the other way round, so a file that passes its own signs straight through produces vouchers whose two entries have the same sign, and every one of them fails.
- Check that the amounts in each voucher sum to zero.
- Check that each ISDEEMEDPOSITIVE agrees with the sign of its amount. Disagreement fails as readily as an imbalance.
- Check rounding: amounts with more decimal places than the currency allows can leave a difference of a paisa or a cent.
Cause 2: the ledger cannot be found
Tally matches ledgers by name, and TallyHelp is clear that the masters a voucher uses must exist before it is imported, under the right kind of group: a bank ledger under Bank Accounts, a sales ledger under Sales Accounts. A name that differs by a single character, a missing “A/c”, a double space, a different capital, is a different ledger.
Referenced master is missing
In TallyPrime’s Exceptions report this is the usual entry for a missing ledger. Drill down to see which name is missing and how many vouchers it affects. You can create the ledger from there, after which Tally re-checks the affected vouchers, or change those vouchers to point at a ledger you already have. Check the exact names in Chart of Accounts and use them verbatim in the next file.
Bank statement vouchers usually name two ledgers: the bank ledger and a contra ledger for the other side. Where the other side is not yet known, posting to Suspense A/c and reassigning later is common practice, but Suspense A/c must then exist in the company too.
Cause 3: the XML 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 “M&M”, or angle brackets around a reversal note.
Those must be written as &, < and >. One unescaped ampersand anywhere makes the whole document invalid, and Tally reports a general failure rather than pointing at the character. A file saved from a text editor with the wrong encoding can fail the same way on rupee signs or accented names.
Cause 4: dates and the company
Tally dates are eight digits, YYYYMMDD, with no separators, and TallyHelp’s guidelines require that format. 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 before the company’s books beginning date cannot be created. If a whole statement was refused and the file looks well formed, compare its period with the company’s financial year first. TallyHelp also notes that features enabled in the company the data came from should be enabled in the company receiving it.
The import goes into whichever company is open in Tally. Confirm the right company is loaded, and take the backup the import screen offers, before pressing Enter.
Checking a file before importing it
- 1Open it in a web browser. A browser renders valid XML as a tree and shows a parse error with a line number if it is not, the fastest structural check there is.
- 2Search for a bare & that is not part of &, <, >, " or '.
- 3Pick any voucher and add up its AMOUNT values. They must come to zero.
- 4Check every LEDGERNAME against Chart of Accounts, character for character.
- 5Check the first and last DATE against the company’s financial year.
- 6To see the exact shape Tally expects, follow TallyHelp’s advice: create one voucher by hand, export it as XML, and compare.
Re-imports and accidental duplicates
Tally decides whether an incoming voucher replaces an existing one by its GUID, under the configuration option “Overwrite voucher when a voucher with same GUID exists”. Vouchers generated from a bank statement are new each time, so there is nothing for that option to match, and importing the same file twice produces two complete sets with no warning.
- Import each file once, and keep a note of the periods imported per bank ledger.
- To redo a period, delete its vouchers first, then import the corrected file.
- Back up the company before any large import. There is no single undo for an import.
- Reconcile the bank ledger against the statement in Bank Reconciliation once the period is in.