ZATCA Phase 2: What Integration Actually Requires
Phase 1 asked you to produce a structured invoice. Phase 2 asks your system to talk to ZATCA directly, sign every document, and chain them together. That is a different engineering problem.
Business Transformation3 min read
Phase 1 of Saudi e-invoicing was a formatting exercise. Phase 2 — the Integration Phase, in force since January 2023 and rolling out in waves by turnover — is a systems-integration project, and teams routinely underestimate it because the word "invoice" makes it sound like an accounting change.
The two invoice types behave differently
This is the distinction that shapes your architecture.
Standard invoices (B2B and B2G) go through clearance. You submit the invoice to ZATCA's Fatoora platform and wait for it to be cleared before it is legally issued to your customer. Your invoicing flow now contains a synchronous dependency on an external service.
Simplified invoices (B2C) are reported — submitted within 24 hours of issue. The customer gets their invoice immediately; the system reports afterwards.
The practical consequence: a B2C point of sale can keep working through a network outage and catch up. A B2B flow cannot issue at all if clearance is unavailable. Those need different retry, queueing and failure-handling designs, and treating them the same is where projects come unstuck.
What the technical requirements actually mean
- UBL 2.1 XML — invoices are generated as XML, or PDF/A-3 with the XML embedded. Your existing PDF template is not the invoice any more; it is a rendering of it.
- Cryptographic stamps — each document is signed. That means certificate provisioning, storage and renewal become part of your operational runbook, not a one-time setup step.
- UUIDs and previous-invoice hashes — each invoice references the hash of the one before it, forming a chain. This is the requirement most likely to break a naive implementation: it means invoice generation cannot be casually parallelised, and restoring from a backup mid-sequence needs care.
That hash chain deserves emphasis. It imposes ordering on a process most systems treat as independent. If two workers can generate invoices simultaneously, you have a correctness problem that will not appear in testing at low volume.
The thresholds keep coming down
The waves are defined by turnover in 2022, 2023 or 2024 — and crucially, exceeding the threshold in any of those years triggers the obligation, regardless of current revenue. Wave 23 covers businesses above SAR 750,000 with a deadline of 31 March 2026. Wave 24 drops the threshold to SAR 375,000, with integration required by 30 June 2026.
That second number brings a very large number of small businesses into scope. If you were previously below the line, check the historical years rather than the current one.
Scoping the work honestly
A realistic Phase 2 project has four workstreams, and only one of them is about invoices:
- Data quality — VAT numbers, addresses and item descriptions that were "good enough" for a PDF now have to satisfy a schema validator.
- Integration — API connectivity, certificate lifecycle, retry and queueing.
- Failure handling — what a cashier or a salesperson sees when clearance fails, and what happens to the sale.
- Archival — signed XML has to be stored and retrievable, not just printed.
Most overruns come from workstream one. Teams budget for the API and discover their customer master data cannot pass validation.
A note on buying versus building
Most businesses should integrate through their existing ERP or an established provider rather than implement signing and clearance themselves. The regulation will keep evolving, and maintaining a compliance implementation is an ongoing commitment, not a delivery.
What you should not outsource is the data. Clean master data is the part that stays valuable regardless of which vendor you use.
Need Phase 2 integration scoped against your actual invoicing flow? Start a project.