ZATCA Phase 2 on Odoo: the software is the easy part.

Saudi Arabia has run mandatory e-invoicing since 4 December 2021, when Phase 1 obliged every taxpayer except non-residents to stop issuing handwritten and spreadsheet invoices and to generate structured invoices from a compliant solution. Phase 2, the integration phase, is the harder half. Since 1 January 2023 the Zakat, Tax and Customs Authority has been connecting taxpayers to its Fatoora platform in waves, by revenue, each with a fixed date by which its systems must be transmitting. Twenty-five waves have been announced; twenty-four are in force.

For a business running Odoo there is one piece of good news worth stating plainly, because the UAE rollout has taught Gulf finance teams to expect the opposite. Standard Odoo implements ZATCA Phase 2 end to end, free, in the Community edition. No third-party transmission service is required and no accredited intermediary sits in the middle. The software is the easy part. What takes the work is onboarding, configuration, and the discipline of running a system that speaks to a tax authority every time an invoice is raised.

What changes under Phase 2

Phase 1 governed how you generate an invoice. Phase 2 is about ZATCA seeing it. Four things change:

• Format. Invoices transmitted to ZATCA must be XML. The schema is UBL 2.1, profiled against EN 16931, with Saudi rules overriding it where the two conflict. Saudi Arabia does not use PINT, so a Peppol-ready invoice is not a ZATCA-ready invoice.
• Transmission. Your solution integrates with Fatoora through ZATCA's API, over an authenticated and encrypted connection, using a certificate issued to your own system.
• Additional fields. A UUID alongside the sequential invoice number, the hash of the previous document in the sequence, a tamper-resistant counter that cannot be reset, and a nine-field QR code are all mandatory.
• A cryptographic stamp. Every invoice carries one. For simplified invoices your own solution generates it; for standard tax invoices ZATCA generates it.

One consequence is easy to miss and expensive to discover late: clearance or reporting is a condition of input VAT deduction. An invoice that never reached ZATCA is not only a compliance failure for the issuer — it is a deduction the customer cannot claim.

Who is in scope now, and the Wave 25 deadline

Waves 1 to 24 are all in force. Wave 24's deadline passed on 30 June 2026 and covered taxpayers whose VAT-subject revenues exceeded SAR 375,000 during 2022, 2023 or 2024 — already a small-business threshold.

Wave 25 is the one to plan around. ZATCA's criteria cover every taxpayer whose revenues subject to VAT exceeded SAR 187,500 during 2022, 2023, 2024 or 2025, and those taxpayers must integrate their e-invoicing solutions with the Fatoora platform by no later than 1 February 2027. The inclusion of 2025 is the detail that matters most: this is the first wave to use a 2025 revenue year, so a business that stayed below every earlier threshold and then crossed SAR 187,500 in 2025 is newly in scope, with roughly four months to prepare.

ZATCA notifies each wave's taxpayers at least six months before their integration date, but the obligation attaches to the published criteria, not to the arrival of a letter. A business that meets a threshold should not wait to be told. Outside the regime sit supplies fully exempt from VAT, reverse charge supplies, and imports of goods into the Kingdom.

Clearance and reporting are not the same thing

The distinction is the most important technical fact in the regime, and the one most often flattened into a single word.

• Standard tax invoices, broadly business to business, are cleared. You transmit the invoice to ZATCA, ZATCA verifies it against the prescribed controls, ZATCA applies the cryptographic stamp, and only then do you share the invoice with your customer. Clearance happens before issuance.
• Simplified tax invoices, broadly business to consumer, are reported. Your own solution applies the stamp, the invoice goes to the customer immediately, and it must be reported to ZATCA within 24 hours of generation.

The asymmetry changes how two parts of the same company operate. Business-to-business invoicing becomes dependent on a live round trip to a government platform: an invoice ZATCA rejects is not legally valid and cannot go to the customer until it has been corrected and accepted. Retail and point-of-sale invoicing must never be held up by connectivity, but it accumulates an obligation to discharge within a day, so an outage produces a reporting backlog rather than unissued invoices. ZATCA requires you to report any incident that hinders generation or integration, to report its resolution, then to catch up.

The Arabic requirement

The human-readable form of the invoice must be in Arabic. That obligation comes from Article 53 of the VAT Implementing Regulation rather than from the e-invoicing rules themselves, and ZATCA's guidance is specific about its reach: everything a person reads on the invoice must be in Arabic, including remarks and notes, not only the field labels. Arabic and Hindi numerals are both acceptable, and bilingual invoices are permitted, so English may sit alongside Arabic. The technical layer of the XML stays English, because UBL element names are English.

What Odoo does out of the box, and in which edition

Two modules carry the weight. The Saudi fiscal localisation, l10n_sa, gives you Phase 1 and the five-field Phase 1 QR code, and stops there. A business running on that module alone is not Phase 2 compliant, and the QR code is the clearest symptom: five fields on simplified invoices only, where Phase 2 requires nine on every invoice type, embedding the XML hash and an ECDSA signature.

Phase 2 itself is l10n_sa_edi, and it implements the genuine flow rather than a partial stub: certificate signing request, Compliance CSID, ZATCA's compliance checks, Production CSID, then submission to the clearance endpoint for tax invoices and the reporting endpoint for simplified invoices — producing UBL 2.1 XML, the nine-field QR code and a PDF/A-3 with the XML embedded. A companion module, l10n_sa_edi_pos, extends the same flow to point of sale. Sending a PDF is optional, but any PDF you do send must be PDF/A-3 with the XML inside.

The edition question is where accuracy matters most. The l10n_sa_edi module ships in the Odoo Community repository under LGPL-3, confirmed in its manifest on the 17.0, 18.0 and 19.0 branches, so ZATCA Phase 2 does not require Odoo Enterprise. What does require Enterprise is the surrounding accounting: l10n_sa_reports and l10n_sa_withholding_tax, which produce the Saudi VAT and withholding tax returns. The returns need Enterprise. The e-invoicing does not.

This is close to the opposite of the UAE position, where Odoo does not transmit to the Federal Tax Authority and compliance requires a connector to an accredited service provider. An assumption carried from one regime to the other will be wrong. If the edition decision is open on other grounds, our comparison of Community and Enterprise covers what else the subscription buys.

What actually takes the work

• Fatoora onboarding, one journal at a time. Onboarding is manual and per sales journal, using a six-digit one-time password from the Fatoora portal that expires after 60 minutes. Multi-branch and multi-till businesses onboard every journal separately.
• Registering every unit. Every device issuing invoices under one VAT registration number needs its own registration with ZATCA, which in Odoo maps to its own journal. Statutory, and routinely missed.
• Complete company data. Onboarding fails on incomplete records. Company name within 63 characters, district, building number, plot identification, identification scheme and SAR as the currency must all be right before the first call to ZATCA.
• Turning Arabic on. Odoo does not produce Arabic invoices by default. Customer language and the Gulf Cooperation Council invoice format are configuration steps, and they apply to point-of-sale receipts as well.
• ZATCA reason codes on credit and debit notes. Every note needs a reason from ZATCA's prescribed list. For teams used to raising credit notes freely, this is the change that most visibly alters daily behaviour.
• The one-way switch to Production. Sandbox, simulation and production are the three modes. Once production is switched on and an invoice submitted, there is no going back, and simulation invoices are not legally valid.
• Owning the rejection queue. A rejected invoice stays rejected and is not legally valid. Correction is manual, then retried — a rota question rather than a software one.
• Protecting the stamping credentials. Keeping the cryptographic stamp identifier safe is a statutory obligation. The stamping key must be non-exportable, with disk encryption where it is held in software.

Penalties, stated conservatively

E-invoicing breaches are penalised through the VAT Law. ZATCA's published starting amounts are a fine from SAR 5,000 for failing to issue electronic invoices and from SAR 10,000 for deleting or amending one after issuance. Certain field-level violations begin with a warning: a missing QR code on a simplified invoice, a missing buyer VAT registration number on a tax invoice, and failure to notify ZATCA of a malfunction. The statutory ceiling for violating any provision of the VAT Law or its Regulations is SAR 50,000, and where the same violation recurs within three years of ZATCA's final decision the fine may be doubled. ZATCA says only that fines follow the type of violation and the number of repetitions, so treat any precise escalation table with care unless its source is named.

The commercial exposure is usually larger than the fine. An invoice that never reached ZATCA is one your customer cannot deduct input VAT against, and in the tax invoice flow it is one you cannot lawfully hand over at all.

Knova has not delivered a live Saudi ZATCA clearance integration, and we would rather say so plainly. What we bring is the regional e-invoicing work behind it: a live UAE integration connecting a client's Odoo to an accredited service provider on the Ministry of Finance list, and our own module posting invoices to Pakistan's FBR gateway. The pattern holds across all three regimes: the regulator publishes a specification, the ERP must meet it exactly, and the project succeeds or fails on tax configuration, master data and operational discipline rather than on code. That is the ground our Odoo implementation work covers, in English, Arabic or Urdu.