ZATCA Phase 2 Integration: Engineering Guide (Wave 25)

# ZATCA Phase 2 (Fatoora) Integration: An Engineering Guide

Short answer: ZATCA Phase 2 requires your billing system to issue invoices as

cryptographically signed UBL 2.1 XML and exchange them with ZATCA's Fatoora platform over

an authenticated API. Standard (B2B) invoices must be cleared by ZATCA before you send

them to the buyer. Simplified (B2C) invoices must be reported within 24 hours. Wave 25 —

businesses above SAR 187,500 in VAT-taxable revenue — must integrate by 1 February 2027.

---

Who is in scope right now

ZATCA has rolled Phase 2 out in waves, each one lowering the revenue threshold. The

threshold is met if VAT-taxable revenue exceeded the figure in any of the qualifying

years, not the most recent one.

Wave 25 was announced on 24 July 2026 and halves the previous threshold. At SAR 187,500 it

reaches most VAT-registered businesses in the Kingdom — at this level, "are we in scope"

has effectively become "yes, and when".

If you are reading this before February 2027 and have not started, the honest timeline

matters: a first integration against Fatoora is rarely a two-week job, and the compliance

simulation portal will reject invoices for reasons that take time to diagnose.

Verify before you rely on this. Wave criteria and dates come from ZATCA and change.

Check zatca.gov.sa for your wave before planning against these

dates, and expect further waves below SAR 187,500.

---

Phase 1 and Phase 2 are different problems

Phase 1 (Generation, live since December 2021) required you to stop issuing handwritten and

free-text invoices, and to produce a structured electronic invoice with a QR code. It was a

change to your output.

Phase 2 (Integration) is a change to your architecture. Your system now has to talk to

ZATCA in the invoice's critical path. That introduces a network dependency into a workflow

that previously had none, and it is the single biggest source of surprise for teams who

scoped Phase 2 as "add some XML".

---

Two invoice types, two completely different flows

This distinction drives most of the architecture, and getting it wrong is the most expensive

mistake available.

Standard tax invoices (B2B) — clearance

A Standard invoice must be submitted to ZATCA and cleared before it is given to the buyer.

ZATCA validates it and returns it carrying a cryptographic stamp. Only the cleared,

stamped invoice is legally valid. An uncleared invoice is not an invoice you may issue.

Clearance is therefore synchronous and blocking. Your checkout, billing run or ERP

posting cannot complete until ZATCA responds. Design for that: timeouts, retries, a queue,

and an explicit decision about what your business does when Fatoora is unreachable.

Simplified tax invoices (B2C) — reporting

A Simplified invoice is issued to the buyer immediately, then reported to ZATCA within 24

hours. Reporting is asynchronous. The customer walks away with a valid receipt; your

system submits it afterwards.

This is a far kinder design constraint, and it is why point-of-sale systems can keep

operating through a network outage while an ERP issuing B2B invoices cannot.

The architectural consequence: if you serve both B2B and B2C, you are building two

pipelines with different availability requirements, not one pipeline with a flag.

---

What your system must actually produce

A compliant invoice is not "XML with the right fields". Each of these is independently

capable of causing rejection:

• UBL 2.1 XML — the invoice must be generated in this format. PDF/A-3 with an embedded

XML file is the accepted alternative. Converting a PDF to XML after the fact does not

satisfy the requirement; the structured document is the invoice, and the human-readable

rendering is a by-product.

• A UUID per invoice, distinct from your own invoice numbering.
• A cryptographic stamp, applied using a certificate ZATCA issues to your solution.
• A hash chain — each invoice carries the hash of the previous one, making the sequence

tamper-evident. This is the requirement that most often breaks in practice, because it

makes your invoice sequence stateful. See the failure modes below.

• A TLV-encoded QR code carrying the seller's name and VAT number, the timestamp, the

total with VAT, the VAT amount, and hash and signature data.

• The correct invoice subtype flags distinguishing Standard from Simplified, and

correctly typed credit and debit notes.

---

Onboarding: CSR to CSID

Before you can transmit anything, each invoicing solution unit must be registered with

ZATCA. The shape of it:

1. Generate a key pair and a Certificate Signing Request identifying the solution unit.

2. Submit the CSR to ZATCA with a one-time code obtained from the Fatoora portal.

3. Receive a Compliance CSID — valid only for the compliance simulation stage.

4. Pass ZATCA's compliance checks by submitting sample invoices of each type you intend to

issue, including the credit and debit note variants.

5. Receive your Production CSID, which is what signs live invoices.

Two things teams routinely get wrong here. First, the CSID is per solution unit, not per

company — if you run three POS terminals and an ERP, that is four onboardings, four key

pairs, and four certificates to store and rotate. Second, certificates expire. An

integration with no renewal path is a production outage scheduled in advance.

---

Where implementations actually fail

These are the issues that consume the schedule, and none of them appear in a requirements

summary.

The hash chain makes invoicing stateful. Each invoice references the previous invoice's

hash, per solution unit. That means invoice generation can no longer be a stateless,

horizontally scaled, fire-and-forget operation. Two workers generating invoices concurrently

for the same unit will produce a broken chain. You need a serialisation point — a per-unit

queue, an advisory lock, or a single writer. Teams discover this under load, in production,

which is the worst possible time.

Clearance failure has no good default. ZATCA is unreachable mid-billing-run: do you

block the sale, queue and retry, or issue and reconcile? Only one of these is compliant for

a Standard invoice, and it is the one your commercial team will like least. Decide it

deliberately, with the business in the room, and write it down.

Credit and debit notes are not invoices with a minus sign. They are separate document

types with their own required references to the original invoice. Systems that model them

as negative invoices fail compliance checks late, after the happy path already passed.

Arabic is mandatory in the invoice itself. Arabic is required for the invoice content.

If your item descriptions, tax categories and totals are English-only in the database, that

is a data problem, not a rendering problem, and it is slow to fix retroactively.

Rounding and VAT calculation are specified. Line-level versus document-level rounding

differences of a halala will fail validation. Match the specification exactly rather than

inheriting whatever your ORM's decimal handling does.

Clock accuracy matters. Timestamps are part of signed content and of the 24-hour

reporting window. A drifting server clock produces invoices that fail validation for reasons

that look nothing like a clock problem.

---

Two integration architectures

Direct integration. Your system holds the certificates, builds the XML, signs, and calls

Fatoora itself. Full control, no per-invoice vendor cost, no third party in your invoice

path. You own certificate lifecycle, XML conformance, and keeping pace with ZATCA's

specification updates. This suits organisations with real engineering capacity and

non-standard invoicing logic.

Middleware or a certified provider. A vendor handles signing and transmission; you send

them invoice data. Faster to reach compliance and they absorb specification changes. You

accept a dependency in the critical path of your revenue, per-invoice pricing, and the

question of where your invoice data resides.

There is no universally correct answer. The deciding factors are usually how unusual your

invoicing logic is, whether you have engineers who can own a certificate lifecycle, and how

you feel about a third party sitting between your ERP and a tax authority. What does not

work is choosing middleware to avoid understanding the requirements — you still have to get

the invoice data right, and the failures still land on you.

---

Test properly before you go live

ZATCA provides a compliance simulation environment. Use it for more than the happy path:

• Every document type you will issue, including credit and debit notes.
• Arabic content with real item descriptions, not placeholders.
• The hash chain across a long sequence, and deliberately concurrent generation.
• Clearance timeout and rejection handling — force the failure and watch what your system

does.

• Certificate renewal, before it happens to you unplanned.

---

Penalties

Non-compliance carries financial penalties, and the practical exposure is not only the fine:

a Standard invoice that was never cleared is not a valid tax invoice, which creates a VAT

position problem for your customer as well as for you.

ZATCA runs a Cancellation of Fines and Exemption of Financial Penalties initiative,

which the Minister of Finance extended by six months from 1 July 2026. It

runs to 31 December 2026.

It covers fines for late registration, late payment, late filing, and penalties from

correcting VAT returns. To benefit you must be registered with ZATCA, have filed all

outstanding returns, and have paid the full principal of any outstanding liability.

Instalment plans are available if applied for before the initiative expires.

Read the exclusions carefully, because they are where the misunderstanding happens:

• It does not cover penalties on any return that becomes due after 30 June 2026.
• It does not cover tax evasion penalties, or fines under Article 45 of the VAT Law.
• It does not refund fines already paid before the initiative took effect.

That first exclusion matters most for anyone reading this as an integration safety net. The

initiative is a route to clearing historic exposure, not a grace period covering

obligations that fall due while you are still building. It does not extend your Wave 25

deadline, and it will not absorb penalties arising from invoices you should be clearing in

2027.

Confirm current status with ZATCA directly before relying on any of this — the end date has

already moved once.

---

Frequently asked questions

Am I in scope for ZATCA Phase 2?

If your VAT-taxable revenue exceeded SAR 187,500 in 2022, 2023, 2024 or 2025, you are in

Wave 25 and must integrate with Fatoora by 1 February 2027. Earlier waves covered higher

thresholds and have already passed. ZATCA notifies targeted taxpayers directly, but you

should not wait for the notification to begin work.

What is the difference between clearance and reporting?

Clearance applies to Standard (B2B) invoices: ZATCA must validate and stamp the invoice

before you send it to the buyer, so the call is synchronous and blocking. Reporting

applies to Simplified (B2C) invoices: you issue the invoice immediately and submit it to

ZATCA within 24 hours.

How long does a ZATCA Phase 2 integration take?

For a single, reasonably standard ERP, plan in months rather than weeks. The XML generation

is the straightforward part. The schedule goes on the hash chain's concurrency implications,

credit and debit note modelling, Arabic content in existing data, certificate lifecycle per

solution unit, and deciding what happens when clearance fails.

Can I convert my existing PDF invoices to XML?

No. The structured UBL 2.1 XML document is the invoice. A PDF converted after the fact does

not satisfy the requirement. PDF/A-3 with a genuinely embedded XML invoice is accepted.

Do we need one certificate or several?

One per invoicing solution unit. Separate POS terminals and an ERP each need their own

onboarding, key pair and CSID, along with a plan for renewing every one of them.

---

*Last verified against zatca.gov.sa on 14 September 2026. Wave

criteria and deadlines change; confirm your own position with ZATCA before acting on this

guide.*