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 character-accuracy percentage describes a particular test set and measurement method. It does not tell you whether the amounts in your client's creased statement are correct. Errors may be clustered around a poor scan or repeated layout, so treating every character as an independent coin toss would give a misleading estimate of document accuracy.

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

The statement carries its own answer key

Many bank statements declare an opening balance and a closing balance. Between them sit the transactions. So:

opening + sum(amounts) = closing

If this equation fails, investigate missing rows, signs, decimals and the balances themselves. If it passes, the net movement agrees — but offsetting errors can cancel out, and incorrect descriptions or dates do not necessarily change the sum. Inspect those fields and retain the original scan.

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: a difference of twice a transaction amount is a reason to investigate its sign against the original, rather than automatically changing it.

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 whose checked arithmetic agrees is marked balanced; still review unclear fields. 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.

On NoRekey a scanned page costs the same as a digital one, and 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.