Bank statement OCR, and when you do not need it

Before you look for a bank statement OCR tool, do this: open the PDF and try to select a line of text with your cursor.

If the words highlight, your statement already contains its text. Nothing needs recognising. Running OCR on it is not a neutral step, it actively makes the file worse, because it throws away exact characters and guesses them back from pixels.

If your cursor just draws a rectangle over the page, then yes, you have a scan, and OCR is the only way in.

That five second test decides everything else on this page.

The two kinds of PDF that look identical

A PDF is a container. What is inside decides what a converter can do with it.

A digital PDF stores the string 1,204.55 along with the font and the exact coordinates where it sits. Extraction reads that string. There is no interpretation and no confidence score, because there is nothing to interpret.

A scan stores a photograph of the page. Every character has to be inferred from arrangements of dark pixels, and the engine returns its best guess. On a clean 300 dpi scan of a modern statement that guess is right almost all of the time. Almost is the operative word.

The errors OCR makes are the errors a statement cannot absorb

OCR is good at prose, because prose has redundancy. Misread one letter in a paragraph and you can still read the sentence. A column of amounts has no redundancy at all: every character carries full meaning, and nothing in the surrounding text tells you a digit is wrong.

Misread	Effect on the number	Would you notice?
0 read as 8	1,204.55 becomes 1,284.55	No
5 read as 6	65.00 becomes 66.00	No
Decimal point lost	12.99 becomes 1299	Only if you scan the column
Minus sign dropped	A payment becomes a deposit	Only at the total
1 read as 7	1,150.00 becomes 7,150.00	Probably
Thousands comma read as a period	1,204.55 becomes 1.204.55	Depends on the parser

The bottom two are loud. The top four are silent, and silent is what matters, because a file you cannot check is a file you have to trust.

The bigger problem has nothing to do with characters

Here is the part that gets skipped in every article about statement OCR: most conversion errors are not character errors. They are layout errors, and they happen at the same rate on a perfect digital PDF.

A bank statement has no table structure inside the file. There are no cell boundaries, no column tags, no rows. There is text at coordinates, and the columns exist only because a human eye groups things that line up. Software has to rebuild that grouping, and it goes wrong in three specific ways:

An amount lands one column over. Debit and credit columns often sit 40 points apart. A refund printed slightly left of where the credits usually start gets read as a debit. The character was perfect. The sign is now inverted.

A wrapped description splits a transaction. Long merchant strings wrap to a second line. If the parser treats that second line as a new row, you get a phantom transaction with no amount and a real one missing its description.

A page break drops a row. Headers, footers, and the “continued” line at a page boundary all sit in the same coordinate space as the data. Strip too much and you lose the transaction printed next to it.

None of this shows up when you look at the spreadsheet. Three hundred rows all look plausible.

The check that actually proves the conversion

A bank statement carries its own checksum, and almost nobody uses it. Each row’s closing balance is the previous balance plus that row’s movement. Walk the balance column from the opening figure and every row has to land exactly on the printed value.

If a digit was misread, the chain breaks at that row. If an amount landed in the wrong column, the chain breaks. If a row was dropped, the chain breaks. One arithmetic pass catches the errors that no visual review will.

This is why our converter runs that check automatically and tells you which rows do not follow, and it is a better question to ask a conversion tool than which OCR engine it uses. An engine’s accuracy is a claim. A balance that reconciles is proof.

If your statement has no running balance column, and some credit card statements do not, then reconcile against the printed totals instead: sum the debits, sum the credits, and compare with the summary box on page one.

When you genuinely need OCR

Four cases, and they are all about where the file came from rather than what is in it:

• A statement from a closed account, mailed as paper and scanned at home.
• A photograph taken on a phone at a branch counter.
• A fax, which still happens in lending and still arrives at 200 dpi.
• A statement printed to paper and re-scanned, which some employers and landlords insist on.

For those, OCR quality is worth caring about. Scan at 300 dpi in greyscale rather than black and white, keep the page flat, and expect to check the balance chain by hand.

What to do with the statement you have

Run the selection test. If the text selects, use a converter that reads the text layer directly and skip OCR entirely, because there is no upside to it. If nothing selects, you need OCR, and you need the arithmetic check more than usual.

Either way the last step is the same, and it is the only one that tells you whether the file is right.