ZATCA Phase Two E-Invoicing: What Has to Change Inside Your System

Phase Two changes how your system works from the inside. A standard tax invoice between businesses is not valid until the Zakat, Tax and Customs Authority has cleared it, and a simplified invoice issued to a consumer has to be shared with the FATOORA platform within 24 hours of the transaction. In practice that means your system now needs a cryptographic certificate, a document sequence it is not allowed to break, an API client that handles clearance, rejection and warnings, and a record of the Authority's response to every document.

This guide is written for anyone in Saudi Arabia running an ERP, a point-of-sale system or an in-house invoicing system who needs to know what actually has to be built or changed before their wave deadline. Every figure and date below comes from the Authority's own documents, consulted on 19 September 2026.

When does your business fall under the mandate?

Phase One (generation and storage) took effect on 4 December 2021 for everyone subject to the E-Invoicing Regulations. Phase Two (integration) has been in force since 1 January 2023 and is applied to successive waves based on annual revenue subject to VAT, with the Authority notifying each wave at least six months before its date.

Below is the wave table as published on ZATCA's roll-out phases page, last updated 1 September 2026. The criterion stated in the table is the highest of the 2022, 2023 or 2024 revenues:

Wave 25 is the latest one announced as of 19 September 2026, and the table closes with a note that further waves will be announced. The Authority's announcement of 24 July 2026 set the criterion for that wave at VAT-taxable revenue above SAR 187,500 during 2022, 2023, 2024 or 2025, which brings 2025 into the calculation.

What this means in practice: if your VAT-taxable revenue exceeded SAR 187,500 in any of those years, you are either under the mandate now or will be within months. The date that matters is the one in the Authority's notification, not one you estimate yourself.

The invoice path depends on who is buying

Phase Two puts two different paths inside your system at the same time, and this is where most technical teams get confused.

Standard tax invoices (B2B) follow the clearance model. ZATCA's detailed technical guidelines state that a standard document is only considered valid once it has been cleared by the Authority. Your system submits it first, the platform returns it carrying ZATCA's stamp with an updated QR code, and only then is it handed to the buyer in a human-readable form. That puts a network call in the middle of a sale that used to be instant.

Simplified invoices (B2C) follow the reporting model. They are issued at the point of sale and given to the customer immediately, then shared with the platform within 24 hours of the transaction being completed. Here the Authority does not stamp the document: the cryptographic stamp and the QR code are your system's responsibility, and the platform replies with acceptance, acceptance with warnings, or rejection.

The design consequence is clear. The first path needs synchronous handling with an acceptable timeout and defined behaviour on failure; the second needs an asynchronous submission queue with a retry policy and monitoring against the 24-hour window. Building both with the same logic is a common mistake that shows up late, on the day the connection drops with a cashier standing in front of a customer.

What actually gets built into the system

The requirement is not a single item called "integration". These are the pieces that get added to an existing system.

Document format. Documents are submitted to the Authority as XML, not as PDF/A-3. The XML implementation standard (version 1.2, 19 May 2023) defines three successive validation layers: syntax against the UBL 2.1 schema, content against a customised subset of EN 16931 rules, then country-qualified Saudi rules (CIUS). The part that matters most is the order of precedence in a conflict: Saudi rules override EN 16931, and EN 16931 overrides the UBL specification. Building your XML generator on a generic UBL library alone will not get you there.

Cryptographic stamping and key storage. Every document is signed with a private key tied to a certificate issued by the Authority, and the hashing algorithm is SHA-256. Where that private key lives is an architectural decision rather than an operational detail, because exporting or moving it off the device is explicitly prohibited.

Sequencing and the previous document hash. Each onboarded unit must generate its documents in a single sequence covering standard and simplified documents together, and every document carries the hash of the one generated before it. The technical guidelines are emphatic that this chain is maintained even for documents the platform rejected, because the platform records the hash of rejected submissions too. Concretely: a database column that is never renumbered, and no deletion or regeneration of documents.

The QR code. It is built as TLV encoding, then Base64, capped at 700 characters. It carries nine fields: seller name, seller VAT registration number, invoice timestamp, total including VAT, total VAT, then the invoice hash, the ECDSA signature, the public key, and finally ZATCA's signature over that public key for simplified invoices. The first five have been required since Phase One; the last four arrive with integration.

A response log. The platform returns one of three outcomes for each submission: a valid document, a document accepted with warnings, or a rejected document with error messages. Acceptance with warnings is the middle state that is easy to ignore because it does not stop the sale, which is why it is worth collecting those warnings into a periodic report your accountant actually sees rather than leaving them in server logs.

Clean master data. A large share of rejections traces back to stale data: a missing customer VAT number, an incomplete address, an invalid unit of measure or currency code. Reviewing these fields before development starts is cheaper than fixing them after the first round of rejections.

How onboarding with the FATOORA platform works

The onboarding path described in the technical guidelines follows defined steps, most of them automated inside your system:

1. The taxpayer signs in to the taxpayer portal, opens the FATOORA platform, chooses to onboard an e-invoicing solution, and generates a one-time password (OTP) for each unit.
2. The OTP is entered into the system, which generates a certificate signing request (CSR) carrying the unit's details, including a unique identifier for the unit and the VAT number associated with it.
3. The platform returns a Compliance CSID, which allows onboarding to continue.
4. The unit goes through automated compliance checks that verify it can produce conforming documents. The number of submissions follows what you declared in the request: three documents for each enabled type, namely an invoice, a debit note and a credit note.
5. Once those checks pass, a Production CSID is issued, and with it the system calls the reporting and clearance APIs directly without signing in to the portal again.

The document types you declare are encoded as a functionality map: 1000 for standard invoices only, 0100 for simplified only, and 1100 for both. Choosing the wrong code means starting onboarding over, so settle what each unit actually issues before you begin.

Before any of this, the Authority provides a developer portal with a sandbox and a local validation toolbox where documents and API calls can be tested well away from real data. Start there, not in production.

Note as well that a Production CSID is revoked automatically when VAT registration is cancelled or suspended, including when a business joins a VAT group. That case comes up during restructuring and stops submissions without warning.

How many certificates do you need? Your branch layout decides

This question shapes the architecture more than any other, and the technical guidelines answer it by operating model:

Look closely at that last case. If your tills are simple terminals that depend on a server, a simplified invoice must not be printed for the customer until the server has stamped it and applied the code. That reorders the moment of printing inside the till software itself, not only on the server. Standard invoices, meanwhile, still need ZATCA's clearance before the document reaches the buyer.

What happens during an outage

Most guides skip this, and it is where real implementations stumble. The Authority operates a notification service for e-invoicing system failures, requiring you to notify it of any incident or fault that obstructs issuing and storing invoices, to notify it again once the fault is resolved, and to issue electronically all invoices for transactions that took place during the outage.

This is not only an administrative step. The violation in the penalty schedule below is worded to require, alongside the delay itself, a failure to notify the Authority of incidents and faults through the channels it specifies, and the text adds an explicit carve-out where the taxpayer holds evidence that the failure was caused by a technical fault in the Authority's systems. Your system's ability to prove what happened and when therefore has direct regulatory value.

What that means when building: a durable submission queue that survives a service restart, a log of every attempt with its timestamp and the platform's response, an alert to the responsible manager before a document approaches the 24-hour limit, and a screen that surfaces pending documents by the error blocking them rather than by arrival order.

Features your system may have today that are prohibited

ZATCA's simplified guideline lists examples of prohibited functionality in e-invoicing systems, and some of them genuinely exist in in-house systems written years ago:

• No user management, for example access without signing in.
• Tampering with invoices, notes or logs.
• Allowing more than one issuing sequence per invoicing unit.
• Exporting or moving the private key used for cryptographic stamping.
• Changing the time or date inside the invoicing system.

Checking this list against your current system is quick, and it usually reveals that the work is larger than adding an API client. The "edit invoice" screen an accountant uses to correct a typo, for instance, has no place after integration; a credit or debit note takes over that job.

A new system, or an integration layer?

Integration does not necessarily mean replacing your system. The decision depends on the state of what you have:

One point deserves attention if you are considering a custom build. ZATCA's e-invoicing page states that a taxpayer who complies with the requirements is considered compliant even if their service provider is not listed in the indicative directory of solution providers. That directory exists to help businesses find vendors; it is not a condition of compliance. What is measured is the documents your system issues, not who built it.

If you also operate in Egypt, do not assume the two regimes resemble each other: the Egyptian Tax Authority's requirements differ in coding, signing and environments, and we cover them separately in our guide to connecting your system to Egyptian e-invoicing.

The cost of being late

ZATCA's simplified guide to the classification of VAT violations (second edition, May 2024) sets out two violations specific to integration and sharing. The structure is graduated: general violations begin with a warning and a correction window of 30 to 60 days, and the fine escalates with repetition.

Both violations carry a 30-day recurrence period, and the fine falls away in either case if the taxpayer holds evidence that the failure was caused by a technical fault in the Authority's systems. Check with your tax adviser for what applies to your exact situation; the figures above are a general classification, not a ruling on a specific case.

Where to start

In the first week it is enough to settle four things: your wave date from the Authority's notification, the document types each of your units issues, how certificates will be distributed across your servers and branches, and the state of your master data. Those four determine the size and cost of the work more than any general estimate. Building begins in the sandbox after that, and production stays the last stop rather than the first.

If you have an existing system and want an assessment of what integration would take, or you are considering a custom system that issues conforming documents from day one, or you need a dashboard and integration layer on top of what you already run, send a description of your current setup to the Snaabble team. We will come back within one business day with an initial plan and an early estimate of time and cost, free and with no commitment.

Sources

• Roll-out phases and the wave table. Zakat, Tax and Customs Authority, last updated 1 September 2026.
• Criteria for Wave 25. ZATCA, 24 July 2026.
• E-invoicing Detailed Technical Guidelines. ZATCA, version 2, November 2022.
• Electronic Invoice XML Implementation Standard. ZATCA, version 1.2, 19 May 2023.
• Simplified guideline to e-invoicing requirements. ZATCA.
• Simplified guide to the classification of VAT violations. ZATCA, second edition, May 2024.
• E-invoicing system failure notification service. ZATCA.
• Developer portal and sandbox. ZATCA.

All links consulted on 19 September 2026.

Frequently asked questions

Does e-invoicing apply to non-resident businesses in Saudi Arabia?

ZATCA's roll-out phases page states that Phase One has applied since 4 December 2021 to all taxpayers excluding non-resident taxpayers, and to any other party issuing tax invoices on behalf of suppliers subject to VAT. If your situation sits in a grey area, check with your tax adviser before any development starts.

Can we keep issuing invoices from spreadsheets after integration?

No. The Authority is explicit that Phase One itself requires a complete stop to handwritten invoices and to invoices produced in word processors or spreadsheet software. Integration then adds certificate-based signing and API submission on top, which a spreadsheet file cannot provide.

What is the difference between a Compliance CSID and a Production CSID?

A Compliance CSID is issued after the certificate signing request and only lets your unit continue onboarding and run the compliance checks. A Production CSID is issued once those checks pass, and it is what allows calls to the reporting and clearance APIs with real data.

Does our invoicing vendor have to be registered with ZATCA?

No. ZATCA's e-invoicing page states that a taxpayer is considered compliant as long as the system used meets the requirements, even if the service provider is not listed in the indicative directory of solution providers. The directory is there to help businesses find vendors, not to define compliance.

What happens if a simplified invoice is not submitted within 24 hours?

The violations classification guide treats failure to share invoices in the required format and within the specified periods as a violation that starts with a warning and then escalates in fines. Relief is tied to notifying the Authority of faults through its designated channels, or to evidence that the failure was caused by a technical fault in its systems, which is why your system should log every submission attempt and its response.