Custom Arabic OCR annotation for document AI

Bayanat Labs provides Arabic OCR annotation for document AI teams: ground truth for printed and handwritten Arabic, with line, word and character geometry, exact transcriptions, right-to-left and mixed-direction reading order, key-value fields, tables and PII boxes. Native annotators follow transcription rules agreed before the first page, and every batch is checked against gold pages from your own documents. Data stays in-region by default, and you start with a fixed-scope pilot, usually within two weeks.

Planning a whole collection? Our custom Arabic document datasets cover workflows such as invoice checks, forms and procurement, including extraction and questions grounded in the page. This annotation service handles the reading order, transcriptions and labels your documents need.

What our Arabic OCR annotation covers

Why Arabic OCR is hard, and the rule each problem needs

KITAB-Bench (Heakl et al., 2025), an 8,809-sample benchmark across 9 domains, lists complex fonts, numerals, word elongation and table structure among the open problems of Arabic OCR. Script-level traps need written rules:

Worked example: bidirectional text on a Saudi invoice

Saudi VAT Implementing Regulations (Article 53(5)) require the details on a tax invoice to appear in Arabic, with any other language shown as a translation, so Arabic sits beside Latin codes and digits. Unicode stores text in logical (reading) order and reorders only the display; annotators must recover the logical string from what they see:

Reviewers render each transcription in RTL beside its crop, and normalized values get format checks.

Arabic document annotation specs we agree up front

The spec also fixes tatweel, crossed-out text, stamps over text and output format (PAGE XML, ALTO or JSON); see our playbook on how to annotate Arabic text.

Scoping an Arabic document project: OCR text, layout, fields and evidence

"Annotate our invoices" can mean four different deliveries. OCR text teaches a model to read; layout and reading order teach it how a page is organized; normalized fields teach it to extract; document questions and validation checks teach it to answer from the page and notice when the numbers disagree. You can commission the first layer on its own or add the others, but each one needs its own labels, its own acceptance check and its own rule for keeping test documents apart. Decide which layers you are buying before the pilot, because adding fields later usually means a second pass over every page.

Page count is not template count

Many invoices from one accounting system can be a single layout filled in many times. A model trained and tested on them can score well by memorizing where the total sits, then fail on the first invoice from a new supplier. A document scope should therefore report pages, distinct issuers, distinct templates and, for handwriting, distinct writers as separate numbers, keep variants of one template identifiable, and put whole issuers or templates, not single pages, into the test split. Genuine, de-identified and synthetic pages stay distinguishable in the delivery, so you can measure how a model trained on rendered pages does on real scans.

The fields a document scope should fix before the first page

• Source and provenance type: genuine, de-identified or synthetic, and the written permission behind each source. Source permissions are defined with you before collection.
• Page or image ID and page size: a stable ID plus the pixel width and height, so every coordinate can be checked against the page it belongs to.
• Reading order: an index for every region and line, across right-to-left, left-to-right and mixed runs.
• Polygon or bounds: the geometry level (region, line, word, character) and the coordinate convention, such as pixels from the top-left corner.
• Raw OCR text: the transcription as printed, in logical order, with Arabic or Latin digits and separators kept.
• Normalized fields: the field list, the normalized format of each (dates, amounts, ID numbers) and the rule when a field is missing or corrected by hand.
• Evidence location: the page ID and box for every extracted value and every answer.
• Issuer and template split: the issuer, template and, for handwriting, writer each page belongs to, so a template appears in one split only.
• Volume: an estimate up front, fixed after the pilot shows throughput and difficulty on your documents.

Illustrative record: one synthetic invoice, every value tied to its evidence

This record was written by Bayanat Labs for this page to show the format. It is not a delivered record or a catalog sample: there is no underlying page, and the seller, amounts, coordinates and IDs are invented. Coordinates are pixels from the top-left corner, as [x1, y1, x2, y2].

Two guideline decisions hide in this one record. Which total is the value of the field: the guideline has to say whether a handwritten correction overrides print, and whether both amounts are kept. And the box for each amount must sit inside the 2480 × 3508 page and enclose the digits it claims; a checker can test both mechanically before a human looks at the page.

How a document pilot is accepted

Draw the pilot sample yourself, stratified by issuer, template, capture quality and handwriting share. Render each transcription right to left beside its crop, recompute every normalized value from the text as printed, check that every box falls inside its page and encloses its value, recompute each validation check from the labeled fields, re-label 10 to 20 pages yourself, and confirm that no issuer or template appears in both training and test. Our guide to how to evaluate an Arabic OCR dataset covers these checks, and more, in a 10-point audit you can reuse for any vendor, including us.

For a new collection, Bayanat Documents builds Arabic document datasets to order, with page count and template coverage agreed with you. If the documents will feed a search or RAG system, Bayanat Search adds queries, relevance judgments and grounded answers over them; to compare models on reading and extraction, Bayanat Bench builds held-out tests kept separate from training deliveries. To scope a project, send the document types, the layers you need, the sources you can authorize and your timeline: discuss document type, authorized sources and exact custom labels.

How an Arabic OCR annotation project runs

Each project follows Vet → Train → Produce → QA → Deliver:

1. Scoping. Document types, handwriting share, capture quality, schema, volume and residency, checked on real pages.
2. Spec and gold pages. A spec written around your documents; gold pages adjudicated by senior native linguists. Annotators pass screening before touching client data, then calibrate on gold.
3. Pilot. Error rates and agreement measured; the spec revised where disagreement is systematic.
4. Production with QA. Hidden gold pages in every queue, double transcription on a sample, adjudication and rework loops.
5. Scale and delivery. Files in your schema, with quality reporting and an audit trail on every task.

Quality control for Arabic OCR training data

• Gold pages from your documents, not generic test sheets, for calibration and hidden checks, plus agreement between independent transcribers.
• Reported by slice: printed vs handwritten, Arabic vs Latin runs, document type, capture quality. A blended rate can hide failing digits on phone photos, so targets are set per slice.
• Adjudication and rework: a senior native linguist resolves disagreements, repeated disagreement changes the spec, and failed items are reworked.

Security and residency for IDs, invoices and records

An ID card or bank statement is almost entirely personal data. Pages are hosted in-region by default, with on-prem and private-cloud options. Access is least-privilege, actions are logged, and contributors work under NDA. Our PDPL and data residency checklist lists the questions to ask before the first upload.

Arabic document AI use cases by industry

By industry: KYC on IDs, Iqamas and commercial registrations, statements and bilingual invoices in banking; archive digitization with Hijri dates, stamps and handwritten notes in government; contracts and court documents in legal; lab reports and handwritten prescriptions, reviewed by licensed physicians, in healthcare; receipts, packaging and newspaper archives in media and retail.

When to automate Arabic OCR labeling, and when to use human annotators

In the KITAB-Bench paper (February 2025), modern vision-language systems such as GPT-4o and Gemini outperformed traditional OCR engines (EasyOCR, PaddleOCR, Surya) by an average of 60% in character error rate, yet the best model, Gemini-2.0-Flash, reached only 65% accuracy on PDF-to-Markdown conversion. Model rankings move quickly, so treat these figures as a snapshot. Our LabelBench audit covers text labels, not OCR, but shows a similar gap: on the fixed held-out manifest, a local language model at 78% exact-match accuracy on binary Arabic toxicity fell to 25.3% on the real multi-label taxonomy. We decide with Safe Automation Coverage: the fraction of a queue that can be accepted while the 95% Wilson lower confidence bound on accuracy stays above a declared target.

Synthetic rendered pages add fonts, not real scanners or hands: see the limits of synthetic data.

In-house team vs crowd platform vs specialist vendor

Full scorecard: how to choose an Arabic data annotation vendor.

Pilot terms

A pilot has a fixed scope: one or two document types, an agreed set of your pages and the spec. It includes gold-standard QA and ends with a quality report: error rates by slice, an error taxonomy, spec revisions and how many pages could safely be pre-labeled. It usually completes within two weeks. To scope one through our contact page, send sample pages, your schema, volumes and residency constraints. Work then scales as a managed, embedded or enterprise engagement, alongside our wider Arabic data annotation services.