Bank statement OCR that checks its own work

The usual OCR problem

General-purpose OCR returns text and a confidence score. For prose, a wrong letter is a typo. For a bank statement, a wrong digit is a wrong balance, and confidence scores do not tell you which digits are wrong. A statement is also not prose: it is a table, and OCR text has to be put back into columns before any of it means anything.

The pipeline

1. Orientation. Each page is turned upright. Upside-down, sideways and PDF-rotated pages are detected, and the previous page's orientation is tried first, so an upright document costs nothing extra.
2. Recognition. Tesseract, compiled to WebAssembly, reads the page in your tab with word coordinates and skew correction. A small pool of workers runs in parallel, sized to your device.
3. Layout. Words are grouped into the transaction table using recognised headers (about 15 languages) and the columns where numbers and dates sit. Repeated headers, footers and summary boxes are set aside.
4. Arithmetic. Every row is tested against the printed running balance. Disagreements trigger a re-read of only the affected pages with different settings; the result that reconciles best is kept.
5. Repair, only with proof. A lost decimal point or thousands separator is restored only when the resulting number is exactly the one the balance requires. Otherwise the fix is offered, never silently applied.

Why checking beats confidence scores

A statement contains redundancy that a confidence score cannot use: if the opening balance is 1,000.00 and the next printed balance is 3,454.80, the amount in between must be 2,454.80. When OCR read 245.48 instead, the mismatch is detectable and the correct value is known. That is a proof, not a probability. The mechanism is described step by step, with numbers, on how verification works.

Where OCR still fails

• Dates. No arithmetic proves a date. A 13 read as 18 can pass every check.
• Descriptions. Merchant names are not verified; a misread letter stays a misread letter.
• Bad images. Heavy blur, glare, shadows over text and very low resolution can defeat recognition. Affected rows are flagged and the statement shows Needs review.
• No balance column. Without a running balance or printed totals, there is nothing to check against, and the statement is Unverified.

Where the OCR runs

In your browser tab. The OCR engine, its WebAssembly core and the English language model are served from this site, so reading a scan makes no third-party request. If you choose another OCR language, that language's model file is downloaded once from a public CDN. No statement image or text is sent anywhere for OCR. Learn more on converting without uploading.

Practical tips

• Scan flat, in good light, at 200 dpi or higher. A flatbed scan beats a phone photo, though a steady photo in even light works.
• Prefer the bank's own PDF or a structured download (OFX, MT940) when you can get one: it needs no OCR at all.
• Pick the OCR language that matches the statement before loading it.

Start with scanned statement to Excel, or open the app and try a scan.