If your bank statement is a scan — a paper statement fed through an office scanner, a PDF a client photographed on their kitchen table, an old archive statement the bank only keeps as images — every free conversion method stops working at once. Excel's PDF import finds nothing. Copy-paste selects nothing. The document looks like a statement to you, but to software it's a picture.
Getting a picture into a spreadsheet needs OCR — optical character recognition. And here's the uncomfortable truth this article is really about: generic OCR is good at words and quietly bad at numbers, and bank statements are made of numbers where a single wrong digit matters. The fix isn't better squinting at the output. It's verification. We'll cover both.
Why scans defeat the free methods
A digital PDF contains text: characters with positions, fonts, sizes. Excel's Data → Get Data → From PDF reads that text layer and reconstructs tables from it. A scanned statement has no text layer — it's pixels. Excel scans it, reports no tables, and that's the end of the road. The same applies to copy-paste, to Google Sheets' importers, and to most "PDF to Excel" utilities, which are text-layer tools wearing a general-purpose name.
Some banks also export "digital" PDFs that are secretly images — statements assembled from page scans on the bank's side. If you can't select the text with your cursor, you have a scan, whatever the file extension says.
Where OCR goes wrong on financial documents
OCR turns pixels back into characters by pattern recognition, and at typical scan quality the patterns that collide most are exactly the ones a statement is made of:
- 1 ↔ 7 (especially with the European crossed 7 or a serif 1), 0 ↔ 8, 5 ↔ 6, 3 ↔ 8. One confused digit turns €1,540.00 into €7,540.00 without making the row look damaged.
- Comma vs period. At 200 DPI they're a few pixels apart. On statements from banks using decimal commas — most of Europe, including layouts like Tatra banka's or mBank's "1.234,56" — a misread separator shifts an amount by a factor of a thousand.
- Minus signs and negative formats. A debit shown as "−45.00", "45.00−", "(45.00)" or "45.00 D" depending on the bank. Generic OCR reads the characters but doesn't know they all mean the same thing, and scanner noise can add or delete a minus outright — flipping a payment into a deposit.
- Column drift. A skewed page tilts the amounts column until row 30's debit sits under row 31's credit. Everything reads "correctly" — into the wrong fields.
- Multi-line descriptions. Payee, reference and type spread over three lines become three phantom transactions, or glue themselves to the wrong amounts.
The pattern across all five: OCR errors on statements don't look like errors. A misread word is visibly gibberish; a misread number is just a different number. That's why "it looks fine" is the most dangerous sentence in statement conversion.
The only honest accuracy test: the statement's own arithmetic
Every bank statement ships with its own answer key, printed right on it: the opening balance, plus every credit, minus every debit, must equal the closing balance. Many statements also print running balances or per-page subtotals — more checkpoints for free.
This means a converted statement can be proven right or wrong, not eyeballed. If the extracted rows satisfy the balance equation, every amount, every sign and every decimal separator was read correctly — a wrong digit anywhere breaks the sum. If reconciliation fails, you know before the data touches your books, not at tax time.
So when you evaluate any OCR tool for statements, ignore the claimed accuracy percentage — 99% accuracy on characters still means several wrong amounts on a 300-transaction statement — and ask one question instead: does it reconcile the output against the printed balances, per file, and show you the result? Extraction without reconciliation is confident guessing. (This check is the core of how Statement Mill works: every export is verified against the statement's own balances before you download it, scans included.)
Converting a scanned statement, step by step
1. Get the best image you reasonably can
OCR quality is downstream of image quality. From a scanner: 300 DPI, grayscale or color, straight on the glass. From a phone: flatten the page, fill the frame, shoot from directly above, and keep shadows off the numbers column — a shadow across amounts is the classic cause of a failed reconciliation. Don't waste time beyond that; the verification step will tell you if the image was good enough.
2. Run it through a converter built for statements
Upload the scan to a statement-specific converter — not a generic "PDF to Excel" site. The difference is everything from the previous section: financial OCR that expects decimal alignment and negative formats, layout logic that folds multi-line descriptions back into one row and follows tables across pages, and reconciliation at the end. With our converter this is one drag-and-drop; the first three pages need no signup, so you can test with your ugliest scan before creating an account.
3. Check the verification result — then trust it
If the balances reconcile, the numbers are right; download your Excel, CSV or QuickBooks file and move on with your day. If a section fails to reconcile, don't hand-fix random rows: retake or rescan that page and run it again. A failed check almost always means the image, not the arithmetic.
What about running OCR yourself?
If you're technical, free OCR engines like Tesseract will happily read a statement scan — and hand you a flat text stream with all five failure modes above intact and no verification. Rebuilding table structure, normalising regional number formats, folding descriptions and reconciling balances is precisely the hard part; the character recognition was never the product. It's a fun weekend project and a poor monthly workflow. For a one-off, a purpose-built converter's free tier costs less than the weekend.
The short version
Scans and photos can't be converted by Excel or copy-paste at all, and generic OCR converts them plausibly rather than correctly — its errors are invisible by design. The way out isn't a more careful reading of the output; it's arithmetic. Use a converter that reconciles every file against the statement's printed balances, and a scanned statement becomes exactly as trustworthy as a digital one: try it with your worst scan — three pages, no signup, and the balance check will tell you honestly whether it worked.