Convert a bank statement PDF to Excel

Why bank2tally

Built for accountants, not just a generic file converter

This started as a bank-to-Tally tool, so the Excel output comes from the same accurate, bank-specific parsing — not a generic PDF-table extractor guessing at columns. A few things that are different from most converters in this space:

• Pay-per-use credit packs that never expire — not a subscription, not ad-supported
• 3 free conversions a month, no signup needed to try the first one
• Column layouts verified against real statements, bank by bank — not a one-size-fits-all guess
• If you also use Tally, the same upload gives you Tally-ready XML, not just Excel

How it works

Works on text-based PDFs (the kind net banking downloads). Scanned or photographed statements aren't supported yet. Password-protected PDFs work — you set the password when you convert.

What's in the spreadsheet

One row per transaction, already split into real columns

The output isn't a raw text dump of the PDF — each transaction becomes its own row with date, narration, reference number, debit, credit and balance already in separate columns, exactly as they were printed on the statement. That means you can sort by amount, filter to a date range, or drop the sheet straight into a pivot table without first cleaning up merged cells or stray line breaks, which is the usual mess a generic PDF-to-Excel tool leaves behind.

Common uses

Beyond feeding it into Tally

Accountants use the Excel output for working papers during an audit, for building a client-facing summary without exposing the original PDF, or for reconciling a statement against a general ledger in a spreadsheet before anything gets posted anywhere. Because the same upload can also produce Tally-ready XML, you don't have to decide up front — convert once, and choose the output that fits what you're doing with it that day.

Two specific things generic converters get wrong

Indian statements have quirks a US-built tool wasn't designed for

Most PDF-to-Excel tools are built against Western bank statement conventions, and two very ordinary features of an Indian statement trip them up. First, Indian digit grouping — a balance printed as "1,84,550.00" (lakhs, not thousands) can get parsed as "1.84" or truncated at the first comma by a tool that expects "184,550.00" instead. Second, several Indian banks wrap one transaction's narration across two or three lines on the PDF — a UTR number and counterparty bank on their own line below the main entry. A naive table extractor often reads each wrapped line as its own row, producing a spreadsheet with ghost rows that have an amount column but no narration, or a narration with no amount. bank2tally's parsers are built per bank specifically to handle both: Indian-format numbers parse correctly regardless of comma placement, and wrapped narration lines are stitched back into the single transaction they belong to before the row is written.

Questions