OCR Arabic On-prem

Why Arabic OCR still fails, and how we fixed it

Ligatures, diacritics, and mixed-direction documents break almost every off-the-shelf engine. The three changes that took us from 71% to 99.2% field-level accuracy on real Gulf documents.

APFlow
Blog · May 2026 · 6 min read
A calligrapher writing Arabic script with a reed pen on ornamented paper
Photo: Oussama Abouchatir · Unsplash
TL;DR
  • ·The Arabic alphabet is not the problem. Ligatures, diacritics, and digit direction are.
  • ·Mixed-direction layouts are the real killer: a top commercial engine scored 71% on real Gulf documents.
  • ·Three pipeline changes took field-level accuracy from 71% to 99.2%.
  • ·Everything runs on-prem. The constraint forced a better pipeline.

A typical Gulf tax document is a small act of typographic chaos. The vendor name runs right-to-left in Arabic, the line items are bilingual, the registration number marches left-to-right, and the totals sit in a table whose columns flip direction halfway down the page. To a human, it is obvious. To most OCR engines, it is noise.

We learned this the hard way. Our first pipeline used a best-in-class commercial OCR API, the kind that tops English benchmarks. On clean English receipts it was flawless. On the first batch of real Gulf documents, it returned 71% field-level accuracy. For a back office, 71% is not "mostly working." It means roughly one in three documents needs a human to re-key it, which defeats the entire point.

The problem isn't the alphabet

It is tempting to assume Arabic is hard because it has different letters. It doesn't work that way. The alphabet is small, 28 base letters. The difficulty is that each letter changes shape depending on where it sits in a word, and adjacent letters fuse into ligatures that share strokes. English OCR leans heavily on the gaps between characters. Arabic gives it far fewer.

Mixed direction is where it really breaks

Even when the characters are read correctly, layout destroys them. Gulf documents are bidirectional tables. A description column flows right-to-left, the quantity and price columns are left-to-right, and the engine has to decide reading order before it can decide what belongs to which row. Get the order wrong and you get something worse than garbage: a plausible number attached to the wrong field.

A wrong number that looks right is more expensive than no number at all.

What we actually changed

  1. 1 Layout-aware segmentation first.
    Before any text recognition, a vision model maps the page into directional regions, so reading order is decided from geometry, not guessed from characters.
  2. 2 An Arabic-first recognizer.
    We fine-tuned an open model on hundreds of thousands of real document crops: ligatures, stamps, low-contrast scans, and margin handwriting, instead of clean synthetic text.
  3. 3 Numbers must reconcile.
    Every extracted figure is checked against the document's own arithmetic. A number that does not balance is flagged, never silently posted.
99.2%
field-level accuracy, up from 71%, measured on 4,000 held-out Gulf documents across 60 vendors, including scanned, photographed, and exported PDFs.

Why on-prem made it harder, and better

We could have shipped a cloud API and called it done. But teams in the region cannot send this data to a third party, so the whole pipeline had to run on the customer's own GPUs. That constraint forced a discipline that improved accuracy: every model had to be small enough to run locally, so each layer had to earn its place. The result reads an Arabic document as well as a careful human clerk, and it never leaves the building.

Share

Put one workflow into production.

A 15-minute call, then a real assessment of what an agent can run on your own servers.

Book a scoping call →
Keep reading