A bilingual invoice states the same figure twice, in two scripts, sometimes with different separators. Reading it correctly is worth an order of magnitude.
Most extraction pipelines are built against invoices in one script, one digit set and one currency convention. A group buying connectivity across the Gulf, Türkiye and East Africa receives documents of a different kind. They are correct, they are legible to their intended reader, and they are hostile to a parser written elsewhere.
None of what follows is exotic. It is simply specific, and specific is what a parser has to be. Start with the document itself, which often states every figure twice.
A bilingual invoice commonly states each figure once per language column. Digit normalisation alone cannot say which of the two is authoritative, or notice when they disagree, because both are perfectly valid numbers.
That is a label problem rather than a number problem. Labels are matched through a stored synonym list, so the Arabic and the English label for monthly charges, for value-added tax, or for the tax registration number resolve to the same field. A disagreement between two statements of the same field opens a review item, rather than being settled by document order.
Getting the label right still leaves the arithmetic, and the arithmetic has its own regional shape.
Several currencies in the region carry three minor digits rather than two. Code that multiplies by a hundred to reach minor units loses a factor of ten on every invoice denominated in them. The exponent is read from a currency table, which is why money is stored as integer minor units plus a currency code rather than as a decimal number.
Tax is the matching trap. Rates diverge by jurisdiction and change by date, so they are held as a dated per-jurisdiction lookup. At least one jurisdiction levies a communications charge that sits outside the value-added tax base, and that has to be computed as such. A document whose lines do not sum to its total, or whose tax lines do not sum to its declared tax, opens a review item before anything downstream reads it.
Each of these is small on its own. Together they explain a strategic choice.
A group in this region cannot simply adopt a North American telecom expense platform and be finished. Vendors built for one script and one convention will reach this work years from now, because their own customers rarely ask for it.
Riopex builds it first, on purpose. Every original is kept alongside its normalised twin, so a reviewer can always see what the carrier actually printed.
The bet is paid off in specifics, and the smallest of them is the digits themselves.
Arabic-Indic digits are a different set of code points from the Latin digits, and the separators that travel with them differ too: a distinct decimal mark, a distinct thousands mark, and a distinct percent sign. The failure mode is mixing conventions, reading an Arabic decimal mark as a thousands separator, and turning a figure into a thousand times itself.
So the rule is to match the separator convention to the digit set that was actually observed, normalise to Latin digits, and keep the raw string exactly as printed. The normalised value is what arithmetic uses, and the raw value is what a reviewer sees when they want to check.
Dates carry the same risk, and one calendar always asks.
An invoice issued on a Hijri date has to be converted to a Gregorian date to sit in a monthly fact table, and at the boundaries the conversion can go either way. Riopex stores the converted date, the raw date and the calendar it came from, and asks a person to confirm it.
That is one of the few places where review is mandatory rather than confidence-driven. A billing period off by a month moves a charge into the wrong close, and every downstream figure inherits the error.
How a document lands, is extracted, is checked and is converted into money is on the bills page.
