PINT AE Mandatory Fields and Validation Rules

Quick answers

What is PINT AE?

PINT AE is the UAE profile of the Peppol International Invoice standard, built on UBL 2.1. It defines the structure every UAE electronic invoice must follow, and it is what your invoice is validated against before it reaches the buyer.

How many mandatory fields does a UAE e-invoice have?

Around 51 for a standard tax invoice, spread across six groups. A commercial invoice carries fewer, since the VAT-specific elements do not apply.

What does conditional mean in PINT AE?

The field becomes mandatory when a specific scenario applies, such as a free zone supply or a reverse charge. Conditional fields are where most validation failures originate.

Where do invoices actually fail validation?

Validation happens at your accredited service provider, before transmission. There is no manual override and no partial acceptance — an invoice either passes or is rejected in full.

Do I need to implement PINT AE myself?

Only if you are building your own integration. If you use invoicing software, your provider handles the mapping — what you are responsible for is capturing the underlying data.

Three obligation levels, not one

Every data element in the dictionary carries one of three levels.

Mandatory means the element must be present in every invoice of that type. Its absence fails validation.

Conditional means it becomes mandatory when a particular scenario applies — a free zone supply, a reverse charge, a margin scheme. This is where most implementation errors live, because a field that is optional in your usual transactions becomes required in an unusual one, and nobody notices until an invoice is rejected.

Optional means what it says.

The dictionary defines well over a hundred elements in total. For a standard tax invoice, around 51 of them are mandatory.

The six groups

A commercial invoice — one that is not a tax invoice — carries a smaller set, because the VAT elements that make a tax invoice a tax invoice do not apply.

Business terms and why they look like ibt-001

Fields in the dictionary are identified by business term codes rather than by name — the invoice number is ibt-001, the issue date ibt-002, the invoice type code ibt-003. The naming comes from the European standard the Peppol model is built on.

This matters when you map your own system: your ERP field is matched to a business term, not to a label. Two systems calling a field "invoice date" may be populating different business terms, and that discrepancy only surfaces at validation.

The code lists

Several fields do not accept free text. They accept values from a published list, and a value outside that list fails validation even when it looks correct.

Currency follows ISO 4217. Units of measure follow UNECE Recommendation 20. Participant identifier schemes follow ISO 6523. The UAE code is 0235.

The UAE also defines a transaction type code specific to this profile — an eight-digit binary string flagging special features such as a free zone supply or a margin scheme. It is not derived automatically: your system has to identify the feature before it can set the flag, which means the classification logic sits upstream of invoice generation.

Where invoices actually fail

Validation happens at your accredited service provider, before transmission. There is no manual override and no partial acceptance — an invoice either passes or is rejected in full.

The failures that recur are not exotic.

A conditional field left empty because the scenario was not recognised. A code value that is close but not exact. A total that does not reconcile with the sum of its lines to the cent. A TRN missing on a transaction where it was conditionally required. A unit of measure entered as free text.

None of these is difficult to fix. All of them are difficult to find after the fact, which is the argument for validating in a provider's test environment before go-live rather than discovering the pattern in production.

Versions change

Both the Peppol PINT AE specification and the Ministry's mandatory field document have been revised since first publication, and further revisions should be expected as the mandate progresses.

Any field list published outside the Ministry — including a summary like this one — can fall behind. Before implementation work, take the current version from the Ministry of Finance rather than from a secondary source.

What this means if you are not building an integration

If you use invoicing software rather than writing your own XML, none of the above is yours to implement. Your provider maps your data to the specification.

What remains yours is the data. A specification cannot invent a buyer TRN you never captured, or an emirate you never recorded, or a unit of measure your catalogue does not hold. The most common reason a business fails validation on day one is not a technical gap — it is that the fields were never collected in the first place.

Where Fatura Go fits

Fatura Go does not generate PINT AE XML and does not transmit invoices. That requires an accredited service provider.

What it does is keep the underlying data in the shape the specification expects: supplier and buyer TRNs, addresses, emirate, line-level VAT with the rate category recorded per line, and totals that reconcile. Whichever provider you eventually onboard with, that is what they will be mapping from.

Frequently asked questions