Arabic document processing: what OCR and AI can read, and how to test it on your files

Why Arabic documents break OCR that works on English

Joined letters with four shapes

Arabic is written right to left and is cursive even in print, and a letter that joins on both sides has four forms, for isolated, final, medial and initial positions [1]. A fold or a smudge that breaks a join changes what the model sees as a letter.

Dots and missing vowels

Several Arabic letters share one shape and are told apart only by their dots, and the short vowel marks are optional: in normal writing they are left out [1]. A dot lost on a poor scan can turn one valid word into another valid word, which a spelling check will not catch. Names suffer most, because there is no dictionary to fall back on.

Two directions on one line

A line of Arabic that carries a date, an account number or an English company name is bidirectional: digits and Latin script run left to right inside right-to-left text [2]. A tool can read every character correctly and still hand the fields back in the wrong order.

More than one set of digits

A document can carry Western digits, Arabic-Indic digits or the Eastern Arabic-Indic digits used for Persian and Urdu, and Unicode encodes each set as separate characters [1]. A check that accepts only 0 to 9 rejects a phone or identity number that was read correctly.

Tables that run from the right

A table on an Arabic form starts at the right-hand edge. An extraction that reads the cells left to right produces a table with every column in the wrong place and every value plausible.

Stamps, seals and signatures

Official documents are stamped and signed, often across the text that matters. A stamp over a reference number or a signature through a date needs a human reader whatever the model, and the design should expect it rather than treat it as an edge case.

Handwriting

Handwritten Arabic varies far more between writers than print does, and its joins, dots and letter shapes are all less regular. Two of the services below list handwritten Arabic. Neither listing is an accuracy figure.

What the main OCR services say they support in Arabic

How to test it on 200 of your own documents

Choose the documents from the real intake

Take about 200 from the last year's intake, not from a folder of good examples. Weight them towards the document types with the most volume, then add the hard cases on purpose: handwritten, stamped, faxed, photographed on a phone, and mixed Arabic and English. Note which condition each document represents, because the report is broken down by it.

Build the answer key by hand

Two people type the fields that matter from each document independently, and a third settles the differences. That doubles the labelling effort and it is worth it: an answer key with errors in it makes every tool look worse, or better, than it is.

Decide what counts as right, field by field

Identity numbers, amounts, dates and phone numbers are right or wrong once digits and spacing are normalised. Names and addresses also need a softer measure, such as the character error rate, alongside exact match. Agree the rules before the first tool runs, so nobody tunes the scoring to the result.

Run every shortlisted tool unchanged

Same files, same answer key, default settings first, then any settings the vendor recommends. Record the version of each tool and API you ran, because the result belongs to that version.

Report by field and by condition

One overall accuracy figure hides what you need to know. Report each field by document type and condition, and show how the tool's own confidence scores line up with its errors. The useful question is whether the errors sit below a threshold you could send to a person.

Keep the set

The documents and their answer key become the regression test for every later change: a new model, a new vendor version, a new form.

ARABIC DOCUMENT PROCESSING TEST: ACCURACY REPORT

Tool, version and API version tested:
Date run:
Documents: about 200, listed by document type and by condition
Answer key: typed by two people independently, differences settled by a third

1. Fields scored and the rule for each
   Field | Rule (exact match after normalising, or character error rate) | Why it matters

2. Results by field and document type
   Field | Document type | Documents | Correct | Errors | Example errors

3. Results by condition
   Printed | Handwritten | Stamped or signed over | Photographed | Mixed Arabic and English

4. Confidence against errors
   Threshold | Share of fields sent to review | Errors above the threshold

5. Failure notes
   What broke, with the document reference and an image crop

6. Decision
   Fields accepted automatically, fields always reviewed, and what to test next

Design the human review before you pick the tool

Route by field, not by document

A document with nine confident fields and one doubtful one should cost the reviewer one check, not ten. Route each field on the tool's confidence and on the rules below.

Validate before a person sees it

Check digits where an identifier has them, dates that exist, amounts that add up, and fields that must agree with each other, such as a Hijri and a Gregorian date for the same event. A field that fails a rule goes to review however confident the model was.

Show the image beside the value

The reviewer sees the crop of the page the field came from next to the extracted value, rendered right to left, and corrects the value rather than retyping the document.

Audit a sample of the confident fields

A review queue fed only by low confidence tells you nothing about the errors the system was sure of. Check a random sample of accepted fields as well.

Feed the corrections back

Every correction is a labelled example. Kept with its image, it grows the test set and shows whether the next version is actually better.

Where the documents are processed

Where 1AYM fits