The Mandatory Fields of a UAE E-Invoice, Explained

A UAE e-invoice under PINT AE 1.0.4 must carry a document header, a seller, a buyer, one or more lines, a VAT breakdown and the totals, plus a short list of terms that exist only in the UAE specification: a document UUID, an eight-flag transaction type code, an item type on every line, and AED amounts beside any other currency. This page groups those fields, shows where each one sits in the UBL file, and says which are always required and which depend on the document.

The Ministry of Finance counts 51 mandatory fields for a PINT AE tax invoice in its October 2026 programme briefing. We quote that count as the Ministry's and do not repeat it as ours. The structure below was read on 11 November 2026 from OpenPeppol's PINT AE Billing 1.0.4 archive (rule sheet and published examples, downloaded 8 October 2026), not from memory. We could not re-open the Ministry's PDF in this session, so for the official list, use the Ministry's own document.

What is PINT AE, and how does it differ from a plain Peppol invoice?

PINT AE is OpenPeppol's UAE specialisation of the international Peppol invoice model. Version 1.0.4 was released on 2 June 2026 according to its release notes. A PINT AE invoice is a UBL 2.1 XML file. It declares itself with the customization identifier urn:peppol:pint:billing-1@ae-1 and the profile urn:peppol:bis:billing.

It keeps the familiar business terms (the invoice number is IBT-001, the issue date IBT-002 and so on) and adds UAE terms numbered BTAE-01 upward. Those added terms are the part a generic Peppol mapping misses. The specification is published at docs.peppol.eu, and the date rules that decide who must use it are on our UAE e-invoicing page.

What are the field groups?

OpenPeppol's own example named "Standard invoice Mandatory fields" is the shortest valid tax invoice in the archive, and it shows the groups well. Each group below is a section of the file, so each one is a section of an ERP mapping.

The identifier and amount fields are the same kind of data any invoice holds. The groups that need design work are the transaction type, the party identifiers and the line classification, covered next.

Which fields exist only in the UAE specification?

These are the BTAE terms that appear in the rule sheet, with what each rule says:

• UUID (BTAE-07). Rule ibr-193-ae: "The unique identifier number (BTAE-07) must be provided." It is one value per invoice.
• Transaction type code (BTAE-02). Eight characters of 0 or 1, written in cbc:ProfileExecutionID. The rules read the positions as: free trade zone, deemed supply, margin scheme, summary invoice, continuous supply, disclosed agent billing, e-commerce supply and export. A plain domestic invoice is 00000000, as in the published example.
• Item type (BTAE-13). Goods, services or both, on every line. Rule ibr-184-ae requires the item classification identifier when the type is goods. Rule ibr-185-ae requires the service accounting code (BTAE-17) for services, and ibr-186-ae requires both for "both".
• Legal registration identifier type (BTAE-15 for the seller, BTAE-16 for the buyer). The type says whether the number is a trade licence, an Emirates ID, a passport or a cabinet decision number. A trade licence needs its issuing authority (BTAE-12 seller, BTAE-11 buyer, rules ibr-172-ae and ibr-101-ae as the rule texts number them), and a passport needs its issuing country.
• Exchange rate (BTAE-04). Required when the invoice currency is not AED (ibr-159-ae).
• AED amounts (BTAE-08, BTAE-10, BTAE-20). The line VAT in AED, the line amount with VAT in AED and the invoice total with VAT in AED. Rule ibr-104-ae requires the first two on every line that has VAT information, and ibr-175-ae requires the total when the invoice is in another currency and the tax currency is AED.
• Type of goods or services subject to reverse charge (BTAE-09). Required on a reverse-charge line (ibr-166-ae), selected from a published code list (ibr-006-ae).

Note the second bullet. The transaction type flags are not decoration: they switch other rules on, as the next section shows.

Which fields are required only in some cases?

Most of the PINT AE rules are conditions. Reading the rule sheet, the ones a mapping most often meets are these:

Three more rules apply to every UAE address and every standard-rated line. The seller, buyer and delivery address must give an emirate drawn from AUH, DXB, SHJ, UAQ, FUJ, AJM or RAK (ibr-128-ae). Seller and buyer addresses need a street, a city and a country subdivision (ibr-143-ae, ibr-144-ae). A standard-rated category must carry a rate of 5.00 (ibr-190-ae).

Who must be identified, and how?

The party rules cause more failed first files than any other group, so they deserve their own section.

A UAE business is addressed on the Peppol network under scheme 0235 with its ten-digit Tax Identification Number, the TIN. In the published example the seller's address is 0235:1357902468 and the VAT number is 135790246801003, which is the TIN followed by five more digits ending in 03. The VAT number goes in the tax scheme block with the scheme code VAT.

Two rules make the seller's identifiers non-optional. Rule ibr-177-ae requires either the seller's tax registration identifier or its VAT identifier. Rule ibr-150-ae requires the seller's legal registration identifier whenever the seller's electronic address is under scheme 0235. For the buyer, ibr-149-ae asks for the legal registration identifier when the buyer's address is under 0235, with exceptions for addresses that start with 1 or 9. Rule ibr-135-ae asks for a buyer identifier or VAT number, with an exception for exports.

Two things follow for master data. The customer record needs a registration type and, for a trade licence, an authority, not only a VAT number. And an ERP that stores one "tax number" field per party will have to store more than that.

What does an ERP have to supply, and what can a provider add?

This is a design question and the specification does not answer it for you. What the file must contain is fixed. Who writes each value is not.

Data only your ERP holds: the parties and their registration identifiers, the lines and their prices, the VAT category per line, the item type, the HS code for goods or the service accounting code for services, and the payment terms.

Values a provider can often add or compute: the customization and profile identifiers, the UUID, the AED mirror amounts from an exchange rate you supply, and the eight-character transaction type code if your ERP can flag the case. Agree this split in writing. If neither side writes the transaction type, the file fails.

How each ERP family handles this is in UAE e-invoicing from Oracle, SAP and Dynamics. What happens to the invoice after it is issued, and what the Federal Tax Authority receives, is in the UAE tax data document explained. Correcting an invoice that is already issued is a separate set of rules, set out in credit notes and corrections under UAE e-invoicing.

What this page does not cover

It does not list signing or transport. It does not settle who falls in which wave: that is in the AED 50 million threshold article and the readiness guide. It does not state a field count of its own, and it does not name a penalty, because the Ministry's penalty rules were not read for this page.

GoRoute is not on the Ministry's list of Accredited Service Providers. It is a certified Peppol Access Point, POP000991. If you are appointing a UAE provider, choose from the Ministry's list, using the buyer's checklist.

Where to go next

To see how a mapping like this is built and tested, watch the GoRoute tutorials or read the developer documentation. If you are mapping an ERP now and want to talk it through, book a call. Start from our UAE e-invoicing page.

Sources: OpenPeppol, PINT AE Billing 1.0.4 (rule sheet and published examples, downloaded 8 October 2026; release notes dated 2 June 2026); UAE Ministry of Finance, UAE eInvoicing Programme briefing, October 2026 (cited for the count of 51, not re-opened on the day). Prepared by Lisa Thompson, GoRoute's AI marketing operations manager; reviewed by Dr. Syed Raza.