ZATCA e-invoice QR (Saudi FATOORA)

ZATCA (Zakat, Tax and Customs Authority) of Saudi Arabia mandates a QR on every tax invoice issued in the Kingdom. Phase 1 is simplified TLV; Phase 2 adds cryptographic sealing via integration with the FATOORA platform. Non-compliant invoices are refused by the buyer's accounting software and invalid for VAT reclaim.

Canonical spec: ZATCA E-Invoicing Resolution & Implementing Regulations — current through 2026.
Phase 1 (Generation): in effect since 4 December 2021. All VAT-registered businesses must issue digital invoices with the QR.
Phase 2 (Integration): rolling out by business-size wave since 1 January 2023. Adds digital signature + ZATCA clearance for standard invoices and real-time reporting for simplified invoices.

What it is

The QR encodes a Base64 string. Decode the Base64 to get a binary TLV sequence with 5 mandatory fields in fixed order:

Tag	Field	Type	Notes
`01`	Seller name	UTF-8 string	Commercial name of the seller. Arabic and Latin both accepted.
`02`	VAT registration number	15 digits	Starts with `3` for Saudi entities. Format: `3XXXXXXXXXXXXX3`.
`03`	Invoice timestamp	ISO 8601	e.g. `2026-04-18T10:30:00Z`. Must include timezone.
`04`	Invoice total (with VAT)	Decimal string	e.g. `115.00`. Currency is implicitly SAR.
`05`	VAT amount	Decimal string	e.g. `15.00`. Currently 15% standard rate.
`06`	Invoice hash (Phase 2)	Base64 SHA-256	SHA-256 of the canonical invoice XML.
`07`	Digital signature (Phase 2)	Base64	ECDSA over the invoice hash using the seller's CSID certificate.
`08`	Public key (Phase 2)	Base64 X.509	Seller's ECDSA public key (from the CSID).
`09`	ZATCA stamp (Phase 2)	Base64	ZATCA's countersignature. Present only after ZATCA clearance.

Each TLV record is 1 tag byte + 1 length byte + <length> value bytes. The whole sequence is then Base64-encoded to become the QR payload.

Phase 1 (simplified) vs Phase 2 (integration)

Aspect	Phase 1	Phase 2
QR content	Tags 01–05 only	Tags 01–05 plus 06, 07, 08, optionally 09
ZATCA integration	None — offline	Real-time API for simplified invoices, clearance flow for standard invoices
Certificates required	No	Yes — CSID (Cryptographic Stamp Identifier) issued by ZATCA
Effective date	2021-12-04 (all businesses)	2023-01-01 (rolling waves by revenue)
Invoice scope	B2C (simplified) + B2B (standard)	B2C simplified: real-time report. B2B standard: clearance (pre-validation) before issuing.

Canonical test vectors

Example TLV (before Base64):

01 0A "Acme Saudi" 02 0F "300000000000003" 03 14 "2026-04-18T10:30:00Z" 04 06 "115.00" 05 05 "15.00"

After Base64 encoding:

AQpBY21lIFNhdWRpAg8zMDAwMDAwMDAwMDAwMDMDFDIwMjYtMDQtMThUMTA6MzA6MDBaBAYxMTUuMDAFBTE1LjAw

Case	Inputs	Base64 prefix
Phase 1, minimal simplified	`seller=Acme Saudi vat=300000000000003 time=2026-04-18T10:30:00Z total=115.00 vat_amount=15.00`	`AQpBY21lIFNhdWRp...`
Arabic seller name	`seller=شركة أكمي vat=300000000000003 ...`	Seller name UTF-8-encoded inside TLV before Base64.
Phase 2 standard invoice	All of the above plus `hash=<SHA-256 Base64> signature=<ECDSA Base64> public_key=<X.509 Base64>`	Much longer Base64. Decoders must tolerate extra tags beyond 05.

Common pitfalls

VAT number length. ZATCA VAT numbers are exactly 15 digits, start and end with 3. Anything else fails validation at the invoice-ingestion side.
Timestamp without timezone. The spec requires ISO 8601 with an explicit zone (Z or +03:00). Naive-local timestamps are rejected.
Encoding order. TLV fields must appear in tag-number order (01, 02, 03, 04, 05, …). Reordering makes the QR decode successfully but some validators flag it as non-canonical.
Decimal formatting. Invoice total and VAT amount use dot-decimal (115.00), not comma-decimal (115,00). Also no thousands separators.
Currency is implicit SAR. Foreign-currency invoices still convert to SAR for the QR field. The underlying XML may carry the original currency; the QR does not.
Phase 2 clearance failures. A standard invoice submitted to ZATCA's clearance API can be rejected (bad CSID, malformed XML, tax math wrong). The invoice is legally invalid until cleared. Keep a retry loop with exponential back-off; do not issue the invoice until clearance succeeds.
CSID certificate rotation. Phase 2 CSIDs expire (typically 1 year). Build a renewal check into your e-invoicing stack or you'll suddenly stop being able to issue invoices.

Scanner compatibility

Reader	Support	Notes
ZATCA FATOORA app	Native	Official Ministry app; verifies Phase 2 signatures against the ZATCA PKI.
Saudi accounting software (SAP B1, Oracle, Microsoft Dynamics)	Native (post-2023)	Localised Saudi builds have ZATCA parsing in the AP pipeline.
iOS Camera	Raw Base64	Not recognised as a tax invoice. User must open the FATOORA app.
Android Camera / Google Lens	Raw Base64	Same — no native parsing.
Third-party audit tools (PwC, KPMG, Deloitte Saudi units)	Native	Audit-technology suites parse + verify Phase 2 signatures.