What is the difference between clearance and reporting?

Clearance is for tax invoices between businesses: the invoice is sent to the authority at the moment of issue and comes back cleared before it is handed to the customer. Reporting is for simplified invoices to consumers: your system stamps and hands them over at once, then reports them to the authority within 24 hours.

Does Phase 2 cover small businesses?

It expands in waves by revenue, starting with the largest businesses and moving down. The authority notifies a business at least six months before its deadline; better not to wait for the notice but to check your wave on the authority's site and prepare early.

Is a foreign accounting package that prints a QR code enough?

No. The QR code alone is a Phase 1 requirement. Phase 2 requires an XML file to UBL 2.1, a cryptographic stamp, a hash chain and a live integration with the authority's platform for clearance or reporting. Many foreign packages provide that only through a local add-on or a middleware layer.

Do I need special hardware?

No. What is required is a software solution that meets the technical requirements and is integrated with the authority's platform, whether an ERP, an online store or a POS system. Each invoicing unit (branch or device) must be registered and hold its own certificate.

What happens if the internet goes down?

For simplified invoices you can keep issuing locally with the cryptographic stamp and report when connectivity returns within the 24-hour window; the system must preserve the sequence. A tax invoice is not valid until cleared, so the system should retry automatically and show the user its status.

What are the penalties for non-compliance?

The authority sets specific fines in its regulations for violations such as not issuing an e-invoice, not integrating, or deleting and editing invoices, and it updates the amounts and the enforcement approach from time to time. Consult the official violations table on the authority's site rather than figures in circulation.

Our current system does not support Phase 2. Do we replace it?

Not necessarily. A middleware layer can receive invoices from your current system, generate the approved XML, stamp and integrate with the authority, and return the result to the system. Replacement becomes justified when the system itself is an obstacle in other respects.

E-Invoicing in Saudi Arabia: A Guide to ZATCA Phase 2 (Integration)

Updated 17 October 202611 min read

The Zakat, Tax and Customs Authority rolled out e-invoicing in two phases. The first, the generation phase, began on 4 December 2021 and required businesses to issue invoices electronically instead of on paper or by hand. The second, the integration phase, began on 1 January 2023 and is applied in waves; it requires businesses to integrate their systems with the authority's Fatoora platform and submit invoices in a defined format.

The difference is not cosmetic. In the first phase it is enough to issue an invoice from a system; in the second, a tax invoice is not valid until the authority has cleared it, and the system itself must meet precise technical conditions. This guide explains those conditions in plain language and gives you a checklist for choosing a compliant system or checking your current one.

Who is covered, and when?

Phase 2 is applied in waves set by the authority according to taxable revenue in a reference year, and businesses in each wave are notified at least six months before their deadline. The waves started with the largest businesses and move down to smaller ones, so the right question is not "am I covered?" but "when?".

Check your wave at the source: the authority's website announces each wave, its revenue threshold and its deadline. Do not rely on second-hand summaries, because waves are announced progressively and the thresholds change.

Two kinds of invoice, two different flows

The regime distinguishes the tax invoice (business to business, B2B) from the simplified invoice (to consumers, B2C), and each takes a different path in Phase 2:

Tax invoices are subject to clearance: sent to the authority's platform at the moment of issue, and returned cleared and stamped before being handed to the buyer. An uncleared invoice is not a valid invoice.
Simplified invoices are subject to reporting: your system stamps them cryptographically and hands them to the consumer at once, then reports them to the authority within 24 hours of issue.
Credit and debit notes follow the type of the original invoice, take the same path, and must reference the invoice they adjust.

The technical requirements a system must meet

This is where most foreign systems and hurried local solutions stumble. Phase 2 does not ask for "a nice invoice with a QR code" but for a file in a defined format carrying linked cryptographic elements:

Invoice format: XML to the UBL 2.1 standard with the fields the authority defines, or PDF/A-3 with that same XML embedded.
A unique identifier (UUID) per invoice, distinct from the sequential invoice number.
The invoice counter (ICV): a number that increases with every invoice and is never reset, which exposes any deletion.
The previous invoice hash (PIH): each invoice carries the fingerprint of the one before it, forming a chain into which nothing can be inserted and from which nothing can be removed.
The cryptographic stamp: a digital signature on simplified invoices generated with a key specific to the invoicing unit, which must not be exportable.
The QR code: seller name, VAT number, timestamp, invoice total and VAT amount, with the hash, signature and verification key added in Phase 2 so a consumer can verify the invoice in the authority's app.
Prohibited functions: no editing or deleting an issued invoice (corrections go through notes), no changing the time or back-dating, no uncontrolled multiple sequences, and no export of the stamping key.
Archiving: keeping e-invoices in their original format for the statutory period, retrievable on request.

How integration with Fatoora works

Integration is a defined technical procedure, not a setting in a control panel:

The business generates a one-time password (OTP) for the invoicing unit from the Fatoora portal on the authority's site.
The system generates a certificate signing request (CSR) with the business and unit details and sends it with the OTP to the authority's API.
The authority issues a temporary compliance certificate used for a defined set of tests: tax and simplified invoices and credit and debit notes of each kind.
After passing the tests the system receives its production certificate (CSID) and begins live clearance and reporting.
The authority provides a simulation environment for testing the full integration before production; no system should be connected to production before passing it.

Checklist: is your system ready?

Generates XML to UBL 2.1 with the authority's fields, not PDF alone.
Distinguishes tax from simplified invoices and takes the correct path for each.
Clears tax invoices before handing them over, and reports simplified ones within 24 hours automatically.
Maintains a counter and hash chain per invoicing unit and per branch.
Handles loss of connectivity: stores and resends without breaking the sequence.
Issues credit and debit notes linked to the original invoice.
Prevents editing, deleting and re-dating issued invoices.
Keeps the stamping key inside the system and does not allow its export.
Keeps an audit log of every operation and archives invoices for the statutory period.
Has passed compliance tests in the simulation environment and holds a valid production certificate.

Common mistakes we see in existing systems

A foreign accounting package that produces a PDF with a QR code and is assumed compliant; there is no XML and no clearance.
Several branches or POS devices sharing one counter, so the chain breaks at the first conflict.
Credit notes issued as invoices with negative amounts, with no link to the original.
Simplified invoices reported manually at the end of the day, so the 24-hour limit is missed on the first holiday.
Fixing an error by editing the invoice in the database instead of issuing a note.

What this means when choosing an ERP or accounting system

Ask the vendor three things before anything else: show me the XML of an invoice issued by your system. How do you handle a tax invoice the authority rejected? And what happens if the internet drops at the point of sale for two hours? Whoever answers in detail knows Phase 2; whoever says "the system is approved" without detail should be asked for proof.

The most important rule: compliance is required of your invoicing unit, not of the vendor in general. Any offer promising "an authority-approved system" must make clear that approval is granted to your system after integration and after passing the tests.

Tecorva's role

We build ERP systems, stores and point-of-sale systems that generate invoices in the approved format, carry out the integration with Fatoora and pass the compliance tests in simulation and then production, and connect existing systems that do not support Phase 2 through a middleware layer instead of replacing them. Clearance itself is granted by the authority to your system; we are the ones who build what passes its tests and stays compliant with its updates.

E-invoicing: a guide to Phase 2