UAE e-invoice format: the Peppol ID, PINT AE fields and a sample XML, explained

Short answer: A UAE e-invoice is an XML file in the Peppol PINT AE format (built on UBL 2.1), not a PDF. Every business is addressed on the network by a Peppol ID: 0235: plus its 10-digit TIN, which is the first 10 digits of its TRN. Most rejections don't come from missing invoices. They come from small format details: free-text emirates instead of codes like DXB, "KG" instead of KGM, a missing 8-digit transaction flag, or totals with three decimals. This guide walks through a real-structure sample invoice, element by element, and lists the rules your system has to meet before your Accredited Service Provider (ASP) will accept the data.

From our side

When teams first look at the format, they assume the TRN and the totals are the hard part. In practice the trouble is the codes that free-text fields never forced anyone to standardise: units, emirates and licence authorities. We'd start by exporting one month of invoice lines and counting how many distinct unit labels you actually use. That number tells you how big the clean-up really is.

— Avi Singh, Founder

This page is for developers, ERP consultants and finance system owners who need to know exactly what goes in the file. For deadlines, penalties and choosing an ASP, read our ERP integration guide for UAE e-invoicing instead. This page doesn't repeat them.

The Peppol ID, decoded

The Ministry of Finance's e-invoicing guidelines define your participant identifier as 0235 followed by your 10-digit Tax Identification Number. The mandatory fields list says the TIN is the first 10 digits of your Corporate Tax TRN. In a tax group it comes from your own TRN, not the representative's. You don't build the ID yourself: your ASP registers it and shares it with you once onboarding through EmaraTax is complete.

Three predefined endpoints replace the buyer's ID in special cases. The guidelines set them out:

A practical rule: store the buyer's Peppol ID as its own field in the customer record, with a "not yet on e-invoicing" option that maps to 9900000098. Don't work it out from the TRN at send time. Some buyers will onboard later, and you need to know who has and who hasn't.

A sample UAE e-invoice, element by element

Below is a shortened standard tax invoice. It follows the structure of the official PINT AE example files that OpenPeppol publishes with the specification. The values are made up and some optional blocks are left out.

<Invoice xmlns="urn:oasis:names:specification:ubl:schema:xsd:Invoice-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-00418</cbc:ID>
  <cbc:UUID>…assigned per e-invoice…</cbc:UUID>
  <cbc:IssueDate>2026-10-12</cbc:IssueDate>
  <cbc:DueDate>2026-11-11</cbc:DueDate>
  <cbc:InvoiceTypeCode>380</cbc:InvoiceTypeCode>
  <cbc:DocumentCurrencyCode>AED</cbc:DocumentCurrencyCode>
  <cac:AccountingSupplierParty><cac:Party>
    <cbc:EndpointID schemeID="0235">1234567890</cbc:EndpointID>
    <cac:PostalAddress>
      <cbc:StreetName>Warehouse 7, Street 12</cbc:StreetName>
      <cbc:CityName>Dubai</cbc:CityName>
      <cbc:CountrySubentity>DXB</cbc:CountrySubentity>
      <cac:Country><cbc:IdentificationCode>AE</cbc:IdentificationCode></cac:Country>
    </cac:PostalAddress>
    <cac:PartyTaxScheme>
      <cbc:CompanyID>123456789000003</cbc:CompanyID>
      <cac:TaxScheme><cbc:ID>VAT</cbc:ID></cac:TaxScheme>
    </cac:PartyTaxScheme>
    <cac:PartyLegalEntity>
      <cbc:RegistrationName>Example Trading LLC</cbc:RegistrationName>
      <cbc:CompanyID schemeAgencyID="TL" schemeAgencyName="Dubai Economy and Tourism">…</cbc:CompanyID>
    </cac:PartyLegalEntity>
  </cac:Party></cac:AccountingSupplierParty>
  <!-- AccountingCustomerParty: same shape, buyer's values, e.g. CountrySubentity AUH -->
  <cac:PaymentMeans><cbc:PaymentMeansCode>30</cbc:PaymentMeansCode>…</cac:PaymentMeans>
  <cac:TaxTotal>… VAT breakdown per category and rate …</cac:TaxTotal>
  <cac:LegalMonetaryTotal>… four totals, 2 decimals …</cac:LegalMonetaryTotal>
  <cac:InvoiceLine>
    <cbc:ID>1</cbc:ID>
    <cbc:InvoicedQuantity unitCode="XCT">40</cbc:InvoicedQuantity>
    <cbc:LineExtensionAmount currencyID="AED">4800.00</cbc:LineExtensionAmount>
    <cac:Item>
      <cbc:Description>…</cbc:Description><cbc:Name>…</cbc:Name>
      <cac:CommodityClassification>
        <cbc:CommodityCode>G</cbc:CommodityCode>
        <cbc:ItemClassificationCode listID="HS">…</cbc:ItemClassificationCode>
      </cac:CommodityClassification>
      <cac:ClassifiedTaxCategory><cbc:ID>S</cbc:ID><cbc:Percent>5</cbc:Percent>…</cac:ClassifiedTaxCategory>
    </cac:Item>
    <cac:Price>
      <cbc:PriceAmount currencyID="AED">120.00</cbc:PriceAmount>
      <cbc:BaseQuantity unitCode="XCT">1</cbc:BaseQuantity>
      <cac:AllowanceCharge>… gross price, discount …</cac:AllowanceCharge>
    </cac:Price>
    <cac:ItemPriceExtension>
      <cbc:Amount currencyID="AED">5040.00</cbc:Amount>
      <cac:TaxTotal><cbc:TaxAmount currencyID="AED">240.00</cbc:TaxAmount></cac:TaxTotal>
    </cac:ItemPriceExtension>
  </cac:InvoiceLine>
</Invoice>

What each part maps to

The MoF field names on the left are the ones in the official mandatory fields list. The middle column is where each one lives in the XML.

The 8-digit transaction flags

The invoice transaction type code is eight positions, each 1 or 0, in this order: free trade zone, deemed supply, profit margin scheme, summary invoice, continuous supply, disclosed agent billing, e-commerce, exports. Most domestic B2B sales are 00000000. The official sample files use 00000001 for an export and 01000000 for a deemed supply. Several flags make other fields mandatory under the PINT AE validation rules:

Where more than one applies, set each relevant position. The code is always built in list order. The point for system design: these flags are facts about the sale, so record them on the order or invoice as it's created. Don't try to work them out at month end.

Code lists that catch people out

These checks come from the validation rules published with PINT AE 1.0.4. Most are "fatal": the invoice is rejected, not just flagged.

• Emirates. When the country is AE, the subdivision must be one of AUH, DXB, SHJ, UAQ, FUJ, AJM or RAK (rule ibr-128-ae). A customer master full of "Dubai", "dubai " and "DXB." needs cleaning first.
• Units. Units must be UN/ECE Recommendation 20 codes (with the Rec 21 extension). Kilogram is KGM, piece H87, each EA, carton XCT, box XBX, litre LTR, hour HUR. The MoF field list gives "KG" as a plain-English example, but KG is not in the code list and fails the check. The silent trap is CTN: it passes validation, but it means content ton (metric), not carton.
• Item type. Each line is goods (G), services (S) or both (B). Goods need an HS code, services need a service accounting code (scheme SAC), and "both" needs both.
• Tax categories. S standard, Z zero-rated, E exempt, O outside scope, AE reverse charge, plus a category for the margin scheme. Exempt lines need an exemption reason code. Reverse charge lines need the buyer's TRN and the type of goods from the reverse-charge list.
• Credit note reasons. A tax credit note (381) must carry a reason code: cancelled supply, changed tax treatment, changed consideration, goods returned, tax charged in error, or VD (volume discount). Every reason except VD also needs a reference to the original invoice.
• Payment means. Required on invoices (not credit notes or deemed supplies). If you choose credit transfer, the payment account must be given too.

Numbers and currency rules

• Two decimals on all document totals: amount due, total without tax, total tax, total with tax, and document-level allowances and charges.
• Line arithmetic is checked. Line net amount must equal quantity × (net price ÷ base quantity), plus line charges, minus line allowances (rule ibr-147-ae). Net price must equal gross price minus discount. Systems that round the unit price but store an unrounded line total fail here.
• Foreign currency. If the invoice isn't in AED, an exchange rate (cac:TaxExchangeRate, up to six decimals) is required. The tax accounting currency must be AED, and the invoice's total VAT and total with VAT must also be given in AED. The VAT and line amounts in AED on every line stay mandatory.

Pre-flight checklist for your data

Run this against one real month of invoices before you start mapping. Each "no" is a change to your system, not to the ASP's.

1. Do we store our own TIN and our trade licence number, type and issuing authority in one agreed spelling?
2. Does every business customer have a Peppol ID field, and an explicit "not yet onboarded" state?
3. Is every address held with an emirate code rather than free text?
4. Does every product have a Rec 20 unit code, an item type and an HS code (or SAC for services)?
5. Can an order record the eight transaction flags and the extra data they require?
6. Are credit notes separate documents with a reason code and a link to the original invoice?
7. Do we store AED line amounts and the rate used on every foreign-currency invoice?
8. Do our totals pass the two-decimal and line-arithmetic rules without manual fixing?

Score your system in a minute

Tick each statement that is already true for your invoicing system today. Be strict: "mostly" counts as no.

This runs in your browser. Nothing you tick is sent anywhere unless you choose to send it.

How we help

We're a software company with a development team in India, working with UAE businesses remotely. We aren't an ASP and have no UAE office. We work on the system side. We add the missing fields and code lists to your billing system, ERP or ordering portal. We clean and map the existing data, build the connection to the ASP you choose, and bring rejections back into your system so staff can fix them. You get a fixed quote after a 20-minute walkthrough, so the full cost is known before work starts.

More on what we build is on our software and e-invoicing integration page for UAE businesses. Book a call or send us an invoice export to review. If you run Odoo, SAP Business One or Zoho Books, see what each of those ERPs provides for PINT AE. For the VAT rules behind the fields, read UAE tax invoice requirements.

Sources

• Ministry of Finance, UAE Electronic Invoicing Guidelines v1.1 (1 June 2026): participant identifier, predefined endpoints, tax group TINs, onboarding
• Ministry of Finance, UAE Electronic Invoice mandatory fields v1.0 (23 February 2026): field names, transaction type flags, legal registration types
• Ministry of Finance, eInvoicing programme hub (accessed 13 October 2026)
• Ministerial Decision No. 243 of 2025 on the Electronic Invoicing System (2025)
• OpenPeppol, PINT AE specification 1.0.4 (PDK 1.4.4) (29 July 2026): example files, code lists and validation rules (ibr-128-ae, ibr-132-ae, ibr-147-ae, ibr-154-ae, ibr-cl-23 and others), re-checked 13 October 2026

Last reviewed 13 October 2026. Rules are from PINT AE 1.0.4. The specification is updated from time to time, so check the current version with your ASP. This guide explains published technical guidance and isn't legal or tax advice.