Why a bank statement breaks when you paste it into Excel
A bank statement looks like a table, so it is fair to assume you can select the rows, copy them, and paste them into Excel. Almost every time, the result is a mess. Dates arrive as five-digit numbers, amounts land in the wrong column, and a single transaction with a long payee name splits itself across three rows.
The cause is simpler than it looks: a PDF has no concept of a table. There are no columns and no rows inside the file, only text fragments, each carrying a coordinate saying where it sits on the page. What you see as a neat grid is an arrangement your eye interprets and the file does not describe.
So any tool or spreadsheet that reads the text without also reading those coordinates is guessing. Sometimes it guesses well. Often it does not, and the failure is quiet: the spreadsheet looks plausible and the numbers are wrong.
These are the things that actually break, and what each one tells you about whether a converter is doing real work or hoping.
Getting a clean conversion
- Check that your statement has a text layer. If you can select a row of text in your PDF reader, it does. If nothing selects, the statement is a scan and needs optical character recognition rather than extraction, because no cleverness will find text that is not there.
- Look for a tool that reads text position, not just text. The distinction is the whole game: a converter working from coordinates can rebuild the columns, and one reading a stream of characters cannot.
- Map the columns yourself the first time. A heading that says 'Paid out' is a debit column and 'Paid in' is a credit column, and a good tool recognises both, but check that it did. A wrong mapping produces a file that imports without complaint and is wrong anyway.
- Confirm the direction of the money. A debit should come out negative and a credit positive. If your converter exports both as positive numbers, every total you build on top of it will be wrong.
- Verify the arithmetic before you rely on the result. If the statement has a balance column, the transactions should add up to it row by row. That one check catches almost every extraction error, because a dropped or duplicated line breaks the running total immediately.
- Only then import the file into your accounting software, and reconcile the closing balance against the statement's own closing balance.
Worth knowing first
- Scanned and photographed statements are a different problem entirely. They need OCR, which is slower and less accurate, and worth checking more carefully than a straightforward extraction.
- Right-aligned amount columns are harder than they look. Because '6.80' and '3,100.00' end at the same point but start at different points, a naive extractor sees a ragged edge and may read it as two separate columns.
- Dates are genuinely ambiguous. 03/04/2026 is either 3 April or 4 March, and the file does not say which. A good tool reads the whole column looking for a day above the twelfth, which proves the format, and tells you when it cannot tell rather than silently picking one.
- Multi-page statements repeat the column headings and a page footer on every page. Left in, those lines become junk rows in the middle of your data, and they shift every row below them.
- Some statements also carry 'balance brought forward' and 'balance carried forward' lines. They hold a number in the balance column but they are not transactions, and imported into a ledger they appear as entries that never happened.
Try it on your own statement
The file is read by your browser — it never leaves your device.
Open the converterQuestions
Why did my dates turn into numbers like 45012?
Excel stores dates as a serial number counting days from its own epoch, and it applies that reading to anything that looks vaguely date-like. An extraction that writes 03/04/2026 into a cell can be taken as a date and re-displayed as a serial number. Writing dates in ISO form, such as 2026-04-03, before export is the reliable fix, because an ISO date cannot be misread.
Why do my amounts end up in the wrong column?
Because the columns were inferred from spacing rather than measured. Statements use two conventions: one signed amount column, or separate debit and credit columns that are each empty on most rows. A converter assuming the simple case shifts everything sideways on a statement using the other. Check which convention your statement uses, and check that each amount column came from the heading you expect.
Why is one transaction split across several rows?
Long payee names wrap onto a second line in the PDF, and a line-based extractor treats that second line as a new row. It is a continuation of the description above it, not another transaction. A good converter folds it back into the row it belongs to, because the wrapped part is often the reference number you reconcile against.
Can I just copy and paste, or use 'Save as' instead?
Sometimes, for a simple statement with no wrapped descriptions and a single amount column, copying and pasting works fine. It stops working the moment the layout gets interesting, and crucially it fails without telling you. If you are reconciling accounts, a method that can be silently wrong is not worth the time it saves.