PINT AE explained

Ask ten UAE finance teams what an electronic invoice is and most will describe a PDF. Under the Electronic Invoicing System, an electronic invoice is an invoice issued, transmitted and received in a structured electronic format that enables automatic and electronic processing. That definition comes from Article 1 of Cabinet Decision No. 106 of 2025, and every word in it is doing work.

The structured format the UAE has chosen is PINT AE. This guide explains what that means concretely, at the level of the actual document.

Where PINT AE sits

Peppol is an international network for exchanging business documents. It has an invoicing specification, and that specification has country-specific variants, because tax law is local even when networks are not. PINT is the Peppol International invoice model. PINT AE is the United Arab Emirates alignment of it.

Underneath, the document is UBL 2.1. Universal Business Language, an OASIS standard that predates all of this by more than a decade. An invoice is an XML document rooted at <Invoice>, a credit note at <CreditNote>, and the elements come from two namespaces you will get used to reading: cbc for common basic components, the leaf values, and cac for common aggregate components, the structures that hold them.

A PINT AE invoice announces itself in its first two lines:

<cbc:CustomizationID>urn:peppol:pint:billing-1@ae-1</cbc:CustomizationID>
<cbc:ProfileID>urn:peppol:bis:billing</cbc:ProfileID>

The customization identifier is what tells a receiving system to apply UAE rules rather than Singaporean or Malaysian ones. Everything downstream, every validation, hangs off that string.

Business terms, and the two prefixes

The specification does not talk about XML elements. It talks about business terms, and it gives each one an identifier that appears in error messages, mapping documents and vendor conversations.

Terms prefixed IBT come from the international PINT model, itself descended from the European EN 16931 semantic model. IBT-024 is the specification identifier. IBT-031 is the seller's VAT identifier. IBT-046 is the buyer identifier. If you have worked with European e-invoicing, you already know these under their BT numbers.

Terms prefixed BTAE are UAE additions. BTAE-07, for instance, is the invoice UUID.

Validation rules follow the same convention. Rules prefixed IBR are business rules. Rules prefixed ibr-cl are code list rules, and they are the ones that fail most often, because they check a value against an enumerated list rather than against arithmetic. A country code that is not in ISO 3166-1 fails ibr-cl-14. A payment means code outside UNCL4461 fails ibr-cl-16. An allowance reason outside UNCL 5189 fails ibr-cl-19.

These rules are Schematron assertions with a fatal flag. There is no partial credit. An invoice either passes or it does not exist.

What the document contains

This section is an orientation, not a reference. The field-by-field detail lives in the PINT AE fields glossary, which carries every business term, its obligation level, and its IBT or BTAE identifier.

A minimal, mandatory-fields-only PINT AE tax invoice is smaller than most people expect. It carries the customization and profile identifiers, an invoice number, a UUID, an issue date, a due date, an invoice type code, and a document currency code. Then a supplier party, a customer party, tax totals, monetary totals, and at least one invoice line.

Some specifics that matter in practice:

The invoice type code distinguishes documents. 380 for an invoice, 381 for a credit note. There are six categories of electronic invoice in the UAE: electronic tax invoice, self-billed electronic tax invoice, electronic tax credit note, self-billed electronic tax credit note, commercial invoice, and electronic credit note. Which one you issue is determined by the transaction, not by preference.

The endpoint identifier is how the network finds your counterparty:

<cbc:EndpointID schemeID="0235">1357902468</cbc:EndpointID>

The scheme attribute identifies the identifier scheme; the value is the UAE tax identification number. Your TIN is your Peppol participant identifier. If you are registered with the Federal Tax Authority (FTA) for any tax type, it is the first ten digits of your TRN. If you belong to a tax group, it is derived from your own TRN, not the group representative's. If you are in scope and not registered for any tax, you register to obtain a TIN.

The TRN, in contrast, appears as a party tax scheme company identifier and is the fifteen digit number. It is required on electronic tax invoices and electronic tax credit notes. It is not mandatory on commercial invoices, nor on out of scope and exempt transactions.

Country subdivision is a real field with real consequences. <cbc:CountrySubentity>DXB</cbc:CountrySubentity> inside the postal address. Businesses that have never had to code the emirate on an invoice suddenly do.

The UUID is generated by your ASP, not by you. The Ministry's responsibility table assigns UUID generation to the Accredited Service Provider, to guarantee uniqueness and prevent duplication. This surprises engineers who assume they own document identity. You own the invoice number. The network owns the UUID.

The rules that are specific to the UAE

Some of these are in the specification. Some are in the Ministry's guidance, and they are the ones that catch people.

Rounding happens at the invoice total, to two decimal places. Not at line level. Not at tax category level. If your accounting system rounds per line and then sums, your totals will disagree with the schema's arithmetic and you will fail a business rule. The rounding amount field itself is optional, and its value is yours to supply.

Items are goods, services, or both. An Item type field takes G, S, or B. Most legacy systems do not carry this distinction and will need it derived.

You may not add your own optional fields. This is stated flatly. Persons and government entities are not allowed to add additional optional fields of their own into PINT AE. If you need an industry-specific field or classification, the instruction is to discuss it with your ASP and find out how it can be accommodated. In a schema this rigid, "discuss it with your ASP" is doing a lot of lifting, and it is a reasonable thing to raise during provider selection rather than after.

There is no line count limit. The UAE imposes no constraint on the number of lines in an electronic invoice.

Credit notes can reference multiple preceding invoices. A single electronic tax credit note can carry references to several past electronic tax invoices, in the preceding invoice reference structure. A credit note can also cover only part of the original invoice amount.

Advance payments and prepayments are handled through the Paid Amount field, with the original invoice carried in the preceding invoice reference so the adjustment can be traced.

Surcharges go in document level charges. The Dubai Municipality surcharge on construction projects and tourism levies are the examples the Ministry gives. Import VAT paid by an agent on behalf of another party goes in the same place, under Article 50 of the VAT Executive Regulation.

Date of supply, when it differs from the issue date, goes in the VAT point date field. This is not optional bookkeeping detail. It determines the tax period.

Authority name is free text. The trade licence issuing authority is populated manually by the issuer, and there is no code list. Expect inconsistency across the network for years.

HSN codes are optional today. The Ministry has said the timeline for making them mandatory will be announced in due course. Build for their arrival.

Beneficiary details may mirror the customer where the ultimate beneficiary and the customer are the same. This keeps the document technically complete without implying a third party exists. For individual consumers, use the individual's name and available identification, or note that no registered identifier exists.

Provisional invoices do not exist as a category. Every provisional invoice you issue is an electronic invoice. Adjust it afterwards with an electronic credit note or an additional electronic invoice.

Worked examples of each document type, as schema-valid XML, are available in the PINT AE sample documents.

PINT AE XML versus a JSON payload

A distinction worth being precise about, because it is where the liability boundary in most integrations sits.

Your accounting system emits data. Your ASP transmits PINT AE XML. Between those two facts, someone performs a conversion. The framework anticipates this: the supplier submits invoice data to their ASP in a format agreed between them, and the ASP validates that data and converts it into the UAE standard XML if it arrived in a different format.

So you can hand your ASP JSON. Many will accept it. What you cannot do is assume that handing over JSON transfers the correctness problem along with it. The Ministry's responsibility table is unambiguous: calculating all electronic invoice values is the supplier's responsibility, and exchange and reporting remain the supplier's compliance obligation even though the ASP performs the activity.

If your JSON says the tax total is AED 500 and it should be AED 525, no amount of accredited XML generation will fix it. Validation catches structure. It does not catch a wrong number that is internally consistent.

This is worth writing into a contract. Who is liable when a conversion produces a schema-valid document with the wrong semantics? The answer is almost always you, and the interesting question is what your provider is willing to do about it.

Both directions, and both languages

The framework is not a filing mechanism. It is an exchange.

Your ASP transmits your invoice to the buyer's ASP and, in parallel, reports tax data to the FTA. The buyer's ASP validates, confirms electronically back to your ASP, delivers the invoice to the buyer in whatever format those two have agreed, and independently reports tax data to the FTA. Confirmations propagate back down the chain. When validation fails at the receiving ASP, it confirms the failure to your ASP and to the FTA, and no tax data is reported for that document.

Which means you must be able to receive as well as send. Every supplier of yours who is in scope will be pushing structured XML at you from their go-live date. Accounts payable is an e-invoicing project too, and it is usually the one nobody staffed.

The framework supports Arabic and English, which the Ministry notes ensures compliance with any Arabic reporting requirements mandated in the UAE.

What to do with this

If you are scoping an integration, the useful exercise is not reading the specification front to back. It is taking the three most awkward invoices your business issued last month, and asking whether every field PINT AE demands exists somewhere in your system, in a form that will pass a code list check.

Usually two or three do not. That is the project.

---

Sources

• Peppol PINT AE billing specifications, as published by Peppol and referenced by the Ministry of Finance
• OASIS Universal Business Language (UBL) 2.1
• PINT AE Schematron validation artefacts, UBL model and code list phases
• Cabinet Decision No. 106 of 2025, Article 1, definitions of Electronic Invoice and Electronic Credit Note
• UAE Electronic Invoicing Guidelines V1.0, Ministry of Finance, 23 February 2026, sections 5.1, 5.2, 6.2, 10.1, 10.2, 12.2 and the constraints and considerations list
• Ministerial Decision No. 243 of 2025

Technical detail verified against the published PINT AE sample documents and validation artefacts, and against the Ministry of Finance guidelines, on 9 July 2026. The specification is versioned. Check the customization identifier against the current release before building.

Related

• The penalty-free window
• The 2026 to 2027 e-invoicing timeline
• How to appoint an Accredited Service Provider
• UAE e-invoicing penalties, explained properly

Tools

• PINT AE fields glossary — the full field reference
• Peppol participant lookup