What this template emits
A UBL 2.1 invoice conformant to ZATCA Phase 2 standards. The invoice carries a bilingual visual leg (Arabic on the left, English on the right) and a structured XML leg suitable for submission to the ZATCA Fatoora platform.
Phase 2 added three integration requirements on top of Phase 1's QR-only mandate:
- Embedded UBL 2.1 XML with ZATCA-specific extensions for the profile, invoice type, and additional document references.
- A cryptographic stamp generated against a ZATCA-issued certificate, linking the invoice to the issuer's tax registration.
- A QR code containing TLV-encoded data: seller name, VAT registration, invoice timestamp, total, VAT amount, the XML hash, and the digital signature.
This template's XML emitter handles items 1 and 3 (TLV placeholder). The cryptographic stamp requires a private key issued by ZATCA's Compliance Portal and is generated at signing time on the Pro tier.
Arabic rendering moat
ZATCA expects the registered name in Arabic on the structured XML. Most PDF generators built on DOMPDF or TCPDF cannot render Arabic right-to-left correctly without third-party shaping libraries; characters appear isolated or in the wrong order. LightningPDF's Chromium engine renders Arabic the same way Chrome does, with proper ligatures, contextual letter forms, and RTL text flow. No font configuration, no add-on.
The English trading name and the Arabic registered name typically appear on the same invoice. The bilingual layout puts them in adjacent columns.
Validation status
The full ZATCA validator ships only in the Fatoora SDK and requires registered-taxpayer access to the portal. On 2026-06-03 we ran a structural conformance check against the 11 ZATCA-required elements (ProfileID clearance:1.0, UUID, IssueDate, IssueTime, InvoiceTypeCode with @name, TaxCurrencyCode SAR, AdditionalDocumentReference entries for ICV / PIH / QR, bilingual Arabic + English content). All 11 checks pass. Result file: test-results/validators/zatca/structural-checks.json.
The full Schematron run will be added once we have Fatoora portal access; at that point we will also wire the cryptographic stamp signing with a real certificate (currently a placeholder in the XML).
Submission flow
For B2B (standard) invoices on the clearance profile:
- The issuer generates the invoice locally.
- The XML is signed with the issuer's certificate.
- The signed XML is submitted to ZATCA's Fatoora platform.
- Fatoora returns a cleared invoice hash; the issuer's PDF carries this hash in the QR code.
- The PDF is delivered to the buyer; the buyer's accounting software reads the QR for verification.
For B2C (simplified) invoices on the reporting profile, the QR code is computed locally and the invoice is reported to Fatoora within 24 hours rather than cleared in real time.
Frequently asked questions
Does this template handle Phase 1 (the QR-only requirement) too?
Yes. Phase 1 only required the QR code; Phase 2 added the embedded XML and cryptographic stamp. The template emits both. Receivers in Phase 1-only mode can ignore the XML attachment.
Can I integrate without a Fatoora certificate?
The XML is emittable without a certificate; the cryptographic stamp is not. For testing, ZATCA's sandbox issues test certificates. Production submission requires the real Compliance Portal credentials.
What about other GCC countries?
The UAE Federal Tax Authority published a separate e-invoicing framework expected to enter mandatory operation across 2026-2027. The UAE PINT (Peppol International Invoice) profile shares the EN 16931 base; a UAE-specific template will follow the same emitter pattern.