If you have ever pasted a bank statement table straight into Excel, you know the result: transaction descriptions spill into the amount column, a multi-line memo splits across three rows, and the running balance at the bottom no longer matches the number printed on the statement. Converting a PDF bank statement to Excel is not hard in principle, but the file format works against you at every step, and the method you pick determines how much of that mess you end up cleaning by hand.
This walkthrough covers two real paths: Excel's own built-in import tool, which costs nothing and lives in the ribbon you already have, and a dedicated statement converter such as Convert·Into, which is worth reaching for once the file is long, scanned, or one of several you need done the same way. Either way, the walkthrough ends with the checks that tell you whether the result can be trusted before you file it.
Why PDF bank statements resist a simple copy and paste
A PDF is a display format. The numbers you see on a statement are glyphs positioned on a page for printing, not values stored in rows and columns the way a spreadsheet stores them. When you copy that page and paste it into Excel, Excel has to guess where one column ends and the next begins, using nothing but the horizontal spacing between characters. Guess wrong once, on one row, and a date column collapses into the description next to it.
That guessing gets harder as the statement gets busier: transaction descriptions that wrap onto a second line, a running balance column that is only printed every few rows, or a footer that repeats the bank's name and address on every page and gets mistaken for a row of data. None of this means the statement is corrupted. It means the table structure you can see was never actually stored as a table.
Start with Excel's built-in Get Data from PDF tool
Before reaching for anything else, it is worth trying the tool already in Excel. On the Data tab, choose Get Data, then From File, then From PDF, and point it at the statement document. Excel scans the file for anything that looks like a table, shows you a preview of what it found, and lets you load the result into Power Query, where you can rename columns, split a combined date and description field, and set data types, before anything lands on a worksheet.
For a single statement with one clean transaction table per page and no scanned pages, this often gets you most of the way there without installing anything new. It is not a given, though: Excel's table detection can misjudge where a table starts and ends, particularly when a statement's transaction table restarts its header on every page, or when the last page of a statement carries a shorter table with a shifted column. Where Power Query starts to struggle covers the specific patterns that tend to break the built-in tool, and it is worth reading before you commit to this route for anything beyond a page or two.
Two things Excel's importer cannot do at all: read a scanned or photographed statement, since there is no text layer for it to detect, and open a password protected file without you removing the password first. Telling a scanned statement from a text based one takes about five seconds and is worth doing before you pick a method, because it decides whether the built-in tool is even in play.
When Excel's import is not enough
The built-in importer tends to hold up for a single, short, text based statement. It tends to struggle once any of the following applies:
- The statement runs long. Twenty or thirty pages of transactions increase the odds that a header repeats mid table, a footer gets read as a row, or a column shifts somewhere in the middle, and each of those needs a manual fix.
- The statement is scanned or photographed. There is no selectable text for Power Query to find, so the import returns nothing useful, and the file needs OCR before any table detection can run.
- You have several statements to combine. Running the same import, cleanup and formatting pass across twelve monthly files by hand is slow, and it is easy for one file's column order to differ slightly from the rest.
- The statement is password protected. Excel will not open it until the password is removed, which means an extra step outside the spreadsheet entirely.
None of this is a flaw in Excel. Power Query was built to read structured data sources, and a bank statement PDF is, at best, a semi structured approximation of one. This is the point at which a dedicated statement converter earns its keep.
Converting a bank statement with Convert·Into
Convert·Into is built specifically around this problem: it reads statement documents from a wide range of banks, recognises each bank's own layout, and reconciles the result against the balance printed on the statement before handing you the file. The process has four stages, and none of them require you to configure a template first.
- 1
Upload the statement
Drop the statement document, or several at once, into Convert·Into. There is no template to select; the tool works from the file itself. - 2
Let the layout get identified
The tool reads the document, identifies the issuing bank and its column layout, and locates the transaction table across every page, including any that repeat a header partway through. The list of banks it recognises out of the box is on the supported banks page. - 3
Review the extracted rows
Extracted transactions are shown next to the source statement so you can check dates, descriptions, and amounts line by line. Fields the parser could not read, and any row whose running balance does not match the balance printed on the statement, are flagged automatically so you know exactly what to check before you export. - 4
Export to Excel
Once the rows check out, export to Excel, CSV or QBO/OFX, whichever your ledger imports directly.
Scanned and photographed statements go through OCR at the upload stage rather than being rejected outright, though OCR carries its own error pattern worth knowing about: catching the digit errors OCR tends to introduce explains what a misread 3 or 8 looks like on the page and how the balance check catches it before it reaches your ledger.
Convert your first statement
Verify the converted file before you use it
Whichever method produced the spreadsheet, the file is only as good as the check you run on it afterward. The single most reliable check is arithmetic, not visual inspection: the opening balance plus every transaction should equal the closing balance, and both figures should match what is printed on the statement itself.
Convert·Into runs this reconciliation automatically, recalculating the running balance line by line against the printed figures and flagging any row where the two disagree. A four-check verification pass walks through the full set of checks worth running on any converted statement, including one most people skip: confirming the transaction count on the last page matches what actually landed in the spreadsheet.
Picking a method for the statement in front of you
For a single, short, text based statement, Excel's Get Data from PDF is a reasonable first attempt, and it costs nothing beyond the time to shape the columns in Power Query. For anything longer, scanned, password protected, or arriving as a batch of monthly files that all need the same treatment, a dedicated converter removes the repeated manual cleanup and adds a balance check you would otherwise have to build yourself in a formula. Either way, the file is not done until the numbers in it have been checked against the statement it came from, not just glanced at.
Frequently asked questions
Can Excel open a PDF bank statement directly, without any other software?
No. Excel cannot open a PDF file as a spreadsheet on its own, but it does have a built-in import path: Data, Get Data, From File, From PDF. That route reads the document through Power Query and lets you preview and shape the table before it lands on a sheet, which is different from pasting the text in and hoping the columns line up.
Why do the dates and amounts come in as text instead of numbers?
This usually happens because the original PDF stores each character as a positioned glyph rather than a typed value, and whatever imported the file kept the visual spacing instead of the underlying number. A cell that looks like 1,204.55 but sits left aligned and fails SUM is almost always text, not a number, and it needs reformatting before any formula will touch it.
Does a scanned bank statement convert the same way as a text based one?
No. A text based statement carries the transaction data as selectable characters, so a table detection tool can read it directly. A scanned or photographed statement is just an image of numbers, so it needs OCR first, and OCR introduces its own misread risk, most often a 3 read as an 8 or a 5 read as a 6.
What should I check once the statement is in Excel?
Compare the closing balance in the last row of your sheet against the closing balance printed on the statement, and confirm the opening balance and the transaction count as well. If the opening balance plus the sum of all transactions does not equal the closing balance, a row was dropped, merged, or misread somewhere in between.
Will this work for a statement that runs to twenty or thirty pages?
Yes, though the method matters more at that length. Excel's own PDF import can handle a long document, but a table that restarts its header on every page, or shifts a column on the final page of transactions, tends to trip up automatic detection more often as the page count climbs. A dedicated statement converter that recognises the bank's layout across every page tends to hold up better at that scale.
Can I convert several months of statements into one spreadsheet in a single pass?
Yes, most conversion tools, including Convert·Into, accept multiple files at once and can combine them into one workbook or keep them as separate sheets. Each file is still checked against its own opening and closing balance before the rows are treated as reliable.