Converting a scanned bank statement to Excel — what OCR gets wrong and how to fix it

A digital statement downloaded from your bank contains real text. A statement you scanned, photographed, or received as a fax-style PDF from a client contains only pixels. Excel's PDF import, copy-paste and most "PDF to Excel" sites read nothing from it. You need OCR — optical character recognition — and then you need to know where OCR lies.

What OCR does with a statement

The engine finds text on the image, recognises each character, and records where on the page it sat. A bank statement converter then has to rebuild the table from those positions: which words are on the same line, which line is a new transaction, which column an amount belongs to. Good engines (the one behind Rowvert is document-specialised) do this well on clean scans; all of them make the same handful of mistakes on bad ones.

The five classic OCR errors on bank statements

1. Digits swapped for look-alikes. 0↔O, 1↔l/I, 5↔S, 8↔B. An amount of 1,580.00 becomes 1,5B0.00 — obviously wrong — or, worse, 1,530.00, which looks plausible.
2. Decimal points and commas dropped. 1,250.00 → 125000 or 1250 00. A thousands separator read as a decimal point moves the amount by a factor of a thousand.
3. Minus signs and brackets lost. -86.20 → 86.20. A debit becomes a credit.
4. Columns merged. On a skewed scan, an amount printed under "Money out" is positioned under "Money in". Everything on that row is right except its sign.
5. Lines merged or split. Two transactions on adjacent lines read as one; a two-line description read as two transactions, the second with no amount.

How to catch all five

Use the statement's own arithmetic. The running balance printed on each line is an independent record of the same numbers, so any OCR error in an amount shows up immediately as a mismatch between the amount and the balance movement:

balance(this row) − balance(previous row) must equal credit − debit

Run that check per row (see how to reconcile a bank statement in Excel), or use a converter that does it automatically and flags the rows that fail. In Rowvert, rows read from an image that don't fit the running balance are marked Verify — read from image; you look at those rows against the PDF, correct or remove them, and download. Rows that pass the check are, by construction, right — OCR would have had to make two compensating errors on the same line.

Getting a better scan in the first place

Most OCR errors come from the image, not the engine:

• 300 dpi, black and white or greyscale. Phone photos work if the page fills the frame and is flat.
• Straight. A 2° skew is enough to push amounts into the neighbouring column. Most scanner apps deskew automatically; use that.
• Whole page, including the header. The opening/closing balances and the column headings are what let the converter reconcile and label columns.
• One statement per file, or at least one account per file.
• No highlighter or pen marks across amounts.

Which statements scan worst

• Thermal-paper ATM mini statements (faded, no headers).
• Statements with a coloured background or watermark behind the table.
• Photocopies of photocopies.
• Very old statements in a proportional font where digits are narrower than letters.

For these, expect to verify a few rows by hand — but you will know which rows, which is the whole point.

Is OCR accurate enough for accounting?

For digital PDFs: extraction should reconcile 100% of the time; if it doesn't, the converter is at fault, not the document. For good scans: expect 98–99% of rows to pass the balance check on the first try, and the rest to be flagged. For poor scans: 90–95%, with the rest flagged. What you should never accept is a converter that returns a spreadsheet from a scan without telling you which rows it is unsure about.

Try it: upload a scanned page on Rowvert — 1 page a day is free without an account.