Bayanat Labs Synthetic Saudi E-Invoices, Receipts and Bilingual Forms

synthetic Arabic invoices Saudi e-invoice data UBL XML key information extraction Arabic OCR document question answering

Key numbers

Counted by script from the released files. Each key number is read from meta/stats.json, meta/gates_summary.json or meta/baseline_results.json of the Hugging Face dataset at revision 4eb6531b76ac77377a4a42dde98ba186b256bcad and pinned to its SHA-256; percentages and three-decimal scores are computed from those files and rounded half up, as the dataset card writes them. Code at tag v0.1.0, commit 0dbe24707b773b3c51371ff7adebc2ddf5bfb48c. MANIFEST.json lists every file with its size and SHA-256.

Downloads and identifiers

Get started

Load a config with the datasets library. The generator, the validators and the converters install from GitHub at the v0.1.0 tag; the package is not on PyPI.

pip install datasets pillow huggingface_hub

from datasets import load_dataset
pages = load_dataset("Bayanat-Labs/saudi-einvoice-synth", "pages", split="test", streaming=True)

pip install "saudi-einvoice-synth[all] @ git+https://github.com/Bayanat-Labs/saudi-einvoice-synth@v0.1.0"

What is released

Attribution: Synthetic Saudi E-Invoices, Receipts and Bilingual Forms by Bayanat Labs, CC BY 4.0. City and district names from the Bayanat Labs Arabic Gazetteer (CC BY 4.0), which takes them from GeoNames (CC BY 4.0) and Wikidata (CC0 1.0). https://huggingface.co/datasets/Bayanat-Labs/saudi-einvoice-synth

Intended uses

• Train and test OCR, key information extraction and document question answering on Saudi-style invoices, receipts and bilingual forms, with field boxes on the clean page and on each degraded variant.
• Test a model on layouts it has not seen, with the template families held out of train (10 only in test, 5 only in validation).
• Develop parsers for UBL XML and TLV QR codes on the xml config.

Out of scope

• Producing, validating or submitting real tax invoices: every page says it is not a valid tax invoice, and signatures are test signatures, not valid for submission.
• Reading the checks here as what the ZATCA SDK or a ZATCA system would report: the SDK was not run, and no file was ever sent to a ZATCA system.
• Reading results on these generated pages as results on real invoices: degraded variants are simulated, and the gap to real invoices has not been measured.

Rights at a glance

Training, display, redistribution and synthetic-voice use are separate permissions.

Limitations

• Everything was generated: every party, identifier, product and amount. Every page carries the footer "Synthetic research sample — not a valid tax invoice". The data is for research; it is not for producing, validating or submitting real tax invoices.
• Person names are random combinations of Arabic given and family names. Full names were compared with the names of people from Wikidata, through the Bayanat Labs Arabic Entity Atlas and Arab-World Wikidata Slice, in Arabic and English, and exact matches after normalisation were removed. A generated name can still match a real person, and anyone can report it to hello@bayanatlabs.com.
• Organisation names were compared with names in Wikidata: 13,065 Arabic and 13,048 English names, 0 matches. A generated name can still match a small real business; report it to hello@bayanatlabs.com.
• VAT numbers have the fifteen-digit form the XML rules require; the dataset card gives the pattern. No register was consulted, so a match with a real registration cannot be ruled out; anyone can report one to hello@bayanatlabs.com.
• The ZATCA SDK was not run, because its download page requires accepting terms and conditions, which this project did not do. What was run instead: validation against the OASIS UBL 2.1 schemas and a separate check of the published KSA business rules, written for this project. All 22,450 XML documents pass both; that says nothing about what the SDK or a ZATCA system would report. Signatures are test signatures with a self-generated key, not valid for submission. No file was ever sent to a ZATCA system.
• 24,050 records with amounts reconcile exactly, and the QR code read back from all 22,450 clean pages that carry one equals the XML value. The QR decoder has a limit of 60 seconds per image with one retry; an image that runs out of time counts as unread in the read rates on degraded images, which the dataset card gives, and this happened to one image.
• The OCR check on boxes uses Tesseract's tessdata_best models and keeps the most favourable of up to ten settings per box: 98.99% of the boxes it covers have a character error rate of at most ten per cent. It leaves out 390,028 boxes in Arabic-Indic digits, which only get an ink check. So it shows that boxes sit on readable text in the most favourable case; it does not measure what an OCR engine reads at one setting, which the reference baseline does.
• The PDF text check covers values without Arabic letters, and all of them are found; over all values the rate is 94.82%, because the Arabic text layer of the source PDFs is not reliable in some fonts. Use the labels, not the PDF text layer, as the Arabic text.
• In 26 of the 60 template families the line table has no discount column, so a discounted line prints only its amount after the discount and the discount itself is not printed. Quantity times price then differs from the printed amount: 11,521 of those families' 78,171 lines (5,537 of their 10,200 records). The discount is in the canonical record and in the XML.
• Images need not rebuild byte for byte: in the shard built twice (500 of 25,000 records), 68 of 2,792 images differ, and every PDF embeds its creation time; the comparison covers that shard only. 73 seeds use a second draw: 71 to remove near-duplicates and two because the table of the earlier draw did not fit the page. Rows name the commit that built them, three commits in all, each in the history of tag v0.1.0. The later commits add only a time limit in the QR check, those two second draws and documentation, and the tag reproduces the records of every shard.
• Labels have the status machine_validated: they passed scripted checks, and no reviewer has gone through them. Degraded variants are simulated: the release has no print-and-scan subset and no hidden test split, and the gap to real invoices has not been measured.
• The reference baseline is a sample, not a product and not a benchmark of Tesseract in general: Tesseract with tessdata_fast models on 1,000 validation and test records drawn with a stated seed across all shards; their ids are in the dataset's meta/baseline_sample.json. Mean character error rate on value boxes without Arabic-Indic digits: 0.103 on clean pages, 0.125 on scan and 0.192 on photo variants. Field-level F1 for five fields, using OCR and rules on page one only (totals are on a later page for 213 of 572 A4 documents, where those two fields cannot score): 0.705 on clean, 0.699 on scan and 0.584 on photo; on clean pages, 0.698 on template families also in train and 0.709 on families only in validation or test. Nothing was trained, and the rules were written for these layouts.

Sources and licences

No real invoice, receipt or form went into this dataset. Field values, catalogue items and questions come from written lexicons and rules; city and district names are real, from the gazetteer, and streets are generated combinations of words. The sources and versions of what went into the build are in the dataset's meta/PROVENANCE.jsonl. Source details

How to cite

Cite as:

Bayanat Labs (2026). Synthetic Saudi E-Invoices, Receipts and Bilingual Forms, version 0.1.0. Bayanat Labs. https://huggingface.co/datasets/Bayanat-Labs/saudi-einvoice-synth

• CITATION.cff

No DOI. Cite the URL in the citation above and the date you read it.

@misc{bayanatlabs2026saudieinvoicesynth,
  author       = {{Bayanat Labs}},
  title        = {Synthetic Saudi E-Invoices, Receipts and Bilingual Forms, version 0.1.0},
  year         = {2026},
  month        = nov,
  howpublished = {\url{https://huggingface.co/datasets/Bayanat-Labs/saudi-einvoice-synth}}
}

How we handle citations

Changelog

Corrections and removal requests

If something in this release should not be there, or is wrong, email hello@bayanatlabs.com. We handle removal requests within 30 days, and platform requests within 24 hours. How removal requests work

Related product: Bayanat Documents