The 70% line: which OCR words you actually need to check

Thirty-four supplier invoices, scanned, run through OCR, amounts typed into a spreadsheet in one sitting. Two weeks later the accountant asks why row 19 says 47,800 when the physical bill in the file says 41,800.

The OCR did not fail. It read a 1 as a 7, reported 89% confidence on that block, and nobody looked twice at a block reporting 89%.

That is the gap the confidence numbers in Advanced OCR exist to close — but only if you read them for what they actually say.

The three numbers on screen

After a run, each recognised block sits in its own editable box with a small label above it: the block type and a percentage. paragraph · 94%. line · 61%. Anything below 70 gets an amber border instead of the usual grey one, so a page of amber boxes is visible at a glance without reading a single word.

Above the blocks there is a page-level line that reads something like:

Some words on this page need checking — they are highlighted. Page confidence 87% · 14 of 212 words need checking

Three separate pieces of information there, and people routinely read only the middle one.

The page confidence is a length-weighted average across every word on the page. Length-weighted matters: a nine-letter word counts for more than a stray comma, which stops one misread punctuation mark from dragging the whole page down. It does not mean 13% of the words are wrong.

The count — 14 of 212 — is the honest one. That is how many individual words fell below 70. It is a to-do list with a number on it.

The summary sentence is a threshold reading of that count. Under about one word in eight, it says the page recognised cleanly. Past that, it tells you some words need checking. Past roughly one word in three, it says much of the page was hard to read and suggests a different preprocessing mode, because at that point the problem is the scan and not the proofreading.

What confidence is not

This is the part that costs people money.

Confidence is the engine's certainty about the character shapes it matched. It is not a check on whether the result makes sense, and it is definitely not a check on whether the result is true.

A 1 printed in a narrow serif font genuinely looks like a 7 with a short flag. The engine matches it, finds a good fit, and reports high confidence — because by its own measure it is confident. Same story for these:

None of these produce low confidence. They produce a wrong character the engine is perfectly happy with. Low confidence tells you where the engine struggled; it cannot tell you where it was cheerfully mistaken.

The tokens the tool deliberately refuses to fix

There is automatic tidying after recognition — joining words broken across a line by a hyphen, collapsing stray whitespace, that class of repair. It improves ordinary prose.

It is switched off for anything that looks like a number, a date, an identifier, an amount, an email address, a reference code, a currency figure or a hyphenated proper name. Those tokens pass through untouched, exactly as recognised, even when a "fix" looks obvious.

That is deliberate, and it is the right call. A plausible-looking correction to an account number is the correction most likely to be wrong and least likely to be caught. Better to hand you the raw reading than a tidied one you would trust without checking.

The consequence for you is direct: the fields with the highest cost of error are precisely the fields no automation touched. Nobody has looked at them but the recognizer. You are the second pass.

A checking routine that takes four minutes instead of forty

Reading the whole page against the original defeats the purpose of running OCR. Check by risk instead of by order.

1. Every digit that leads to an action. Amounts, GSTIN, account and IFSC numbers, invoice numbers, dates, phone numbers, PIN codes. Read these character by character against the scan. Not word by word — character by character, because 41,800 and 47,800 look identical when skimmed.
2. Every amber-bordered block. These are the engine's own admissions. Faint print, tight kerning and decorative fonts are the usual causes, and they cluster — one bad region often produces several.
3. Proper nouns. Names of people, firms and places have no dictionary to fall back on, so a misread letter stays misread.
4. Everything else, skimmed once for sentences that stop making sense.

Do the fixing in the boxes on screen rather than in a text editor afterwards. Your edits are kept separately from the original recognition and are applied when you export, so the .txt, .md, .json and Word (.docx) downloads all carry your corrections. Export first and correct later and you will be doing it twice.

When a good score is the warning sign

Occasionally a page returns a respectable confidence figure and the text underneath is meaningless — a run of clean-looking symbols and short fragments that no human wrote. This happens when the page preparation went wrong rather than the recognition: the engine was handed a badly thresholded image and confidently matched shapes in the noise.

Internally this is caught by measuring what share of the characters are plausible letters and digits rather than punctuation soup, and it is one of the triggers for a retry in Advanced mode. But if you are running in Fast mode, nothing retries for you.

The tell is simple. If a page you expected to be difficult comes back suspiciously clean, read three lines of it. Two seconds, and it catches the failure mode that a percentage cannot.

Getting a better number instead of proofreading a bad one

When the amounts column on an invoice keeps coming back doubtful, the usual cause is scale. The whole page is rendered down to fit your device's working resolution before recognition, and small digits lose the most in that reduction.

Crop the region you actually need with Image Crop and run that alone. A tight crop of one column fills the same pixel budget as the whole sheet did, so the digits arrive at the recognizer several times larger. It is the single most effective thing you can do for a table of figures, and it takes about twenty seconds.

Two other routes are worth knowing. If the PDF's text turns out to be selectable after all, skip recognition entirely — PDF Text Extract reads the embedded text layer exactly, with no confidence question to answer. And when you need a whole scanned document turned into an editable Word file in one go rather than block by block, PDF OCR is built for that shape of job. Both live alongside the rest of the scanner tools.

If you are automating this

The JSON export carries per-block geometry and confidence alongside the text, which means a script can flag low-confidence blocks for human review instead of a person eyeballing a page. Pair that with the rule above — treat every token containing a digit as unverified regardless of its score — and you get a review queue that is short enough to actually be worked through.

The general principle survives outside this tool and is worth holding onto: OCR confidence tells you where a machine hesitated, never where it was wrong. The digits are always yours to check.