Arabic tax invoices for the UAE and Saudi Arabia

Send the invoice as JSON. Back comes a bilingual Arabic and English tax invoice with the VAT arithmetic checked, the amount in Arabic words, the Hijri date and, for Saudi Arabia, the ZATCA QR read back from the finished document.

Samples go through the playground: no key, about 6 requests a minute.

What is in the document

Bilingual layout. Arabic first, English beside it, every number, date and tax number isolated so it cannot jump to the wrong end of a line.
VAT arithmetic. VAT per line, rounded half-up, and totals that are the sums. Send your own totals and a mismatch fails the gate instead of reaching your customer.
The amount in Arabic words. فقط ألف وأربعمائة وسبعة دراهم إماراتية لا غير, with the number–noun agreement Arabic grammar requires: ثلاثة دراهم، أحد عشر درهمًا، مائتا درهم.
Dates. Gregorian, and Umm al-Qura Hijri on Saudi invoices (optional in the UAE).
Foreign currency. Invoice in dollars and the VAT and total are also shown in dirhams or riyals at your exchange rate.
The QR, proved. For Saudi Arabia the QR is drawn into the document, then read back from the rendered pixels and decoded: seller, VAT number, total and VAT must match the invoice.

Free tool: amounts in Arabic words.

Invoice gates

Every invoice with verify carries the usual text-layer gates (G0–G7) plus five of its own.

I1 · Required fields: The particulars the country and invoice type require: seller address and tax number, buyer details on a full invoice, the buyer's VAT number on a Saudi standard invoice, an exchange rate for foreign currency. A UAE simplified invoice to a VAT-registered buyer over AED 10,000 fails.
I2 · Arithmetic: Line VAT and totals recomputed; your own totals, if sent, must match to the fil or halala. Unusual VAT rates are reported.
I3 · QR: Saudi Arabia: the QR is read back from the finished document and its TLV decoded; tags 1–5 must describe this invoice, and the Phase 2 signature tags are reported. The TLV length byte counts UTF-8 bytes, which is where Arabic seller names break other encoders.
I4 · Identifiers: UAE TRN: 15 digits starting with 1. Saudi VAT number: 15 digits, first and last 3.
I5 · Text layer: The invoice number, the seller's tax number and the total must extract from the PDF exactly as written, in poppler and PyMuPDF. That is what an auditor's tool, a search index or an accounting import will read.

What it is not

Not an e-invoicing provider. Tanqeet never signs, clears or reports invoices, and never holds your cryptographic certificate.

Saudi Arabia (ZATCA Phase 2). Every VAT-registered business now issues invoices from its own e-invoicing unit. Send the QR that unit produced as zatca_qr: Tanqeet renders it and proves it describes this invoice. A Phase 1 QR (tags 1–5) is generated only if you ask, for sellers outside Phase 2.

UAE. Until your e-invoicing date (1 January 2027 for revenue of AED 50 million or more, 1 July 2027 for everyone else) the PDF is the tax invoice. After it, the legal invoice is the PINT AE XML sent through an accredited service provider, and this PDF is the copy people read, which still has to read correctly.

The call

POST /v1/invoice/pdf or /v1/invoice/png. Every field is in the docs. One invoice is one document on every plan. With strict, a failed gate returns 422 and the report instead of a PDF.

bash

curl -X POST https://api.tanqeet.smeepo.com/v1/invoice/pdf \
  -H "Authorization: Bearer $TANQEET_KEY" -H "Content-Type: application/json" \
  -d '{
    "country": "SA",
    "number": "SA-2026-0001",
    "issued_at": "2026-09-10T14:05:00",
    "seller": {"name_ar": "شركة الرياض للتقنية", "tax_number": "310123456700003", "address_ar": "الرياض"},
    "buyer":  {"name_ar": "مؤسسة جدة التجارية", "tax_number": "300987654300003", "address_ar": "جدة"},
    "lines":  [{"description_ar": "اشتراك شهري", "unit_price": "1000.00"}],
    "zatca_qr": "AR3YtNix2YPYqSDYp9mE2LHZitin2LYg2YTZhNiq2YLZhtmK2KkCDzMxMDEy…",
    "totals": {"total": "1150.00"},
    "verify": true
  }'