How to import a bank statement into Tally Prime

4 August 2026

Short answer: convert the statement to Tally XML, then use Gateway of Tally → Import → Vouchers. Tally cannot read a bank statement PDF, and the Excel route needs a template and a column mapping. XML skips both, because the file already contains finished vouchers.

The path, start to finish

1. Convert the statement to Tally XML. Drop the PDF into TieOut and export as Tally XML. The statement is parsed in your browser and never uploaded. Set the bank ledger name during export — write it exactly as it appears in the Tally company.
2. Create the ledgers in Tally first. The bank ledger must exist before you import, and so must the contra ledger (TieOut defaults to Suspense). Tally matches on ledger name, exactly, so “HDFC Bank 4521” and “HDFC bank 4521” are two different ledgers.
3. Import the vouchers. In Tally Prime: Gateway of Tally → Import → Vouchers, then give the path to the XML file. In Tally.ERP 9: Gateway of Tally → Import Data → Vouchers. Tally reads the file and reports what it imported.
4. Check the import. Open the bank ledger and compare the closing balance with the statement. Then check that the voucher count matches the transaction count in the statement.
5. Allocate. Everything lands against your contra ledger. Reallocate from there — that is ordinary Tally work, and it is the part that genuinely needs your judgement.

Where imports actually go wrong

Ledger names. This is the cause of most failed imports. A voucher naming a ledger that Tally cannot find is rejected, and if that is every voucher, the import appears to do nothing at all. The fix is boring: copy the ledger name out of Tally and paste it into the exporter, rather than typing it from memory.

Duplicates on re-import. If you convert January–March, then later convert February–April, the February and March transactions exist in both files. Whether that duplicates depends on whether the vouchers carry stable identifiers. TieOut derives a deterministic ID from the transaction itself, so the second import updates the same vouchers rather than adding second copies. Not every converter does this — with an unfamiliar tool, test on a scratch company before running it on live books.

The period is already closed. Tally will not accept vouchers into a period you have closed or one outside the company’s books-beginning date. Check the date range before importing.

Silent partial imports. Tally reports how many vouchers it created. Read that number. If it is lower than the transaction count in the statement, some vouchers were rejected — do not discover that at year end.

Why not import via Excel?

You can, and plenty of firms do, but the work is front-loaded. Excel import into Tally needs either a TDL add-on or an import template whose columns map exactly onto voucher fields, and you maintain that mapping per bank format, forever. There is also a translation step you own: deciding which column is a debit, which is a credit, and what happens on rows where the narration wrapped.

XML moves that translation into the converter. The file that reaches Tally is already a set of Receipt and Payment vouchers with ledger names, dates, amounts and narrations attached, so there is nothing to map. If you are importing one statement a quarter, either route is fine. If you are doing this for thirty clients every month, the mapping maintenance is the whole cost.

Before you import: make sure the data is right

An import is only as good as the extraction behind it, and Tally will happily accept a clean-looking file with a missing page of transactions. The check that catches this is arithmetic: every row of a bank statement must satisfy previous balance + credit − debit = current balance, and the last balance must equal the printed closing balance.

TieOut validates that chain on every conversion and flags the rows that break it, so you find the bad row before it becomes a voucher. Converting from a native PDF rather than a scan helps here too — the text is already in the file, so nothing is inferred from pixels.