Odoo can send your invoices to ZATCA's Fatoora platform through its Saudi module. Each sales journal is onboarded separately with a one-time password, and simulation invoices are not legally valid. This page covers what ZATCA requires, what Odoo already includes, the three environments, the onboarding steps and the data mistakes that get invoices rejected.
Devvista is an official Odoo partner and software development company that sets up and connects Odoo for Saudi businesses remotely, in Arabic and English. If you want a plan for your own Odoo, book a call.
What ZATCA phase two asks of an Odoo company
Saudi e-invoicing has two phases. Phase one, the generation phase, started on 4 December 2021 and covers issuing and storing electronic invoices. Phase two, the integration phase, is enforceable from 1 January 2023 and rolls out in waves by taxpayer group. In phase two your invoicing system has to connect to ZATCA's Fatoora platform, send each invoice in the required format and receive a clearance or reporting response (ZATCA roll-out phases).
ZATCA says it will notify taxpayers of their phase two wave at least six months in advance. So the practical question is not whether Odoo can do it, but whether your Odoo is configured, onboarded and tested before your own date. Check your wave directly with ZATCA, because wave lists change and this page does not repeat them.
What Odoo already includes for Saudi Arabia
Odoo ships a Saudi localisation that covers both phases. According to Odoo's Saudi Arabia documentation, the table below shows what each module does.
| Module | What it does |
|---|---|
l10n_sa | Default fiscal localisation for Saudi Arabia, with the phase one QR code |
l10n_sa_edi | Phase two API integration with ZATCA for e-invoicing |
l10n_sa_pos and l10n_sa_edi_pos | The same compliance fields and e-invoicing for Point of Sale invoices |
The localisation also requires the company currency to be SAR, a VAT number and an identification scheme on the company, and a company name of no more than 63 characters. Check the name on the first day of the project, because it is the limit that is easiest to forget.
Sandbox, simulation and production: three environments, one-way door
Odoo connects to ZATCA in three modes. Pick the wrong one at the wrong time and you either test against live data or go live without a proper rehearsal.
| Mode | What it is | Where the one-time password comes from |
|---|---|---|
| Sandbox | A shared, pre-configured test environment for trying the integration out of the box | Pre-configured test setup |
| Simulation (pre-production) | A test environment for your own integration, run on a duplicate of your production database | Fatoora Simulation Portal |
| Production | The live environment, where invoices have legal effect | Fatoora Portal, Production Environment |
Two limits from Odoo's documentation matter. Simulation invoices are not legally valid. And once the API mode is switched to production and an invoice is submitted, it cannot be switched back to sandbox or simulation. That is why we always rehearse on a copy of the database and keep production for the last step.
The onboarding steps inside Odoo
Odoo's documentation describes four steps for each environment.
- Set the ZATCA API mode in Accounting, Configuration, Settings.
- Complete the company information: legal name, VAT number, identification scheme and address.
- Open the sales journal, go to the ZATCA tab, click Onboard, enter the six-digit one-time password from the Fatoora portal and confirm.
- Create and confirm test invoices, click Process now and check that the API response reads "Action Successful".
Each sales journal is onboarded separately, so a company with a main journal, a branch journal and a point-of-sale journal repeats step three three times. The one-time password expires after 60 minutes, so generate it when you are ready to type it in, not at the start of a meeting.
Arabic on the invoice: what has to be in Arabic
Odoo's documentation states that Saudi VAT rules require Tax Invoices and Simplified Tax Invoices to be in Arabic, and that invoices may also carry English. Arabic can be set per customer, or for the whole company by enabling the Gulf Cooperation Council format option.
In practice this is a data job as much as a setting. Customer names, addresses and product names need Arabic values in the database for the printed invoice to read fully in Arabic. Our guide to Odoo in Arabic for UAE companies covers the translation and right-to-left report side, which applies the same way here.
Why invoices get rejected, and what to do
Odoo's documentation is direct about the consequences: a rejected invoice is not legally valid and must be corrected and resubmitted. Successfully submitted invoices can only be reset to draft in sandbox or simulation, never in production. So the cost of a data mistake is highest after go-live.
| Problem | Where it shows up | Fix before go-live |
|---|---|---|
| Company name over 63 characters | Company settings | Shorten the name to what the registration allows |
| Wrong or missing VAT number or identification scheme | Company and customer records | Check against the ZATCA registration |
| Company currency not SAR | Accounting settings | Set SAR before any posted invoice |
| Journal not onboarded | ZATCA tab of each sales journal | Onboard every journal that issues invoices |
| Expired one-time password | Onboard window | Generate a new one and enter it within 60 minutes |
Which invoice scenarios to rehearse before production
Odoo's Saudi documentation has dedicated sections for invoice submission, QR code verification, debit and credit notes, down payments and retention, plus the Point of Sale flow. Those are the scenarios a rehearsal should cover, because each one produces a different document that has to be accepted.
| Scenario | What to check in simulation |
|---|---|
| Standard tax invoice to a business customer | The API response reads "Action Successful" and the printed invoice shows Arabic |
| Simplified invoice to a consumer | The QR code is present and verifies |
| Credit note and debit note | They link back to the original invoice and are accepted |
| Down payment and final invoice | The amounts across both documents reconcile |
| Retention | The retained amount appears correctly on the invoice |
| Point of Sale receipt | The POS journal is onboarded and its invoices are accepted |
Run each scenario at least once on the simulation copy and keep the responses. If a scenario is rejected there, it will be rejected in production, where the invoice cannot be moved back to simulation.
Is your Odoo ready? A short check
Before anyone connects anything, answer these. Each one decides how much work the project is.
- Which Odoo version and hosting do you run (Odoo Online, Odoo.sh or your own server)? The Saudi modules are documented for Odoo 19, and older versions need a separate check.
- Do you have custom modules that change invoices, taxes or numbering? These need testing against the e-invoicing flow.
- Do you issue invoices from more than one journal, branch or point of sale?
- Are customer and product names in Arabic where the invoice needs them?
- Who on your side holds the Fatoora portal login that issues the one-time password?
Project steps and what drives the cost
A typical Odoo e-invoicing project for a Saudi company has five steps: review the current setup, fix company, customer and tax data, onboard in simulation on a database copy, run a batch of real invoice scenarios (standard, simplified, credit and debit notes), and then onboard production and monitor the first invoices.
The work is scoped by the number of journals, the amount of customisation and how much Arabic data has to be cleaned. Devvista prices either as a fixed price from $500 to $100,000 depending on complexity, or hourly from $10 to $100 per hour depending on the type and level of developer. After a short review of your Odoo we give you a day-based plan so you can see what the work involves before you commit. For licence and implementation costs in general, read our Odoo pricing guide.
Where Devvista fits
Devvista is an official Odoo partner and software development company. We work remotely with companies in Saudi Arabia, including Jeddah, Riyadh and Dammam, in English and Arabic, and we do not claim a local office. For Odoo work in general see our Odoo implementation service, and for the same topic in the UAE read Odoo UAE e-invoicing integration.
If your Saudi project needs more than Odoo, such as a custom connector, an automation between your shop and your accounts, or extra developers for a fixed period, the same team covers custom software development, ecommerce development and hiring developers. You can see how we document our work in the case studies.