ZATCA phase two, in plain language

ZATCA phase 2, the integration phase of Fatoora, isn't a policy announcement anymore. It's the reason your invoicing system now needs to talk to a government platform before an invoice can legally exist. For a mid-size company running invoicing through a mix of ERP exports, PDFs, and manual entry, that's a real engineering job, not a checkbox on your VAT filing.

The mechanics are specific. The cost of putting it off is specific too. Delay long enough and integration stops being a project you plan and becomes a fire you fight during a filing deadline.

What ZATCA phase 2 integration actually requires

Phase one just asked you to generate e-invoices with a QR code. Phase two, the integration phase, connects your system directly to ZATCA. Every invoice you issue has to be generated in a structured XML format (UBL 2.1), stamped with a cryptographic signature tied to a device-specific certificate ZATCA issues you, and either cleared or reported through ZATCA's platform depending on whether it's a standard B2B invoice or a simplified B2C one.

That means your point of sale, your ERP, or whatever generates invoices today needs a new layer in between: one that builds the XML, signs it, generates the compliant QR, and sends it to ZATCA's API before (for standard invoices) or shortly after (for simplified ones) the invoice reaches your customer. If any of those steps fail, you don't have a valid tax invoice. You have a PDF.

Getting there involves a compliance step with ZATCA itself: registering your invoicing solution, generating cryptographic keys, and running through a sandbox check before you're issued the production certificate that lets you generate stamps for real. Skip or rush that step and your production invoices get rejected on day one.

• Your invoicing or ERP system generating XML instead of, or alongside, PDFs
• A cryptographic stamp and compliant QR code on every invoice
• Onboarding with ZATCA: certificates, device registration, and a compliance check before go-live
• A live connection to ZATCA's clearance or reporting API, with retry and error handling for downtime
• Archiving signed XML invoices, not just PDFs, for audit

The phased rollout, by revenue

ZATCA didn't flip a switch for every taxpayer at once. It rolled phase two out in waves, grouping companies broadly by annual revenue, largest first, and giving each wave a compliance window measured in months, not weeks. If you're a mid-size company, you're not first in line, but you're not last either. Waves have moved down through progressively smaller revenue bands since the rollout started.

Where ZATCA phase 2 integration timelines get tight

The pattern that repeats: companies wait for their formal notification from ZATCA, then discover their ERP vendor needs months to build or activate the integration module, not weeks. A mid-size company with a customized or older ERP setup, or one running multiple systems across branches in Riyadh, Jeddah, and Dammam, routinely underestimates how much data cleanup alone takes: correct VAT numbers, consistent product codes, matching customer records. That's before you write a line of integration code.

What delaying it actually costs

ZATCA has issued penalties for e-invoicing non-compliance since phase one, and phase two carries the same enforcement teeth: fines for not integrating, for invoices that fail validation, and for missing or incorrect QR codes and cryptographic stamps. Those add up per violation, not per audit.

The bigger cost is usually operational, not the fine itself. Companies that start integration only after receiving their ZATCA notification tend to rush the ERP vendor, skip proper testing against the sandbox, and go live with a system that occasionally rejects invoices or times out against ZATCA's API. When that happens mid-month, you can't invoice until it's fixed. For a business running on tight cash cycles, especially around Ramadan or year-end, a blocked invoicing system isn't a compliance problem anymore. It's a revenue problem.

Phase two integration is a project with a start date, a data cleanup phase, an ERP or middleware build, sandbox testing, and a go-live. Companies that treat it that way finish with room to spare. Companies that treat it as paperwork find out how expensive the difference is on the day their invoicing stops working.