PINT-AE explained: how the UAE customised Peppol for the FTA
Generic Peppol invoices fail UAE validation. Here's why — and the four UAE-specific things every PINT-AE implementation must handle.
If you have read anything about UAE e-invoicing in the last six months, you have probably seen the term PINT-AE dropped without much explanation. Vendors use it. The FTA uses it. Consultants charge for it. But what is it actually?
The short answer: PINT-AE is the UAE's customised version of the global Peppol BIS Billing 3.0 specification. It uses the same UBL 2.1 XML envelope, the same five-corner exchange model, and the same overall flow. But it adds UAE-specific fields, code lists, and validation rules that a generic Peppol invoice does not satisfy.
This article walks through the four areas where PINT-AE diverges from generic Peppol, and what your engineering team needs to handle before the first invoice flows to production.
1. The customisation declaration
Every PINT-AE invoice starts with a single line that tells the network this is a UAE invoice, not a Norwegian or Singaporean one:
<cbc:CustomizationID>
urn:peppol:pint:[email protected]
</cbc:CustomizationID>This CustomizationID is the trigger. Every accredited service provider (ASP) routes based on it. Every validator checks against it. Use the wrong value and the invoice bounces immediately — before any of your tax codes or line items are even read.
The version suffix matters too. As the FTA publishes updates to the PINT-AE specification, this string changes. Your middleware needs a clean way to update it without redeploying core logic.
2. TRN format and validation
Every party on an invoice — supplier, customer, sometimes a payee — needs a UAE Tax Registration Number (TRN) in a very specific shape. Generic Peppol allows free-form party identifiers. PINT-AE does not.
The TRN appears in cbc:CompanyID nested inside the party identification block:
<cac:PartyTaxScheme>
<cbc:CompanyID>100123456789012</cbc:CompanyID>
<cac:TaxScheme>
<cbc:ID>VAT</cbc:ID>
</cac:TaxScheme>
</cac:PartyTaxScheme>The TRN is fifteen digits, all numeric, starting with 100. The FTA validator will reject anything else — including older formats, formats with spaces, formats with the "VAT-" prefix some ERPs put in by default, and formats that include the legal entity number. If your accounting system stores TRNs in any non-standard shape, you need a normalisation step before generating the XML.
3. UAE-specific tax category codes
This is where most ERP integrations break. Generic Peppol uses the UN/EDIFACT 5305 tax category code list — codes like S (standard rate), Z (zero rate), E (exempt). The FTA adopts the same baseline codes but adds and reinterprets several to fit UAE VAT law.
The mappings that consistently trip up implementations are zero-rated exports, designated zone supplies, reverse charge mechanism, and out-of-scope. Each has a specific category code and often requires an accompanying cbc:TaxExemptionReasonCode with a value from the FTA's published list. Get this wrong and the invoice will validate as XML but fail tax-logic checks downstream — the worst kind of bug, because it slips through your test suite.
4. Emirate code at line level
This is the field nobody expects. PINT-AE requires the Emirate of supply at the invoice line level — not just at the party level. The valid codes are three-letter abbreviations: DXB (Dubai), AUH (Abu Dhabi), SHJ (Sharjah), AJM (Ajman), UAQ (Umm Al Quwain), RAK (Ras Al Khaimah), FUJ (Fujairah).
<cac:InvoiceLine>
<cbc:ID>1</cbc:ID>
<cbc:InvoicedQuantity unitCode="EA">5</cbc:InvoicedQuantity>
<cac:Item>
<cbc:Name>Consulting service</cbc:Name>
<cac:ClassifiedTaxCategory>
<cbc:ID>S</cbc:ID>
<cbc:Percent>5</cbc:Percent>
</cac:ClassifiedTaxCategory>
<cbc:EmirateOfSupply>DXB</cbc:EmirateOfSupply>
</cac:Item>
</cac:InvoiceLine>For most service businesses this is a single value that applies to every line on the invoice. For trading businesses with goods shipped from multiple warehouses, it can vary line by line — and that requires a meaningful change to how your ERP captures shipment data.
What this means for your ERP
If you are running Odoo Community, the PINT-AE community modules will get you started but will not handle all four of the above correctly out of the box. If you are running SAP Business One or Dynamics 365 Business Central, the publisher-supplied UAE localisation packs are improving but still need configuration for tax category mapping and emirate capture. If you have built custom invoicing software in the last five years, you almost certainly need to retrofit a PINT-AE export layer.
The good news: this is bounded, well-specified work. A clean PINT-AE integration on a single ERP takes 6 to 10 weeks end-to-end. The bad news: the FTA does not grant grace periods for failed validation. Every rejected invoice is a customer payment delayed and a compliance penalty accruing at up to AED 5,000 per month.
If you want to start a PINT-AE integration with senior engineers who have shipped this work on the systems you are running, our UAE e-invoicing service page walks through how matching works.