Extracting invoice data in Arabic, French and mixed scripts

An invoice issued in Riyadh may carry Arabic vendor details, English item descriptions, Eastern Arabic numerals in the header and Western digits in the totals table. Every one of those transitions is a place where a parser built for a single script quietly produces the wrong answer.

Reading order is not visual order

In a right-to-left document the label sits to the right of its value. A parser that assumes left-to-right pairing attaches every label to the wrong field and reports it confidently, because nothing about the character recognition failed — only the pairing did.

This is why layout has to be resolved from coordinates rather than from reading order alone. The label nearest a value in the direction the document actually flows is the one that belongs to it.

Two numeral systems on one page

Eastern Arabic numerals must be normalised before any arithmetic check can run, and it is common to find both systems on the same invoice — one in the header, another in the table. Digits are normalised to Western form and dates to ISO 8601 before validation begins, so that a comparison is never made between two different notations.

Ambiguous dates are refused, not guessed

A date written 03/04/2026 is the third of April or the fourth of March depending on where the invoice was issued. Where the format cannot be established from the document itself, the field is flagged rather than resolved by assumption. A guessed date that happens to be wrong is more expensive than an empty one.

Validate with arithmetic, not with confidence

The strongest signal that a multilingual extraction is correct is not the recognition score — it is whether the numbers add up. When the line items sum to the subtotal and the subtotal plus tax equals the total, the parse is almost certainly right, whatever script it was read in.