How to convert a bank statement PDF to Excel (and know it's right)

Getting a bank statement into Excel is easy. Getting it into Excel with every transaction present, every amount in the right column and every date read correctly is the part that takes the afternoon. This guide covers the three realistic routes, where each one breaks, and a two-formula check you can run on any result, whichever tool produced it.

Before you convert anything: does your bank already export a spreadsheet?

Converting a PDF is the fallback, not the first choice. Many banks let you download transactions directly:

HDFC Bank NetBanking offers statement downloads in PDF, Excel, Text, Delimited and MS Money formats (HDFC Bank FAQ).
HSBC UK lets you download your transaction list as Excel or CSV from online banking, even though statements themselves are PDF only (HSBC UK).
Wells Fargo lets you download account activity as a spreadsheet, by default the last 90 days and up to 18 months for some accounts (Wells Fargo).
Monzo exports statements as PDF, CSV or QIF straight from the app (Monzo).

So the PDF route matters when the period you need is older than the bank's download window, the account is closed, the statement was sent to you by someone else (a client, a borrower, a relative), or the bank only offers PDFs.

Option 1: Excel's built-in "Get Data from PDF"

Microsoft 365 Excel on Windows can read tables out of a PDF: Data > Get Data > From File > From PDF, pick the file, then choose the detected tables in the Navigator and either Load or Transform Data (Microsoft Support).

When it works: a digital (not scanned) statement with a clean grid and one transaction per line.

When it breaks:

Wrapped descriptions. A long payee or UPI reference that wraps onto a second line becomes a second row with no date or amount. Microsoft's own documentation for the PDF connector notes that multi-line rows may not be identified and suggests cleaning up with fill-down or grouping (Microsoft Learn).
One table per page. A 12-page statement can arrive as 12 separate tables you have to append, with the page header repeated in each.
Sectioned statements. Some US banks print deposits, checks and withdrawals in separate sections rather than one chronological list, so Excel finds several differently-shaped tables.

It's free and private (the file stays on your computer), so it's worth trying first on simple statements.

Option 2: Copy and paste

Select the transactions in a PDF viewer, paste into Excel, then split columns with Data > Text to Columns. It works for a one-page statement and fails quietly on anything longer: empty debit cells collapse so amounts shift into the wrong column, and multi-line descriptions interleave with the next transaction. If you go this way, run the checks below before you trust a single total.

Option 3: A dedicated bank statement converter

A converter built for statements understands that a row needs a date, a description and an amount, merges wrapped lines, and separates money in from money out. Before you upload anything, check four things:

Where does your PDF go? Many converters upload the file to their servers and keep it for a period (one well-known converter's privacy policy says uploaded documents "persist on our servers for 24 hours"). Others parse the PDF in your browser. For a document carrying your account number and every transaction you made, this matters.
Does it prove the result? The useful tools check the extracted rows against the statement's own opening balance, closing balance and running balance, and show you where they disagree. A converter that only gives you rows leaves the checking to you.
Can it open password-protected PDFs? Most Indian bank e-statements, and many others, are encrypted. Some converters refuse them outright.
Does it export the format you need next? Excel for analysis; CSV or OFX if the data is going into accounting software.

The two checks that prove a conversion (whatever tool you used)

Put your transactions in columns: A date, B description, C money out, D money in, E the statement's printed balance (if it has one).

Check 1: Does the whole statement foot?

In an empty cell:

= opening_balance + SUM(D:D) - SUM(C:C)

The result must equal the closing balance printed on the statement, to the cent. If it doesn't, a transaction is missing, duplicated, or in the wrong column. ("Footing" is accountants' shorthand for totalling a column; our reconciliation guide explains it properly.)

Check 2: Does every row agree with the running balance?

If your statement prints a balance after each transaction, add a column F starting on the first transaction row (row 2 here, with the opening balance in E1):

F2:  =ROUND(E1 + D2 - C2 - E2, 2)

Fill it down. Every cell should be 0.00. The first non-zero row is where the extraction went wrong: typically a merged row, a missed transaction, or a debit read as a credit. Rounding matters: without ROUND, floating-point arithmetic can leave differences like 0.0000000001 that look like errors.

Check 1 tells you whether something is wrong. Check 2 tells you where.

Common problems after conversion, and the fixes

Symptom	Cause	Fix
Dates left-aligned, won't sort	Dates imported as text	Data > Text to Columns, choose Date and the right order (DMY or MDY)
03/04 read as 4 March instead of 3 April	Day-first statement opened with US date settings	Re-import choosing DMY; never "fix" dates by hand
Amounts like `1,23,456.78` won't add	Indian digit grouping read as text	Remove commas, then convert to number
`(250.00)` or `250.00-`	Accounting-style negatives	Convert to `-250.00` before totalling
`12,345.67 Cr` / `Dr` in the balance column	Balance printed with a credit/debit suffix instead of a sign	Strip the suffix; Cr = positive, Dr = negative (overdrawn)
Rows with a description but no date or amount	Wrapped description lines	Merge into the row above
"Balance brought forward" rows	Page carry-over lines	Delete; they are not transactions
Dates without a year (e.g. "12/28")	Year printed only in the statement period	Add the year from the period; watch December–January statements

How Footed handles it

Footed was built around the checks above:

The PDF is opened in your browser with pdf.js. Only the extracted text is sent for parsing; it's processed in memory and not stored.
Any layout. An AI model reads the text, so it doesn't depend on a template for your bank.
Every conversion is reconciled. Footed checks that the opening balance plus the extracted transactions equals the closing balance, checks row by row wherever the statement prints a running balance, and highlights any row that doesn't agree so you can look at it before downloading.
Excel, CSV or OFX downloads.

FAQ

Can I convert a bank statement to Excel for free? Yes. Excel's Get Data from PDF is free if you have Microsoft 365, and copy-paste costs nothing but time. Footed's free tier covers 5 pages a day.

Why doesn't my converted total match the statement? Usually one of three things: a missing row (often at a page break), a wrapped description treated as its own row, or a debit that landed in the credit column. Run Check 2 above to find the first row where the balance stops agreeing.

Is it safe to upload a bank statement to an online converter? It depends on what the service does with the file. Read the privacy policy for how long files are kept, or use a tool that parses the PDF on your device.

Can I convert a scanned statement? Yes. Footed detects pages with no text layer and reads them with a vision model instead (slower, and the page image is sent for processing rather than just text). The balance check still flags any misread row. Alternatively, run OCR locally first; see how to convert a scanned bank statement to Excel.

Try it on your own statement. Footed converts bank statement PDFs to Excel, CSV or OFX, keeps the PDF in your browser, and shows you any row that doesn't reconcile. Free for 5 pages a day.

Published 2026-10-07.