PINT AE Explained: The UAE's Peppol Invoice Format

Every UAE e-invoice, whatever ERP produced it and whichever provider carries it, ends up as the same thing: an XML document that conforms to PINT AE. If that document fails validation, nothing else in your e-invoicing project matters. The invoice is rejected, it is not reported, and the clock on your issue deadline keeps running.

This article is for tax managers, ERP owners and CTOs who need to understand the format itself: how the data model is built, what the mandatory fields cover, how parties are identified, how the UAE-specific flags work, how credit notes behave, which validation errors appear most often and how PINT AE differs from the European Peppol BIS Billing 3.0. Specification details are as of October 2026.

What Is PINT AE?

PINT AE is the UAE's specialisation of Peppol International (PINT), the global invoice data model maintained by OpenPeppol. It defines exactly which data a UAE e-invoice or e-credit note contains, how that data is expressed in XML and which business rules it must pass.

The specification lives on docs.peppol.eu as two documents: PINT AE Billing, for normal invoices and credit notes, and PINT AE Self-Billing, which uses the same data model with extra rules for buyer-issued invoices. Version 1.0.3 was released on 26 March 2026, and later code-list releases carry version 1.0.4. Each release contains a semantic model, syntax bindings, code lists, business rules and Schematron files, which are the machine-readable checks every provider runs.

The UAE Ministry of Finance (MoF), as the national Peppol Authority, decides the policy content; OpenPeppol publishes the technical artefacts. If you are new to the network itself, start with what Peppol is.

How Is a PINT AE Invoice Structured in UBL 2.1?

A PINT AE invoice is a UBL 2.1 Invoice document (or Credit Note document), the OASIS XML standard that Peppol uses worldwide. The UAE layer sits on top through identifiers, extra elements and stricter rules.

Three header elements tell every system which rules to apply:

• cbc:CustomizationID (business term IBT-024): must start with urn:peppol:pint:billing-1@ae-1 or, for self-billing, urn:peppol:pint:selfbilling-1@ae-1. Rule aligned-ibrp-001-ae makes this a fatal check.
• cbc:InvoiceTypeCode (IBT-003): distinguishes tax invoices, commercial invoices, credit notes and self-billed documents.
• cbc:ProfileExecutionID (BTAE-02): carries the UAE invoice transaction type code, explained below.

Below the header sit the usual UBL blocks: supplier and customer parties, delivery, payment terms, allowances and charges, tax totals, monetary totals and invoice lines. Elements specific to the UAE carry business-term IDs beginning with BTAE, while shared PINT terms use IBT and IBG.

What Are the Mandatory Fields in a UAE E-Invoice?

MoF technical guidance published on 23 February 2026 lists 51 mandatory fields for a tax invoice. Commercial (non-tax) invoices follow an adapted list with the same structure, according to KPMG's summary.

The fields are only the floor. PINT AE also has conditional rules that make optional fields mandatory in certain scenarios, and the Schematron enforces those as strictly as the core list.

How Do Participant Identifiers Work in PINT AE?

Every UAE business is addressed on Peppol by the scheme code 0235 followed by its 10-digit Tax Identification Number (TIN). The TIN is the first ten digits of the 15-digit VAT Tax Registration Number (TRN).

The identifier appears as the seller's and buyer's electronic address (cbc:EndpointID with schemeID="0235"). Your Accredited Service Provider (ASP) registers it in its Service Metadata Publisher (SMP) so that senders can find you. Three practical points:

• Never use the full TRN as the endpoint. If a customer gives you a 15-digit TRN, take the first ten digits.
• VAT group members each need their own TIN-based ID; the group representative's TIN cannot be used for everyone, as Alvarez & Marsal's summary of the June 2026 guidelines notes.
• Special placeholder addresses exist for invoices that are reported to the Federal Tax Authority (FTA) but not delivered to a UAE buyer's ASP. Vertex's PINT AE notes give 9900000099 for exports and 9900000098 for deemed supplies and buyers not subject to UAE e-invoicing.

Buyer identification has its own rules. IBR-135-AE requires either a buyer identifier or a buyer VAT identifier unless the invoice is flagged as an export. IBR-149-AE requires the buyer's legal registration identifier whenever the buyer's address uses scheme 0235 and is not a placeholder starting with 1 or 9.

What Is the Invoice Transaction Type Code?

The invoice transaction type code (BTAE-02) is an eight-character string of 0s and 1s in cbc:ProfileExecutionID. Each position flags one special type of transaction, and more than one can be set at once. A plain domestic B2B supply is 00000000.

Positions 1, 2, 3, 4 and 8 are named in OpenPeppol's code list and rules; positions 5, 6 and 7 are confirmed in Vertex's PINT AE implementation notes. This field matters because most ERPs have no native concept of "deemed supply" or "disclosed agent billing" on an invoice. Someone has to decide, per transaction type, how the flag is derived, and that decision is a tax judgement, not an IT setting.

How Do Credit Notes and Corrections Work?

Once an invoice has been exchanged and reported, it cannot be edited or cancelled. Corrections downwards are made with an electronic credit note that references the original invoice; corrections upwards are made with an additional invoice.

Document types are set by the invoice type code. According to Sovos's UAE samples, the codes in use are:

• 380 tax invoice and 381 tax credit note
• 480 commercial (out-of-scope) invoice and 81 commercial credit note
• 389 self-billed invoice and 261 self-billed credit note

Some flag combinations are blocked on credit notes and out-of-scope documents. IBR-157-AE forbids the summary invoice, deemed supply and margin scheme flags when the type code is out of scope of VAT or a credit note related to goods or services. The June 2026 guidelines also cover two common edge cases. An advance payment triggers an e-invoice when the payment is received, and the final invoice then refers back to it through the preceding invoice reference. For construction retentions, the e-invoice shows only the net amount actually payable.

What Are the Most Common PINT AE Validation Errors?

Most rejections come from data, not from XML syntax: wrong identifiers, missing conditional fields, inconsistent flags and arithmetic that doesn't add up. The list below combines published PINT AE rules with general UBL validation behaviour.

1. Wrong specification identifier: a European BIS 3.0 CustomizationID, or a typo, fails aligned-ibrp-001-ae immediately.
2. Full TRN used as the endpoint: the address must be the 10-digit TIN with scheme 0235, so lookup fails or the identifier rules fire.
3. Missing buyer identifiers: no buyer identifier or VAT identifier on a non-export invoice (IBR-135-AE), or no legal registration identifier for a UAE buyer (IBR-149-AE).
4. Illegal flag combinations: for example, a credit note carrying the margin scheme flag (IBR-157-AE).
5. Totals that don't reconcile: line amounts must sum to the invoice total before VAT, and VAT per category must equal taxable amount times rate after rounding. ERPs that round at a different level fail here.
6. Unmapped codes: internal tax codes, units of measure or currencies not converted to the standard code lists.
7. Placeholder misuse: sending an export invoice with a real buyer address, or a domestic invoice with a placeholder.

A rejection is reported back through the Peppol Message Level Status. The five-corner model article explains where in the flow each check happens, and the ERP integration guide shows where to fix these issues in common systems.

How Does PINT AE Differ from Peppol BIS Billing 3.0?

PINT AE and BIS Billing 3.0 share the Peppol network, UBL 2.1 syntax and much of their vocabulary, but they are separate specifications. An invoice that passes BIS 3.0 validation will fail PINT AE. The differences that matter in projects are below.

For multinationals this matters in practice. A group that already sends BIS 3.0 invoices from Europe cannot point its UAE entity at the same output template. It needs a UAE-specific mapping, ideally driven by the same master data.

How VEATEX Helps

VEATEX is a Shopify, web and software development agency that also builds Peppol e-invoicing platforms for the GCC, working with clients in the US, UK and the Gulf for over 11 years. We built a Peppol platform for a client that passed OpenPeppol testing and is now on the UAE pre-approved ASP list, so we work with PINT AE validation rules daily. We map ERP data to PINT AE, derive transaction type flags from your existing attributes and build test packs that cover every scenario you invoice. See our e-invoicing services or our custom software work.