ZATCA e-invoicing (Fatoora): validate your invoices before you submit

Saudi Arabia's tax authority ZATCA mandates electronic invoicing (Fatoora) for VAT-registered businesses. Phase 1 (Generation) required structured e-invoices with a QR code; Phase 2 (Integration) requires invoices to be produced as UBL 2.1 XML, cryptographically stamped, and cleared or reported through ZATCA's platform — rolled out in successive waves by taxpayer size.

A PDF is not enough: the invoice must be a UBL 2.1 XML that satisfies EN 16931 plus Saudi-specific BR-KSA rules, otherwise ZATCA rejects it at clearance/reporting.

ZATCA builds on the European semantic standard EN 16931, expressed in UBL 2.1 syntax, and adds over a hundred Saudi-specific business rules (BR-KSA): SAR tax currency, seller VAT number format (15 digits starting and ending with 3), building number when the party country is SA, the Previous Invoice Hash (PIH) that chains each invoice to the last, QR TLV structure, and tax/rounding rules.

This validator checks the UBL structure, EN 16931 core rules and a growing set of BR-KSA rules, and explains each failure in plain language.

The most common ZATCA rejections are missing UUID or Previous Invoice Hash, a tax currency that is not SAR, a missing building number for Saudi addresses, an invalid seller VAT number, and totals or VAT amounts that do not reconcile.

Most of these are business-rule failures that a plain XSD check never catches — so a UBL that 'looks valid' can still be rejected.

Validate the UBL your ERP or middleware produces against EN 16931 + BR-KSA before it reaches ZATCA's clearance/reporting API, so non-compliant invoices are caught in your pipeline, not by the regulator.

This is a pre-submission validator — it does not sign, generate the QR, or clear invoices; those stay in your ZATCA integration.