PINT AE: the UAE e-invoice format

What is PINT AE, in plain words?

PINT stands for Peppol International: a family of technical specifications that describes the format of business documents such as e-invoices and e-credit notes, and lets each country add its own requirements while staying interoperable with the rest of the Peppol network. AE is the UAE's version. The UAE's requirements are defined in its Data Dictionary (Guidelines V2.0, §3; MD 168/2026, Art. 1).

In practice PINT AE answers three questions for each e-invoice: which fields must be present, which values they may take, and which business rules they must pass. The law requires an e-invoice to contain all the data fields the Ministry prescribes (MD 243/2025, Art. 7), and OpenPeppol publishes the specification itself, with its rules and XML examples (Guidelines §10 and §12).

To be accredited, a provider's software must meet all the requirements of PINT AE and related or equivalent specifications as published by OpenPeppol, in line with the Data Dictionary (MD 168/2026, Art. 4(1)(d) and Art. 6(4)). Your ASP validates the invoice data it receives (Guidelines §5.1), so a file that breaks a rule is rejected, whoever built it.

Sources: ^[2][3][4][5]

Why is a PDF not an e-invoice?

Because the law defines an e-invoice by its format, not by the way it is sent. An e-invoice is issued, transmitted and received in a structured electronic format that enables automatic processing (MD 243/2025, Art. 1). UAE e-invoices are XML files, and they carry no QR code or barcode (Guidelines V2.0, §5.3). A PDF is a picture of an invoice for a person to read; a system cannot process it field by field.

So once e-invoicing applies to you, an emailed PDF no longer counts as the invoice on its own. A tax invoice has to be issued in the form of an e-invoice (Guidelines §6.2, on Article 65(5) of the VAT Decree-Law), and traditional commercial invoices in PDF or on paper must be replaced by e-invoices exchanged and reported through the five-corner model (§10.2.1).

A PDF does not disappear entirely. When your buyer has not implemented e-invoicing yet, a regular tax invoice, a PDF for example, is still required in addition to the electronic one; if that buyer also has no Participant Identifier, the e-invoice must carry the predefined endpoint 0235:9900000098 (§10.2.2). The reason is given in §6.2: because e-invoices are XML, a buyer that has not implemented e-invoicing may need a separate invoice, to support its input tax recovery for example.

Sources: ^[2][3]

What does a PINT AE invoice contain?

The table above groups the 51 mandatory fields of an electronic tax invoice from the Ministry's Mandatory Fields V1.1 (§4.1). Most of them are on your tax invoice today. What is new are the identifiers and codes that let a system process the invoice without a person:

• Electronic addresses. The seller is identified as 0235 followed by its 10-digit TIN (fields 11 and 12), and the buyer by its Participant Identifier in the same form, or by a predefined endpoint where the specification calls for one (fields 22 and 23; Guidelines App. 6, §18.3.3). The TIN is the first 10 digits of the business's own TRN, also inside a tax group; the Mandatory Fields V1.1 refer to the Corporate Tax TRN (§2).
• The invoice transaction type code. Eight flags, each 1 or 0, for free zone, deemed supply, margin scheme, summary invoice, continuous supply, disclosed agent billing, supply through e-commerce and exports (field 5). One invoice can carry several scenarios at once (Guidelines §10.4).
• The specification identifier and business process type. Fixed values that tell the receiving system which rules the file follows (fields 7 and 8).
• A tax category on every line and in the breakdown. Standard rate, exempt, outside the scope of VAT, reverse charge, zero rated or margin scheme (Guidelines §10.5).
• Amounts in AED. Each line's VAT amount and amount payable are given in AED even when the invoice is in another currency, and an invoice in another currency also states its total with VAT in AED (Guidelines §12.2, items 16 and 17).

Sources: ^[1][2]

What can and cannot go into the file?

There is no maximum number of lines in a UAE e-invoice (Guidelines §12.2, item 2), and goods and services on the same invoice are told apart by the item type: G for goods, S for services, B for both (item 6). Surcharges such as a municipality fee go under document-level charges (item 7).

You may not add optional fields of your own to PINT AE. If your sector needs extra fields or classifications, discuss with your ASP how they can be accommodated (items 24 and 25).

Sources: ^[2]

How does a tax invoice differ from a commercial e-invoice?

The Guidelines list six categories of e-invoice: the electronic tax invoice and tax credit note, their self-billed versions, the commercial invoice and the electronic credit note (§10.1). A commercial invoice is an invoice that is not a tax invoice (§3), issued for sales that need no tax invoice, such as sales that are exempt or out of scope for VAT, or sales by a business not registered for VAT. These must be e-invoices too (§10.2.1).

The Mandatory Fields V1.1 give the commercial e-invoice its own list (§4.2). Compared with the tax invoice, the seller gives its TIN where it has no TRN, the buyer is identified by its legal registration identifier and its type instead of a TRN, and the two per-line AED amounts are not on the list. The TRN is not mandatory on commercial invoices or on out-of-scope and exempt transactions (Guidelines §12.2, item 1).

In the XML, a VAT-registered seller puts its 15-digit TRN in the seller VAT identifier (IBT-031). A seller not registered for VAT puts its 10-digit TIN in the seller tax registration identifier (IBT-032) instead, and one of the two must be present (Guidelines App. 6, §18.1.1).

Sources: ^[1][2]

Which invoice type codes will you meet?

The invoice type code (field 3) tells the receiving system what kind of document it is. The choice follows the tax treatment of what you sold, not only your VAT registration or where you are established (Guidelines App. 6, §18.3.1). The Guidelines discuss three codes; the full lists are in the code lists of OpenPeppol's PINT AE specification:

• 380: a UAE tax invoice where VAT applies. It is the code in the Ministry's own sample (§12.1 and §18.3.1).
• 480: out of scope of VAT, used only when every supply on the invoice is outside the scope of VAT. Exempt and zero-rated supplies stay within VAT and show through the tax category, not through 480 (§18.3.1).
• 81: a credit note related to goods or services. With 480 and with 81, the buyer's legal registration identifier (IBT-047) becomes mandatory under rule IBR-136-AE (§18.2.1).

Sources: ^[2][5]

What does a PINT AE file look like?

Below is a shortened sample with fictitious data. Its elements follow the PINT AE syntax that OpenPeppol publishes, and its fixed values (specification identifier, business process type, invoice type code 380 and the all-zero transaction type code) are those of the Ministry's own sample (Guidelines §12.1). It is not a valid file on its own: most mandatory fields are left out so the structure is easy to read. The official examples are in OpenPeppol's PINT AE specification, under "Download resources" (Guidelines §12).

<Invoice>
  <cbc:CustomizationID>urn:peppol:pint:billing-1@ae-1</cbc:CustomizationID>   <!-- 1 -->
  <cbc:ProfileID>urn:peppol:bis:billing</cbc:ProfileID>                       <!-- 2 -->
  <cbc:ProfileExecutionID>00000000</cbc:ProfileExecutionID>                   <!-- 3 -->
  <cbc:ID>INV-0001</cbc:ID>                                                   <!-- 4 -->
  <cbc:IssueDate>2027-01-04</cbc:IssueDate>
  <cbc:InvoiceTypeCode>380</cbc:InvoiceTypeCode>
  <cbc:DocumentCurrencyCode>AED</cbc:DocumentCurrencyCode>                    <!-- 5 -->
  <cac:AccountingSupplierParty>
    <cac:Party>
      <cbc:EndpointID schemeID="0235">1000000001</cbc:EndpointID>             <!-- 6 -->
      ...
    </cac:Party>
  </cac:AccountingSupplierParty>
  <cac:AccountingCustomerParty>
    <cac:Party>
      <cbc:EndpointID schemeID="0235">1000000002</cbc:EndpointID>             <!-- 7 -->
      ...
    </cac:Party>
  </cac:AccountingCustomerParty>
  <cac:TaxTotal>
    <cbc:TaxAmount currencyID="AED">50.00</cbc:TaxAmount>                     <!-- 8 -->
    ...
  </cac:TaxTotal>
  <cac:LegalMonetaryTotal>
    <cbc:TaxExclusiveAmount currencyID="AED">1000.00</cbc:TaxExclusiveAmount>
    <cbc:TaxInclusiveAmount currencyID="AED">1050.00</cbc:TaxInclusiveAmount>
    <cbc:PayableAmount currencyID="AED">1050.00</cbc:PayableAmount>
  </cac:LegalMonetaryTotal>
  ...
</Invoice>

1. Specification identifier (field 8). urn:peppol:pint:billing-1@ae-1 is the value shown in the Ministry's own sample (Guidelines §12.1).
2. Business process type (field 7), a fixed value: urn:peppol:bis:billing.
3. Invoice transaction type code (field 5): eight flags of 1 or 0. All zeros means none of the special scenarios applies.
4. Invoice number, issue date and invoice type code 380 (fields 1 to 3).
5. Invoice currency code (field 4).
6. Seller electronic address: the scheme 0235 and the seller's 10-digit TIN (fields 11 and 12).
7. Buyer electronic address (fields 22 and 23). For a buyer that has not implemented e-invoicing yet and has no Peppol Participant Identifier, it would be 0235:9900000098 (Guidelines §10.2.2).
8. Totals: the invoice's total tax, then the totals without and with tax and the amount due for payment (fields 31 to 34).

Sources: ^[2][5]

Which version of PINT AE applies now?

The Ministry's documents do not print a release number for PINT AE. They point to the PINT AE billing specification that OpenPeppol publishes (Guidelines §10 and §12), and they make keeping current a duty of the providers: ASPs must stay informed of updates and always use the latest version when they exchange e-invoices (App. 3, §15.4), while the Ministry works with Peppol so that ASPs follow the latest agreed UAE requirements (§15.1).

Check the current release on OpenPeppol's UAE specifications page, and ask your ASP which release it validates against and how it announces changes. The specification identifier in the Ministry's own sample is urn:peppol:pint:billing-1@ae-1 (§12.1).

Sources: ^[2][5]

Who builds the PINT AE XML: you, your ASP or a connector?

Any of the three, depending on what you agree with your ASP. In the five-corner model your business (corner 1) submits invoice data to its ASP (corner 2) in an agreed format; the ASP validates it and converts it into the UAE XML e-invoice when it arrives in another format (Guidelines §5.1). Agreeing how invoice data will be shared is a step of its own in the Ministry's readiness plan (App. 1, §13.3(a)).

So there are three set-ups: your system produces PINT AE itself; your system sends the ASP its own format, through an API or a file, and the ASP converts it; or a connector reads your posted invoices and builds the PINT AE file before it reaches the ASP. In each case the ASP still validates the result, and the data has to be right at the source: no format can supply a missing buyer TIN or correct a wrong tax category. The ASP vs connector page compares the set-ups.

Sources: ^[2]

Where Vattora fits, and when you do not need it

Vattora reads posted invoices and credit notes from your accounting system, builds each one as a PINT AE e-invoice and checks it against the PINT AE rules it implements before it leaves; a problem stops it on Vattora's side, with the reason, before your ASP sees it. Your ASP still validates, exchanges and reports. The readiness check maps 20 of your invoices to PINT AE and lists every gap. If your system or your ASP already produces PINT AE from your data, you do not need Vattora for the format.