Lesson 4 — PINT AE, and where the specification actually lives
A format question with a practical answer: what exactly does the provider expect from you?
PINT AE is the UAE country specialisation of Peppol, built on UBL 2.1 and using the Invoice and CreditNote namespaces. Specialisation is the operative word. This is not a UAE-only invented format; it is the international Peppol invoice with UAE rules layered onto it, which is why a system that already speaks UBL can be extended to speak PINT AE rather than rebuilt.
The published set, stated as at a date because it moves.
| Specification | Version as at 3 June 2026 |
|---|---|
| PINT AE Billing | 1.0.4 |
| PINT AE Self-Billing | 1.0.4 |
| UAE Tax Data Document | 1.0.3 |
An upcoming branch dated 29 July 2026 raises the UAE Tax Data Document to 1.0.4, and no effective date has been published for it. Treat the versions above as correct on the date given, and check the source before assuming they still are.
Where the specification actually lives is the part most people get wrong. The MoF Electronic Invoicing Guidelines V1.1, dated 1 June 2026, state that the UAE requirements are defined in the Data Dictionary accessible through the Peppol PINT AE specifications, published at docs.peppol.eu/poac/ae/. There is no separate Data Dictionary file to download from the Ministry of Finance. If you have been hunting for one, that is why you have not found it.
A second document sits alongside it. The Electronic Invoice Mandatory Field Requirements V1.0, dated 23 February 2026, is the readable summary of what a UAE e-invoice must carry, grouped into six areas.
| Field group | What it covers |
|---|---|
| Invoice Details | The document's own identity — number, dates, type, currency |
| Seller Details | Who is supplying, and the identifiers that prove it |
| Buyer Details | Who is being invoiced, and their identifiers |
| Document Totals | The header amounts the document must balance to |
| Tax Breakdown | Tax by category and rate at document level |
| Invoice Line | Everything required on each individual line |
This is where an e-invoicing project actually spends its time. Nothing in that list is exotic. Almost all of it is data your system already holds somewhere, in some form, for some customers. The work is making it complete and consistent for every customer, because an access point rejects documents rather than filling gaps in them. A customer address left blank for four years has cost you nothing so far; from your go-live date it costs you a rejection.
That is not theoretical. Odoone checks the mandatory fields before a document is sent, and the checks covering addresses, countries and line descriptions ship as editable rules you can read. If a business turns the module on and suddenly sees a missing-address error on invoices that have gone out happily for years, the feature is working correctly: the address is mandatory under the specification, and the access point would have rejected the document anyway. Far better to meet that error in your own system in September than as a rejection in January.
The failure here is a quiet one. Hard-coding a version, or briefing a developer from a PDF someone downloaded months ago, produces software that validates against a specification which has since moved. Cite the source rather than a copy of it, and set a calendar reminder to re-check the published versions before you go live.
The idea to carry forward: PINT AE is UBL 2.1 with UAE rules, those rules live at Peppol rather than in a Ministry download, and every version number is true only as at a date.