Bank Statement OCR Errors: Where They Come From and How to Catch Them

By Tarun Vashishth · Published 2026-08-25

If a bank statement converter supports scanned PDFs, it's doing optical character recognition — looking at pixels and guessing which characters they represent. That's a genuinely useful capability this tool doesn't have (see what's actually in a PDF for why), but it comes with a specific, well-understood category of error that's worth knowing how to spot.

Why OCR makes character-level mistakes at all

OCR is pattern recognition on pixels, not a lookup of embedded text. A native PDF's text layer says, unambiguously, "this glyph is the digit 8." A scanned image just has a blob of dark pixels shaped roughly like an 8, and the OCR engine has to infer what character produced that shape — from font rendering, scan resolution, compression artifacts, and print quality. Most of the time it infers correctly. The failure cases cluster around characters that are visually similar to begin with.

The classic confusion pairs

0 and O — a zero and a capital O are often nearly identical in many fonts, especially at low resolution.
1, l, and I — the digit one, lowercase L, and capital I can be visually indistinguishable in certain fonts and sizes.
5 and S, 8 and B, 2 and Z — similar shapes under scan compression or a slightly skewed page.
Decimal points and stray marks — a speck of scan noise or a compression artifact can be misread as a decimal point, or a real decimal point can be missed entirely.

None of these are exotic edge cases — they're the specific character pairs OCR engines have always struggled with, scanned bank statement or otherwise. In a description field ("O'Brien's Cafe" vs. "0'Brien's Cafe"), a misread character is annoying but harmless. In an amount field, a single misread digit changes the value — sometimes subtly enough to look plausible.

Why a subtly wrong amount is worse than an obviously wrong one

An amount that reads as complete gibberish gets noticed immediately. The dangerous case is a plausible wrong number: $128.00 misread as $728.00 because a 1 was read as a 7 under scan skew, or $1,500.00 read as $1,900.00 from a smudged 5. Both are perfectly reasonable-looking transaction amounts on their own — nothing about them looks like an error until you check them against something.

The check that catches it regardless of cause

This is exactly what reconciliation against the statement's own printed totals is for, and it doesn't care whether the error came from OCR misreading a scanned page or a text-extraction bug on a native PDF: if opening balance plus every extracted transaction doesn't equal the statement's printed closing balance, at least one amount is wrong, full stop — regardless of which technology produced the extraction. See the fullverification guide for the complete procedure, which takes a few minutes and works on the output of any converter, OCR-based or not.

What this tool does instead

Because this converter reads a PDF's embedded text layer rather than performing OCR, it doesn't have the 0/O or 1/l class of error at all — the character is read from the file's own text data, not inferred from pixel shape. The trade-off, stated plainly: it can't process a scanned or image-only statement, because there's no text layer to read. If your statement is a scan, an OCR-based converter is your only option, and reconciling its output against the statement's printed totals afterward is the practical safeguard.