01
UBL 2.1 XML
The invoice is a structured XML document in ZATCA’s prescribed format, built on UBL 2.1. A PDF is a rendering of an invoice, not the invoice.
KSA compliance · ZATCA · Fatoora
The mandate is settled. The specification is not.
Phase 2 has been rolling out since January 2023 and enforcement has been in effect since July 2026. If you are an established business in the Kingdom you integrated years ago — this is an operating standard you already meet. What has moved since is the specification you built against.
Status
In force. Full enforcement since 1 July 2026.
SAR 5,000 to SAR 50,000 for non-compliance
Last reviewed
The state of the mandate
Where the regime stands today.
These are milestones, not deadlines. They describe what the mandate already requires rather than anything still ahead of an established taxpayer.
4 December 2021
In effect
Phase 1 (Generation) enforceable
Compliant electronic invoice generation became enforceable for all VAT-registered taxpayers.
1 January 2023
In effect
Phase 2 (Integration) began
Integration with ZATCA began, rolled out in waves by revenue rather than all at once.
19 May 2026
In effect
Technical specifications version three issued
Version three of the e-invoicing controls, requirements, technical specifications and procedural rules.
30 June 2026
In effect
Wave 24 integration closed
The final Wave 24 integration date, set by Governor Decision No. 287-99-1447, gazetted 26 September 2025.
1 July 2026
In effect
Full enforcement in effect
Enforcement in effect across integrated taxpayers, with penalties from SAR 5,000 to SAR 50,000.
Still ahead — and probably not for you
1 February 2027
Announced
Wave 25 integration deadline
Taxpayers in the announced wave · SAR 187,500 or more in any of 2022–2025
Announced 24 July 2026. The threshold halves to SAR 187,500, measured on revenue in any of 2022, 2023, 2024 or 2025. This wave reaches small businesses previously out of scope — it is not an enterprise-segment obligation.
What Phase 2 requires
Six things that have to be true of every document.
Phase 2 is not a transmission requirement with formatting attached. Four of the six below exist specifically so that tampering with invoice history is detectable after the fact.
02
A 128-bit UUID per invoice
Every invoice carries a globally unique identifier generated by the issuing system, so no two invoices anywhere share an identity. It is ZATCA’s key for the document, distinct from your own invoice number.
03
A non-resetting Invoice Counter Value
A sequential integer starting at one, held per device or per E-Invoicing Generation Suite, that never resets. Its purpose is detection: a gap in the sequence is evidence that an invoice was removed.
04
A Previous Invoice Hash chaining each to the last
Each invoice carries a SHA-256 hash of the one before it, so the sequence forms a chain. Inserting or deleting an invoice after the fact breaks the chain and is detectable — which is the entire point of the mechanism.
05
A cryptographic stamp using a ZATCA-issued CSID
Invoices are digitally stamped with a Cryptographic Stamp Identifier — an X.509 certificate obtained from ZATCA. A compliance CSID is issued for onboarding and testing; a production CSID is what signs live documents.
06
A QR code carrying the stamp
A TLV-encoded QR code carrying seller name, VAT registration, timestamp, totals, the cryptographic stamp, the public key and the signature. It is not a convenience feature; it is how a document is verified in the field.
Clearance and reporting are different obligations
Standard invoices (B2B)
Cleared before issue
The invoice is submitted to Fatoora and must be cleared by ZATCA before it can be issued to the buyer. Clearance sits inside the transaction flow, not after it — an invoice that has not cleared is not an invoice yet.
Simplified invoices (B2C)
Reported within 24 hours
The invoice is issued to the customer immediately and reported to ZATCA within twenty-four hours of generation. The obligation is real but asynchronous, which is why point-of-sale flows are not blocked on a network round trip.
The specification is not static
Version three landed on 19 May 2026.
ZATCA issued the third version of the e-invoicing controls, requirements, technical specifications and procedural rules, covering tax invoice requirements, simplified tax invoices, self-billing arrangements and third-party invoicing.
This is the part that gets missed. The mandate has been stable for years, so integration is treated as finished work — but the rules it was built against have been revised three times. An integration delivered in 2023 was built to a different specification than the one in force today, and nothing about it fails loudly on the day that changes.
Being live is not the same as being current.
E-invoicing controls, requirements, technical specifications and procedural rules — version three — ZATCA →Inside NetSuite
Where this actually lands in the system.
The requirements above are ZATCA’s. What follows is where they land inside NetSuite — the fields, the entity boundaries and the user permissions that decide whether a compliant document is produced or a broken chain is.
Our reading, not ZATCA’s text. This section is written from implementation experience rather than quoted from the specification. The requirements it maps to are sourced below; the mapping itself is ours.
01
Invoice numbering and the counter are not the same field
The first thing an audit finds.
- The Invoice Counter Value is a compliance artefact that never resets — it is not your document number, and driving it from NetSuite’s numbering sequence is how counters end up resetting at year end.
- The counter is held per device or EGS, so a single logical company issuing from several sources needs its scope decided deliberately rather than inherited.
- Renumbering or re-issuing a document in NetSuite has to leave the counter untouched, which constrains how amendments are handled upstream.
02
Hash chaining across a OneWorld group
Each entity clears separately, so each entity has its own chain.
- A multi-subsidiary group does not have one chain — each clearing entity maintains its own, and the Previous Invoice Hash has to resolve per entity at transaction time.
- Subsidiary-level VAT registration, numbering and templates all have to resolve consistently with whichever chain the document belongs to.
- A shared numbering scheme across subsidiaries is workable; a shared counter or a shared chain is not.
03
Credit and debit notes are in scope
They clear too, and they carry references.
- Credit and debit notes are cleared or reported on the same basis as the invoice they adjust, and they take their place in the chain like any other document.
- Each must cite the document it adjusts, so the reference has to be a structured field rather than free text in a memo line.
- Adjustment flows that currently net off through journal entries produce no document at all, which is a gap rather than a simplification.
04
Self-billing and third-party invoicing
Both are addressed in version three, and both change who issues.
- Under self-billing the buyer raises the document on the supplier’s behalf, which means agreements, permissions and numbering all have to be represented rather than assumed.
- Third-party invoicing puts an agent in the issuing position, with the same consequences for stamping and for whose chain the document joins.
- Neither arrangement is a variant of the standard flow that can be handled by a template change.
05
What breaks when a document is voided or amended after clearance
The most common source of a broken chain in a live system.
- A cleared invoice cannot simply be voided in the ledger — the document exists at ZATCA, and reversing it locally puts the two out of step.
- Deleting or renumbering after clearance is what breaks the hash chain, and the break is detectable by design.
- Correction has to run through credit and debit notes rather than through edits, which usually means changing what finance users are permitted to do, not only what the integration sends.
Delivered in production
ZATCA integration on NetSuite, live.
Not a capability statement. These are builds where ZATCA integration was configured as part of the programme and is running.
Sources
- E-invoicing controls, requirements, technical specifications and procedural rules — version three — Zakat, Tax and Customs Authority (ZATCA), 2026-05-19
- Detailed Guidelines for E-Invoicing — technical and procedural requirements — Zakat, Tax and Customs Authority (ZATCA)
- E-invoicing (Fatoora) programme — regulations, waves and implementing resolutions — Zakat, Tax and Customs Authority (ZATCA)
- Wave 25 announcement — SAR 187,500 threshold, integration by 1 February 2027 — Zakat, Tax and Customs Authority (ZATCA), 2026-07-24
Have your integration read against the current specification.
We review what your system produces today — the counter, the chain, the stamp, the clearance flow and the document types added in version three — against the specification in force rather than the one it was built to. You get the differences, ranked by exposure. If nothing has drifted, that is the answer.