Arabic OCR for scanned forms and invoices: what breaks and how to test it

Take an illustrative case. A mid-sized insurer in Amman wants to stop retyping paper claim forms, so it runs a two-week pilot of an Arabic OCR tool. The printed headings come back clean. The handwritten national ID numbers come back with two digits swapped, and the totals on scanned pharmacy receipts lose their decimal point. Nobody notices, because the output looks tidy. Arabic OCR can work well on forms and invoices, but only if you test it on your own documents, field by field, and decide in advance where a person checks the result.

This explainer covers what tends to break, how to measure accuracy honestly, and where human checks belong. We recommend measuring field accuracy before you compare vendors, because a good page-level score can hide a bad amount field.

What breaks when Arabic OCR reads scanned forms and invoices

Arabic script raises problems that Latin-script OCR rarely meets. Each one can turn into a wrong value in your system.

Joined letters and dots

Arabic letters join and change shape depending on their position in a word. Several letters differ only by the number or position of dots, such as ب and ت and ث. A faint scan, a fax or a stamp over the text can remove a dot, and the engine then reads a different letter. A name like "ثابت" can come back as a real but different word, which makes the error hard to spot.

Spelling variants and decoration

The same word can be written with different alef forms (ا أ إ آ), with ة or ه at the end, and with ى or ي. Printed headings may use tatweel, the stretching stroke that widens a word. Diacritics appear on some forms and not others. None of this changes the meaning, but it changes the text an exact-match search or a database lookup sees.

Two digit systems and mixed direction

Forms in Jordan and the Gulf can mix Western digits with Eastern Arabic-Indic digits, sometimes on the same page. Arabic text runs right to left, while numbers, IBANs, VAT numbers and English product names inside it run left to right. An engine can return mixed lines in the wrong order, so an amount and its currency can swap places, or a date can come back reversed.

Layout, stamps and handwriting

Invoices put values in tables, boxes and margins. Merged table cells, rotated text and stamps across a signature line can break the reading order. Handwriting is the hardest case: customers fill in names, phone numbers and IDs by hand, and the quality varies from person to person.

Which engines read Arabic, according to their own documentation

Check language support in each vendor's documentation, not in a sales deck. Here is what the pages we checked on 19 October 2026 say.

• Tesseract (open source). The Tesseract data files documentation lists Arabic (ara) among its language models. It offers a fast set, which is quicker but less accurate, and a best set, which is the most accurate and the slowest.
• OCRmyPDF (open source). It adds a text layer to scanned PDFs and, per the OCRmyPDF language guide, relies on Tesseract language packs, chosen with a flag such as -l ara+eng.
• Azure AI Document Intelligence. The Read and Layout language support page lists Arabic for printed text, and lists Arabic for handwritten text in version 4.0. The version 3.1 handwritten list does not include Arabic, so the API version you call matters.
• Amazon Textract. The Textract best practices page lists English, Spanish, German, Italian, French and Portuguese. Arabic is not on that list, so ask AWS in writing before you plan an Arabic workload on it.

Vision language models can also read page images. Our concern on forms is that their mistakes can look fluent: a model may write a plausible name or number instead of signalling doubt. Treat them as one more engine and run them through the same test.

How to test Arabic OCR accuracy on your own documents

A fair test compares engines on the same pages, scored by rules you fix before you see any output. This is the sequence we recommend.

1. Sort documents into classes. For example: printed invoices, scanned claim forms, phone photos of receipts, and handwritten fields. Score each class separately, because a single average hides the weak one.
2. Pick a sample from real traffic. Include poor scans, stamps and mixed Arabic and English pages in the share you actually receive. Remove or mask personal data you do not need for the test.
3. Type the ground truth twice. Two people type the correct text and key fields independently, and a third settles differences. Ground truth is the agreed correct answer for each page.
4. Write the normalisation rules. Decide how to treat alef forms, ة and ه, ى and ي, tatweel, diacritics and digit systems. Apply the same rules to every engine's output and to the ground truth.
5. Score text and fields. Use the measures in the table below, per document class and per field.
6. Record confidence scores. Textract, for example, returns a confidence score from 0 to 100 with its results; check whether each candidate engine does the same. Keep these scores, because they drive the human-check rules in the next section.

The last row deserves the most attention. An engine with a slightly higher error rate but honest confidence scores can be safer than one that is rarely wrong but never signals doubt.

When to add human checks to Arabic OCR

We recommend checking fields, not pages. A clerk who rereads a whole form can start to skim. A clerk shown only the three fields the system doubts has a better chance of reading each one carefully. The AWS Textract guidance supports a threshold approach: it advises a minimum confidence threshold where errors matter and says business processes involving financial decisions might require thresholds of 90% or higher.

Set the threshold for each field from your own test results, not from a vendor default. Rules catch errors that confidence misses. Line items should add up to the total, a VAT number should have the right length, and a claim date should not fall after the scan date.

A second illustrative case shows the trade-off. A family-owned distributor in Riyadh processes supplier invoices. Amounts above an agreed limit always go to an accounts clerk, and smaller ones go straight to the ERP when the line items add up. The clerk's queue should shrink to the invoices that need judgement, while the risky fields keep a person in the loop.

When you should not use OCR at all

OCR is the fallback when no structured data exists. In Saudi Arabia, ZATCA's Phase Two readiness guide says a Phase Two invoicing system must generate and store e-invoices as XML, or as PDF/A-3 with embedded XML. When a Saudi supplier already in Phase Two sends that file, read the XML instead of the pixels. Keep OCR for paper, for older archives and for suppliers outside the scheme.

Scanned forms also carry personal data, such as ID numbers, phone numbers and sometimes health details. Before you send pages to a cloud OCR service, check which region processes them and what your data protection and sector rules require. This is general information, not legal advice; obligations depend on your sector and the data involved.

How to start

Start with one document class that hurts today, such as claim forms or supplier invoices. Build a small labelled sample, run one open-source baseline and one cloud engine, and set field thresholds from the results. Only then compare prices and contracts.

Our Published Research & Arabic AI Benchmarks work publishes Arabic and bilingual platform evaluations, and the method follows our guide to Arabic LLM evaluation. When the test is done, Custom AI Applications & Modernisation can help build the extraction into your systems, and the legacy systems page explains how that fits a move away from paper and spreadsheets. If the scanned text will feed an assistant, read our guide to Arabic RAG. More on the Transformation Lab page.

If you are not sure where to begin, book the free AI Exposure Scan: a free 45-minute conversation that ends in a written next step.

Related lab: Transformation Lab ↗