ZATCA E-Invoicing Phase 2 (FATOORA): What Saudi Businesses Must Have in Place

What is the difference between Phase 1 and Phase 2?

Phase 1 of e-invoicing, the Generation phase, began on 4 December 2021 and required everyone subject to the regulation to generate and keep invoices and credit and debit notes electronically. ^[1] Phase 2, the Integration phase, began on 1 January 2023 and is rolled out in waves by target group; it requires invoicing systems to be integrated with ZATCA’s systems through an application programming interface. ^[1]

ZATCA sums up what Phase 2 adds in three points: connecting e-invoicing solutions to the FATOORA platform, issuing invoices in a specific format and adding new fields to the invoice. ^[4] In other words, a business no longer simply issues and stores an invoice; the invoice now passes through ZATCA either before it reaches the buyer or immediately after.

Who is in scope for Phase 2, and when?

ZATCA determines the target groups and their phases, and notifies each group at least six months before its integration date. ^[1] The most recent announced at the time of writing (November 2026) is Wave 25, which covers all taxpayers whose VAT-subject revenue exceeded SAR 187,500 in 2022, 2023, 2024 or 2025; they must complete integration with FATOORA by 1 February 2027 at the latest, and ZATCA will notify those targeted directly. ^[4]

The requirements apply to resident taxable persons and to any customer or third party issuing a tax invoice on their behalf, but not to non-resident taxable persons. ^[2] In-scope documents cover standard-rated and zero-rated supplies, exports, intra-GCC supplies and advance payments; fully exempt supplies, reverse-charge supplies and imports are excluded. ^[1]

Clearance and reporting: two routes for two invoice types

The core of Phase 2 is that tax invoices and simplified invoices follow different routes:

• Tax invoice (B2B): sent to ZATCA for clearance; ZATCA checks it and adds its cryptographic stamp to those that pass its controls, and only then is it shared with the buyer. The same applies to associated credit and debit notes. ^{[1, 2]}
• Simplified invoice (B2C): given to the buyer immediately and reported to ZATCA within no more than 24 hours of issue, carrying the cryptographic stamp. ^{[1, 2]}

The Implementation Resolution makes input tax deduction conditional on invoices having been cleared or reported, from a date ZATCA announces. ^[1] So an integration failure at the supplier does not stay an internal technical problem; it can become a financial problem for the customer.

What must every electronic document carry?

Invoices must be issued in XML, or as PDF/A-3 with embedded XML, and whatever is submitted to the platform for clearance or reporting must be in XML. ^{[1, 2]} An ordinary PDF sent to the customer is not enough. ^[2]

The Implementation Resolution sets out technical elements that protect the invoice’s integrity: ^[1]

• A unique identifier (UUID) for each invoice or note, alongside its sequential number.
• A hash of each invoice embedded in the next one, chaining invoices together so that any change is detectable.
• A counter that cannot be reset or reformatted.
• A cryptographic stamp using a registered stamp identifier and a non-exportable key.
• A QR code, mandatory on all invoices and notes, containing data such as the seller’s name and VAT number, date and time, totals, the hash and the signature.

A tax invoice comes back from clearance carrying the QR code and ZATCA’s stamp, and is then shared with the buyer. ^[2]

Solution requirements and prohibited functions

ZATCA does not mandate a particular system, but it prohibits functions that open the door to tampering, including: ^{[1, 3]}

• Uncontrolled access, such as anonymous log-in, default passwords or no user session management.
• Editing or deleting invoices, notes or logs after they are issued.
• More than one invoice sequence, or resetting the counter.
• Exporting the cryptographic stamping keys.
• Changing the system time during issuance.

On storage, the solution must allow invoices to be exported to a local archive without an internet connection, and exported archive files must be named with the VAT number, issue date, issue time and invoice reference number. ^[1] Invoices may be stored on premises in the Kingdom or in the cloud, provided ZATCA can access the data. ^[2] Retention periods follow the VAT Implementing Regulations: at least 6 years for records in general. ^{[1, 5]}

Steps to integrate with FATOORA

The onboarding step itself is short: the taxpayer logs in to the FATOORA portal with their ZATCA e-services credentials, requests a one-time password (OTP) for the solution and enters it in the solution within its validity period, and the solution obtains its cryptographic stamp identifier (CSID). ^{[2, 3]} Every device or unit issuing invoices under the same VAT number must be onboarded. ^[2] But the real work comes before this step:

Mapping the issuing points and cleaning customer data usually take the most time, because data errors that used to slip through can now hold up clearance of a tax invoice, and every branch or point-of-sale device left unconnected becomes a point of non-compliance.

Who owns the project inside the business?

A common planning mistake is to treat integration as a technical task for the solution provider alone. It is better led by the finance director or tax lead, because its key decisions are financial: which transactions get a tax invoice and which a simplified one, how returns and discounts are handled through credit notes, and who follows up rejected invoices each day. IT handles integration, security and access rights, and the provider tests the scenarios finance defines before go-live.

What if the connection to the platform fails?

The Implementation Resolution expects the solution to queue invoices while offline and send them once the connection is restored. ^[1] The taxpayer must notify ZATCA of incidents, and resume integration and submit the affected invoices promptly once the problem is fixed. ^[1]

The Detailed Guideline sets out the procedure for each case, including keeping evidence of submission attempts and notifying ZATCA through the dedicated form if the 24-hour window for a simplified invoice is missed. ^[2] It is worth writing a short contingency procedure that sets out who monitors pending invoices, when the issue is escalated to the solution provider and when ZATCA is notified.

Mistakes businesses make in the first months

ZATCA highlights recurring errors, including manual invoices, using a non-compliant solution, generating invoices that do not meet the requirements and deleting invoices after they are generated. ^[3] In practice, another one is connecting the main systems while forgetting secondary systems that also issue invoices, such as a returns module or point-of-sale terminals in a remote branch.

Hypothetical example

A Jeddah distribution company in a recent wave issues invoices from a main accounting system and ten point-of-sale terminals in its showrooms. It connected the main system to the platform before the deadline but never mapped the terminals, so two of them kept issuing simplified invoices from an old software version that did not report them. Finance found the gap when it compared showroom sales with reported invoices. The lesson: a daily report reconciling what was issued with what was cleared or reported catches these gaps before ZATCA does.

Conclusion

Phase 2 is not a change to the look of the invoice but to its route: a tax invoice is cleared before it reaches the customer, and a simplified invoice is reported within 24 hours. Start by mapping every issuing point and cleaning customer data, choose a compliant solution, and put a written procedure for outages in place well before your wave’s deadline.