In this guide 6 sections
OCR misreads invoices when the image is poor or the layout is unusual. Skewed phone photos, stamps over totals, dot matrix prints, wrapped item descriptions and handwritten corrections cause most errors. A sound setup flags low confidence fields in a review queue, so a person checks them before anything posts.
Phone photos are the biggest source of bad reads
A vendor snaps a bill on a desk and sends it over WhatsApp, with the page tilted, one corner in shadow and a flash patch swallowing the total. Engines expect straight lines.
A tilted page bends those lines, and characters near the far edge smear into their neighbours until a 1 reads as a 7. Chat apps make it worse by compressing the image. Fine strokes vanish.
Ask senders for a flat scan or a PDF export where you can. When photos cannot be avoided, a good pipeline straightens the page, crops the borders and lifts the shadows before it reads a single character.
- Tilt of more than a few degrees
- Shadow across one half of the page
- Flash glare over the total
- Chat apps shrinking the image before it reaches you
- Fingers or a desk edge inside the frame
Stamps, handwriting and dot matrix break the usual patterns
A round company stamp pressed over the grand total is a classic trap. The ink overlaps the digits, so the engine reads half a number and half a seal in one go. Receiving stamps do the same to quantity columns on delivery notes.
Dot matrix prints from older billing systems leave gaps inside each letter, so a zero starts to look like a six. Carbon copies are fainter still. The third copy usually reads worst of all.
Handwritten corrections are harder again. A supplier strikes out a rate and writes a new one beside it, and the engine may read the struck figure, the new figure or both. Faded thermal paper from card machines and fuel receipts is another culprit. The print fades within months. Scan such slips on the day.
Layout is where line items go wrong
Totals are easy because they sit in a predictable spot. Line items are the hard part. A long description wraps onto a second row, and the engine treats that row as a fresh item with no quantity and no rate.
Some vendors print the tax block beside the item table. Others merge the unit column into quantity or push page two of the bill onto a sheet with no header at all. A template that suits one supplier fails for the next.
Find out which fields fail before you blame the engine. Usually it is the same three or four fields, across the same handful of vendors, and a simple tally will show it. Do the tally.
- Wrapped descriptions read as extra items
- Unit of measure merged with quantity
- Tax block placed beside the table
- Page two carrying items but no header
- Credit notes printed in the invoice format
What the review queue should show
No engine reads everything right. The fix is to show the human what to doubt. Every extracted field carries a confidence score, and anything under your threshold lands in a queue where a person confirms or corrects it. The reviewer needs the original image beside the extracted value, with the doubtful field highlighted in place. Hunting through a full PDF wastes the minutes you hoped to save.
The queue needs an owner. Someone in accounts decides how long a bill may wait, who clears it during leave, and which vendors jump the line before Friday’s payment run.
Add arithmetic checks as well. If the line totals do not add up to the invoice total, flag the bill even when every field looked confident. Flag any quantity that disagrees with the purchase order too. Both catches are cheap.
- Image on the left, extracted fields on the right
- Doubtful field highlighted in place
- Reason shown, such as total mismatch or low confidence
- One key to accept, one to correct
Feed corrections back and track the failures
Every correction is a lesson. Store the original read with the fixed value. After a month, sort by vendor and field to see where the engine keeps stumbling and where a person keeps fixing the same thing by hand.
Some failures belong to the vendor. Send the worst offenders a short note asking for a clean PDF. Two or three polite requests can remove more errors than a month of tuning the engine.
Start this week by pulling twenty recent bills that someone keyed by hand. Mark each hard field. Note the cause.
OCR failure log
This log has a line for every misread field. Columns cover vendor, document type, field name, what the engine read, the correct value, the likely cause (tilt, stamp, dot matrix, wrapped line, handwriting) and who fixed it. A summary block at the foot counts failures by cause and by vendor.
Open a blank worksheet to printQuestions owners ask
Is a better scanner enough to fix OCR errors?
It helps with clean paper. It does not help with stamps, handwriting or odd layouts, which need field checks and a review queue. A scanner at a sensible resolution is still a good first step.
What confidence threshold should send a field to review?
Start cautious and send plenty for review. Loosen the bar field by field once your correction log shows the engine is reliable there. Amounts and dates deserve a stricter bar than free text notes.
Why does the same vendor fail again and again?
Usually the layout or the printer is to blame. A dot matrix bill or a table with merged cells fails every time. A rule for that vendor, or a clean PDF from them, fixes it.