OCR models for invoices and receipts: languages, scripts, and mixed alphabets

So the fading thermal receipt in your hand and the crisp PDF invoice from a supplier are, to the recognition model, two different problems wearing the same shirt. One is character recognition. The other is deciding which number is the total.

The inputs are supplier invoices, retail receipts, credit notes, a crumpled expense slip shot at a bad angle with a shadow across the total. The output is vendor, dates, totals, tax, currency, and line items, each tied to a page location. Perspective skew, a logo eating the header, a total printed twice: none of that is exotic. It's Tuesday.

the model that finishes your sentences for you

A language model, vision-capable or not, is trained to continue plausible patterns. Point it at a damaged surname, a smudged part number, or a total half-covered by a thumb, and it produces something. Not gibberish. Something plausible. What the recognizer saw and what it decided you meant are two different facts, and keeping only one loses the ability to catch the mistake later.

It gets worse with anything visually ambiguous: O and 0, a decimal that's a thousands separator elsewhere, a diacritic that either belongs or doesn't. Recognition has to preserve the script as written, before normalization or translation.

A model trained to sound fluent will happily fix your invoice for you. That's the problem.

a wrong number that looks completely right

The failure that costs money isn't garbled output. It's a valid-looking amount pulled from the wrong place: the subtotal instead of the total, a balance-forward figure, a neighboring line item. Nothing looks broken. It passes a glance.

Build an abstention path and mean it. Low-resolution regions, clipped pages, glare, unreadable handwriting, contradicting totals: these need an exception, not a guess. Confidence scores are poorly calibrated across vendors, so cross them with image-quality checks, format validators, known dictionaries, and disagreement between two passes.

what has to survive before anything downstream can trust it

Keep the original file untouched, and assign page and document identifiers before processing runs. Log the path: source hash, capture device, crop and dewarp versions, which model produced the reading, language hints, raw text with confidence, and the normalized field beside the reviewer change.

Provenance turns review into verification instead of retyping. Store a bounding polygon per field and show the crop beside the value.

Build fixtures per language and score mixed-script pages on their own. CER and WER treat a dropped comma and a wrong account number as equivalent, which they are not. Add exact-match scoring for identifiers, dates, and amounts, and gate the system on field accuracy, arithmetic reconciliation, duplicate detection, and exception rate.

where the language model earns a seat at the table

Start deterministic: OCR, then vendor templates, anchors, arithmetic checks. That baseline handles most invoices cheaply. Bring a vision-language model in only where it earns its place: difficult handwriting, irregular layouts, associating a label with a distant value, or explaining a discrepancy. It should never quietly replace a stage that already worked.

Keep observation and interpretation separate, and don't let the model's output reach a database without schema validation outside it. Text on a document is data a supplier controls, not an instruction. For multi-page work, split documents deterministically and state whether a table may continue across a boundary.

None of this chases the prettiest paragraph. It preserves evidence and lets a person verify without redoing the job.

the local box versus the hosted bill

Local hardware keeps documents under your control and gets cheaper at steady volume, once you count storage, backup, model memory, GPU time, and review labor. A hosted document API or frontier vision model buys elasticity and a higher exception ceiling, but costs upload time, retention, residency, rate limits, and a per-page bill. Hybrid routing works when privacy rules are firm and escalation stays visible.

The rule that holds regardless: write the faithful transcription first, and treat anything normalized or translated as derived, never as the record of truth. Version model, preprocessing, dictionaries, and validation together, and replay a fixed set, clean pages through impossible ones, whenever any piece changes.

None of that solves the part I still don't have a clean answer for: a supplier name written in one script has no single correct spelling in another. Whichever transliteration you pick is a specific answer to a question with no correct one. I log the choice and move on. Not solved.