Import the XML into Tally Prime
Tally imports XML, not PDF — so the statement is converted first, then imported from Gateway of Tally → Import → Vouchers:
- Convert the statement to Tally XML. Drop the statement PDF into the converter above, set the bank ledger name, and export as Tally XML. Nothing is uploaded — the file is parsed in your browser.
- Create the bank ledger in Tally. Tally matches on ledger name, so the bank ledger must already exist with exactly the name you used during export. This is the single most common cause of a failed import.
- Import the vouchers. In Tally Prime go to Gateway of Tally → Import → Vouchers and select the XML file. In Tally.ERP 9 the path is Gateway of Tally → Import Data → Vouchers.
- Check and allocate. Vouchers land as Receipts and Payments against your chosen contra ledger, Suspense by default. Reallocate inside Tally. Voucher IDs are stable, so re-importing the same statement will not duplicate entries.
If an import fails or comes in short — a closed period, a ledger Tally cannot find, a voucher count that does not match the statement — the full walkthrough is in how to import a bank statement into Tally Prime.
Why XML and not Excel plus a TDL
XML is Tally's own import format: it carries voucher type, date, ledger, amount and narration in the structure Tally already understands, and it needs nothing installed. The Excel route needs a TDL — a small Tally extension that maps your spreadsheet's columns onto voucher fields — which you either buy, commission or write, and then maintain whenever a bank changes its statement layout. A TDL earns its place for allocation logic Tally cannot express natively, not for plain statement import: when a TDL is worth it.
Before you import: check the extraction
A statement that imports cleanly can still be missing a transaction. Every row TieOut extracts is checked against the statement's running balance first, so you know the data is complete before it reaches your books rather than during an audit — see how the balance check works and what it does not cover.
Guides in this series
- Do you need a TDL to import bank statements into Tally? — TDL is how you get an Excel bank statement into Tally, and it is a real cost you keep paying. Where the add-on earns its place, where XML makes it unnecessary, and how to decide.
- What Tally XML actually contains, and why it imports cleanly — An annotated look at the voucher XML Tally imports — the envelope, the ALLLEDGERENTRIES sign convention, the date format, and the one attribute that stops a re-import creating duplicates.
- How to import a bank statement into Tally Prime — The XML voucher import path in Tally Prime, the two things that make it fail (ledger names and duplicates), and why importing via Excel is the longer road.
Per-bank notes
The Tally side is the same whichever bank you use, but the extraction is not — each bank's statement hides a different trap. See the per-bank pages for what TieOut handles in each layout, or go straight to SBI, HDFC, ICICI, Kotak, Axis, Federal or PNB.
FAQ
How do I convert a bank statement PDF to Tally XML?
Drop the PDF into a converter that writes Tally’s voucher format, enter the bank ledger name exactly as it appears in your Tally company, and export as Tally XML. TieOut does this in your browser — the statement is never uploaded — and the file it writes contains finished Receipt and Payment vouchers, ready for Gateway of Tally → Import → Vouchers.
Can I import a PDF bank statement into Tally directly?
No — Tally imports XML, not PDF. The PDF has to be converted first. TieOut does that conversion in your browser and writes the XML in the voucher format Tally expects, so there is no intermediate Excel file and no retyping.
Should I import via XML or via Excel and TDL?
XML, in almost every case. It is Tally’s native import format and needs no add-on. The Excel route requires a TDL to map your spreadsheet columns onto voucher fields, which means either buying a TDL or writing one, and then maintaining it as your statement layouts change. TDL earns its place when you need custom allocation logic, not for plain statement import.
Will re-importing the same statement create duplicate vouchers?
Not from TieOut. Each voucher is written with a stable REMOTEID derived from the transaction, so importing the same statement again updates the existing vouchers rather than adding a second copy. This matters because overlapping date ranges are normal when you catch up on a few months at once.
Which ledger do the vouchers post to?
You name the bank ledger at export time, and the contra side goes to a ledger of your choice — Suspense by default — so you can allocate inside Tally afterwards. Automatic ledger mapping learned from your past allocations is on the roadmap.
Does this work with Tally.ERP 9 as well as Tally Prime?
Yes. The XML voucher format is the same; only the menu path differs. Tally Prime uses Gateway of Tally → Import → Vouchers, and Tally.ERP 9 uses Gateway of Tally → Import Data → Vouchers.
Tally, Tally Prime and Tally.ERP 9 are products of Tally Solutions. TieOut is not affiliated with or endorsed by Tally Solutions; the XML it writes simply follows Tally's documented voucher import format.