Import a bank statement into TallyPrime the right way

TallyPrime has two completely different bank-statement doors, and picking the wrong one is why imports end up as a wall of Suspense entries. This guide covers both, the voucher types that matter, and how to avoid duplicates.

Two doors, two purposes

Before touching a file, decide which of these you actually want. They produce different results and are not interchangeable.

Import → Transactions (XML). Creates real vouchers in your books — Payment, Receipt and Contra entries with ledgers already chosen. Use this when the statement is your primary data entry, which is the normal case for a client's bank account you are writing up from scratch.
Banking → Bank Reconciliation / Import Bank Statement. Brings statement lines in to be matched against vouchers that already exist in Tally. Use this when the entries were already passed and you only want the reconciliation ticked off. It will not create your vouchers for you.

The commonest mistake is using the reconciliation door for data entry. Nothing is created, nothing matches, and it looks as if the import failed.

The three voucher types

Every line on a bank statement becomes one of three things in Tally:

Payment — money left the bank for a real third party. Bank account is credited, the expense or party ledger debited. Cheque issued, NEFT out, UPI paid, EMI, standing instruction, bank charge.
Receipt — money came into the bank from outside. Bank debited, party or income ledger credited. Customer payment, interest credited, refund.
Contra — money moved between your own accounts, so no income or expense arises. Cash deposited into bank, ATM withdrawal, self cheque, transfer between two of your own bank accounts.

Contra is the one people skip, and skipping it quietly inflates both expenses and income. An ATM withdrawal booked as a Payment to "Cash Withdrawal Expenses" is not an expense — the money is still yours, sitting in Cash in Hand.

Dr/Cr, stated once and clearly

Your bank statement is written from the bank's point of view: a "withdrawal" reduces your balance. In your books the bank account is an asset, so a withdrawal credits the bank ledger and a deposit debits it. If your imported vouchers all look inverted, this reversal is what was missed.

Route A — import vouchers with Tally XML

Take a backup first. Gateway of Tally → Data → Backup. Every bulk import should be preceded by one; an import cannot be undone with Ctrl+Z.
Produce the XML. Convert the statement PDF on the home page and choose the Tally XML export. The bank ledger name you type must match the ledger in your company exactly — "HDFC Bank 4521" and "HDFC Bank-4521" are two different ledgers to Tally.
Review the voucher types and ledgers on screen before downloading. Load your chart of accounts to get suggestions against your real ledger names, and accept only the ones you agree with. Anything you leave unassigned goes to Suspense on purpose, so it is easy to find afterwards.
Import. In TallyPrime: Gateway of Tally → Import → Transactions, give the file path, and confirm. In Tally.ERP 9 it is Gateway → Import Data → Vouchers.
Read the import log. Tally reports vouchers created, combined and ignored, and writes errors to Tally.imp in the application folder. If the created count is lower than your row count, that file says why.
Verify. Open Display → Account Books → Ledger → your bank ledger for the period and check the closing balance against the statement. If it matches to the paisa, the import is clean.

Why XML and not Excel

Tally XML is Tally's own published format, so there is no column mapping and no template to configure — the file already says "this is a Payment voucher dated 3 April with these two ledger entries". Excel-based voucher import needs a template that matches your version and is far easier to get subtly wrong.

Route B — Banking → Import Bank Statement

Pass or import your vouchers first. This route matches, it does not create.
Go to Banking → Bank Reconciliation and select the bank ledger.
Choose Import Bank Statement and give it the statement file. Tally reads bank-provided formats and its own configured layouts; export the bank-statement CSV or Excel from the converter for this.
The first time a bank is used, Tally asks you to configure the layout — which column is date, which is withdrawal, which is deposit. It remembers this per bank, so it is a one-time step.
Tally ticks off the lines it can match on date and amount. Work through the unmatched ones by hand; those are usually timing differences (cheque issued but not yet cleared) rather than errors.

Avoiding duplicates and Suspense pile-ups

Import one period at a time, and note the closing date. Overlapping date ranges is the number one cause of double entries.
Do not re-import a file you have already imported after correcting one row. Fix that voucher in Tally instead, or delete the imported set and import once, cleanly.
Keep the bank ledger name stable across imports. A typo creates a second ledger and splits your balance across two.
Use Suspense deliberately. Rows you genuinely cannot classify should land in Suspense so you can list them later with Display → Account Books → Ledger → Suspense and clear them in one sitting. Guessing a ledger to avoid Suspense is worse than leaving it.
Watch for bank charges with GST. These arrive as one debit but are often two ledgers — Bank Charges and the GST input. Split them at review time if you claim the credit.

Common import errors

"Ledger does not exist" — the ledger name in the file does not match Tally character for character. Fix the name, or create the ledger first.
All vouchers land in Suspense — no chart of accounts was loaded at review time, so nothing could be matched. Load your ledger master and export again.
Dates fall in the wrong year — the statement crosses 1 April and your company period does not cover it. Tally silently skips vouchers outside the active financial year.
Everything imported inverted — withdrawal and deposit columns were swapped at the source. Check one known row against the PDF before importing the rest.