Odoo and UAE E-Invoicing: PINT AE, Accredited Service Providers and What to Configure Before 2027

Odoo runs the books in a large share of UAE businesses that will be caught by the e-invoicing mandate. The system can produce a compliant invoice, but few installations are configured to do so today. Most were set up to print a PDF with a TRN on it, which is exactly what the new regime does not accept. This guide covers what has to change in Odoo, in what order, and where the typical setup falls short.

Where Odoo sits in the 5-corner model

The UAE model has five parties: the supplier, the supplier's Accredited Service Provider, the buyer's ASP, the buyer, and the Federal Tax Authority receiving tax data in near real time. Odoo is the supplier's system in corner one and, when you receive invoices, the buyer's system in corner four.

Odoo's job is to hold accurate data and produce a structured invoice in the UAE profile, called PINT AE, which is based on the UBL standard. The ASP's job is to validate it, deliver it to the buyer's ASP and report it to the FTA. Odoo never talks to the FTA directly. That split prevents the most common planning error: assuming the ERP upgrade alone makes you compliant.

The data Odoo must hold

A PINT AE invoice is rejected by the ASP if mandatory fields are missing or inconsistent. Every one of those fields comes from Odoo master data or configuration, so readiness is mostly data work. The table maps the main requirements to where they live in Odoo.

Tax codes deserve a specific note. The structured invoice needs a tax category per line, not just a rate. Odoo setups that use a single 0% tax for zero-rated exports, exempt supplies and out-of-scope items will fail validation or report the wrong category to the FTA. Separating them is a short configuration task, but every product and fiscal position has to be rechecked afterwards.

The ASP connector: two routes

There are two ways to get the invoice from Odoo to an ASP. The first is a localisation module, either from Odoo itself or from a third party, that generates the PINT AE XML inside Odoo and sends it through an API to your chosen ASP. The second is an integration built by the ASP, where their connector reads the posted invoice from Odoo, builds the XML on their side and returns the status.

Both routes work. The localisation route keeps the XML and its validation errors visible in Odoo, so finance can fix a rejected invoice where they created it. The ASP route is quicker to deploy but puts the format logic outside your control, so upgrades and custom fields need coordinating with the provider.

Whichever route you take, the ASP must be contracted first. Businesses with revenue of AED 50 million or more had to appoint one by 30 October 2026, and the connector cannot be tested without sandbox credentials from that provider. Choose the ASP early and let the Odoo work follow.

Testing in the sandbox

Every ASP offers a test environment. Build a test set that covers a standard tax invoice, a foreign-currency invoice, a zero-rated export, an exempt supply, a partial credit note and a full credit note. Add any case specific to your business, such as advances, retention or multi-company invoicing.

Send each case from Odoo, read the response, and confirm the invoice arrives in the buyer test inbox with the right totals. Then run the same set from a staging copy of production data, because real customer records are where TRN and address gaps show up.

What changes for the finance team day to day

Less than people fear, provided the setup is done. Invoices are still created in Odoo the same way. The difference is that posting now triggers transmission, and each invoice carries a status returned by the ASP: accepted, rejected or pending. A rejected invoice must be corrected and resent, and the team needs a daily view of anything not yet accepted.

Three habits have to change. Drafts are cancelled, not deleted, so the sequence stays intact. Corrections are made by credit note referencing the original, never by editing a posted invoice or raising a negative one. Customer onboarding now includes capturing a valid TRN and full address before the first invoice, which means sales and finance agreeing who owns that step.

Common gaps in existing Odoo setups

In our projects the same problems appear repeatedly.

• Community edition. Odoo Community holds the ledger, but the localisation and electronic invoicing features ship primarily in Enterprise, and most connectors assume a supported Enterprise version. Community users need a third-party module or an ASP-built integration, and should price that honestly against an upgrade.
• Old versions. Installations on version 14 or earlier no longer receive localisation updates, so a new invoice format will not reach them. The e-invoicing project becomes an upgrade project, and that belongs in the plan and the budget now.
• Custom invoice layouts. A customised PDF template is irrelevant to compliance. The PDF can still go to the customer, but the XML is the legal document, and layout customisations that bypass standard fields can stop the XML being generated correctly.
• Custom modules and multi-company. Bespoke modules that alter invoice numbering or tax computation must be reviewed, and each legal entity in a shared database needs its own TRN, sequence and ASP registration.

A practical order of work

Readiness breaks into six jobs: confirm scope and date; choose and contract an ASP; clean master data; make Odoo produce compliant invoices and credit notes; integrate and test end to end; train the team and set controls. For an Odoo business, confirm the version and edition first, because that decides whether an upgrade is on the critical path. Contract the ASP second. Clean data third, because it takes longest and needs no technical dependency.

Only then install the connector, test in the sandbox, and switch on. Businesses that adopt ahead of their mandatory date are excluded from the penalty regime; the penalty for late implementation is AED 5,000 per month or part month under Cabinet Decision No. 106 of 2025.

For an independent check of where your Odoo setup stands, a UAE e-invoicing readiness review covers version, data, tax configuration and the connector route in one pass. Kaido implements Odoo for UAE businesses and is paid by the client, not by any vendor or ASP.