ZATCA E-Invoicing with Odoo
Techvaria configures and integrates Odoo for ZATCA Phase 2 compliance in Saudi Arabia — cryptographic stamping, invoice chaining, UBL 2.1 XML generation, TLV QR codes, and live Fatoora integration for both clearance and reporting. We handle EGS onboarding end to end: CSR generation, OTP exchange, CSID issuance, ZATCA’s compliance checks, and the move to production. If you are in Wave 25 with a 1 February 2027 deadline, or already past your wave date and quietly non-compliant, this page explains exactly what is required, what Odoo already does natively, and what still needs building.
ZATCA Phase 2 Requirements: Clearance, Reporting & Odoo
ZATCA’s e-invoicing mandate runs in two phases, and the difference between them is the difference between a formatting change and a systems integration project.
Phase 1 — Generation, in force since December 2021. Invoices must be issued electronically in a structured format, carry required fields, and — for simplified invoices — display a QR code. Crucially, Phase 1 is self-contained: your system generates a compliant document and that is the end of it. Most businesses cleared Phase 1 with a template change.
Phase 2 — Integration, rolling since January 2023. Your invoicing system now talks to ZATCA directly, in real time, with cryptography. This is not a template change. Your system must be registered with ZATCA as an E-Invoice Generation Solution, hold a cryptographic identity issued by ZATCA, produce UBL 2.1 XML to specification, digitally sign each document, chain every invoice to the one before it, and transmit to the Fatoora platform through an API.
Two transmission models apply, and they behave differently:
- Standard tax invoices (B2B and B2G) require clearance. The invoice is submitted to ZATCA before it goes to your customer. ZATCA returns a cleared, stamped document. Until that response arrives, you do not legally have an invoice.
- Simplified tax invoices (B2C) require reporting. The invoice is issued at the point of sale and transmitted to ZATCA within 24 hours.
That first model is the one that changes how a business operates, because your invoicing process now has an external dependency in the middle of it.
ZATCA Phase 2 Waves: Which One Are You In?
ZATCA enforces Phase 2 in waves determined by VAT-subject revenue, and notifies businesses at least six months before their date. Waves are cumulative — once you are in, you stay in, regardless of later revenue. If your revenue in any of the tested years crossed the threshold, you are in scope.
| Wave | Revenue threshold (VAT-subject) | Integration deadline | Status |
|---|---|---|---|
| Waves 1–22 | SAR 3 billion down to SAR 1 million | 2023 – early 2026 | Closed — enforcement active |
| Wave 23 | Above SAR 750,000 | 31 March 2026 | Closed — enforcement active |
| Wave 24 | Above SAR 375,000 (2022, 2023 or 2024) | 30 June 2026 | Closed — enforcement began 1 July 2026 |
| Wave 25 | Above SAR 187,500 (2022, 2023, 2024 or 2025) | 1 February 2027 | Open — act now |
Two things about this table deserve attention.
Wave 25 effectively completes the rollout. At SAR 187,500, the threshold now reaches small and micro-businesses. If you are VAT-registered in Saudi Arabia and have not yet integrated, Wave 25 is almost certainly your wave, and 1 February 2027 is your date. Working back from it, an integration that includes configuration, onboarding, ZATCA’s compliance checks and testing needs to start well before December — not in January.
Being past your wave date is a live exposure, not a historical one. Businesses in Waves 23 and 24 that missed integration are generating invoices that do not meet the requirement every single day. This is worth separating clearly from the fines amnesty running to 31 December 2026: that initiative covers late registration, late payment, late filing and VAT return corrections. It does not cover e-invoicing violations, and it explicitly excludes penalties under Article 45 of the VAT Law, tax evasion penalties, fines already paid, and penalties on returns due after 30 June 2026. Anyone telling you the amnesty buys time on Phase 2 integration is wrong, and it is an expensive thing to be wrong about.
What Odoo Already Does Natively — and What It Doesn’t
This is the question every Saudi Odoo user asks and almost nobody answers honestly, because most parties answering it are selling a ZATCA module. Here is our straight answer.
Odoo ships a Saudi localisation, and it is real. Recent Odoo versions include Saudi Arabian localisation with e-invoicing support — UBL 2.1 generation, cryptographic stamping, QR code production, invoice chaining, and integration with ZATCA’s clearance and reporting endpoints. If you are on a current Odoo version running a reasonably standard invoicing process, there is a genuine chance you need configuration and onboarding rather than a purchased module. Nobody selling a module will lead with that.
Where native coverage runs out is specific and worth knowing before you buy anything:
- Older Odoo versions. Localisation support has matured across releases. On an older version you are choosing between upgrading Odoo and bridging the gap another way — and the upgrade is often the better commercial answer.
- Multiple EGS units. Several branches, several POS devices, or several legal entities on one database each need their own registered unit and CSID lifecycle. Native handling of that at scale is where custom work usually starts.
- Non-standard invoicing flows. Consolidated billing, complex export and zero-rated scenarios, self-billing, and heavily customised invoice logic can all produce XML that validates in theory and rejects in practice.
- Retail and POS at volume. High-throughput simplified invoicing with offline resilience and a reliable 24-hour reporting queue needs engineering attention beyond default configuration.
- Chain recovery. What happens when the chain breaks. Native Odoo will not design your recovery procedure — and you need one before you need it.
Our position: we assess what your Odoo version and process already cover before quoting anything. If native localisation plus configuration gets you compliant, we will tell you, and the engagement is smaller. That is a worse sales pitch and a better outcome.
Our ZATCA E-Invoicing Services for Odoo
Every ZATCA engagement follows the same sequence, because ZATCA’s own onboarding is sequential and the compliance checks will not pass out of order. Nothing goes to production until it has cleared ZATCA’s simulation environment.
ZATCA Readiness Assessment
We review your Odoo version and localisation status, invoicing flows by document type, branch and POS structure, VAT configuration, master data quality, and confirm which wave applies to you. You receive a written gap report and a fixed-scope proposal — including, where it applies, a finding that native configuration is sufficient.
Odoo Configuration for Saudi VAT and E-Invoicing
Saudi VAT at 15% with correct standard, zero-rated, exempt and out-of-scope treatment; company and branch identification data; buyer and seller identification schemes; document types mapped to standard versus simplified treatment; and the mandatory field set validated across every invoice template you actually use.
EGS Onboarding and CSID Management
We generate the Certificate Signing Request, complete the OTP exchange through the Fatoora portal, obtain the compliance CSID, run ZATCA’s compliance checks, and move you to a production CSID. For multi-branch and multi-device environments we document the unit structure and set up the renewal process so certificates do not expire quietly.
Fatoora Integration: Clearance and Reporting
Both API paths configured and tested — synchronous clearance for standard invoices with the cleared response stored against the record, and reporting for simplified invoices within the 24-hour window, with queuing and retry handling for API downtime.
Invoice Chaining, Stamping and QR Implementation
PIH and ICV sequencing verified end to end, cryptographic stamping validated, and TLV QR encoding checked field by field against the specification rather than by eye.
POS and Retail Simplified Invoicing
For retail, F&B and high-volume environments: per-device EGS structure, offline behaviour, reporting queue design, and reconciliation between issued and successfully reported documents so nothing sits unreported unnoticed.
Testing in ZATCA’s Simulation Environment
Every document type you issue is tested against ZATCA’s simulation environment before production — not a sample. Export invoices, credit notes, debit notes and zero-rated supplies are where rejections concentrate.
Remediation for Businesses Already Past Their Wave Date
If you are in Wave 23 or 24 and not integrated, we prioritise getting compliant transmission live first, then address the historical position with your tax adviser. Speed matters more than elegance in this scenario.
Odoo Version Upgrade for ZATCA Readiness
Where your Odoo version predates adequate localisation support, we scope the upgrade as the compliance route — frequently cheaper and more durable than bridging an old version with custom code.
Post-Go-Live Monitoring and Support
Rejection monitoring, chain integrity checks, CSID renewal tracking, and support through ZATCA specification updates — which do continue to arrive.
What Phase 2 Requires From Your Odoo System
These are the technical obligations your system must meet. Each one is a place a migration or configuration can go wrong, which is why we test them individually rather than as a whole.
EGS Registration and Cryptographic Identity
Each Odoo EGS unit must be registered with ZATCA and issued a CSID. We manage unit registration, certificate renewal, and identity matching to prevent transmission errors.
UBL 2.1 XML to Specification
Every invoice must be generated as structured XML conforming to ZATCA’s implementation of UBL 2.1. Field-level precision matters — VAT category codes, exemption reason codes, party identification schemes and rounding behaviour all have defined rules, and ZATCA validates them.
Cryptographic Stamping and Digital Signature
Invoices carry a cryptographic stamp applied with the certificate issued during onboarding. Simplified invoices are stamped by your system; standard invoices receive ZATCA’s stamp on clearance.
Invoice Chaining: PIH and ICV
Every invoice links to the previous through PIH and ICV, creating a secure chain. We validate sequencing and recovery procedures to prevent production failures.
TLV QR Codes
Simplified invoices must display a QR code encoding specific fields in Tag-Length-Value format, base64 encoded. The encoding is exact; a visually correct QR code carrying wrong-order fields is a non-compliant invoice.
UUID and Mandatory Field Set
Each document carries a UUID alongside the full set of mandatory fields — seller and buyer identifiers, VAT registration numbers, supply dates, and line-level tax treatment.
Clearance API for Standard Invoices
Standard tax invoices submit to the clearance endpoint and wait for a cleared response before issue. Your system needs to hold the document, handle the response, and store the cleared XML against the record.
Reporting API for Simplified Invoices
Simplified invoices submit to the reporting endpoint within 24 hours, which needs queuing and retry handling for when the API is unavailable — because at some point it will be.
Archiving and Audit Readiness
Cleared and reported documents, with their ZATCA responses, must be retained and retrievable in their original format for audit.
How Odoo Fatoora Onboarding Actually Works
Most pages describe this as a single step. It is six, they run in order, and each has a failure mode. Knowing the sequence in advance is the difference between a two-week onboarding and a two-month one.
| Step | What happens | Where it commonly fails |
|---|---|---|
| 1. Prepare EGS unit data | Define each generation unit — instance, branch or device — with its identifying data | Unit structure decided too late, then rebuilt after CSIDs are issued |
| 2. Generate CSR | Odoo produces a Certificate Signing Request carrying the unit’s identity attributes | Attribute mismatch against ZATCA registration data; wrong environment selected |
| 3. OTP exchange via Fatoora portal | Obtain a one-time password from the portal and submit it with the CSR | OTP expiry — they are short-lived; and using a production OTP against simulation |
| 4. Compliance CSID issued | ZATCA returns a compliance certificate for testing | — |
| 5. ZATCA compliance checks | Submit required sample documents for each invoice type you issue | Untested document types — credit notes, export invoices and zero-rated supplies are where this stalls |
| 6. Production CSID and go-live | Production certificate issued; live transmission begins | Chain continuity between test and production; unreported backlog from the switchover window |
The step that surprises people is five. ZATCA’s compliance checks are per document type, and businesses routinely test the standard invoice, pass, and discover at go-live that their credit note or export invoice format was never validated. We test every document type you actually issue, including the ones issued rarely — because rarely is not never, and a rejected credit note at month-end is a reconciliation problem that lands on finance.
Why ZATCA Integrations Fail — and How We Prevent It
These are the failure modes we are called in to fix. Every one of them is preventable at design stage and expensive afterwards.
- The invoice chain breaks. A database restored from backup, a test instance sharing a certificate, or a document created out of sequence breaks PIH continuity, and every subsequent invoice fails validation. Repairing a broken chain in production is genuinely difficult. Prevention is procedural: strict environment separation, certificate discipline, and a documented recovery procedure written before you need it.
- Only the happy path was tested. The standard B2B invoice passes; export invoices, credit and debit notes, zero-rated supplies and advance payments were never validated. These surface at month-end.
- The EGS unit structure was wrong. A business registers one unit, then discovers each branch or POS device needed its own. Reissuing certificates across a live estate is disruptive.
- Nobody watches rejections. Invoices submit, some fail, and nothing alerts anyone. Weeks later there is a gap between issued and cleared documents that must be reconciled retroactively. Rejection monitoring is not optional infrastructure.
- Certificates expire quietly. CSIDs have a lifecycle. Without renewal tracking, compliance stops on an ordinary Tuesday.
- The 24-hour reporting window is treated as generous. For B2C volume it is not, if the queue has no retry logic and the API has an outage. Design for failure and it is comfortable; assume availability and it is not.
- Master data was never cleaned. Missing buyer VAT numbers, malformed identification schemes and inconsistent address data cause rejections that look like integration bugs but are data problems. We validate master data before onboarding, because ZATCA validates it whether you did or not.
Find Out Where You Stand Before the Deadline Does
The free ZATCA readiness assessment takes about an hour. We confirm which wave applies to you, review your Odoo version and localisation status, inventory the document types you issue, check your master data against ZATCA’s field requirements, and return a written gap report with a fixed-scope proposal and a realistic timeline. If your Odoo version and configuration already cover the requirement, the report will say so — and you will have documentation to that effect rather than a quotation. With Wave 25 due 1 February 2027, the useful time to find out is now, not December.
Why Businesses Choose Techvaria for ZATCA E-Invoicing with Odoo
Most parties answering “do I need a ZATCA module for Odoo” are selling one. We start by checking whether your Odoo version and configuration already cover it — and when they do, we say so and the engagement is smaller.
Across [X] Odoo implementations, our approach on compliance work is consistent: assess before quoting, test every document type rather than a sample, and design the failure handling before go-live rather than after the first rejection backlog. The onboarding walkthrough and failure-mode sections above are the actual content of our design reviews, published, because we would rather be judged on method than adjectives.
We work with Saudi businesses from our regional base, delivering configuration, onboarding, integration and post-go-live monitoring remotely — the model most Odoo compliance work runs on, since Fatoora onboarding and API integration are performed against ZATCA’s platform rather than on site. Where on-site presence is genuinely required, we agree it in scope rather than assuming it away.
Our consultants work across trading, manufacturing, retail and services businesses in the Gulf and India, including multi-entity groups with obligations in more than one jurisdiction.
Related reading: QuickBooks to Odoo migration · SAP Business One to Odoo migration · Tally to Odoo migration
Hear From Our Clients
At Tasis Tech, we hold a very high bar when it comes to delivering Odoo projects — from understanding client requirements to documentation and quality delivery. Working with Techvaria has been a genuinely smooth and valuable experience. Their team not only understands the technical side but also has a strong grasp of business processes, which is rare to find. Their Odoo expertise is exceptional, and what I appreciate most is their ability to align with our delivery standards without needing constant follow-up. It feels more like working with an extension of our own team, rather than an external vendor. Looking forward to more successful collaborations ahead.
As an Odoo Partner myself, I sometimes have to admit I don't understand something. This is usually when we see complicated configurations and accounting. In these cases I just turn it over to Techvaria. TV's experts in Odoo accounting and configuration is second to none/ Anyone who gets stuck and needs people with the skill of a Forensic Accountant should be looking at Techvaria for help! Every instance I have had issues with they have figured out and corrected very quickly, and for a very reasonable cost. Very easy to communicate with too.
We recently worked with Techvaria on the implementation of the Odoo ERP software, and the entire experience was excellent. Techvaria team demonstrated deep expertise and a strong understanding of the Odoo platform, guiding us through every step of the implementation process. From initial planning and customization to deployment and training, they provided clear communication, valuable insights, and practical solutions tailored to our business needs. Their ability to troubleshoot challenges and offer proactive advice made a complex transition feel smooth and manageable without having to develop custom modules.I highly recommend recommend Techvaria to any business looking for a knowledgeable and reliable partner for Odoo ERP implementation.
I would like to thank Techvaria Odoo team for the pleasant collaboration. I truly appreciate team commitment and direct availability – it really makes a difference. It’s a pleasure to work with people who are approachable and engaged. I’m looking forward to expanding our collaboration even further!
ZATCA E-Invoicing by Business Type
Frequently Asked Questions
Recent Odoo versions include Saudi localisation with e-invoicing support — UBL 2.1 XML, cryptographic stamping, QR codes, invoice chaining and ZATCA API integration. Whether that is sufficient for you depends on your Odoo version, branch and device structure, and how standard your invoicing flows are. Compliance still requires correct configuration and EGS onboarding regardless.
Waves are set by VAT-subject revenue and are cumulative. Wave 24 covered revenue above SAR 375,000 with a 30 June 2026 deadline. Wave 25 covers revenue above SAR 187,500 — tested against 2022, 2023, 2024 or 2025 — and is due 1 February 2027. If you are VAT-registered and not yet integrated, Wave 25 is almost certainly yours. ZATCA notifies businesses at least six months ahead.
Standard tax invoices for B2B and B2G require clearance — submitted to ZATCA before going to the customer, and returned cleared and stamped. Simplified invoices for B2C require reporting — issued at point of sale and transmitted to ZATCA within 24 hours. Your Odoo system needs both paths configured.
Not necessarily. On a current Odoo version with standard invoicing flows, native localisation plus configuration and onboarding is often enough. Custom work is usually driven by older versions, multiple EGS units across branches or POS devices, high-volume B2C throughput, or non-standard invoicing. Assess before purchasing anything.
You are non-compliant on every invoice issued since. The priority is getting compliant transmission live quickly, then addressing the historical position with your tax adviser. Note that the fines exemption initiative running to 31 December 2026 covers late registration, payment, filing and return corrections — it does not cover e-invoicing violations.
No. The initiative extended to 31 December 2026 covers late registration, late payment, late filing and VAT return correction fines. It explicitly excludes tax evasion penalties, fines under Article 45 of the VAT Law, fines already paid, and penalties on returns due after 30 June 2026. Confirm your specific position with your tax adviser.
It depends on Odoo version, number of EGS units, document types to validate and master data quality. The sequence is fixed — configuration, CSR and OTP, compliance CSID, ZATCA compliance checks, production. Step five is where timelines slip when document types were not tested upfront. The assessment gives you a firm timeline.
Yes, with the right structure. Each generation unit needs its own registration and CSID, with renewal tracked per unit. Designing that structure before onboarding is important, because reissuing certificates across a live multi-branch estate is disruptive and avoidable.
