How to Import Bank Statements into Tally (UAE & Gulf Guide)

Tally is still the workhorse ledger for a huge share of businesses across the UAE, Saudi Arabia, Oman and Bahrain — and every month, the same bottleneck appears. The bank sends a PDF. Tally wants structured data. Somewhere in between, a bookkeeper is retyping four hundred rows by hand.

This guide walks through how to import a bank statement into Tally properly: what Tally will and will not accept, how to prepare the file so the import actually matches, and how to prove the data is complete before it touches your books.

What Tally can and cannot read

TallyPrime has no PDF engine. It does not attempt to read a statement layout, and it will not guess where your columns are. Everything it imports has to be structured data with predictable fields.

In practice there are three routes, and choosing the right one saves a lot of time:

Route	What it does	Best for
Banking → Bank Reconciliation → import statement	Loads the bank's statement into the reconciliation screen and matches it against already-posted entries	Reconciling a bank ledger you already post to
Voucher import (XML)	Creates actual receipt/payment vouchers in Tally from a structured file	Bulk-posting transactions that are not yet in Tally
Excel import (recent TallyPrime releases)	Imports masters and vouchers from a spreadsheet template	Teams on a current TallyPrime version who prefer Excel

The Banking module's statement import expects a format it recognises for the specific bank you have configured. Voucher import expects Tally's own XML. Excel import expects Tally's template layout. All three have one thing in common: they start from clean, columnar transaction data — which is exactly what a PDF is not.

Whichever route you pick, the work is the same up front: get one row per transaction, with real dates, real numbers, and debits and credits in their own columns. Get that right and every import path becomes straightforward.

Step 1 — Convert the PDF into a clean spreadsheet

Start by turning the statement into structured rows. With the BayanSheet converter, you upload the PDF and it extracts every transaction into a proper spreadsheet — entirely inside your browser, so a client's statement is never transmitted anywhere.

BayanSheet is tuned to Gulf and UAE bank layouts, including dedicated pages for Emirates NBD, FAB, ADCB and Dubai Islamic Bank. Export to CSV or XLSX — both are easy to reshape into whatever Tally is expecting.

If you have never done the conversion step before, the walkthrough in how to convert a bank statement to Excel covers it end to end.

Step 2 — Verify before you import, not after

This is the step most people skip, and it is the one that costs the most.

Before you shape the file for Tally, prove the extraction is complete using the arithmetic every statement already contains:

Opening balance + credits − debits = closing balance

If that ties out, no row was lost. If it does not, a transaction is missing or a figure was misread — and you want to know that now, not after two hundred vouchers are sitting in your books. BayanSheet runs this reconciliation check automatically after conversion and flags the rows involved when the chain breaks. There is more detail on why this matters in bank reconciliation from PDF statements.

Two extra sanity checks take thirty seconds:

• Does the row count in your spreadsheet match the transaction count on the PDF?
• Does the last balance in your file match the closing balance printed by the bank?

Step 3 — Shape the columns Tally expects

Now prepare the file. Regardless of the import route, aim for this structure:

Column	Notes
Date	DD/MM/YYYY — the format every Gulf bank prints
Transaction description / narration	Keep the bank's original text; it drives matching
Debit	Money out, positive number, blank if not applicable
Credit	Money in, positive number, blank if not applicable
Balance	Optional but useful for verification
Ledger name	Only for voucher import — must match Tally exactly

Three details that break imports more often than anything else:

Dates. A UAE statement showing 05/07/2026 means 5 July. If the file is interpreted as US-style MM/DD/YYYY it becomes 5 May, and your reconciliation silently drifts by weeks. Format the column as text in DD/MM/YYYY, or as a true date value — never as an ambiguous mix.

Amounts as numbers, not text. Strip currency symbols, thousand separators and trailing DR/CR flags into a separate column. AED 1,250.00 DR is text; 1250.00 in a debit column is a number Tally can use.

Separate debit and credit columns. Some statements put everything in one column with a minus sign. Split it. A single signed column is the fastest way to end up with reversed entries. BayanSheet exports debits and credits separately by default, which removes this problem entirely.

Step 4 — Match your ledger names

If you are importing vouchers rather than just reconciling, Tally matches ledgers by name as plain text. Emirates NBD Current A/c and Emirates NBD Current Account are two entirely different ledgers as far as Tally is concerned.

Before importing, open your chart of accounts and copy the exact ledger names into your spreadsheet. Where you can, build a small lookup table: a column of common narration keywords (SALARY, ATM WDL, POS PURCHASE, CHQ DEP) mapped to the ledger you normally post them to, then use a formula to assign ledgers in bulk. That single lookup, reused every month, is where most of the time saving actually comes from.

Step 5 — Import into TallyPrime

For bank reconciliation:

1. Open the bank ledger, then Banking → Bank Reconciliation.
2. Choose the option to import the bank statement.
3. Select your prepared file and confirm the bank configuration for that ledger.
4. Review the matched and unmatched rows. Tally will match on date and amount; unmatched rows are usually timing differences or entries you have not yet posted.

For voucher import:

1. Convert your prepared sheet into Tally's import format (XML, or the Excel template if your release supports it).
2. Go to Import → Vouchers (or Import → Transactions, depending on release).
3. Point Tally at the file and run the import.
4. Check the import log immediately. Tally reports errors and skipped lines there — a silent partial import is far worse than a visible failure.

Step 6 — Reconcile inside Tally

After importing, reconcile the bank ledger against the statement. The bank reconciliation statement in Tally should show a balance that agrees with the PDF's closing balance once uncleared items are accounted for.

If it does not agree, work backwards in this order: check for duplicate imports (running the same file twice is common), then for date-format drift, then for rows dropped at extraction. Because you already verified the conversion in Step 2, the first two causes are far more likely.

A workflow you can repeat monthly

The teams who find this painless are the ones who stopped treating it as a monthly project:

1. Download PDFs for every account on the same day each month.
2. Convert and let the reconciliation check confirm completeness.
3. Apply your saved narration-to-ledger lookup.
4. Import into Tally and reconcile the same day.

Once the lookup table exists, steps 2 to 4 take minutes per account rather than hours — and the books are clean enough that VAT and Corporate Tax work later in the year is a review, not a rebuild. See preparing bank statements for UAE Corporate Tax for how that same clean ledger feeds the annual filing.

Ready to try it on this month's statements? Convert your first pages free with BayanSheet — nothing uploaded, nothing stored, just clean rows ready for Tally.