The XML You Will Never Write, and Must Still Understand

Guide·Updated 6 September 2026

Nobody at your business will ever type a PINT AE invoice by hand. Your Accredited Service Provider generates it from the data your billing system sends. So why read about the format at all? Because when an invoice is rejected, the error names an element of this document, not a line on your PDF. Because every field in it has to come from somewhere in your records. And because the FTA reads the XML, not the invoice your customer sees. This is the structure, in the plainest terms we can manage.

What PINT AE actually is

Peppol is an international network for exchanging business documents, and PINT, the Peppol International Invoice model, is its shared invoice format. Each country that adopts it layers on its own requirements. PINT AE is that layer for the UAE: the shared model plus the UAE-specific business terms the Ministry of Finance and the FTA need. Technically it is a UBL 2.1 XML document, either an Invoice or a CreditNote, in the standard UBL namespaces, that passes three sets of checks: the XML schema, the PINT shared rules, and the UAE rules. Fail any of them and the document is not an e-invoice.

The lines that make it a UAE document

Two declarations at the top tell every system on the network what it is looking at. cbc:CustomizationID carries urn:peppol:pint:billing-1@ae-1, which says: validate me against the UAE rules, not the European ones. cbc:ProfileID carries urn:peppol:bis:billing, the billing process. A provider that validates against the wrong customisation will pass invoices the FTA later rejects, which is one reason the provider selection questions include how they test.

A skeleton, with the UAE parts marked

<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-0418</cbc:ID>
  <cbc:IssueDate>2026-09-01</cbc:IssueDate>
  <cbc:InvoiceTypeCode>380</cbc:InvoiceTypeCode>
  <cbc:DocumentCurrencyCode>USD</cbc:DocumentCurrencyCode>
  <cbc:TaxCurrencyCode>AED</cbc:TaxCurrencyCode>
  <cac:AccountingSupplierParty><cac:Party>
    <cbc:EndpointID schemeID="0235">1002345678</cbc:EndpointID>
    <cac:PartyTaxScheme><cbc:CompanyID>100234567800003</cbc:CompanyID>
      <cac:TaxScheme><cbc:ID>VAT</cbc:ID></cac:TaxScheme></cac:PartyTaxScheme>
  </cac:Party></cac:AccountingSupplierParty>
  ...
  <cac:InvoiceLine>
    <cac:Item><cac:ClassifiedTaxCategory><cbc:ID>S</cbc:ID><cbc:Percent>5.00</cbc:Percent>
    </cac:ClassifiedTaxCategory></cac:Item>
  </cac:InvoiceLine>
</Invoice>

Everything in copper is either UAE-specific or the place where UAE businesses most often go wrong. Reading down:

The eight flags: ProfileExecutionID

The mandatory field list calls it the invoice transaction type code. In the XML it is a single eight-character string of ones and zeros in cbc:ProfileExecutionID, in a fixed order: free trade zone, deemed supply, profit margin scheme, summary invoice, continuous supply, disclosed agent billing, e-commerce supply, exports. A plain domestic sale is 00000000. An export through your own e-commerce platform is 00000011. Each position is a VAT classification your system must be able to make per transaction, and each one becomes structured data the FTA can compare against your returns. Today those decisions mostly live in an accountant’s head; the format requires them to live in your data.

Two currencies, one of them fixed: TaxCurrencyCode

cbc:DocumentCurrencyCode is whatever you bill in. cbc:TaxCurrencyCode must be AED, always, so every VAT amount is stated in dirhams whatever the invoice currency, and a foreign-currency invoice has to carry the exchange rate that produced those dirham figures. Systems that bill in USD or EUR and store no rate per invoice fail here, on every document, from the first one.

Who you are: EndpointID and PartyTaxScheme

Two identifiers, easily confused. cbc:EndpointID with schemeID="0235" is your address on the network: the 0235 scheme marks a UAE participant, and the value is your TIN, the first ten digits of your Corporate Tax TRN. It is where documents are delivered. cac:PartyTaxScheme/cbc:CompanyID is your VAT identity: the full fifteen-digit TRN, with the tax scheme VAT. Both appear for the seller; for a Tax Invoice both are needed for the buyer too, which is the field most customer databases lack. A Tax Group member uses its own TIN for the endpoint, not the representative member’s.

Lines, categories, and the rate written out

Every cac:InvoiceLine carries an item with a cac:ClassifiedTaxCategory: a category code and a rate. The codes are S standard, Z zero-rated, E exempt, O out of scope, and AE reverse charge. The rate on a standard line is written as 5.00, and the format is strict about it; a system storing the rate as 5, 0.05 or a blended figure produces a document that fails. Every line also needs a quantity and a unit of measure code, which is where service businesses that bill a single unqualified amount get caught. Totals are then reconciled twice: cac:TaxTotal broken down per category in cac:TaxSubtotal, and cac:LegalMonetaryTotal tying the lines to the amount due. If the arithmetic does not close to the rounding rules, the invoice fails.

What validation actually does with all this

Your provider runs the document through the schema first (is this well-formed UBL?), then the PINT shared rules (do the totals reconcile, are mandatory elements present?), then the UAE layer (is the tax currency AED, is the endpoint scheme 0235, is the customisation right?). Rules are either fatal, meaning the document is refused, or warnings, meaning it passes with a note. A fatal failure is not a delay: the invoice has not been issued, for VAT purposes or any other, until a version passes. Our commentary on what happens when an invoice is rejected follows that consequence through; this page is the map you need to read the error message it starts from.

What this means for your project

The format is a specification of your data, expressed as XML. Every element above has to be sourced from a field in your billing system or your master data, and where no field exists, the provider can only default or fail. That reframes readiness: not “which ASP” first, but “can our data populate this document, correctly, for every invoice type we issue?” The self-check tests the eight places that answer is most often no, and the readiness service runs the full mapping against the field list.

Common questions