OCR models for tables and statements: languages, scripts, and mixed alphabets
OCR on a table full of names and account numbers will lie to you in the most convincing way: correctly. Every character will be real, every word real, and the row it landed on, the script it swapped in, will be wrong. That's not a calibration issue you fix with more data. It's a structural property of asking a language model to behave like a scanner.
Cyrillic Р is not Latin P
Financial statements, schedules, price lists, lab results, and tabular reports arrive with faint rules, wrapped cells, repeated headers, indentation, negative-number conventions, and dense type. A vision-language model reads ambiguous layout and relationships better than a rules engine, but it can replace an uncertain character sequence with language that reads more naturally than the document did, and in a mixed-script name field that's where it costs you. The constraint I hold to: recognition preserves written script before normalization or translation touches it. Start with layout-aware OCR, table detection, and deterministic spreadsheet validation; bring in a generative or multimodal model only where it earns its keep: handwriting, irregular layouts, semantic field association, exceptions. Test against language-specific fixtures with mixed-script pages, and score diacritics, names, numbers, and punctuation independently. Keep the source file immutable and log the path from capture to verified field:
source hash, page, capture device
OCR/VLM model + preprocessing revision
raw text, region, order, confidence
normalized value, validator, reviewer change
When a character is ambiguous, O or 0, a stray diacritic, a minus sign or dash, store what the recognizer saw and what the business rule proposed as separate fields, and never let the second overwrite the first.
A plausible wrong answer beats no answer, which is the problem
The costly failure mode is correctly recognized digits attached to the wrong row, column, period, or unit. Nothing looks broken. The specific trap in multilingual work: translation or spell correction inside OCR loses the printed form, and a damaged surname or part number gets completed into something familiar-looking, because that's what language models do. Build an abstention path: low-resolution regions, clipped pages, glare, bad handwriting, and contradictory totals should raise an exception, not a guess. Confidence scores are model-specific and badly calibrated, so pair them with image-quality checks, format validators, cross-field arithmetic, and disagreement between recognition passes. Score cell text, row-column association, header hierarchy, and table reconstruction separately from character or word error rate: CER wrongly treats a missing comma and a wrong account number as equally serious. Store a bounding polygon per field, so a reviewer sees the crop beside the proposed value instead of hunting for it.
Reasoning is fine; deciding alone is not
Ask a vision-language model to separate what it observed from what it inferred, and keep tool or database writes behind independent schema validation. Text printed inside a document is data, not an instruction. Treat it as one and a statement talks its way into a tool call it shouldn't get. For multi-page work, split documents deterministically, keep page order and repeated-header identity, and never let a model merge two statements into one. Version the model, preprocessing, dictionaries, and validation rules together, and replay a stratified test set whenever any of them changes. Local deployment keeps documents under your control and gets cheaper as steady page volume climbs. Hosted document APIs buy elasticity and a higher ceiling on hard exceptions, costing upload time, retention terms, and per-page pricing. Hybrid routing works when the privacy line is hard and the escalation path stays visible.
What I still don't have a clean answer for: a name has no single correct spelling across scripts. When a transliterated identifier disagrees with itself across two documents, I don't know whose spelling wins.