PINT AE Explained: The UAE E-Invoice Format, Fields and Validation Rules

PINT AE is the technical format for e-invoices in the UAE. It is the UAE specialisation of Peppol PINT (Peppol International), the shared invoice model that OpenPeppol uses across countries. Each country adds its own rules on top of the shared core. The UAE adds fields for TRNs, AED tax amounts and UAE-specific transaction types.

A PINT AE invoice is an XML file in UBL syntax. People do not read it directly. Your accounting software creates it, your Accredited Service Provider (ASP) checks and sends it, and your customer's software reads it. The specification is published on the Peppol documentation site and is updated from time to time, so your software and ASP need to track the current version.

PINT AE covers two kinds of e-invoice:

• Electronic tax invoices, issued by VAT-registered businesses for taxable supplies.
• Electronic commercial invoices, meaning any invoice that is not a tax invoice, for example one issued by a business that is not VAT registered.

E-invoicing does not remove the VAT duty to issue a tax invoice. The MoF guidelines say that while a customer is not yet on the system, you will still need a regular tax invoice, such as a PDF, as well as the e-invoice. Our guide to UAE tax invoice requirements covers the VAT rules.

Peppol PINT (Peppol International invoice model) is OpenPeppol's template for national e-invoice specifications that still work together. It exists because Peppol BIS Billing 3.0 is based on the European standard EN 16931 and enforces EU VAT rules. PINT splits invoice content into three layers:

• Shared: defined the same way everywhere, such as invoice number, parties, totals and items. A country can make these fields mandatory but cannot change them.
• Aligned: defined in general terms, such as tax details, so each country can add its own rules.
• Distinct: purely local fields.

PINT AE keeps the shared core, adds UAE VAT rules to the aligned parts (such as the TRN format) and adds UAE-only fields.

Two header fields say which rules an invoice follows:

• Specification identifier (IBT-024), UBL element CustomizationID, must start with urn:peppol:pint:billing-1@ae-1: a PINT document, billing version 1, UAE specialisation.
• Business process type (IBT-023), UBL element ProfileID, must start with urn:peppol:bis:billing.

Both are fixed values that your software sets. If either is wrong, the invoice fails rules aligned-ibrp-001-ae or aligned-ibrp-002-ae.

In self-billing the buyer issues the invoice on the supplier's behalf, by agreement. It uses its own identifiers: urn:peppol:pint:selfbilling-1@ae-1, business process urn:peppol:bis:selfbilling and invoice type code 389. The MoF guidelines allow it only for tax invoices from VAT-registered suppliers, the buyer must be on the e-invoicing system, and the compliance obligation sits with the buyer.

The Ministry of Finance (MoF) publishes UAE Electronic Invoice Mandatory Field Requirements. Version 1.1, dated 28 October 2026, replaces version 1.0 of 23 February 2026. For an electronic tax invoice it lists 51 mandatory fields in six groups:

• Invoice details: number, date, type code, currency, transaction type flags, payment due date, business process type, specification identifier and payment means.
• Seller: name, electronic address, legal registration, TRN and address.
• Buyer: name, electronic address, TRN and address.
• Document totals: sum of line net amounts, net total, tax total, total with tax and amount due.
• Tax breakdown: taxable amount, tax amount, category code and rate for each VAT category.
• Invoice lines: quantity, unit of measure, prices, item name and description, and the VAT amount and line amount in AED for each line.

Commercial invoices use an adapted list of 49 fields. For example, a seller without a TRN gives its TIN instead, the buyer's legal registration identifier and its type replace the buyer's tax fields, and the AED line amounts are not required.

Your Tax Identification Number (TIN) is the first 10 digits of your 15-digit TRN. Your Peppol participant identifier is 0235 followed by that TIN, and it is issued through your ASP. Each member of a VAT tax group uses the first 10 digits of its own TRN, not the representative member's. A business without a TRN gets a TIN through EmaraTax.

Where a buyer has no participant identifier, the MoF guidelines set fixed placeholder endpoints: 0235:9900000098 for a buyer not on the system, 9900000097 for deemed supplies and 9900000099 for exports.

The PINT AE data dictionary lists every field a UAE e-invoice can carry: its meaning, whether it is mandatory, its format and its place in the XML. The MoF consulted on a draft in early 2025, and the specification has been published on the Peppol documentation site since June 2025, now as PINT AE Billing version 1.0.4.

• docs.peppol.eu holds the semantic model, UBL syntax, code lists, validation rules and XML samples, for invoices and credit notes.
• The MoF e-invoicing page publishes the guidelines and the mandatory fields document, which are read together with PINT AE.

Each field has a business term ID. PINT terms use IBT-, such as IBT-001 for the invoice number. UAE-only terms use BTAE-, such as BTAE-02 for the invoice transaction type code.

Fifteen key fields, with IDs and names as in the PINT AE semantic model. Example values are illustrative.

A PDF is a picture of an invoice. A PINT AE file is data that machines check, field by field. The MoF is clear that a PDF, scan, image or email is not an e-invoice.

Validation happens twice. Your ASP (Corner 2) checks your file against the PINT AE business rules before sending it. Your customer's ASP (Corner 3) checks it again on arrival. Typical rules include:

• mandatory fields must be present, such as the seller's TRN on a tax invoice;
• codes must come from the published code lists, for currencies, countries, units and VAT categories;
• totals must add up, line by line and for the whole document;
• a credit note should identify the invoice it corrects.

If validation fails at the buyer's side, the buyer's ASP does not report tax data for that invoice, and you have to fix and resend it. You cannot edit an e-invoice after sending it. Corrections are made with an electronic credit note or an additional invoice.

Validation runs in three layers:

1. Syntax: the file must be valid UBL 2.1 XML.
2. Shared PINT rules that apply in every country, such as ibr-080 (buyer electronic address required).
3. AE-specific rules that all UAE senders apply, with IDs ending in -ae or starting aligned-ibrp.

Each rule has a flag. A fatal failure makes the invoice invalid. A warning is reported but does not block it. Every UAE rule we checked is flagged fatal, so treat them as must-pass.

• ibr-132-ae (TRN format): for a UAE party registered for VAT, the VAT identifier must be a TRN of 15 digits, digits only, starting with 1 and ending with 03.
• ibr-136-ae (out-of-scope invoices): an out-of-scope invoice (type 480) or its credit note (type 81) must include the buyer's legal registration identifier.
• ibr-157-ae (transaction flags): an out-of-scope invoice or credit note cannot be flagged as a summary invoice, deemed supply or margin scheme invoice.
• ibr-121-ae (exempt supplies): where the VAT category is E (exempt), no VAT rate may be given.
• ibr-001-ae (credit note reasons): a credit note's reason code must be one of the codes on the UAE list, DL8.61.1.A to DL8.61.1.E or VD.
• ibr-002-ae (exchange rate): the currency exchange rate must be a plain number with no more than six decimal places.

Your provider (Corner 2) validates the data from your software before sending it, so a fatal error there stops the invoice going any further. The buyer's provider (Corner 3) validates it again. If that fails, Corner 3 notifies your provider and the FTA and does not report tax data for the invoice. Either way, you fix the data and issue the invoice again. Most failures come from master data, such as a TRN with spaces, so use the checklist below before your go-live date.

A simple AED tax invoice: 10 items at AED 100, plus 5% VAT. Simplified for illustration — not a complete valid invoice. A real one also needs the sum of line net amounts, the payment due date, payment means, addresses with the emirate, legal registration details and AED line amounts.

<Invoice xmlns="urn:oasis:names:specification:ubl:schema:xsd:Invoice-2" xmlns:cac="urn:oasis:names:specification:ubl:schema:xsd:CommonAggregateComponents-2"
  xmlns:cbc="urn:oasis:names:specification:ubl:schema:xsd:CommonBasicComponents-2">
  <cbc:CustomizationID>urn:peppol:pint:billing-1@ae-1</cbc:CustomizationID>
  <cbc:ProfileID>urn:peppol:bis:billing</cbc:ProfileID>
  <cbc:ProfileExecutionID>00000000</cbc:ProfileExecutionID>
  <cbc:ID>INV-2026-0142</cbc:ID>
  <cbc:UUID>6f1c2b7e-9a4d-4c1e-8b2f-3d5a7e9c1b40</cbc:UUID>
  <cbc:IssueDate>2026-11-02</cbc:IssueDate>
  <cbc:InvoiceTypeCode>380</cbc:InvoiceTypeCode>
  <cbc:DocumentCurrencyCode>AED</cbc:DocumentCurrencyCode>
  <cac:AccountingSupplierParty><cac:Party>
    <cbc:EndpointID schemeID="0235">1001234567</cbc:EndpointID>
    <cac:PartyTaxScheme><cbc:CompanyID>100123456700003</cbc:CompanyID>
      <cac:TaxScheme><cbc:ID>VAT</cbc:ID></cac:TaxScheme></cac:PartyTaxScheme>
    <cac:PartyLegalEntity><cbc:RegistrationName>Example Trading LLC</cbc:RegistrationName></cac:PartyLegalEntity>
  </cac:Party></cac:AccountingSupplierParty>
  <cac:AccountingCustomerParty><cac:Party>
    <cbc:EndpointID schemeID="0235">1009876543</cbc:EndpointID>
    <cac:PartyTaxScheme><cbc:CompanyID>100987654300003</cbc:CompanyID>
      <cac:TaxScheme><cbc:ID>VAT</cbc:ID></cac:TaxScheme></cac:PartyTaxScheme>
    <cac:PartyLegalEntity><cbc:RegistrationName>Sample Buyer FZE</cbc:RegistrationName></cac:PartyLegalEntity>
  </cac:Party></cac:AccountingCustomerParty>
  <cac:TaxTotal><cbc:TaxAmount currencyID="AED">50.00</cbc:TaxAmount>
    <cac:TaxSubtotal><cbc:TaxableAmount currencyID="AED">1000.00</cbc:TaxableAmount>
      <cbc:TaxAmount currencyID="AED">50.00</cbc:TaxAmount>
      <cac:TaxCategory><cbc:ID>S</cbc:ID><cbc:Percent>5</cbc:Percent>
        <cac:TaxScheme><cbc:ID>VAT</cbc:ID></cac:TaxScheme></cac:TaxCategory></cac:TaxSubtotal></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>
  <cac:InvoiceLine><cbc:ID>1</cbc:ID>
    <cbc:InvoicedQuantity unitCode="H87">10</cbc:InvoicedQuantity>
    <cbc:LineExtensionAmount currencyID="AED">1000.00</cbc:LineExtensionAmount>
    <cac:Item><cbc:Name>Office chair</cbc:Name>
      <cac:ClassifiedTaxCategory><cbc:ID>S</cbc:ID><cbc:Percent>5</cbc:Percent></cac:ClassifiedTaxCategory></cac:Item>
    <cac:Price><cbc:PriceAmount currencyID="AED">100.00</cbc:PriceAmount></cac:Price>
  </cac:InvoiceLine>
</Invoice>

ProfileExecutionID holds the eight transaction flags (all zero for an ordinary sale). Each EndpointID with scheme 0235 is a TIN, and each CompanyID under PartyTaxScheme is a 15-digit TRN. Complete official samples are in the Peppol PINT AE download resources.

Most rejections come from master data, not from the software. Work through these before your go-live date:

• Customer TRNs. Check every business customer's TRN against the certificate, store it as 15 digits with no spaces, and record which customers are not registered.
• Addresses and emirate. Each UAE customer needs a structured address with city and emirate, not one free-text line. Foreign customers need a valid country code.
• Item classification. Mark each item or service as goods, services or both, and give it the correct VAT category and a standard unit of measure.
• Credit notes. Every credit note should reference the original invoice number. One credit note can cover several invoices or part of one.
• Foreign currency. Invoices in USD or EUR still need line VAT and the amount payable in AED, using the Central Bank exchange rate. Check how your software stores rates.
• Special transactions. Decide which sales need a transaction flag, such as free zone, exports, deemed supplies or the margin scheme, and set them up once.

Reverse-charge purchases also need correct VAT categories. Our guide to reverse charge VAT explains the rules.

1. Corner 1, you as supplier, create the invoice in your accounting software, which sends the data to your ASP.
2. Corner 2, your ASP, validates it as PINT AE and sends the XML invoice over the Peppol network to the buyer's ASP.
3. In parallel, Corner 2 reports the tax data to Corner 5, the FTA.
4. Corner 3, the buyer's ASP, validates the invoice, confirms receipt to Corner 2 and reports its own tax data if validation succeeds.
5. Corner 4, the buyer, receives the invoice in its own software.
6. Status messages from the FTA and the ASPs flow back, so both sides can see whether the invoice was accepted.

To understand what your ASP does at each step and how to choose one, read What is an ASP in UAE e-invoicing.