UAE E-Invoicing: Getting Your System Ready for the Five-Corner Model

Your system in the UAE will never connect to the Federal Tax Authority. It connects to one intermediary, an Accredited Service Provider (ASP), which converts your data into the official format, delivers it to the buyer's provider, and reports the tax data to the Authority on your behalf. That architectural difference is what separates the UAE system from its Egyptian and Saudi counterparts, and every technical decision you are about to make follows from it.

This guide is for whoever owns an ERP, an online store or an in-house invoicing application that issues invoices in the UAE, and needs to know what to build, what to change, and what not to build at all. The detail of UAE e-invoicing changes faster than most compliance topics, so every date, field and figure below comes from a decision or document published on the Ministry of Finance portal or from the official Peppol specifications, read on 21 September 2026. The Ministry states on that same page that its portal is the only official source of information about the programme.

The dates in force today, and where to take them from

The timeline has already changed, and this is where most of the errors are. Ministerial Decision No. 244 of 2025 set the original dates around a revenue threshold of AED 50 million. Ministerial Decision No. 66 of 2026 then replaced exactly one paragraph of it: the ASP appointment date for the first group. This is what applies now:

The original date for the first group was 31 July 2026, and that is still the date printed in the phase table inside the UAE Electronic Invoicing Guidelines, version 1.1 of 1 June 2026. The Ministry's own guidance document has not been updated since the amendment, so anyone reading the PDF, or an article that copied it, walks away with a date that no longer applies. Follow the text of the decision, not the table in the guide.

"Revenue" in the decision means gross income earned in the most recent accounting period, taken from financial statements prepared under the legislation in force in the State, or from other documentation the Authority accepts when statements are unavailable. Read your threshold off your last set of accounts, not off a sales forecast.

Alongside the mandatory track, two routes opened on 1 July 2026: a pilot programme the Ministry invites you into and which requires your written agreement, and voluntary implementation open to anyone regardless of revenue. Volunteering carries a legal consequence that is easy to miss. A person who implements voluntarily is bound by all provisions of the system as a matter of obligation, except the decisions on violations and penalties, so e-invoicing fines do not apply before that person's own mandatory date arrives.

If you sit inside a VAT group, transactions between members of the same group get a grace period of 24 months starting 1 January 2027, per the Guidelines. The grace period defers compliance only. It does not take intra-group transactions out of scope, and your transactions with parties outside the group are still due on your normal date.

Where your system sits in the five-corner model

The UAE model is Decentralized Continuous Transaction Control and Exchange, abbreviated DCTCE, and it has five corners: the supplier, the supplier's ASP, the buyer's ASP, the buyer, and the Federal Tax Authority. Your system is corner one, and nothing else.

The cycle as the Guidelines describe it: your system sends invoice data to your provider in whatever format the two of you agreed. The provider validates it and converts it into the UAE standard XML invoice if it arrived in another format, then transmits it to the buyer's provider while reporting tax data to the Authority in parallel. The buyer's provider validates in turn, returns an electronic confirmation, delivers the invoice to the buyer in the format those two agreed, and reports to the Authority. If its validation fails, it confirms that electronically to both the supplier's provider and the Authority, and no tax data is reported for that invoice. Confirmations then travel back through both providers to the two parties.

What matters to you in that cycle is the division of labour, because it decides what you write. The Guidelines assign the calculation of all invoice values to the supplier, not the provider, and collecting the buyer's Peppol participant identifier to the supplier as well. The provider handles encryption in transit, the participant lookup on the network, and generating a UUID for every invoice so the same one cannot be duplicated. Put plainly: do not write a UUID generator or a transport encryption layer into your system. Write a field to store what comes back, and a way to capture and keep each customer's identifier.

Choosing an accredited service provider

The Ministry of Finance publishes the list of accredited service providers and refreshes it periodically. When it was checked on 21 September 2026 it carried an update stamp of 17 September 2026 and listed 54 accredited providers, each with a published accreditation number, plus 8 pre-approved providers still going through the final production assessment. The distinction is practical: pre-approval is not accreditation, so confirm the accreditation number before you sign anything.

Three rules govern the choice.

1. One provider only. The Guidelines require a single ASP for both sending and receiving, which is to say for receivables and payables at once. Do not split the flow between two providers.
2. Onboarding starts with you. The person or entity initiates onboarding through the Authority's EmaraTax platform, not the provider. Before you start, check that your trade licence, address and contact details in EmaraTax are current.
3. Each VAT group member onboards separately. Every member has its own tax identification number, from which its network identifier is derived, and members may onboard with different providers.

As for what to ask a provider before signing, the Ministry published Considerations for Selecting an Accredited Service Provider, and its questions are blunt: is the product the provider's own or a third party's? Who actually provides support? What are the service level agreements for response time and uptime? Where is the data stored? Is pricing a subscription or per transaction? The document adds one contractual point worth pinning down: under Ministerial Decision No. 64 of 2025 a provider is committed to 100 free eInvoice exchange and reporting services a year, starting from the date the end-user agreement is signed, and the Ministry recommends writing that into the contract.

On the provider's own capability, Ministerial Decision No. 56 of 2026 amended the accreditation criteria. A provider may use a product owned by a third party, or outsource its development and operation, but retains full responsibility, and the product must have been in operation for at least two years.

The fields and identifiers that must be right before any integration

Most integration projects stall on data, not on APIs. Start with the identifiers.

• The Tax Identification Number (TIN) is the first 10 digits of the 15-digit Tax Registration Number (TRN). Anyone in scope who is not required to register for any tax type must still register with the Authority to obtain a TIN.
• The Peppol participant identifier is the fixed value 0235 followed by the TIN. In the mandatory-fields document this appears as two fields: a seller electronic identifier holding 0235, and a seller electronic address holding the TIN.
• Inside a VAT group, the TIN comes from your own TRN, not the group representative's. This single mistake is enough to fail onboarding.
• The legal registration identifier type is one of four values: TL for a trade licence, EID for an Emirates ID, PAS for a passport, CD for a Cabinet Decision. Add that field, and the identifier itself, to your customer table and to your own company record.

Then move to the fields. The mandatory field requirements published on 23 February 2026 set out two lists: 51 mandatory fields for an electronic tax invoice and 49 for a commercial electronic invoice, spread across invoice details, seller, buyer, document totals, tax breakdown and invoice lines. One of them has no equivalent in off-the-shelf systems: the invoice transaction type code, a string of eight flags, each 1 or 0, standing in order for free zone, deemed supply, margin scheme, summary invoice, continuous supply, disclosed agent billing, supply through e-commerce, and exports. Your system computes those flags from the nature of the transaction, so make room for them in the data model early.

At line level the tax category is mandatory, and it is one of six: standard rate, exempt from VAT, outside the scope of VAT, reverse charge, zero rated, and margin scheme.

The format itself is XML under the PINT AE specification, and the invoice carries no QR code and no barcode, unlike anything your team may have built for the Saudi system. At the time of review the version published on the UAE electronic document specifications page was 1.0.4 for Billing, Self-Billing and the UAE Tax Data Document, inside PDK 1.4.4 released on 29 July 2026, and the customization identifier carried by the document is urn:peppol:pint:billing-1@ae-1. Put a recurring review of that page in your plan, because the specification moves in small releases.

The cases that break off-the-shelf systems

The general rules are easy. What breaks implementations is the edge cases, and most of them are written down in the Guidelines.

• The buyer is not on the system yet. Do not leave the address field empty and do not invent a value. The Guidelines require the predefined endpoint 0235:9900000098, together with a regular PDF tax invoice for the buyer alongside the electronic one, since they still need a document they can read.
• Export to a buyer with no Peppol ID. The predefined endpoint here is 0235:9900000099.
• Deemed supply. The buyer electronic address is always 0235:9900000097 and does not change with the supplier. Where no invoice is issued to the recipient at all, there is no exchange, only reporting to the Authority by the supplier's provider.
• Free zones. The invoice needs beneficiary details in addition to the customer's. Where both are the same entity, the customer details are duplicated into the beneficiary fields.
• Margin scheme. Although the specification requires VAT information to be present, the Guidelines state that the VAT amount displayed should be 0 in this case.
• A summary invoice whose net turns negative. No negative invoice is sent; the transaction is documented with an electronic credit note instead.
• Retention in milestone contracts. The milestone calculation and the retained amount belong in a separate commercial document and must not appear on the electronic invoice. When the retained amount falls due, an electronic tax invoice is issued with the VAT applicable.
• Advance payments. A tax invoice is issued when the advance is received, and the final invoice then covers only the remaining balance, with a reference back to the earlier invoice.

Two small details cause repeated rejections. Rounding applies to the invoice total, to two decimal places, and not at tax-category or line level. And invoices in a currency other than the dirham must still carry the gross total including VAT in AED in the tax accounting currency field, at the rate approved by the Central Bank.

One last rule will save your team a long argument: you are not allowed to add your own optional fields to PINT AE. If you carry an internal classification that has to appear on the invoice, discuss it with your provider within the existing fields rather than trying to extend the specification.

Credit notes, returns and corrections

Ministerial Decision No. 243 of 2025 limits electronic credit notes to four cases: the transaction is cancelled, the agreed consideration is reduced for any reason, the consideration is returned in full or in part, or an administrative or numerical error has occurred. Note that the administrative or numerical error stands on its own, so correcting an invoice after it has been transmitted goes through a credit note rather than an edit to the original.

At implementation level, one credit note may reference several earlier invoices, and a credit note may cover part of an invoice rather than all of it. If your system enforces a strict one-to-one link between a credit note and an invoice, that is the first thing you will change.

Failure, rejection and archiving

This is where the legal text turns into deadlines inside your code.

The "date of the business transaction" is defined as the earlier of the date the transaction occurred and the date payment was received, so compute it on that basis rather than on the date the document was created in your system.

The penalties are published in Cabinet Decision No. 106 of 2025: AED 5,000 for each month or part of a month of delay in implementing the system or appointing a provider; AED 100 for each electronic invoice and each electronic credit note not transmitted on time, capped at AED 5,000 per calendar month; and AED 1,000 for each day of delay in reporting a system failure or a change of data. Note that the daily penalty has no published ceiling, so ignoring an alert for a week can cost more than the late invoices themselves. Route failure alerts to a named person, not to a shared mailbox.

On storage, Article 11 of MD 243 requires electronic invoices, credit notes and associated data to be kept "within the State" for the periods set out in the Tax Procedures Law. Version 1.1 of the Guidelines clarifies that phrase in a way that changes your architectural decision: what is required is that the records remain retrievable and can be produced to the Authority complete and readable on request, "irrespective of the geographic location of the servers, databases, or cloud-based solutions used to store them". The test is availability, not localisation. The periods, per the Guidelines, are five years following the tax period for a taxable person, five years from the end of the calendar year for everyone else, and seven years for real estate records, with four more years during a dispute or an ongoing audit, and one more year from a voluntary disclosure submitted in the fifth year after the relevant tax period. A provider may store on your behalf under a contractual arrangement, but the legal obligation stays with you.

In practice this means your system needs a document-status table recording what was sent and when, the confirmation messages that came back from the provider for both exchange and reporting, and the reason for any rejection. Without that log you cannot evidence compliance, nor work out what has to be re-sent once an outage ends.

How this differs from Egypt and Saudi Arabia

If you run one system across more than one market, the differences are structural rather than cosmetic.

A fourth difference concerns item data: Egypt requires goods and services to be coded against approved code sets as a condition of joining, while HSN codes in the UAE remain optional for now.

The practical summary for a development team: in Saudi Arabia and Egypt you build an API client that talks to a government body, and you carry the certificates, stamps and document sequencing that come with it inside your own system. In the UAE you build one integration to a service provider, so there is less to build and more to select and contract for. For those working in the other two markets, we covered the requirements in detail in the second phase of Saudi e-invoicing and integration with Fatoora and connecting your system to the Egyptian e-invoice platform.

What has not been announced yet

Four items were still open as at 21 September 2026, and none of them should be built on a guess.

• Business-to-consumer transactions stay out of scope until a decision is issued by the Minister, in the words of MD 244 itself. A business selling only to end consumers is not subject to the system today.
• The category of Excluded Persons is left to a decision by the Minister that does not appear among the published legislative documents.
• HSN codes are optional for now, and the Guidelines say the timeline for making them mandatory will be announced in due course.
• The deadline for reporting tax data to the Authority was referred by MD 243 to a decision by the Minister, and no separate decision setting it has been published. The published framework has providers report in parallel with transmission.

One practical note for an Arabic-speaking team: the Guidelines, the mandatory fields document and the provider selection document are published in English only, as the Ministry's Arabic page states outright. The legislative texts themselves are available in Arabic.

A short plan of action

1. Identify your group from your financial statements, and take the two dates that apply to you from MD 244 as amended.
2. Review your entity details in EmaraTax, confirm you have a TIN, and derive the participant identifier you expect to be issued.
3. Audit the customer table: tax registration numbers, legal identifier types, addresses at the right levels, and a Peppol identifier for each customer. This is usually the longest task in the project, and the best time to start it is now.
4. Run a gap analysis between what your system generates today and the mandatory field list, including the transaction type code and the tax categories.
5. Pick a provider from the official list after verifying its accreditation number, and pin down the service levels, the 100 free transactions clause and the storage arrangements in the contract.
6. Test the full cycle: transmission, exchange, reporting, success and failure confirmations, and receiving your own suppliers' invoices.
7. Agree an error-handling governance model with the provider before go-live, not after.

Anyone running a custom system will find that most of the work sits in the layer closest to their data: cleaning customer records, adding identifier fields, computing the transaction type code, and building the status and confirmation log. Those are estimable with real precision once the gap analysis is done.

If you run an ERP, a store or an invoicing application that issues invoices in the UAE, send the Snaabble team a description of the invoice data your system produces today. We will check it against the mandatory field list and come back within 24 hours with a scope, a duration and an expected cost, at no charge and with nothing owed.

Frequently asked questions

Do I have to do e-invoicing if I am not registered for VAT?

Yes. The Ministry of Finance Guidelines state that the system is mandatory for any person conducting business in the State regardless of their VAT registration status, and regardless of whether they are established in the UAE, unless a specific exclusion applies. Anyone in scope who is not required to register for any tax type must still register with the Federal Tax Authority to obtain a Tax Identification Number, from which their network identifier is derived.

Can I contract with more than one accredited service provider?

No. The Guidelines require a single provider for both sending and receiving. The only nuance is that each member of a VAT group onboards separately, and members may choose different providers from one another.

Do I stop issuing PDF invoices to my customers?

Not yet. An electronic invoice is an XML file, and a buyer who has not implemented the system still needs a regular tax invoice alongside it, such as a PDF, to support input tax recovery or their own accounts. In that case the predefined endpoint 0235:9900000098 must be included on the electronic invoice.

What happens if my system goes down before invoices are transmitted?

Ministerial Decision No. 243 of 2025 requires the Authority to be notified of a system failure within 2 business days of it occurring, and the penalty for late notification is AED 1,000 for each day or part of a day. Once service resumes, the provider exchanges and reports the pending invoices, and it is your responsibility to confirm from your own status log that nothing was left behind.

Sources

• eInvoicing portal, UAE Ministry of Finance, accessed 21 September 2026 (page last updated 17 September 2026)
• Ministerial Decision No. 243 of 2025 on the Electronic Invoicing System
• Ministerial Decision No. 244 of 2025 on the Implementation of the Electronic Invoicing System
• Ministerial Decision No. 66 of 2026 amending Decision No. 244
• Ministerial Decision No. 56 of 2026 amending Decision No. 64 on service provider accreditation
• Cabinet Decision No. 106 of 2025 on violations and administrative penalties
• UAE Electronic Invoicing Guidelines, version 1.1, 1 June 2026
• UAE Electronic Invoice Mandatory Field Requirements, version 1.0, 23 February 2026
• Considerations for Selecting an Accredited Service Provider
• eInvoicing Accredited Service Providers list
• United Arab Emirates electronic document specifications (PINT AE), OpenPeppol
• Conditions for joining the e-invoice platform, Egyptian Tax Authority
• E-invoicing roll-out phases, Zakat, Tax and Customs Authority
• E-invoicing Detailed Technical Guidelines, Zakat, Tax and Customs Authority