KMEE / UAE e-invoicing for Odoo
From 2027, every B2B and B2G invoice in the UAE travels as a structured e-invoice through an accredited service provider, and its tax data reaches the FTA. KMEE is building the Odoo localization that does this from inside your ERP: Community or Enterprise, with the provider you choose, in code you can read.
Odoo specialists since 2012 · maintainers of Brazil's e-invoicing for Odoo · authors of Paraguay's
Revenue is counted per legal entity, not per group. Voluntary adoption is open since 1 July 2026. B2C is excluded for now.
Odoo specialists
implementations completed
continents served
e-invoicing localizations in the Odoo community: Brazil and Paraguay
01 / The problem
Under the new model, an invoice is a structured document that passes through two providers and the tax authority. Your ERP has to follow it the whole way.
Each taxable person appoints an accredited service provider (ASP). A group with several entities ends up with several onboardings, credentials and routings, and one Odoo that has to keep them apart.
Delivery to the buyer and reporting to the Federal Tax Authority are two separate outcomes. A successful upload to the provider is not a tax confirmation, and a timeout does not mean the invoice failed.
Tax identifiers, Peppol endpoints, transaction flags, Free Zone details, AED amounts on foreign-currency invoices. The invoice now has to carry them, line by line.
Partial and full credits need official reasons and references. Self-billing needs an agreement and both parties registered for VAT. A generic export does not cover them.
If your system fails, the FTA must be notified within two business days, and penalties run per month and per invoice. Someone has to know, in time, that something is stuck.
02 / Our approach
Brazil has run mandatory e-invoicing for years, and KMEE has maintained its Odoo localization since 2012. We also wrote the Paraguayan one, with electronic invoicing through the national tax system. Both live in Odoo's open source community.
We are building the UAE localization the same way. Odoo's standard accounting stays untouched, the e-invoice is generated from the invoice you already post, and the ASP is a component you can replace. The code is public and auditable.
We work from the primary sources: the Ministerial Decisions, the e-invoicing guidelines and the PINT AE rules published on the Peppol network. Where those sources disagree, we document the case with your tax advisor and your ASP instead of picking one silently.
What we are building, for Odoo 20.0
Entity setup
TIN, TRN, Peppol endpoint and the ASP of each legal entity, kept apart in a multi-company Odoo.
PINT AE documents
Tax invoices, commercial invoices and credit notes generated from the standard Odoo invoice. Self-billing and advance payments follow once each flow is validated.
Delivery and reporting, tracked apart
Each invoice shows received by the ASP, delivered, reported or rejected. Retries never create a second tax document.
Incoming invoices
Supplier invoices and credit notes arrive as draft bills for review, without duplicates.
Audit trail
Original XML, submissions and confirmations stored with the invoice, recoverable for the retention period.
The difference
Closed e-invoicing connector
KMEE localization
Closed e-invoicing connector
Closed connector, priced per document
KMEE localization
Open source code inside your Odoo, no fee per invoice
Closed e-invoicing connector
Locked to the provider the connector was built for
KMEE localization
Works with the accredited ASP each entity chooses
Closed e-invoicing connector
Tied to one Odoo edition
KMEE localization
Built for Odoo 20.0, Community and Enterprise
Closed e-invoicing connector
A rule change waits for the vendor roadmap
KMEE localization
Public code, adapted in the open source community
Closed e-invoicing connector
If the vendor leaves, you start over
KMEE localization
Any partner in the ecosystem can take over
03 / How it works
The UAE uses a five-corner model on the Peppol network. Your Odoo is the first corner; the localization makes sure it knows what happened in the other four.
Posting stays the standard Odoo flow. Missing data is flagged on the invoice before anything is sent.
The localization hands the PINT AE document to the provider you contracted, asynchronously.
The buyer's ASP delivers it over the Peppol network. Buyers outside the network get the alternative delivery the rules require.
Reporting to the authority is a separate step, done by the ASPs.
Received, delivered, reported or rejected, each with its evidence, on the invoice itself.
KMEE is not an ASP and does not replace your tax advisor. We build and run the part that lives in your Odoo.
04 / How we work
We map your entities, the dates that apply to each one, the flows your invoices go through (Free Zone, exports, credit notes, self-billing) and your Odoo version. You leave with it in writing.
Master data, entity setup and the integration with the provider each entity chose, tested in the provider sandbox before any real submission.
E-invoices issued from Odoo, statuses monitored, incidents with an owner and a clock. Your tax advisor stays in charge of the tax decisions.
05 / For Odoo partners
If you implement Odoo in the UAE, every client of yours will ask about e-invoicing. KMEE can be the engineering team behind your answer.
We supply the localization and the integration engineering. The relationship, the implementation and the support contract stay with you.
The same open source modules in every project, instead of one connector per client and per provider.
The code is public. Your client is never locked to KMEE, and neither are you.
Note
The UAE electronic invoicing system covers B2B and B2G transactions. Invoices and credit notes are exchanged in the PINT AE format through accredited service providers, and the tax data is reported to the Federal Tax Authority. Businesses with revenue of AED 50 million or more appoint an ASP by 30 October 2026 and go live on 1 January 2027; the others follow in 2027.
Penalties start at AED 5,000 per month for not implementing the system or not appointing an ASP, and AED 100 for each invoice not issued electronically, up to AED 5,000 a month. A system failure must be notified within two business days.
Classifying each entity is the job of your tax advisor. KMEE takes care of the system that issues, tracks and keeps the invoices.
Sources: Ministry of Finance: UAE e-invoicing | Ministerial Decision 244/2025 (phases) | Ministerial Resolution 66/2026 (new dates for phase 1) | Cabinet Decision 106/2025 (penalties) | Accredited service providers
Clients
06 / Questions
No. Each entity contracts an ASP from the Ministry of Finance list, and KMEE connects Odoo to it. We can help you compare providers on what matters for an Odoo integration: formats accepted, status events, sandbox and exit terms.
It depends on the revenue of each legal entity, not of the group. Entities with revenue of AED 50 million or more must appoint an ASP by 30 October 2026 and issue e-invoices from 1 January 2027. Below that, the dates are 31 March 2027 and 1 July 2027. Your tax advisor confirms the classification of each entity.
It is in development for Odoo 20.0, and we are building it with a multinational group that operates five UAE entities. Companies and partners who join now help shape the scope. Nothing is switched on for real submissions before it is tested with your ASP.
Odoo 20.0, Community and Enterprise. If you run an older version, the upgrade is a separate project, which we also do. The assessment shows the path and the cost.
Odoo S.A. is working on UAE e-invoicing in its own public code, and that code is our starting point, not a competitor. We reuse it and add what operations with several entities need: one ASP per entity, retries without duplicates, separate delivery and reporting statuses, self-billing, an audit trail, and support for the Community edition.
Free Zone and designated zone transactions carry specific data in PINT AE. Your tax advisor classifies each entity and transaction; the localization stores and checks the data that classification requires.
Not for now. B2C transactions are excluded from the mandate until a future decision. B2B and B2G are in scope.
The interface and help are in English. Arabic translations are on the roadmap, according to what each project needs.
The Odoo Community Association is the international nonprofit that maintains thousands of open source modules for Odoo, including tax localizations for dozens of countries. KMEE has contributed since 2012: it maintains the Brazilian localization and wrote the Paraguayan one. Code in the OCA is public, reviewed by several companies and not owned by any single vendor.
No. The code is open source, in your repository, guaranteed by contract. Because the localization is built in the open source community, you can change partners without rebuilding the system, including leaving KMEE.
For your technical team: the localization is open source and built to be proposed to the OCA, the international association that maintains Odoo's community localizations. We are happy to walk through the specification in the first call.
Assessment
Book the free assessment.
In 30 minutes you leave with the picture in writing: which dates apply to each entity, which flows your invoices go through and what your Odoo needs before the first e-invoice.
KMEE · Odoo specialists since 2012 · +50 implementations · 5 continents
Chat on WhatsApp
Quick reply from a KMEE specialist