PINT AE is the structured XML format a UAE e-invoice has to take. It is not a layout — it is a data document in which every party, line, tax and transaction type is a named field drawn from a published list. That is why invoices fail on master data rather than on design.
A document people read, replaced by data a machine checks
The invoice you issue today was designed for a person. It has your logo, a layout someone approved, a total in a bold font, and a PDF wrapper that makes it look the same on every screen. Its job is to be understood by a human being in an accounts payable team.
From go-live, a compliant invoice in the UAE is something else entirely: a structured XML document in the PINT AE format, sent through an Accredited Service Provider who passes it to your customer’s provider and reports it to the Federal Tax Authority at the same time. The Ministry of Finance has said that unstructured formats — PDF, Word documents, images and emails — are not e-invoices. UAE e-invoicing on Odoo sets out what the mandate requires and where Odoo stands today.
That change matters more than it sounds. When nobody reads the invoice, “correct” stops meaning legible and starts meaning complete. A field is either populated from somewhere real or it is not. A value is either on the published list or it is not. There is no column where a human can work out what you meant, and that is the whole reason this is a data project rather than a template project. If you want the yes-or-no question answered first, does Odoo support UAE e-invoicing covers it directly.
What the document actually has to carry
It helps to stop thinking of PINT AE as a file format and start thinking of it as a questionnaire your system has to answer the same way every time. Four groups of answers do most of the work, and each one maps onto a different part of your ERP.
Who the two parties are
Your own company needs its tax registration number and its tax identification number on record. Every VAT-registered customer needs a tax registration number of its own. Addresses need the emirate held as a code rather than as free text, which is the single most common thing an existing system gets wrong, because for years the emirate has been a line someone typed. Legal registration identifiers belong here too. None of this is interesting work and all of it decides whether the document is acceptable.
What was sold, in codes rather than prose
A line that reads “consultancy — October” is fine for a human and insufficient here. Products need item types and classification codes, and units of measure have to map to the standard list rather than to whatever your team has been typing. If your catalogue has grown organically, expect to find the same physical thing sold under three descriptions, two units and one catch-all product code that was created once for a rush order and never cleaned up.
How the tax was treated
Every tax in your system has to map to exactly one category: standard at five per cent, zero-rated, exempt, out of scope, domestic reverse charge or margin scheme — with reasons given where the rules require them. On foreign-currency invoices the tax amount has to be stated in dirhams at the Central Bank rate. The trap here is not that mapping is difficult, it is that mature systems accumulate taxes that are used inconsistently, so the same situation has been invoiced two different ways depending on who raised it.
Which kind of transaction this is
The mandate recognises eight transaction types — free zone, exports, deemed supplies, reverse charge, margin scheme, summary invoicing, continuous supply and agent billing — and each one changes what is mandatory on the document. This is the part companies discover last. A business whose domestic sales are straightforward can still have a quarter of its revenue going through a type that demands extra fields nobody has ever captured.
Why a PDF is not a smaller version of this
People assume a PDF can be converted. In a narrow sense it can: you can extract text from it and guess at fields. But the information the format asks for frequently was never in the PDF to begin with. A classification code, an emirate code, a reason for applying a tax category, a customer’s registration number — if those were not captured when the sale was recorded, no conversion step can invent them. That is the honest reason a “PDF to XML” promise should make you suspicious. It is solving the easy half.
The other half is that a PDF is produced at the end, as a rendering. The structured document has to be produced from the record itself, which means the record has to be right at the moment it is saved rather than at the moment it is printed. For most companies that is the real operational change.
Three different ways an invoice gets rejected
Validation is not one gate. Failures feel different depending on where they happen, and knowing which kind you are looking at saves hours of arguing with the wrong party.
The document is not well formed
Something in the structure is wrong — an element in the wrong place, a value in a shape the format does not accept. This kind of failure is a build problem and it tends to be found once, during implementation, and then never again.
A mandatory field is empty
The document is structurally fine and something required is missing, usually because it was never captured on the customer, the product or the tax. This is the failure you will see most, it is a master data problem, and it comes back on the invoices of whichever customers happen to have the gaps. It does not fix itself over time because new records are created the same way the old ones were.
A value is not on the list
A code exists but is not one of the permitted values — a unit of measure your team invented, an emirate spelled rather than coded, a tax that maps to more than one category. These are the frustrating ones because the data looks perfectly reasonable to a person reading it.
The practical consequence is that you want all three kinds caught inside your own system, before anything is submitted, against the Ministry’s published validation rules. An invoice rejected downstream has already cost you time, and it arrives back as a rule reference rather than as an explanation.
Want to know which fields your Odoo cannot fill?
Send us your Odoo version and how many legal entities issue invoices. We will tell you which parts of the document your data can populate today and which ones need work first.
Book the Two-Day AssessmentWhere the format meets your Odoo
Odoo’s UAE localisation handles VAT, the chart of accounts and invoice layouts that satisfy an auditor reading a document. It contains no notion of PINT AE, of a service provider, or of the classification codes and identifiers the format demands. So something has to sit between your invoice record and your provider: generation of the structured document, local validation before anything leaves, submission, handling of what comes back, and an audit trail per invoice for the retention period, which runs to five years.
The field-by-field view is useful when you are deciding how much work you are in for. Ask of each group above: can my system answer this today, for every record, without a human filling a gap? Where the answer is no, that is your scope. Our Odoo support and maintenance work tends to find the same answer: the generation layer is predictable, the data underneath it is not.
What changes in the way your team works
Three habits usually have to change, and none of them is technical.
First, customer onboarding has to capture the registration number and the emirate code at the point of creation rather than before the first payment. Second, new products have to get a classification code and a mapped unit when they are created, which means somebody owns that decision — in practice the person who owns the catalogue, not the person raising the order. Third, the people who raise unusual invoices need to know which transaction type applies, because the system cannot infer it reliably from the amounts.
This is the part where an AI layer on top of Odoo earns its place, incidentally: not in producing the document, which is deterministic work that software should do silently, but in catching the record that is about to cause a rejection while the person who created it is still looking at the screen.
Where we would tell you not to worry about the format
If you are not in the first wave, the format itself is the wrong thing to study. Your provider or integrator will handle it. The work that pays off now is the unglamorous part: registration numbers on customers, emirates as codes, a tax that maps one way, a catalogue with codes. Do that and the format becomes somebody else’s problem.
And if your business is small, issues few invoices and sells one simple thing domestically, there is a reasonable case for using your provider’s own interface by hand rather than paying for an integration at all. We would rather say that than sell you a connection you will use four times a month. Choosing an accredited service provider covers how that decision interacts with provider selection.
Being straight about our own position
We are not an Accredited Service Provider and we do not intend to become one. We build the integration side, on Odoo, for the provider a company chooses — so we have an obvious interest in integration work existing. Weigh what we say accordingly and get a second view.
What we will not do is quote before asking which legal entities invoice, which transaction types you use, what has been customised and which channels issue invoices. A supplier who prices this from a conversation about invoice volume alone is guessing, and the guess will be wrong in whichever direction suits them.
Nothing here is tax or legal advice. The format’s detail belongs to the Ministry of Finance’s published decisions and guidelines and to the OpenPeppol PINT AE specification; your scope, thresholds and filing obligations belong to your own tax adviser.
Where to start
Take ten recent invoices — deliberately including the awkward ones, a credit note, an export, anything free-zone — and try to answer the four groups of questions above from your own records alone. The ones you cannot answer are your project. That exercise takes an afternoon and it is worth more than any amount of reading about the format, including this page. If you want the sequencing, the 30 October deadline post sets out what order to do things in.