UBL 2.1 XML
The invoice is a structured XML document in ZATCA's UBL 2.1 profile, not a PDF with data on it. The PDF, if there is one, is the human-readable face of the XML.
Saudi Arabia · ZATCA · Fatoora
ZATCA Phase 2 requires a business to integrate its invoicing system with the Fatoora platform: every invoice is issued as UBL 2.1 XML, carries a UUID, a cryptographic stamp made with a certificate ZATCA issues to that specific unit, a hash of the previous invoice and a QR code — with standard tax invoices cleared by ZATCA before they reach the buyer and simplified invoices reported afterwards. Neither Odoo nor ERPNext does this out of the box in either edition; the capability comes from a localisation module plus configuration and testing done by whoever implements the system.
Saudi e-invoicing has two phases. Phase 1, the Generation phase, began on 4 December 2021 and applies to every VAT-registered taxpayer: invoices must be produced by a compliant electronic system rather than by hand, and must carry the mandated fields including the QR code. Phase 2, the Integration phase, began on 1 January 2023 and is being rolled out in waves. It adds the hard part — the technical link to ZATCA.
Which wave you are in is decided by your VAT-subject revenue in the years ZATCA names, and ZATCA states it tells each wave at least six months before its integration date. So the deadline is not a surprise, but six months is short for an ERP project that also has to cover a chart of accounts, item master, tax setup and print formats.
The part most vendors leave out: an ERP alone does not make you compliant. Odoo ships a Saudi localisation, and ERPNext has community-maintained ZATCA apps. Both give you a starting point. Neither ships configured for your business, your certificates, your invoice types or your device fleet, and neither absolves you of the compliance testing that has to happen before your integration date.
BDC implements both Odoo and ERPNext, is an official partner of neither, and takes commission from neither.
The single most volatile fact on this page, kept in one place so it can be re-checked. Each wave is defined by a revenue threshold; once your revenue in any of the named years crosses it, you are in that wave and every later one.
| Wave | Who it covers | Integration date |
|---|---|---|
| Wave 1 | VAT-subject revenues above SAR 3 billion in 2021 | from 1 Jan 2023 |
| Wave 2 | VAT-subject revenues above SAR 500 million in 2021 | from 1 Jul 2023 |
| Wave 3 | VAT-subject revenues above SAR 250 million in 2021 or 2022 | from 1 Oct 2023 |
| Wave 4 | VAT-subject revenues above SAR 150 million in 2021 or 2022 | from 1 Nov 2023 |
| Wave 5 | VAT-subject revenues above SAR 100 million in 2021 or 2022 | from 1 Dec 2023 |
| Wave 6 | VAT-subject revenues above SAR 70 million in 2021 or 2022 | from 1 Jan 2024 |
| Wave 7 | VAT-subject revenues above SAR 50 million in 2021 or 2022 | from 1 Feb 2024 |
| Wave 8 | VAT-subject revenues above SAR 40 million in 2021 or 2022 | from 1 Mar 2024 |
| Wave 9 | VAT-subject revenues above SAR 30 million in 2021 or 2022 | from 1 Jun 2024 |
| Wave 10 | VAT-subject revenues above SAR 25 million in 2022 or 2023 | from 1 Oct 2024 |
| Wave 11 | VAT-subject revenues above SAR 15 million in 2022 or 2023 | from 1 Nov 2024 |
| Wave 12 | VAT-subject revenues above SAR 10 million in 2022 or 2023 | from 1 Dec 2024 |
| Wave 13 | VAT-subject revenues above SAR 7 million in 2022 or 2023 | from 1 Jan 2025 |
| Wave 14 | VAT-subject revenues above SAR 5 million in 2022 or 2023 | from 1 Feb 2025 |
| Wave 15 | VAT-subject revenues above SAR 4 million in 2022 or 2023 | from 1 Mar 2025 |
| Wave 16 | VAT-subject revenues above SAR 3 million in 2022 or 2023 | from 1 Apr 2025 |
| Wave 17 | VAT-subject revenues above SAR 2.5 million in 2022 or 2023 | by 31 Jul 2025 |
| Wave 18 | VAT-subject revenues above SAR 2 million in 2022 or 2023 | by 31 Aug 2025 |
| Wave 19 | VAT-subject revenues above SAR 1.75 million in 2022 or 2023 | by 30 Sep 2025 |
| Wave 20 | VAT-subject revenues above SAR 1.5 million in 2022 or 2023 | by 31 Oct 2025 |
| Wave 21 | VAT-subject revenues above SAR 1.25 million in 2022, 2023 or 2024 | by 30 Nov 2025 |
| Wave 22 | VAT-subject revenues above SAR 1 million in 2022, 2023 or 2024 | by 31 Dec 2025 |
| Wave 23 | VAT-subject revenues above SAR 750,000 in 2022, 2023 or 2024 | by 31 Mar 2026 |
| Wave 24 | VAT-subject revenues above SAR 375,000 in 2022, 2023 or 2024 | by 30 Jun 2026 |
| Wave 25 — current | VAT-subject revenues above SAR 187,500 in 2022, 2023, 2024 or 2025 | by 1 Feb 2027 |
Checked on 2026-08-09. One thing worth knowing, because no one else says it: ZATCA has taken most of the older wave announcements off its live site, so the pages for waves 1–21, 23 and 24 now return a not-found shell and their figures survive only in search-engine copies of those same ZATCA pages. The Wave 22 and Wave 25 announcements are still live and were read directly, as was the roll-out page — but its wave table is an image, not text. Waves 22, 24 and 25 we consider firm; the earlier rows and Wave 23 we would call reliable rather than verifiable today. ZATCA has been announcing a new wave every few months, each with a lower threshold, so if you are reading this long after the date above, verify the last two rows first.
These are the requirements that separate an invoice your accounting software prints from an invoice ZATCA will accept. Every one of them is a place an implementation can quietly fail its compliance test.
The invoice is a structured XML document in ZATCA's UBL 2.1 profile, not a PDF with data on it. The PDF, if there is one, is the human-readable face of the XML.
Every document carries a universally unique identifier and a sequential counter value. A gap or a duplicate is not a cosmetic problem — it breaks the chain.
Simplified invoices are stamped by your own system using a Cryptographic Stamp Identifier issued to that specific invoice-generation unit — not to the company in general. Standard invoices are stamped by ZATCA itself during clearance.
Each invoice embeds the hash of the one before it, so the sequence forms a chain. Restore a database to an earlier point without understanding this and the chain breaks.
A Base64 QR code carrying nine Tag-Length-Value fields. Five have applied since Phase 1 — seller name, VAT number, timestamp, total with VAT, VAT total. Phase 2 adds the invoice hash, the ECDSA signature, the public key, and on simplified invoices ZATCA's own signature over that key.
Standard tax invoices are cleared by ZATCA before they are given to the buyer. Simplified invoices are issued first and reported to ZATCA afterwards, within the window the regulation sets.
Each invoice-generation unit is onboarded through the Fatoora portal, obtaining a compliance certificate first and a production certificate after it passes ZATCA's compliance checks.
Point-of-sale terminals, branch systems and any other unit that issues invoices each need their own onboarding. A single ERP integration does not cover a fleet of tills.
The claim worth checking
Search for e-invoicing software in Saudi Arabia and almost every result claims to be "approved by ZATCA" or "معتمد من هيئة الزكاة والضريبة والجمارك". ZATCA does publish a directory of solution providers. What it does not do is approve, certify or accredit any of them — and it states this on the directory page itself.
What the directory actually is: a guiding, non-binding list of providers who expressed willingness to supply compliant solutions. ZATCA explicitly disclaims that inclusion is an approval, and disclaims liability for publishing the list at all. A taxpayer may use any provider, listed or not, as long as the invoices meet the requirements — and it is the taxpayer, not the vendor, who is assessed for compliance.
The Implementation Resolution goes further than most people realise. It says a solution is deemed compliant after its conformity is verified by ZATCA, or by a third party, or self-certified by the taxpayer. Self-certification is expressly allowed. There is no mandatory product certification for anyone to hold, which is why nobody holds one.
This matters commercially. "Approved by ZATCA" is used to justify a price premium and to close a decision early. It is a marketing claim, not an accreditation, and no honest supplier should be leaning on it — us included. What is real is the compliance check ZATCA runs during onboarding against one specific invoice-generation unit, tied to your VAT number and that unit's certificate: it validates your setup, not a product, and it has to be passed again for every unit you onboard. A vendor can truthfully say it appears in ZATCA's indicative directory, or that it has onboarded units successfully. "Certified" is not available to say.
"This list is a guiding list (non-legally binding to taxpayers)… This list is not considered as an approval by ZATCA of the e-solutions provided by the solution providers. ZATCA shall not bear any liability arising from publishing this list directly or indirectly."
ZATCA, Solution Providers Directory — the Arabic original reads "قائمة استرشادية وغير ملزمة… ولا تعتبر هذه القائمة بمثابة اعتماد من الهيئة". Read 8 August 2026.
An honest starting position for a selection decision. Neither product is compliant on installation; the difference is in where the localisation comes from and who maintains it.
| Area | Odoo | ERPNext |
|---|---|---|
| Where the localisation comes from | A Saudi fiscal localisation maintained by Odoo as part of the product, installed as a localisation module. | Community and vendor-maintained ZATCA apps installed on top of ERPNext, several of them open source. |
| Out-of-the-box compliance | No. The module is a foundation; certificates, invoice types, taxes and print formats are all configuration work. | No. The app is a foundation on the same terms, with the added question of which app you standardise on. |
| Who fixes it when ZATCA changes a rule | Odoo, on its own release cadence, then your implementer applies the upgrade to your instance. | Whoever maintains the app you chose. Check the commit history before you depend on it — this is a real selection criterion. |
| Point-of-sale and simplified invoices | Covered by the localisation for Odoo POS, but each terminal still needs its own onboarding and testing. | Depends on the app and on how your retail flow is built; more likely to need bespoke work. |
| What is always on the implementer | Onboarding each unit, compliance testing, tax and item configuration, print formats, staff training, and a plan for the next wave. | The same list, unchanged. This is the part no product removes. |
Both products change. Verify the current state of the localisation for the version you intend to run before you commit — a module that covered Phase 2 two releases ago is not evidence about the release you will deploy.
Nothing exotic. The value is in doing the unglamorous steps in an order that leaves time to fail the compliance check once and still make the date.
Check your VAT-subject revenue against the current thresholds and find the ZATCA notification if one has arrived. This decides the whole schedule.
Standard versus simplified, credit and debit notes, exports, branches, and every device that issues a document. This is where scope is usually underestimated.
Tax configuration, item master, customer tax numbers and addresses. Most compliance failures are data failures wearing a technical costume.
Install and configure the localisation, onboard each unit through Fatoora, and get through the compliance checks in the simulation environment.
Issue real documents against the sandbox before switching production over, so the first failure happens somewhere it does not cost you an invoice.
Documented training, plus a note in your calendar for the next wave announcement, because thresholds keep falling and group companies get caught later.
Every figure on this page comes from one of these ZATCA pages. If one of them has moved on since the date below, ZATCA is right and we are out of date.
Last checked against these sources on 2026-08-09
Direct answers to what Saudi finance teams ask before starting a Phase 2 project.
No, neither is. Odoo ships a Saudi fiscal localisation and ERPNext has community-maintained ZATCA apps, but in both cases the installed system still has to be configured for your invoice types, taxes and item data, onboarded unit by unit through the Fatoora portal, and passed through ZATCA's compliance checks. The product gives you a foundation; the implementation gives you compliance.
No. ZATCA publishes a solution providers directory, but states on that page that the list is guiding and non-binding, that inclusion "is not considered as an approval by ZATCA of the e-solutions provided", and that ZATCA bears no liability for publishing it. Vendors marketing themselves as "ZATCA approved" are describing a listing, not an accreditation. Compliance is assessed against the taxpayer and the invoices, not against a product brand.
By your revenue subject to VAT in the years ZATCA names for each wave. Once your revenue in any of those years exceeds a wave's threshold, you fall into that wave. ZATCA also states that it notifies targeted taxpayers directly at least six months before their integration date, so a notification is the definitive answer — but the threshold table lets you see it coming before the letter arrives.
A standard tax invoice is the B2B and B2G document, and in Phase 2 it must be cleared by ZATCA before it is handed to the buyer. A simplified tax invoice is the B2C document issued at the point of sale; it is given to the customer immediately and reported to ZATCA afterwards within the window the regulation sets. The two follow different technical paths, which is why a retail business has more integration work than a wholesaler of the same size.
The compliant electronic issuing system, the mandated invoice fields and the QR code carry over. What does not is the integration itself: the cryptographic stamping, the certificate issued per invoice-generation unit, the hash chain, and the clearance or reporting call to Fatoora. In practice, Phase 1 got your data and your print formats into shape; Phase 2 is a genuine technical project on top of that.
It is enough if your ERP is already live and your master data is clean. It is not much if you are also selecting and implementing the ERP in the same window, because the compliance work sits at the end of a project whose earlier phases tend to overrun. If you expect to be in an upcoming wave, the useful move is to start before the notification rather than after it.
Yes. Onboarding is done per invoice-generation unit, so each terminal or branch system that issues documents is onboarded and tested in its own right. A company with one ERP and forty tills has forty-one things to onboard, not one. This is the single most common reason a retail ZATCA project takes longer than the estimate.
ZATCA publishes a violations guide, and the structure matters more than the amounts: general violations start with a notice and a correction window — 30 days for the integration and issuing violations, 60 days for things like a missing QR code or non-compliant archiving — and the fines escalate only on repetition. Recurrence resets after twelve months without a repeat. So a first miss that you correct promptly is a different situation from a sustained one. Read the current guide rather than the figures circulating in blog posts, several of which are from a superseded 2022 edition.
No, and neither can anyone else. There is no certificate an implementer can issue. What we can do is configure the system, onboard your units, pass ZATCA's compliance checks with you and document what was done. BDC implements both Odoo and ERPNext, is an official partner of neither, and takes commission from neither, so the recommendation on which system to use is not a licence sale in disguise.
A short review of your wave, your invoice types and your current system, and a straight answer on how much work is between you and your integration date.
Request a ZATCA readiness review