Phase 1 of Saudi Arabia's e-invoicing programme was, for most businesses, a formatting exercise: stop issuing handwritten invoices, produce a structured electronic document, add a QR code to your simplified receipts. Phase 2 — the Integration Phase — is a different kind of project. It asks your billing system to talk directly to ZATCA's Fatoora platform, to sign every invoice cryptographically, and to chain each document to the one before it.

That is an engineering requirement, not a template change. This guide breaks down exactly what Phase 2 integration requires, how the rollout waves decide when it applies to you, and what to look for in a solution so the deadline is a configuration task rather than a rebuild. If you need the wider context first — what e-invoicing is, why it exists, and how the two phases fit together — start with our complete ZATCA Fatoora guide, or read the same material in Arabic.

What Phase 2 actually asks of your systems

Phase 1 (the Generation Phase, in force since 4 December 2021) required electronic generation and storage of invoices. Phase 2 (the Integration Phase, which began rolling out from 1 January 2023 wave by wave) adds a live connection between your E-Invoice Generation Solution (EGS) and ZATCA.

In practice, an integrated system has to do five things every taxpayer should be able to point at:

  • Produce the invoice as structured XML in ZATCA's format, not just a PDF or a printout.
  • Apply a cryptographic stamp using a certificate issued by ZATCA to that specific solution unit.
  • Maintain a hash chain so invoices cannot be inserted, removed or reordered after the fact.
  • Embed a QR code carrying the invoice's key data in a machine-readable form.
  • Submit each invoice to ZATCA — for clearance or for reporting, depending on invoice type.

Miss any one of them and the invoice is not compliant, even if it looks perfect on paper. The good news is that these are solution-level capabilities: once your software handles them, they apply to every invoice you issue without extra work per document.

How the rollout waves work

ZATCA did not switch Phase 2 on for the whole economy at once. It groups VAT-registered taxpayers into waves, defined by a revenue threshold measured against a specified reference year, and brings each wave onto the integration requirement on its own start date. Each wave's threshold is lower than the last, so the programme moves progressively from the largest taxpayers down to smaller ones.

Two things matter far more than memorising thresholds:

  1. ZATCA notifies taxpayers directly. Businesses that fall into a wave are informed in advance — the authority has consistently committed to at least six months' notice before a wave's integration date. That notice period is your project window.
  2. The criteria are published and updated per wave. Because thresholds and dates are announced wave by wave, any figure quoted in an article ages quickly. Check your wave, its threshold and its exact start date on the official ZATCA website (zatca.gov.sa) or in the notification sent to your registered contact details — not in a blog post, including this one.

The practical takeaway: if you are VAT-registered in Saudi Arabia and you have not yet been notified, you are not exempt — you are early. Six months is comfortable if you start when the notice arrives and uncomfortable if you start three months later.

The integration requirements in detail

1. A ZATCA-compliant XML invoice

Phase 2 invoices are XML documents based on the UBL 2.1 standard, constrained by ZATCA's own implementation rules. That means specific fields, specific cardinality and specific value formats — seller and buyer VAT registration numbers, the invoice type code that distinguishes a standard invoice from a simplified one, line-level tax categories, and totals that must reconcile exactly.

Two consequences are easy to underestimate. First, your master data becomes compliance data: a missing buyer VAT number or a malformed address that nobody minded in a PDF will now fail validation. Second, the human-readable invoice and the XML must agree; the PDF/A-3 representation your customer sees is a rendering of the same document, not a separate one.

2. A cryptographic stamp and the CSID

Every Phase 2 invoice carries a cryptographic stamp — an ECDSA signature produced with a private key held by the solution unit, using a certificate ZATCA issues during onboarding. That certificate is the Cryptographic Stamp Identifier (CSID), and it is issued per solution unit (per device, branch or instance), not once per company.

Conceptually this is the same trust model behind any signed electronic document: the signature proves the invoice came from a registered issuer and has not been altered since. If the mechanics of that are new to you, our explainer on digital signatures on invoices and why they are legally binding covers the underlying idea in plain language.

3. The hash chain: UUID, ICV and PIH

Each invoice includes a unique identifier (UUID), an Invoice Counter Value (ICV) that increments sequentially, and the Previous Invoice Hash (PIH) — the hash of the immediately preceding invoice from the same solution unit.

Together these form a chain: change or delete an old invoice and every hash after it stops matching. This is what makes the archive tamper-evident, and it is also the requirement most likely to expose weaknesses in a home-grown system. Counters must survive restarts, must not be shared incorrectly across units, and must never be reset or reused. Deciding to "just renumber" a batch of invoices — something plenty of finance teams have done historically — is no longer possible.

4. The QR code

The QR code is not decorative. It encodes invoice data in TLV (tag–length–value) format, Base64-encoded, so an inspector or a customer can verify the essentials by scanning: seller name, seller VAT registration number, invoice timestamp, total including VAT, and the VAT amount. In Phase 2 the encoded set is extended with cryptographic elements — the invoice hash, the stamp and the public key — so the scan can be verified rather than merely read.

Because the QR content is generated from the signed document, it cannot be produced by a separate tool or added later by your designer. It comes out of the same pipeline that produces the XML.

5. Clearance or reporting, over the API

Phase 2 defines two submission flows, and which one applies depends on the invoice type:

  • Clearance applies to standard tax invoices — broadly, B2B and B2G. The invoice is sent to ZATCA before it is shared with the buyer, and ZATCA returns a cleared document. Only the cleared version is a valid tax invoice.
  • Reporting applies to simplified tax invoices — broadly, B2C. The invoice is issued to the customer immediately and transmitted to ZATCA afterwards, within the window ZATCA specifies (commonly cited as 24 hours; confirm the current requirement in the official documentation).

The distinction matters architecturally. Clearance puts ZATCA's platform in the critical path of your B2B invoicing, which means you need to think about latency, retries and what your staff do when the connection fails. Reporting is asynchronous, so a retail till can keep serving customers during an outage — provided your queue is durable and drains reliably afterwards.

Onboarding: from CSR to production CSID

Getting a solution unit connected follows a fixed sequence, and it is worth understanding even if your vendor performs it for you:

  1. Generate a CSR. The solution creates a key pair and a Certificate Signing Request containing the details of the unit and the taxpayer.
  2. Get an OTP from the Fatoora portal. The taxpayer logs in to ZATCA's portal and generates a one-time password for the unit being onboarded.
  3. Request a compliance CSID. The CSR plus OTP is exchanged for a compliance certificate, valid for testing.
  4. Pass the compliance checks. The unit submits sample invoices — standard, simplified, credit and debit notes — through the compliance API. All required document types must pass.
  5. Request the production CSID. Once checks pass, the unit is issued its production certificate and can clear and report live invoices.

Plan for this to be repeated per solution unit, and plan for certificate renewal. A CSID has a lifetime; a system that cannot renew unattended will fail loudly on a date nobody has in their calendar.

Choosing an e-invoicing solution: what to check

Most businesses will meet Phase 2 through software rather than by building an integration. Whether you are evaluating a full invoicing platform, a middleware connector or an add-on to your ERP, these are the questions that separate a real solution from a checkbox:

  • Does it handle onboarding end to end? CSR generation, OTP exchange, compliance checks and production CSID issuance — including renewal — without manual key handling.
  • Does it cover every document type you issue? Standard and simplified invoices, plus credit and debit notes with valid reasons and references to the original invoice.
  • How does it behave offline? Ask specifically what happens to a simplified invoice when the API is unreachable, and how the queue drains. A vendor without a clear answer has not run this in production.
  • Is the hash chain managed per solution unit? Multi-branch and multi-till setups are where counters go wrong.
  • Does it archive the signed XML, not just a PDF? The XML is the legal document; retention periods are set by the Saudi VAT regulations, so confirm the current requirement and check the archive can produce originals on request.
  • Does it keep pace with specification updates? ZATCA has revised its technical specifications more than once. Your solution's compliance is a subscription, not a purchase.
  • Does it fit how you actually bill? Recurring charges, multi-currency sales, Arabic and English on the same document. If you invoice abroad as well as domestically, our guide to invoicing international clients in multiple currencies covers the non-ZATCA half of that problem.

A realistic integration timeline

Six months of notice sounds generous until you sequence the work. A workable plan looks roughly like this:

  • Weeks 1–3 — inventory. List every system that issues an invoice: ERP, POS tills, the booking site, the spreadsheet one branch still uses. Each is a solution unit that needs onboarding or retiring.
  • Weeks 3–6 — data cleanup. VAT registration numbers, legal names, addresses, tax categories per product. This is unglamorous and it is where most failed validations originate.
  • Weeks 6–12 — integration and sandbox. Onboard units, run the compliance checks, fix what fails.
  • Weeks 12–18 — parallel running. Issue live invoices through the new flow while the old process is still available, and watch the error rate.
  • Weeks 18–24 — training and cutover. Cashiers and billing staff need to know what a rejection looks like and what to do about it.

Common integration mistakes

The failures we see repeatedly are rarely exotic:

  • Treating clearance as optional for B2B because "the customer already has the PDF". An uncleared standard invoice is not a valid tax invoice.
  • Sharing one solution unit's credentials across branches, which corrupts the counter and hash chain.
  • Storing only the PDF and discarding the signed XML.
  • Rounding tax at the document level when the specification expects line-level treatment, producing totals that fail validation.
  • Leaving Arabic content out of documents that require it.
  • Assuming Phase 1 obligations lapsed. They did not — Phase 2 builds on them.

Frequently asked questions

Do I need Phase 2 if I have not been notified?

You are required to integrate from your wave's start date. If you have not been notified, keep meeting your Phase 1 obligations and make sure ZATCA has current contact details for your business — notices go to the details on your VAT registration.

Is VAT still 15%?

The standard VAT rate in Saudi Arabia is 15%, with zero-rated and exempt categories defined in the VAT regulations. Rates and category rules can change, so confirm the current position with ZATCA before configuring tax codes.

Can I use one solution for several companies?

Yes, but each taxpayer onboards separately and each solution unit gets its own CSID and its own invoice chain. Multi-entity support is a specific feature — confirm it rather than assuming it.

How is this different from mandates in other countries?

The direction of travel is the same everywhere: structured invoices, tamper-evidence and near real-time visibility for the tax authority. The mechanics differ. Spain's VeriFactu regime, for example, also demands unalterable records and chained invoices, but through a different technical route — we cover it in our guide to VeriFactu and Spain's electronic invoicing law. If you sell in both markets, expect one billing system to satisfy two rule sets rather than one.

Can I keep using my current invoicing process?

Only if it can produce signed, chained XML and submit it. Manual or spreadsheet-based processes cannot, which is why most businesses move to a platform. If you are still weighing that up, our primer on what an online invoicing system is is a good starting point.

Get compliant billing in place before the deadline

Phase 2 rewards preparation and punishes improvisation. The businesses that find it painless are the ones that had structured, centralised invoicing before the notice arrived — the integration was then a setting, not a project.

Facturi gives you that foundation: one place to issue, track and archive invoices, with Arabic and English support, multi-currency billing and structured data behind every document. Start free and get your invoicing in order before your wave date does it for you.

This article explains the ZATCA Phase 2 requirements in general terms and is not tax or legal advice. Wave thresholds, dates and technical specifications are published and periodically updated by ZATCA — always verify the current version at zatca.gov.sa or with a qualified adviser before acting.