Tally Prime has two entirely separate import routes for bank data, and most of the confusion around this comes from people trying the wrong one. Which you need depends on one thing: where your file came from.
Your file | Route | Menu |
|---|---|---|
Excel/CSV downloaded from your bank's own portal | Bank Statement import | `Alt+O` → Bank Statement |
Anything converted from a PDF | XML voucher import | `Alt+O` → Vouchers |
If you have a PDF statement — which is what most banks email — the first route will not work, no matter how clean your Excel file is. That is a documented limitation and not something you can format your way around. The rest of this guide explains both.
Route 1 — Bank Statement import (files from your bank's portal)
This is Tally's purpose-built reconciliation import. It reads the statement, creates vouchers automatically, and matches them against entries you already have.
Before you start, the bank ledger has to be configured properly or the import screen won't accept it. Open the ledger and make sure Bank Name, Bank Account No. and IFSC are all filled in.
The steps:
- From the Gateway of Tally, press Alt+O (Import) and choose Bank Statement.
- Select your Bank Ledger.
- Specify the File Path to the statement.
- Set File Type to Supported.
- Select the file to import.
- Set Show Preview to Yes — worth doing every time, because it is your last chance to catch a mis-parsed file before it creates vouchers.
- Press Ctrl+A to import.
- On the preview screen, press I to confirm the import.
- Press S to open the Bank Reconciliation Summary and see what matched.
Tally then classifies every row as an Exact, Potential or Partial match against your existing vouchers, and auto-creates vouchers for the rest.
What it accepts: Excel, CSV and MT940, downloaded directly from your bank's portal. Tally supports this for 200+ banks, and the list is specific — Tally recognises each bank's particular column layout.
What it refuses: PDF files, and Excel or CSV files that were converted from a PDF. This catches people out constantly, and it is worth being precise about why.
Why converted files fail the Bank Statement import
Tally's bank statement importer is not a general spreadsheet reader. It matches your file against a stored layout for your specific bank — the column order, the header text, the date format that bank uses in its own downloads. That is how it knows which column is the debit without asking you.
A file converted from a PDF has the right *data* but not that exact layout. The columns may be in a different order, the headers worded differently, the dates formatted differently. Tally checks the shape, doesn't recognise it, and declines.
So if your bank only emails you PDF statements — which is the normal situation in India — the Bank Statement route is closed to you regardless of how good your conversion is. That is not a criticism of any converter, ours included. It is how the feature is designed.
Route 2 — XML voucher import (the one that works for converted PDFs)
Tally's voucher import reads Tally's own XML schema. It doesn't care where the data came from, because the XML already says what every value means — this is a Receipt, this is the bank ledger, this is the amount. There is no layout to guess at.
Before you start, every ledger named in the XML has to already exist in your company, or those vouchers get skipped. Create them under Gateway of Tally → Create → Ledger.
The steps:
- From the Gateway of Tally, press Alt+O (Import) and choose Vouchers.
- Give the path to your XML file.
- Choose the behaviour for existing vouchers. Add is the safe default. Overwrite replaces matching vouchers and is worth avoiding unless you know exactly what it will match.
- Tally reports how many vouchers were imported and how many were skipped.
One practical catch: the file has to be reachable from the machine running Tally. A network path is fine; a download folder on a different PC is not.
Why vouchers get skipped
If the count comes back lower than you expected, it is almost always one of three things:
- A ledger named in the file doesn't exist. Tally will not create ledgers for you during a voucher import.
- The voucher type doesn't exist. Receipt and Payment exist by default; anything custom has to be created first.
- The date falls outside the company's financial year. Statements that straddle a year-end are the usual cause.
Import the file again after fixing the cause — with Add selected, the vouchers that already went in are not duplicated if their voucher numbers match.
Getting a PDF statement into Tally, start to finish
Putting the two halves together:
- Convert the PDF to Tally XML — not to Excel, if Tally is the destination. Our converter produces the voucher XML directly, and checks that opening balance plus credits minus debits equals the closing balance the bank printed before it hands you the file.
- Create any missing ledgers in Tally.
- Gateway of Tally → Alt+O → Vouchers, point it at the XML, choose Add.
- Check the imported/skipped counts.
The reconciliation check in step 1 matters more here than it does elsewhere. Once vouchers are inside Tally, a dropped transaction is no longer a spreadsheet problem — it is a wrong ledger balance you have to hunt down later.
Tally ERP 9
The voucher import route is the same in ERP 9: Gateway of Tally → Import Data → Vouchers. The menu is worded slightly differently and there is no `Alt+O` shortcut, but the XML schema and the reasons vouchers get skipped are identical.
Which route should I use?
- Your bank's portal gives you Excel or CSV downloads — use the Bank Statement import. It is purpose-built, it auto-reconciles, and you should prefer it whenever it is available to you.
- You only have PDFs — use XML vouchers. It is the only route that accepts converted data.
- You have PDFs and you want reconciliation too — import the XML vouchers, then run Bank Reconciliation inside Tally against them.
Try it on your own statement
Clean Excel/CSV, with every transaction checked to balance.
