The OCR problem nobody warns you about
Receipt parsing sounded like a solved problem until I actually built it.
Thermal paper fades in 60-90 days. Retailers print GST invoices in at least a dozen layouts. Some put the warranty period in the footer, some in the line item, some nowhere at all. And the one field you need most, the purchase date, appears as 07/03/25, 7-Mar-2025, or 070325 depending on the billing software.
Our first parser got 61% field accuracy. Shipping that would have meant users correcting the AI more often than trusting it, which kills the product.
What moved us past 90%: stop treating a receipt as text and start treating it as a document with regions. Merchant block, line items, totals, fine print. Classify the region first, extract second. Confidence scores per field, and anything below threshold gets flagged instead of guessed.
The boring lesson: accuracy work is invisible in a demo and everything in production.
Replies
61% to 90% is a huge jump. The region-first approach makes a lot of sense. Did one receipt layout give you more trouble than all the others?
This is the part people miss with OCR demos show clean receipts, production shows faded ink, weird formats, and missing fields
Stop treating a receipt as text is probably the key insight here. Did you use a fixed set of regions, or does the model dynamically identify them?
Promomix
I like the flag instead of guess philosophy. Users will usually forgive missing data more easily than confidently wrong data.
Bababot
The dozen GST invoice layouts point is so real. Did you build merchant specific rules over time, or are you trying to keep the parser completely generic?
Most OCR discussions stop at can we extract the text? The real question is whether the extracted field is actually the right field. How much did document structure improve this?
Going from 61% to 90%+ is impressive. What ended up being the biggest accuracy killer faded receipts, date formats, or inconsistent layouts?