Localisation and e-invoicing in Odoo

More interview questions land on this station than on any other, and it is the one most published Arabic writing about Odoo gets wrong. The reason is that what looks like one question is two entirely different questions, and anyone who conflates them answers wrongly with confidence.

The two questions people merge

First: does Odoo support my country’s accounting? Meaning a local chart of accounts, correct tax rates, and tax reports in the authority’s own shape.

Second: does Odoo connect to my government’s e-invoicing platform? Meaning sending each invoice to the authority in its technical format, signing it, and receiving the response.

The first is answered by a localisation package. The second needs a separate integration module, and the existence of the first says nothing whatsoever about the second. Most people who say “Odoo supports Saudi Arabia” mean the first and are understood to mean the second.

The table that decides it

Built from the technical module names in Odoo’s open repository on branch 19.0, and from the localisation pages in the official documentation, all read on 6 September 2026:

Country	Accounting package	Platform integration module	Who ships it
Saudi Arabia	l10n_sa	l10n_sa_edi	Odoo itself, licensed LGPL-3
Egypt	l10n_eg	l10n_eg_edi_eta	Odoo itself
UAE	l10n_ae	Nothing published	—

One finding is worth stating outright, because it contradicts what circulates: the Saudi integration module l10n_sa_edi sits in Odoo’s own community repository, and the licence declared in its manifest is LGPL-3. It is not a third-party module, and it is not restricted to Enterprise by licence. Anyone claiming otherwise has not opened the repository.

The other way round: the UAE localisation page in the Odoo 19 documentation does not mention e-invoicing at all — neither as supported nor as unsupported. That absence is a fact rather than an inference, and it is the fact that determines the right answer for a UAE client: coverage comes from a third party, not from the product.

What this means at evaluation and purchase — as opposed to at learning — is in the Odoo guide: the real cost and where it breaks.

What e-invoicing actually does

Before any configuration, understand what changed technically. An electronic invoice is not a PDF sent by email. It is four things at once:

1. A regulated data format — a structured file a machine reads, not an image a human reads.
2. A cryptographic signature or stamp proving the invoice came from this taxpayer and was not altered afterwards.
3. A unique identifier per invoice that prevents duplication and repudiation.
4. Transmission to the authority’s platform — either in real time before the invoice reaches the customer, or by later reporting, depending on the invoice type.

Points two and three are what make reversal impossible: an invoice that has been sent and stamped cannot be edited or deleted. Correction happens through a linked credit note — which changes a deeply entrenched operating habit in many companies that simply edited the invoice.

Saudi Arabia: the two phases

The Saudi e-invoicing regime was implemented in two phases that differ fundamentally, and conflating them is the second most common error.

The generation phase. The requirement is to issue the invoice electronically with specified fields and a QR code, and to store it. No connection to the authority. Any system that issues an invoice carrying the required fields satisfies it, and that is what l10n_sa does on its own.

The integration phase. Here everything changes: the invoice is cryptographically signed and transmitted to the authority’s platform, and a business-to-business invoice goes through a procedure that precedes handing it to the customer. That is the job of l10n_sa_edi, and it is what needs a cryptographic certificate and a live connection.

Anyone who says their system is “e-invoicing compliant” without naming the phase has said nothing. That is the question to put to any system vendor, and it is also the question you may be asked in an interview.

Egypt

The Egyptian e-invoicing system rests on taxpayer registration, a digital signature, standardised item coding, and transmission to the authority’s system.

The third item is the one that consumes the time in every implementation: coding items against the approved standard — which is master-data work, not system work. Anyone who read station three knows why it sat at the beginning of the path rather than the end: this coding lives on the item card, and preparing it for a thousand items after they have movement is harder than preparing it before.

What you actually do at this station

Your training environment is not a registered taxpayer, so you will not send a real invoice to any authority. The goal is different: to know the difference between what exists and what does not, from evidence.

1. Install your country’s localisation package — on a fresh database, because the package is chosen before the first entry and not swapped afterwards.
2. Inspect the taxes it created, and compare their rates against the published rate in your country.
3. Issue an invoice and examine its fields, looking for the fields the localisation added that were not there before.
4. Open the tax report and verify it is built directly from the entries. A tax report produced by exporting to a spreadsheet and editing by hand is a report that does not survive an audit.
5. Open the module manifest in the repository and read its licence and dependencies yourself. That skill — verifying at source rather than believing a post — is the most useful thing you take from this station, and it is what made the table above contradict what circulates.

The fields that must be correct before any integration

Whatever the module, no integration passes with incomplete data. The four that projects fail on:

• Tax registration number for the company and for the customer — without the customer’s, no compliant business-to-business invoice leaves the system.
• A full address in separate fields — not one free-text line.
• Unit of measure with an approved code where one is required.
• Item classification against the required standard.

Read that list again: all four are master data, not invoice settings. And that is the real message of the station — localisation is a data project presented as a technical project, and anyone who starts it from the settings screen discovers that late.

The acceptance test for this station

1. Name the localisation package and the integration module for your country by their technical names, or state plainly that the second is not published.
2. State the difference between the Saudi generation and integration phases in one sentence each.
3. Open a module manifest in the Odoo repository and read its licence — as your own verification, not as a quotation from this page.
4. Produce the list of missing fields in your database that would prevent a compliant invoice being issued.
5. Answer this as you would in an interview: a UAE client asks about e-invoicing in Odoo — what exactly do you tell them?

What comes next

You know what the product does and what it does not. The next station handles what happens when it does not: customisation — where the line falls between what configuration solves and what earns a written module, and why in most cases the correct answer is to write no code at all.