Quality & InspectionFree referencePDF, Excel, Word export

OCR Confusable Characters Reference: Pairs, Risky Fields and Validation Rules

OCR rarely fails randomly. It confuses the same look-alike characters again and again, and those mistakes land in the fields where they cost money: amounts, part numbers and invoice numbers. This list shows the pairs and the validation that catches each.

Download:

Printed as	Often misread as	Typical cause	Fields most at risk	Validation or fix
0 (zero)	O (letter)	Similar round shapes, slashed zero fonts	Part numbers, PO numbers, serial numbers	Apply numeric-only pattern to numeric fields and replace O with 0 there
O (letter)	0 (zero)	Same as above	Alphanumeric codes, supplier IDs	Check against master list of valid codes
1 (one)	l (lowercase L) or I	Vertical strokes in sans serif fonts	Invoice numbers, quantities	Numeric field pattern, then fix l and I to 1
l (lowercase L)	1 or I	Same as above	Descriptions, alphanumeric references	Dictionary check on description words
I (capital i)	1 or l	Same as above	Part numbers with prefixes	Validate prefix against part master
5	S	Curved top and bottom, low resolution	Invoice numbers, tax IDs	Checksum or format check for tax IDs
S	5 or 8	Same as above	Alphanumeric references	Pattern check per field
8	B or 3	Closed loops fill in on poor scans	Amounts, part numbers	Recompute totals from line amounts to expose errors
B	8	Same as above	Part number suffixes, lot codes	Lookup against allowed suffixes
2	Z	Similar diagonal stroke	Dates, codes	Date validation rejects impossible values
6	G or b	Loop and tail merge in small print	Amounts, reference numbers	Totals reconciliation and format check
9	g or q	Loop and tail similarity	Amounts, reference numbers	Totals reconciliation and format check
4	A or 9	Open top on faint print	Dates, part numbers	Date range check and part master lookup
7	1 or T	Faint horizontal bar	Dates, amounts	Date range check and totals reconciliation
rn	m	Letters touch at small sizes	Supplier names, descriptions	Fuzzy match to vendor master
m	rn	Letters split at small sizes	Supplier names, descriptions	Fuzzy match to vendor master
cl	d	Gap between letters closes up	Descriptions, names	Dictionary or vendor master check
vv	w	Adjacent letters merge	Supplier names	Fuzzy match to vendor master
. (decimal point)	, (comma)	Both are small marks at the baseline	Amounts, quantities, unit prices	Detect locale per supplier, recompute line extension and compare to total
, (thousands comma)	. (decimal point)	Same as above, plus European formats	Amounts in Europe and other regions using decimal commas	Store a decimal separator setting per vendor or country
- (hyphen)	_ or missing	Thin stroke lost during binarization	Part numbers, invoice numbers	Check pattern including separators
/ (slash)	1 or l	Thin diagonal stroke	Dates, tax invoice numbers	Date pattern validation
$ or other currency symbol	S or 5	Vertical line through symbol is lost	Amount lines	Match currency code to PO or vendor currency
Z	2	Similar diagonal stroke	Part numbers and codes	Pattern check per field
D	O or 0	Rounded forms on faint print	Part numbers, codes	Lookup against master data

These are patterns seen across OCR engines, not engine specific. Which pairs matter most depends on font, scan quality and engine. Measure your own error confusion matrix on a sample of documents before writing correction rules.

Want a validation rule set for your documents?

Optional: an expert can review a sample of your OCR output and propose field validations.

Optional. The tool and every export work without this. No spam.

How to use the list

Search for the character or the field you are worried about, then apply the matching rule in your capture workflow. Treat the table as a starting list for an exception rule set, not as blanket find and replace. Blind replacement of O with 0 across a document damages names and descriptions, so apply corrections only to fields whose type you know to be numeric or pattern based.

Field type first, then correction

The strongest defense is a typed field. If the invoice number field is known to be digits only, any O, l or I found in it is almost certainly a misread. If a field must match a master list, such as a part number or vendor ID, a lookup is better than a character rule because it rejects wrong values even when no look-alike is involved.

Numeric fields: map look-alike letters to digits
Master data fields: lookup and fuzzy match
Dates: parse and range check
Amounts: recompute from lines and compare
Tax IDs: use the checksum for that country

Decimal and thousands separators

The costliest confusion in AP is not a letter but a dot versus a comma. A value like 1.250 could be one thousand two hundred fifty or one point two five. Keep a decimal separator rule per vendor or country, and always compare the sum of recomputed line extensions to the stated total. A mismatch is a clean signal to send the document to human review.

Common mistakes

Teams often try to fix quality problems with correction rules when the scan itself is the problem. Better resolution, deskew and contrast do more than rules. Another mistake is trusting engine confidence alone: a high confidence 8 that should be a B still passes. Combine confidence with validation against business data.

Frequently Asked Questions

Why does OCR confuse 0 and O?

The shapes are nearly identical in many fonts, and at low resolution the difference in width or a slash disappears. Engines use language models to guess, but part numbers and codes have no language context, so the guess is often wrong.

Should I auto-correct OCR output with replace rules?

Only on fields with a known type. Replacing O with 0 in a numeric invoice number is safe, while doing so across full text damages names. Prefer validation against master data and send failures to a person.

How can I detect a misread amount?

Recompute each line as quantity times unit price, sum the lines, add tax and freight, and compare to the printed total. Any difference beyond rounding signals a misread digit, a decimal separator error or a missed line.

Does a better OCR engine remove these errors?

It reduces them, but no engine removes them. Image quality, fonts and layout matter as much as the engine. Plan for validation and review as part of the process whatever engine you use.

If you want checks like these run against your own vendor and part master data, Netray can build validation that works with your ERP, on your own infrastructure.

Talk to an Expert Explore More Free Tools

Related Tools

Developer Tools

More Quality & Inspection tools

See all

Back to All Tools