UAE e-invoicing: what enterprises need to have in place

The obligation, in one page

Under the UAE electronic invoicing system, invoices between businesses are exchanged in a structured format through accredited providers, and reported to the authority as part of the same movement. The paper or PDF document stops being the invoice. A structured data file becomes the invoice, and the document a person reads becomes a rendering of it.

Three instruments carry the detail. Ministerial Decision No. 243 of 2025 sets the electronic invoicing system itself. Ministerial Decision No. 244 of 2025 sets the scope and the phased dates. Cabinet Decision No. 106 of 2025 sets the penalties that attach to both.

The practical consequence is that an invoice becomes correct or incorrect at the moment it is created in a source system, rather than at the moment someone reviews it.

The five-corner model, and what it changes

The UAE model is built on Peppol. Five parties take part in each exchange, and the fifth is the one that changes how an enterprise has to work.

1. 01

   The supplier

   Creates the invoice in its own source system and passes it to its accredited provider.

2. 02

   The supplier’s provider

   Converts it to the required structured format, validates it against the rule set, and sends it on.

3. 03

   The buyer’s provider

   Receives the invoice on the network and delivers it to the buyer.

4. 04

   The buyer

   Receives structured data into its own system rather than a document into an inbox.

5. 05

   The authority

   Receives the reported data as part of the same movement, not afterwards and not on request.

Because the fifth corner receives the data as the transaction moves, the window in which an enterprise can notice and correct something closes to roughly the time it takes to send an invoice.

What the invoice has to carry

A structured invoice is accepted or rejected by rules, and rules read fields. Each field has to be populated from somewhere in the enterprise, which turns a tax requirement into a data requirement.

Most of this exists already in some form. The question is rarely whether a business holds the data, and almost always whether it holds it in one place, in a usable state, for every counterparty rather than the frequent ones.

Where the work actually sits

The obligation arrives addressed to the tax function and is discharged almost entirely outside it. Mapping the work honestly at the start is what separates a programme that lands from one that discovers its dependencies late.

An exception that nobody owns is the most common failure in the first month after go-live. It is also the cheapest to design for beforehand.

Choosing a provider

Accreditation establishes which providers are eligible. It does not establish which one fits a particular enterprise, and the published list is deliberately silent on that question.

The decision is better treated as part of the operating model than as a procurement exercise. The provider shapes how invoice data leaves the ERP, how it is validated, how statuses come back, how exceptions surface, how data is retained, and how easily a business can move later.

The checklist below sets out the questions we would put to any provider under evaluation, and the evidence to ask for against each.

What to settle in the next ninety days

None of this requires the specification to be final. All of it is work that holds whatever version is current when a business goes live.