Reading Arabic invoices with AI: what works, what still needs a human

Invoice processing is the most requested automation we get asked about, and the one where expectations are furthest from reality. The pitch people have in their heads is: point AI at the folder, get a clean spreadsheet. What they actually need is a system that reads most invoices correctly, knows which ones it is unsure about, and never quietly changes a number.

Arabic makes all of this harder. Here is what genuinely works now, and where a human still has to stay in the loop.

Why Arabic invoices are harder than English ones

Not because the language is exotic. Because of specific, mundane things that break document pipelines:

• Two numeral systems on the same page. A Kuwaiti invoice will often use Western digits for the amounts and Arabic-Indic digits for the date, or mix them within a table. Systems tuned on English documents mis-read one or the other.
• Connected script. Arabic letters join, and their shapes change depending on position. Older OCR built on character segmentation falls apart; it was designed for letters that sit apart from each other.
• Right-to-left tables with left-to-right numbers. The line items read one direction and the figures the other. Column alignment is where extraction quietly goes wrong — the quantity from one row pairing with the price from another.
• Stamps and signatures over text. Common in the Gulf, and they land exactly on the fields that matter: the total, the date, the authorisation.
• Print quality. A lot of what arrives is a photo of a fax of a print-out, taken at an angle in bad light.

What works well now

Vision-capable models have genuinely changed this. The older pipeline — OCR to text, then rules or regex over the text — was where Arabic fell apart, because the OCR step destroyed the layout before anything could reason about it. Models that look at the page image directly and are asked for structured output skip that failure entirely. They read the invoice more like a person does: the number next to that label, in that column, on that row.

Classification is reliable. Is this an invoice, a delivery note, a quotation, or a statement? Which supplier is it from? Which cost centre does it belong to? This is the boring part of the work and it automates almost completely.

Getting fields out in a fixed shape works. Supplier name, invoice number, date, line items, subtotal, VAT, total — asked for as structured data with a defined schema, in both English and Arabic, this is now routine rather than research.

Cross-checking beats trusting. The single most useful technique is not better extraction, it is arithmetic. Do the line items sum to the subtotal? Does subtotal plus VAT equal the stated total? Does the supplier name match one in your ledger? An invoice that fails its own internal maths gets flagged rather than filed. This catches a large share of extraction errors without anyone reading anything.

What still needs a human

Anything that moves money. Payment amounts and bank details never go straight through. Not because the model gets them wrong often, but because the cost of the rare error is unbounded and the cost of a human glance is thirty seconds. Supplier bank-detail changes in particular should require human confirmation by policy — that is the single most exploited fraud vector in accounts payable, and an automated pipeline that updates payment details on the say-so of an emailed PDF is a liability, not an efficiency.

Handwriting. Handwritten Arabic quantities, corrections in the margin, a total scratched out and rewritten — these are where confidence should collapse and a person should look.

Anything unusual. Credit notes, partial deliveries, retentions, invoices in a third currency, documents from a supplier seen for the first time. The system should recognise novelty and escalate it instead of guessing confidently.

The dispute. When a supplier says the invoice was for a different amount, someone has to open the original document and compare. Which means you must keep the original, linked to every extracted field, forever.

The design rule

Build the system so that every automated decision is reversible and traceable. In practice:

• Store the source document, not just the extracted values.
• Record which model version produced each field and when.
• Attach a confidence signal per field, and route low-confidence fields to review rather than accepting them.
• Log who approved what. If an auditor asks in eighteen months how a figure got into the ledger, the answer cannot be “the AI put it there.”

This is not compliance theatre. It is what makes the difference between an automation your finance team trusts and one they quietly stop using because they cannot explain it.

What to expect realistically

Most of the value is not in reaching perfect accuracy. It is in changing the shape of the job: instead of a person re-typing every invoice, a person reviews exceptions. If eight out of ten invoices pass their own arithmetic checks and match a known supplier, the team’s work drops by most of its volume — and the two that get looked at properly get looked at properly, because nobody is exhausted from typing the other eight.

That is the honest promise. Not “AI does your accounts payable.” A machine that handles the repetitive majority and is disciplined about admitting what it does not know.