The language is not the hard part.

Three invoices land in the same queue: one from São Paulo, one from Osaka, one from Riyadh. The extractor returns a clean value for the invoice date on all three, each above 0.95 confidence. Two are right. The third reads 03/04/2026 as 3 April on a document that meant 4 March, and nothing in the response says so, because the characters were never in doubt.

Multilingual document processing is usually argued as a model question: which scripts can the recognizer read? That argument has largely been settled. Non-Latin script OCR is not where these pipelines break any more.

They break one layer up — in everything wrapped around the recognized text. The order of a date. The meaning of a comma. Which half of a name is the family name. And a schema whose keys were written in English, by someone who had only ever seen English documents.

Recognition and interpretation are different jobs

Treating “does it support Japanese?” as one question hides at least four decisions, and only the first is about the model.

• Recognition — turning marks on a page into code points, including the ones your font stack cannot render.
• Segmentation — deciding where a field begins and ends, which is a layout problem before it is a language problem.
• Convention — deciding what the recognized string means where the document was issued.
• Normalization — deciding what you store, in what form, and what you throw away by storing it.

A vendor answering only the first question can honestly say a language is supported while your convention layer is wrong on every document. The characters arrive intact and the values arrive false.

The ambiguity that survives perfect recognition

Some strings are locally unambiguous and globally undecidable. No amount of recognition accuracy resolves them, because the missing information was never on the page.

Every row is a value error produced at high confidence. The model was right about the characters and wrong about the number, and no threshold on the character score will ever catch it.

The only honest resolutions are external: derive the convention from the issuer, from the currency, from the document template, or from an explicit statement elsewhere in the document — or refuse to emit a normalized value at all.

A confidence score does not cover a convention error

Our article on handwriting and ICR describes abstention when the glyphs are genuinely uncertain. This is the opposite failure. Here the glyphs are certain, the confidence is high, and the interpretation is wrong — so a pipeline that routes only on confidence will never route this field to anyone.

The checks that do catch it are structural, and they are cheap:

• Self-disambiguating values — a day above 12 settles date order on its own; propagate that finding to the rest of the document rather than deciding field by field.
• Cross-field arithmetic — line items that do not sum to the stated total usually mean a separator was read as the wrong kind of separator.
• Range and plausibility bounds — an invoice dated 8 months out or an amount three orders of magnitude off its history is a convention error far more often than a real outlier.
• Explicit convention output — emit which rule produced the normalized value, so a wrong rule is visible instead of inferred.

The last one matters most. A date field that says only 2026-03-04 is unauditable; the same field beside the raw string and the rule that transformed it can be checked by anyone, later, without the document.

Names are not a first field and a last field

Personal names defeat a two-field schema in more ways than most systems account for. Family name first in Chinese, Japanese and Korean. Two surnames in Spanish and Portuguese, and only one of them inherited the way an English-speaking system expects. Patronymics that change with the bearer's gender. People with one legal name and no surname at all.

Transliteration compounds it. There is no single correct Latin rendering of an Arabic, Cyrillic or Devanagari name: the same source string legitimately appears as Mohammed, Muhammad and Mohamed across three documents about the same person, and none of the three is an error.

Two rules keep this tractable. Store the source-script string as the record of truth, with any transliteration marked as derived and labelled with the scheme that produced it. And treat cross-script identity as a matching decision with its own evidence and its own threshold — never as string equality on the transliterated form, which produces false merges and false splits in the same corpus.

Direction changes the geometry, not only the text

Arabic and Hebrew documents are laid out right to left, which moves the labels, mirrors the tables and reverses the reading order of everything you assemble from coordinates. A Latin run inside Arabic text — a part number, an IBAN, a date — reorders under the bidirectional algorithm, so the string a human reads and the string in the file are not always in the same order.

Traditional vertical Japanese and Chinese layouts move the axis entirely. Column order runs right to left, and a naive top-to-bottom, left-to-right assembly returns the document backwards while every individual character is correct.

The coordinate contract itself does not change — a box is still a box, as described in our note on bounding boxes as an API contract. What changes is the order in which those boxes become a sentence, and that ordering has to be a property of the document, not a constant in your parser.

Your schema is written in one language too

Keys in English are a reasonable engineering convention. The mistake is letting that convention leak into the values, so that a Portuguese document is stored as a bad English document. Decide per field whether you preserve, normalize, or keep both.

Normalization without the source string is lossy in exactly the direction that hurts. You can always normalize again from the original. You can never recover an original from a normalization that was applied with the wrong rule.

Language detection is routing, and short fields defeat it

Detection is dependable over a paragraph and unreliable over a 12-character field. Proper nouns, amounts, reference numbers and dates carry almost no signal, and a detector forced to answer will answer anyway.

Mixed-language documents are not an edge case either: bilingual contracts with two authoritative columns, Latin brand names inside Japanese prose, an English form completed in Arabic by hand. A per-field detector on any of those produces a per-field convention decision, which is how one document ends up parsed under three different rule sets.

Route at the document level, from the strongest evidence you have — the issuer, the template, the tenant configuration, the channel it arrived through — and treat detection as a signal that can be overridden. A wrong routing decision is worse than no routing decision, because it applies a complete and confident set of wrong conventions.

Classification travels worse than extraction

Field extraction generalizes across languages more readily than document classification does, because a total is a total wherever it sits on the page. A classifier keys on layout and vocabulary together, and both change at the border: a Brazilian nota fiscal, a German Rechnung and a US invoice share a purpose and share almost no surface.

That is a per-country problem more than a per-language one. Two countries writing the same language issue different documents, and the classification reference is the place to pin what your routing actually keys on. If a class is defined by an English layout, say so, and measure it separately everywhere else.

Measure per language, never per corpus

A single accuracy number over a corpus that is 91% English is a statement about English with a rounding error attached. Split it, and publish the denominators beside it.

• Per-language field accuracy — with the document count for that language, so a 100% built on 7 documents is visible as such.
• Convention-error rate — values that parsed cleanly and meant something else, counted separately from recognition errors.
• Abstention rate by script — where the system declines, split by writing system rather than averaged into one figure.
• Reading-order failures — assembled text that is correct character by character and wrong in sequence, which no character metric reports.
• Coverage denominator — how many languages you actually tested against how many you claim, stated as a fraction.

A vendor that can produce those five per language is describing a measurement. A list of supported languages without denominators is describing an intention.

Language is not region, and the two get conflated constantly

Where a document is processed is a legal and architectural decision, covered in our piece on data residency. Which language it is written in is a property of the document. A French contract may be processed in the United States and a US contract in Frankfurt, and neither fact tells you anything about the other.

Welding them together produces two failures at once: a compliance claim that does not survive a careful read, and a routing rule that sends documents to a region for a reason that was never about the region.

The self-aware version of this, since we are the ones publishing it: the Cogneris site itself is published in 15 locales, and that says nothing whatsoever about which documents our extraction reads well. Those are our marketing pages, not a measurement of the product. We put the sentence here because the conflation is easy, and we are not exempt from it.

Seven questions before you call a language supported

1. Which scripts were tested, and against how many real documents each?
2. Which conventions are derived from the issuer rather than guessed from the field?
3. What happens to a date whose order cannot be determined — a value, or an abstention?
4. Is the source string retained beside every normalized value?
5. Is reading order a property of the document or a constant in the parser?
6. Are transliterations labelled as derived, with the scheme recorded?
7. Are accuracy figures reported per language with their denominators?

A pipeline is multilingual when it can say what it does not know about a document in a language it has never seen. Reading the alphabet was the part that got solved.