Most accountants I know have a number in their head for this. How long a month of bank entries takes them. Three hours if the client is quiet and a full day if the client runs a shop and takes forty UPI payments a day.
That number is the reason this article exists, because almost none of that typing needs to happen.
Tally can take the data in directly. What stops people is that the route in is not obvious, the file usually needs work before Tally will look at it, and the error messages when it goes wrong tell you almost nothing.
What Tally gives you out of the box
Two separate things live under different menus, and they do different jobs. People mix them up constantly.
Banking, then bank reconciliation. This matches entries you have already recorded against what the bank says. It is a reconciliation tool. It does not create vouchers for transactions Tally has never seen.
Import data, then vouchers. This one actually creates entries. Feed it a properly formed file and the vouchers appear in your books.
If your client hands you three months of statements for transactions that were never entered anywhere, reconciliation will not help you. You need the second route.
Why the CSV usually fails
So you download the statement, convert it to a spreadsheet, and try to bring it in. Tally throws an error or imports nothing at all.
Here is what is generally wrong with it.
Your dates are text, not dates. Almost every bank PDF converts this way by default, and Tally will not read 01-04-25 sitting in a cell formatted as text.
Debit and credit are stuck in one column with a minus sign. Tally wants them separated because a receipt and a payment are different voucher types, and it has no way to guess which is which from a signed number.
There is no ledger name anywhere in the file. Your bank gives you a narration like UPI/DR/297893240309/JAGADISH/SBIN/9620323750/Payment. Tally needs a party name. Nothing in that string is labelled as one.
Nothing tells Tally what kind of voucher each row should become. Receipt, Payment, Contra. Money out to another of your own accounts is a contra. Money out to a supplier is a payment. A CSV has no way to express that difference.
And your rows are broken. Long narrations wrap onto a second line in the PDF, and unless the converter joins them back, you get blank rows scattered through your file with amounts missing.
Fix all five by hand across three hundred transactions, and you have saved yourself nothing.
The three ways people do this
| Typing it in | A generic CSV converter | Bank Statement Magic XML | |
| 300 transactions takes | 4 to 6 hours | 1 to 2 hours | Under one minutes |
| Voucher type, Receipt or Payment or Contra | You decide each one | You decide each one | Set from the transaction direction |
| Party name out of a UPI narration | You type it | You type it | Pulled out automatically |
| Dates | No issue | Land as text, imports fail | Formatted for Tally before export |
| Debit and credit | Manual | Often merged into one signed column | Kept apart |
| Narration that wraps to a second line | No issue | Leaves blank rows behind | Rejoined to its transaction |
| Column mapping screen | Not applicable | Every file, every month | Skipped entirely |
| Tally Prime and ERP 9 | Both | Both | Both |
| Full original narration retained | If you type it | Sometimes | Yes, in its own column |
The middle column is where most practices sit, and it is the worst of the three. You are doing enough work to feel busy and not enough to be finished.
Getting from PDF to something Tally accepts
Your starting point is nearly always a PDF, because that is what banks send and what clients forward.
The first step is turning it into structured data. A bank statement converter reads the layout and gives you back columns instead of a wall of text. What you want from that step is specific:
Dates as real dates, in DD-MM-YYYY, matching whatever your Tally company is set to.
Debit and credit split into two columns.
The full original narration is kept in one column, and a cleaned party name is pulled out into another. You want both. The narration is your audit trail, and the party name is what actually goes into the ledger.
Balances carried through so you can check the last row against the account before you import anything.
Get a converter that does the party name extraction properly. Most of them stop at columns and leave you to work out that JAGADISH is the counterparty in that UPI string. Across three hundred rows that is most of your afternoon.
Two routes in, and why one is better
Route one, Excel or CSV. Convert the statement to a spreadsheet, tidy up the columns to match what Tally expects, and then bring it in through Import Data. Workable. You are still doing the mapping, and you are doing it again next month for the next client.
Route two, Tally XML. The file arrives already structured as vouchers. The voucher type worked out from the direction of the transaction, the party name in place, dates formatted the way Tally wants them, and amounts in the right fields. You import, and it is done.
This is the difference worth understanding if you are looking at tools. Plenty of them advertise Tally-ready output and mean a CSV with the columns in a helpful order. Actual XML is a different thing. A tool built to import bank statement in tally prime as XML skips the mapping screen entirely.
Doing it
- Download the statement as a PDF from net banking. Get the full period in one file if you can, it saves stitching later.
- Run it through the converter. Pick Tally XML if the tool offers it, otherwise Excel.
- Open the output and check three things. Does the closing balance match the bank? Are the dates the right way round? Any blank rows?
- Take a backup of your company data. Always. Import is not something you want to undo by hand.
- In Tally Prime, go to Gateway of Tally, then Import Data, then Vouchers, and point it at your file.
- Read the import summary. It will tell you how many vouchers came in and how many were skipped.
- Now run Banking, then Bank Reconciliation, to tie everything off against the bank.
Menu paths shift a little between Tally versions, so check against whichever release you are running. In ERP 9 the same sequence lives under Gateway of Tally, Import of Data, Vouchers.
Where it goes wrong
No imports and no apparent explanation. Typically the date format. Find out what your company is going to do and do the same.
Vouchers were issued as incorrect voucher types. No voucher type information was found in your file, Tally defaulted. That’s what XML is for.
Duplicates after 2nd import. Tally will allow the same statement to be imported twice happily. If you wish to re-import items, you should first see what is already in there for this date range.
Errors related to ledgers. The name of the Party in your file is not found in Tally. Make the ledgers or utilize the tool that maps to the existing ones.
There is a slight imbalance of a few rupees. This is typically a wrapped narration, which divides one transaction into two rows. Return to the converted file and find rows where there is a description but no amount.
