Why scanned bank statements go wrong, and how to prove the numbers anyway

A digitally generated statement PDF contains its numbers as text; extracting them is a matter of reading. A scanned or photographed statement contains its numbers as pixels, and extracting them is a matter of guessing well — which OCR does remarkably these days, and not perfectly. The problem isn't that scans fail; it's that they fail quietly, producing a clean-looking spreadsheet with one wrong digit in it. Here is exactly how that happens, and the one approach that catches it every time.

The seven ways a scan lies

Look-alike digits. 1 and 7, 0 and 8, 3 and 8, 5 and 6 — in a small serif font, at 200 dpi, through a slightly skewed scan, they're the same shape. An amount of £1,170.00 becomes £1,110.00 and nothing about the row looks off.

Lost decimal points. The smallest glyph on the page is the first to vanish. £45.60 reads as £4,560 or as 4560, and whether your spreadsheet then treats that as pounds or pence depends on what else went wrong.

Thousands separators. Commas and points swap roles across locales, and OCR doesn't know which locale the statement is in. 1.250,00 and 1,250.00 both exist in the wild.

Signs and markers. A minus sign is one pixel tall. "CR", "DR", "OD" and a trailing minus all encode direction, all differently, and all are small text next to big numbers. A refund loses its sign and becomes a purchase; an overdrawn balance loses its "OD" and becomes a credit.

Column drift. A skewed scan, or a bank layout with narrow gaps, and the balance column's digits get read as the tail of the amount column — or a wrapped description's second line gets read as a new transaction with no amount.

Stamps, folds and dot matrix. A "PAID" stamp across a figure, a fold through a row, a faint dot-matrix printout from a branch, a phone photo with a shadow across half the page. The OCR confidence drops and the engine's best guess gets more creative.

Page handling. Pages scanned out of order, a page scanned twice, a page skipped — the rows are all correct and the statement is still wrong.

Why accuracy percentages don't help

A tool that advertises 99% character accuracy sounds safe. A statement page has perhaps thirty transactions of nine or ten digits each — three hundred characters that matter. At 99% per character, the chance that a page has zero errors is 0.99³⁰⁰, which is about 5%. Put differently: nineteen pages in twenty will have at least one wrong digit. The percentage is measured on the vendor's test set anyway; the scan that matters is the creased one your client photographed on a kitchen table.

Accuracy on the input is the wrong measure. What you need is a check on the output.

The statement carries its own answer key

Every bank statement declares an opening balance and a closing balance. Between them sit the transactions. So:

opening + sum(amounts) = closing

If the extracted rows satisfy that equation to the penny, then every row is present, every amount is right, and every sign is right — because a single misread digit, a lost decimal, a flipped sign or a missing row breaks the arithmetic. The check doesn't care how the error was made. It catches the OCR misread and the skipped page with the same indifference.

Most statements also print a running balance on each row, which tightens the net: each balance must equal the previous one plus the amount. That locates an error to the exact row rather than telling you one exists somewhere on the page, and it can even identify certain errors: if the running balance disagrees with the amount by exactly twice the amount, the sign is flipped, and the statement itself has just told you so.

This is the check NoRekey runs on every conversion, scanned or not, before you see the result — how balance-checking works goes into the mechanics. A scanned statement that reconciles is marked balanced and you move on. One that doesn't is marked for review, with the rows in front of you, so the ninety seconds of attention go to the one line that needs it rather than to re-checking three hundred characters by eye.

Getting a better scan in the first place

The check catches errors; fewer errors is still better. Before you scan or photograph:

• Flat, straight, lit. A phone on a table over a flat page with no shadow beats a flatbed scan of a folded page.
• Resolution. 300 dpi for a scanner; for a phone, fill the frame with the page and don't zoom.
• Whole page. The opening and closing balances are usually at the top and bottom; a photo that crops them makes verification impossible. (Statements that declare no totals can't be checked this way, and an honest converter says so rather than inventing confidence.)
• One page per image, in order. Or one multi-page PDF; either way, keep the sequence.
• Keep the original. The scan is the evidence; the converted file is the working copy.

Scanned pages are harder work than digital ones and cost more to process — on NoRekey a scanned page uses three pages of allowance — but the output is held to the same standard: it reconciles or it's flagged. Scanned statement conversion covers what the OCR pipeline does with a bad photo, and the free plan is the place to try it on your worst one.

The principle generalises beyond us. Whatever tool you use on a scan, don't trust its confidence score; trust the arithmetic. The statement already knows what it adds up to.