How Does Receipt OCR Work?

Receipt OCR converts a photo of a receipt into structured data in four stages: image preprocessing (deskewing, contrast, noise removal), text recognition (the OCR proper — mapping pixels to characters), layout analysis (understanding columns, line items, and the total block), and field extraction (identifying which text is the vendor, date, tax and total — increasingly done by machine-learning models trained on millions of receipts). The first stage is why app captures beat casual photos; the last is where products differentiate.

Stage 1: making the photo readable

Receipts arrive crumpled, curled, shadowed and skewed. Preprocessing finds the receipt's edges, flattens perspective, binarizes (pure black/white), and boosts the low contrast that faded thermal paper offers (why it fades). Good capture UIs do this live — edge detection, glare warnings — because garbage in is unrecoverable later. It's also the practical answer to "why did my scan fail": flatten the receipt, kill the glare, fill the frame.

Stage 2: recognizing the text

Modern OCR is neural: models read whole lines in context rather than matching letter shapes, which is how they survive receipt fonts — dot-matrix-descended, monospaced, ALL-CAPS, printed at 203dpi (the printer's constraints). Digits do well; the failure modes are faded strokes (8→3, 0→8), the abbreviations grocery receipts love ("GV WHL MLK" — the grocery dialect), and handwriting, which remains largely out of reach (handwritten receipts get manual entry).

Stage 3: understanding the layout

Receipts are structured documents: header, item column with a price column, a totals block, a payment block. Layout analysis reassembles OCR's text fragments into that structure — matching item names to their prices across the gap, distinguishing the SUBTOTAL/TAX/TOTAL stack from line items, ignoring the survey-code footer. Narrow 58mm receipts that wrap item names across lines are the classic layout headache.

Stage 4: extracting the fields

Knowing the text says "07/14/26" is recognition; knowing that's the transaction date (not a best-by date in the footer) is extraction. Production systems combine rules (TOTAL keywords, currency patterns, date formats) with trained models that learn positional and contextual cues — plus arithmetic validation: items should sum to subtotal, subtotal + tax = total. When the math reconciles, confidence jumps; when it doesn't, the field gets flagged for the human review queue. That check is the same one an expense-report reviewer runs by eye.

Why receipts stay hard (and what wins)

No standard layout across millions of merchants, thermal fading, 32-character truncation, multilingual stock, tax quirks per jurisdiction — receipt OCR is a long tail of edge cases. Accuracy on clean captures now exceeds high-90s per field in good apps; the residual errors cluster exactly where you'd guess: faded, crumpled, handwritten. The user-side fixes are boring and effective: capture at payment before pocket damage, flatten, avoid glare, verify extracted totals weekly (the verification habit).

The bottom line

Cleanup → recognize → structure → extract, with arithmetic as the referee. OCR turned receipt-keeping from typing into photography; the last honest advice is unchanged — photograph it now, while it's flat and dark and true.