Why copying a bank statement into Excel never works
Copy and paste from a PDF statement gives text that will not sum, dates that will not sort, and silently missing rows. Exactly what breaks, and what to do instead.
Selecting a statement in a PDF viewer, copying, and pasting into Excel is the obvious first attempt. It fails in four specific ways, and the fourth is the dangerous one.
1. The amounts arrive as text
1,234.56 pastes as a string, not a number. SUM() over the column returns zero, or ignores the cells entirely. You can see the figures; Excel cannot add them.
Worse across Europe: 1.234,56 may be read as text, or silently reinterpreted as 1.23456, depending on your locale.
2. The dates do not sort
04/01/2026 becomes text too, so sorting puts the 10th before the 2nd - it is sorting alphabetically. Any monthly analysis built on that column is wrong from the first step.
3. The columns land in the wrong places
A PDF has no columns. It has text positioned on a page, and the viewer guesses a reading order when you copy. Descriptions containing a comma split across cells. A long payee name pushes the amount into the next column. Separate debit and credit columns merge into one.
4. Rows go missing, and nothing tells you
This is the one that costs money. The selection stops at a page break, or skips a row sitting slightly outside the block the viewer detected. You paste 40 transactions where the statement had 43.
The spreadsheet looks completely normal. No gap, no warning, no error. You find out weeks later when an account will not reconcile.
What to do instead
Read the PDF's own text layer rather than a copy of what was on screen, then check the result against the statement's own arithmetic:
opening balance + sum of transactions = closing balance
That equality is the only thing that proves nothing was dropped. If it does not hold to the cent here, the conversion is flagged and you are not charged - a file that might be missing a row is worth nothing.