How to Import a Bank Statement into Tally
Published April 8, 2025 · Last updated May 23, 2026
To import a bank statement into Tally, you convert the statement PDF into Tally-compatible XML and load it through Gateway of Tally > Import > Vouchers in Tally Prime (or Gateway of Tally > Import of Data > Vouchers in ERP 9). Tally does not read PDFs, Excel, or bank CSV files natively for vouchers, XML is the import format it understands. Each debit on the statement becomes a payment voucher and each credit a receipt voucher, posted against your bank ledger, so a full month of transactions enters in a single pass instead of one manual voucher at a time.
- XML is the import path: Tally Prime and ERP 9 import vouchers from XML, not from PDF or Excel directly.
- Two menus, same idea: Tally Prime uses Gateway of Tally > Import > Vouchers; ERP 9 uses Gateway of Tally > Import of Data > Vouchers.
- Voucher mapping: money out (debits) maps to payment vouchers; money in (credits) maps to receipt vouchers, both against the bank ledger.
- Ledgers must exist: the bank ledger named in the XML has to already exist in Tally, and party ledgers should ideally exist or be created during import.
- Back up first: always back up the company before importing so a mis-mapped batch can be rolled back.
Why Tally needs XML, not your PDF or bank CSV
Tally's import engine is built around its own XML schema, which describes vouchers, ledgers, and masters in a structure Tally can post directly into the books. A bank statement PDF is a printed document with no voucher structure, and a bank's CSV export is just rows of text with no notion of payment versus receipt, no ledger names, and no voucher type. So while you can read a CSV in a spreadsheet, you cannot hand it to Tally and expect vouchers.
That is why the conversion step matters. A converter that targets Tally builds the XML for you: it reads each transaction from the statement, decides whether it is a debit or credit, wraps it in the correct voucher tags, and names the bank ledger so Tally knows where to post. The result is a file Tally accepts in one import rather than thousands of keystrokes.
It helps to picture what that XML contains. Each transaction becomes a VOUCHER element with a voucher type (Payment or Receipt), a date, and two or more ledger entries that must balance, one touching the bank ledger and one touching the contra account such as an expense or party. There is also a header that identifies the company the data belongs to. Hand-writing this XML for a few hundred transactions would be slower than manual voucher entry, so the value of a converter is not just reading the PDF but assembling thousands of correctly nested, balanced voucher records that Tally will validate and post without complaint. A single malformed entry can stop the whole import, which is why generating the XML programmatically beats trying to massage a CSV into shape by hand.
Mapping statement lines to the right voucher type
The core of a correct import is matching each statement line to the voucher Tally expects. The logic is consistent: the direction of money decides the voucher type, and the bank ledger is always one side of the entry.
| On the statement | Direction | Tally voucher type | Typical ledger entry |
|---|---|---|---|
| Withdrawal / debit (money out) | Bank decreases | Payment voucher | Credit: Bank ledger · Debit: expense or party ledger |
| Deposit / credit (money in) | Bank increases | Receipt voucher | Debit: Bank ledger · Credit: income or party ledger |
| Bank charges / fees | Bank decreases | Payment voucher | Credit: Bank ledger · Debit: Bank Charges ledger |
| Interest credited | Bank increases | Receipt voucher | Debit: Bank ledger · Credit: Interest Income ledger |
| Transfer between own accounts | Varies | Contra voucher | Between two bank/cash ledgers |
The cleanest way to produce XML with this mapping already applied is to use the bank statement to Tally converter, which assigns voucher types as it reads the statement. If you want the raw XML to inspect or adjust before importing, the Tally XML export gives you the file directly.
The import steps in Tally Prime and ERP 9
The mechanics differ slightly between versions but the sequence is the same: confirm your ledgers, open the import screen, point it at the XML, and verify. In Tally Prime, go to Gateway of Tally > Import > Vouchers, then select the XML file. In Tally ERP 9, the path is Gateway of Tally > Import of Data > Vouchers, then specify the file name and import. .
Before you import, make sure the bank ledger referenced in the XML exists under Bank Accounts, since Tally posts the vouchers against it. Party ledgers can be created during import if the file includes them, but it is safer to confirm the major ones beforehand. After the import finishes, open the Day Book and spot-check several vouchers: confirm the voucher type, the ledger on each side, the amount, and the date all match the statement. If a batch looks wrong, restore the backup you took and adjust the mapping before re-importing.
One behavior worth knowing: when Tally imports vouchers, it reports how many were imported, how many were combined, and how many were ignored. Pay attention to the "ignored" count. A non-zero number usually means some vouchers referenced a ledger that does not exist or failed validation, and those transactions simply did not post, leaving your books short by exactly those lines. The fastest way to find them is to compare the imported voucher count against the number of transactions on the statement; if they differ, the gap is your ignored set. Create the missing ledgers, restore the backup, and re-import the full file rather than trying to add the stragglers by hand. Treating the import as all-or-nothing keeps the books clean and avoids the half-imported state that causes the most confusion later.
After a successful import, the final step is bank reconciliation inside Tally. Open the bank ledger, switch to the reconciliation view, and set the bank date for each voucher against the actual statement. Because the imported vouchers already carry the correct transaction dates and amounts, reconciliation becomes a confirmation pass rather than data entry, and the closing balance Tally computes should match the statement's closing balance to the rupee. If it does not, the difference points straight at a missed or duplicated line, which you can resolve before closing the period.
Details that prevent a messy import
- Ledger names must match exactly. The bank ledger name in the XML has to equal the ledger name in Tally character-for-character, or the voucher fails to post against it.
- Voucher dates inside the period. Each voucher carries the statement's transaction date, so reports and reconciliation line up with the bank.
- Narration carried over. The statement description is placed in the voucher narration, preserving cheque numbers and references for audit.
- Duplicate guard. Importing the same statement twice creates duplicate vouchers, import each period once, and reconcile before the next batch.
Where Tally imports go wrong in practice
From parsing statements across hundreds of bank templates for Indian accounts, the recurring failure points in Tally imports are not in Tally itself but in the data handed to it. The most common is a bank ledger name mismatch, the XML says "HDFC Bank" while Tally has "HDFC Bank A/c," and nothing posts. The second is misclassified direction: statements that print separate withdrawal and deposit columns get read as a single column, and a deposit is mistakenly tagged as a payment. The third is duplicate imports when a user re-runs a month after a partial failure. A converter that emits exact ledger names, reads split debit/credit columns correctly, and lets you preview before import removes the first two; disciplined one-import-per-period removes the third.
From statement to posted vouchers
Manual voucher entry is where most of the time and most of the errors come from, a busy current account can run to hundreds of lines a month, and each hand-keyed voucher is a chance to fat-finger an amount or pick the wrong ledger. Converting the statement to Tally XML collapses that into one reviewed import: you check the mapping once in the preview, post the whole period, and reconcile. When you are ready, run the PDF through the Tally converter to generate the XML, then import it through Gateway of Tally and verify in the Day Book. For a deeper walkthrough of the QuickBooks equivalent, see how to import bank statements into QuickBooks.
Frequently asked questions
How do I import a bank statement into Tally?▾
Convert the statement PDF to Tally XML, then in Tally Prime go to Gateway of Tally > Import > Vouchers (or Gateway of Tally > Import of Data > Vouchers in ERP 9) and select the XML. Debits import as payment vouchers and credits as receipt vouchers against your bank ledger.
Can Tally import a PDF or Excel bank statement directly?▾
No. Tally imports vouchers from its own XML format, not from PDF or Excel. You first convert the statement into Tally-compatible XML, which carries the voucher types and ledger names Tally needs, and then import that file.
How are debits and credits mapped to Tally vouchers?▾
Money leaving the account (withdrawals, fees) maps to payment vouchers that credit the bank ledger. Money entering the account (deposits, interest) maps to receipt vouchers that debit the bank ledger. Transfers between your own accounts use contra vouchers.
What's different between importing in Tally Prime and ERP 9?▾
The voucher mapping is the same. The menu differs: Tally Prime uses Gateway of Tally > Import > Vouchers, while ERP 9 uses Gateway of Tally > Import of Data > Vouchers. Both then ask for the XML file and post the vouchers.
Why did my vouchers fail to post against the bank ledger?▾
Almost always a name mismatch. The bank ledger name in the XML must match the ledger name in Tally exactly, including any suffix like 'A/c'. Confirm the ledger exists under Bank Accounts with the same spelling before importing.
How do I avoid duplicate vouchers when importing?▾
Import each statement period only once and reconcile before importing the next. If an import partially fails, restore the backup you took beforehand rather than re-running the whole file on top of the partial batch.