UAE E-Invoice Mandatory Fields: 51 PINT AE Fields Explained

The Ministry of Finance's 51 mandatory fields

The Ministry of Finance's February 2026 presentation on the UAE eInvoicing Programme sets out the mandatory fields in a PINT AE tax e-invoice under six headings, 51 in total. The table follows its numbering and headings. The PINT ID column is our mapping, since the presentation names the fields without IDs, and the last column shows what makes each field required in PINT AE 2025-Q2.

How the 51 map to PINT AE

Set against the 2025-Q2 invoice semantic model, the 51 fields fall into three groups.

• 38 are unconditionally mandatory in the model. The term is 1..1 and so is each business group above it, so the structure alone requires them.
• 6 are 1..1 inside an optional group. The structure requires them only once the group is used; a UAE rule then requires the group, or the field, on an ordinary tax invoice.
• 7 are optional in the model. The term is 0..1, and a UAE rule makes it required.

Each of the 13 fields outside the first group is required by a rule published in the PINT AE 2025-Q2 UAE rule set, and each rule used here is flagged fatal: a document that breaks it fails validation. The conditions matter as much as the rule. The table keeps each rule's own exceptions rather than reducing it to "mandatory".

Two terms go the other way. The unique identifier number (BTAE-07) and the tax scheme code in the VAT breakdown (IBT-118-1) are unconditionally mandatory in the PINT AE 2025-Q2 model but are not separately enumerated in the MoF's 51-field presentation. A PINT AE document still has to carry them.

What the structure alone requires: 40 terms

The rest of this page reads the semantic model by cardinality, before any UAE rule is applied. That reading is useful for understanding why a field is or is not in the structure, and it is where the figure of 40 comes from. It is not a compliance checklist on its own: the MoF's 51 is.

Each business term carries a cardinality, and each sits somewhere in a tree of business groups that carry their own. Combining the two gives three structural classifications.

• Unconditionally mandatory. The term is 1..1 or 1..n, and so is each group above it. There are 40 of these.
• Mandatory within an optional group. The term is 1..1, but a group on its path is 0..1 or 0..n. Structurally it applies once the group is used, though a UAE rule may require the group. There are 35 of these.
• Optional in the structure. The term is 0..1 or 0..n, though a validation rule may still require it, in general or in a particular scenario. There are 156 of these.

The 40 unconditionally mandatory terms

Grouped as the specification groups them. The path column shows the business groups above each term. The last column is the usual source in an ERP, indicative rather than a mapping specification, since field names differ between systems.

Two entries are worth a note. The unique identifier number (BTAE-07) is a UAE-specific term distinct from your own invoice number. It is system-generated, and whether the invoicing system, the connector or the service layer produces it depends on the implementation. The specification identifier (IBT-024) is a fixed value that names the release the document claims to follow: the UAE rules require it to begin urn:peppol:pint:billing-1@ae-1 for billing, or the self-billing equivalent.

Where PINT AE is stricter than the shared PINT model

PINT AE derives from the shared Peppol International invoice model and tightens 15 terms from optional to mandatory. This is the part of the specification that most often surprises an implementation team, because these are fields an existing invoice export frequently omits — the data may exist in the system without being carried into the document.

Six of these apply to an ordinary invoice and concern addresses: seller and buyer street, city and emirate. Systems that store a customer as a single free-text address block, or that leave the emirate blank because nobody needed it for a PDF, have work to do before the data will map cleanly.

Three more sit on the invoice line. Item description (IBT-154) is a separate term from item name, so a system carrying one product text field needs a decision about what populates the other. Item gross price (IBT-148) and item price base quantity (IBT-149) are frequently absent from an export because the system stores only the net selling price. Gross price also carries a validation rule, which is the next section.

What a validation failure looks like

A PINT AE document is checked against published Schematron rules before exchange. Rules with fatal severity cause the document to fail rather than be delivered and corrected later, so data problems surface at the point of sending — a change from PDF invoicing, where a missing field is usually found by the customer.

The rules are arithmetic as well as structural. One of the UAE-aligned rules ties two of the tightened line fields together:

This is the practical argument for treating field presence and field correctness as one piece of work. A checklist confirms a value is there. The rules decide whether the set of values is coherent.

UAE-specific fields that the shared model does not define

PINT AE adds 25 terms of its own, prefixed BTAE. Most are optional and scenario-driven, but they are worth knowing about because they are where UAE requirements that have no equivalent elsewhere are carried.

VAT, AED and invoices in another currency

Invoice currency (IBT-005) and tax accounting currency (IBT-006) are separate terms, so the document does not have to be denominated in AED. PINT AE then adds UAE-specific machinery for carrying AED amounts alongside the invoice currency: a line amounts in accounting currency group (IBG-39) holding the line amount (BTAE-10) and line VAT amount (BTAE-08) in AED, a currency exchange rate (BTAE-04), and an invoice total with VAT in AED (BTAE-20).

IBG-39 is 0..1 in the model, which is why BTAE-10 and BTAE-08 are not among the 40. The UAE rules require them regardless of invoice currency: the line amount in AED on each line (IBR-194-AE), and the VAT line amount in AED on lines carrying VAT information (IBR-104-AE). The VAT line amount is 0 on reverse charge and zero-rated lines, and is not given on exempt or not-subject-to-VAT lines. Where the invoice currency is not AED, the currency exchange rate is required (IBR-159-AE), and with AED as the tax accounting currency so are the tax total and the invoice total with VAT in AED (IBR-175-AE).

VAT categories and reverse charge

VAT treatment is expressed through the VAT category code rather than a flag, and the UAE-aligned rules constrain how the categories behave. For reverse charge: a line, document-level allowance or document-level charge carrying that category requires a matching reverse charge entry in the VAT breakdown; the invoiced item VAT rate has to be present on such a line; and the VAT category tax amount in that breakdown is 0. For exempt supplies the rate is 0. For not-subject-to-VAT, the line does not carry a VAT rate at all — a distinction that is easy to lose when mapping from a system that treats exempt and out-of-scope as the same tax code.

Terms inside an optional group, in full

The 35 terms that are 1..1 inside an optional group. The path column shows which group has to be present for the structure to require them. Six of them are on the MoF's list, because a UAE rule requires them or their group on an ordinary tax invoice: the payment means type code, the seller and buyer tax scheme codes, the invoiced item tax category code and the two AED line amounts.

Foreign buyers and overseas receivers

The buyer electronic address (IBT-049) and its scheme identifier are on the mandatory path, so the document carries a buyer address regardless of where the customer sits. The UAE-specific rule set states that these rules are applied by UAE senders creating invoices, and that an overseas receiver without a specific receiving capability for UAE invoices applies only the shared PINT rules and may disregard the UAE-specific ones.

The practical reading is that the sending obligations sit with the UAE party. How a particular overseas customer receives the document — and whether they are reachable on the network at all — is a question for your service provider rather than something the specification settles for you.

Exceptions, credit notes and self-billing

The MoF's 51 describe a tax invoice. Several of the rules behind them name the cases where they do not apply, and those cases are where an ERP mapping most often needs more than one path:

• Credit notes. The payment due date and payment means type code are not required (IBR-127-AE, IBR-191-AE), and a credit note related to goods or services does not require the seller tax identifier (IBR-134-AE).
• Deemed supplies. Identified by the transaction type code, and likewise excepted from the payment due date and payment means rules.
• Nothing due. The payment due date is required only when the amount due for payment is greater than 0.
• Out of scope of VAT. This invoice type does not require the seller tax identifier, and requires the buyer legal registration identifier instead (IBR-136-AE).
• Exports. The buyer identifier or buyer tax identifier requirement in IBR-135-AE does not apply.
• VAT category. Exempt and not-subject-to-VAT lines handle the rate and VAT line amount in AED differently from standard-rated ones, as the rule table above sets out.

PINT AE publishes the invoice and credit note as separate transactions with their own semantic models and rule sets, so a credit note is a distinct document type rather than an invoice with a negative sign. Self-billing — where the buyer raises the document on the supplier's behalf — has its own specification, identified by different specification identifier and business process values, so a receiving system can tell what it has been sent without inferring it.

The field-level analysis on this page is the invoice transaction. Counts for the credit note differ, and should be read from its own semantic model rather than assumed from this one.

What this page does not cover

• The e-invoicing timeline, phases and who falls in scope — see the UAE e-invoicing connector page.
• Penalties for non-compliance, which are set by instrument rather than by the specification.
• How to select an Accredited Service Provider, and what the ASP does in the exchange.
• UBL element paths and XML syntax bindings, which are published per term in the specification itself.
• The code lists behind coded fields — unit of measure, VAT category, invoice type — which are versioned separately.
• Tax advice on how a particular supply should be categorised.

Frequently asked questions