MINSEONG.com
MINSEONG / GUIDES

How UAE eInvoices actually move: the 5-corner model, Tax Data reporting to the FTA and the PINT AE data standard

Published · Official sources last reviewed 22 October 2026; MoF Guidelines V1.1 read 24 October 2026 · 11 min read

Most UAE eInvoicing guides, including ours, focus on who is in scope, which deadline applies and what the ministerial decisions require. This guide answers a different question: what actually happens to an invoice once you press “send”? The Ministry of Finance (MoF) describes the UAE system as a decentralised exchange-and-reporting model with five “corners”, built on the Peppol network and a UAE-specific data standard called PINT-AE. Understanding that model makes it much easier to read your Accredited Service Provider (ASP) contract, design your integration and know which problems are yours to fix.

Everything below comes from two official MoF sources that we read directly: the MoF eInvoicing programme page and the UAE Electronic Invoicing Guidelines, Version 1.1 dated 01 June 2026. Where we have not verified a technical detail, we say so instead of guessing.

1. The five corners at a glance

The MoF Guidelines define the “5 Corner model” as the framework under which Electronic Invoices are issued and distributed in the UAE. The corners are:

  • Corner 1 (C1): the supplier. The business that sells and issues the invoice. In the decisions this party is the Issuer.
  • Corner 2 (C2): the supplier’s ASP. The accredited service provider the supplier has appointed.
  • Corner 3 (C3): the buyer’s ASP. The accredited service provider appointed by the buyer.
  • Corner 4 (C4): the buyer. The business or Government Entity that receives the invoice (the Recipient).
  • Corner 5 (C5): the Federal Tax Authority (FTA). The authority that receives tax data about each invoice.

The MoF programme page calls this model “Decentralized Continuous Transaction Control and Exchange” (DCTCE). “Decentralised” is the key word: invoices are not routed through a single government platform. They travel between the two businesses’ ASPs over the Peppol network, while the ASPs separately report tax data to the FTA. The Guidelines also state that each in-scope Person must appoint only one ASP, covering both sending and receiving Electronic Invoices.

2. Step by step: how an eInvoice travels

The MoF programme page lists ten steps. In summary, using its own terms:

  1. The supplier (C1) submits the eInvoice data (PINT AE) to its ASP (C2) in a format the two have agreed.
  2. C2 validates the data and, if it was received in another format, converts it into the UAE standard eInvoice XML format.
  3. C2 transmits the XML eInvoice to the buyer’s ASP (C3).
  4. In parallel, C2 reports a Tax Data Document (TDD) to the FTA (C5).
  5. After validating the eInvoice, C3 sends a Message Level Status (MLS) back to C2.
  6. C3 delivers the eInvoice to the buyer (C4) in a format agreed between them.
  7. If validation succeeded, C3 also reports a TDD to C5.
  8. C5 sends an MLS to C2 once the TDD has been reported successfully.
  9. C2 forwards to the supplier both the exchange MLS from C3 and the reporting MLS from C5.
  10. C3 forwards the reporting MLS from C5 to the buyer.

Section 5.1 of the Guidelines V1.1 describes the same flow in eleven steps, using plainer wording (“reports Tax Data”, “electronic confirmation”) and listing separately that the FTA also confirms to C3. The substance is the same: two ASPs exchange the invoice, both report tax data, and confirmation messages flow back to the supplier and buyer.

What happens if the buyer’s ASP rejects the invoice

Both MoF sources say that if C3’s validation of the eInvoice fails, C3 sends a negative status to C2 and to the FTA, and in that case C3 does not report tax data. We have not verified the official rejection codes, the legal effect of a rejection or how quickly a corrected invoice must be resent; agree that process with your ASP. Our system failure and continuity guide covers outages separately.

3. Peppol, PINT-AE and the Data Dictionary

Peppol is the network

Peppol is an international framework for exchanging electronic business documents, maintained by OpenPeppol, a non-profit association. The Guidelines define a Service Provider as an organisation authorised by OpenPeppol to access the Peppol Interoperability Framework, and list continued Peppol membership among the conditions an ASP must keep meeting. The MoF programme page notes that using this standard also allows eInvoices to be exchanged with businesses outside the UAE.

PINT-AE is the UAE document format

According to the Guidelines, PINT (Peppol International) is a family of technical specifications describing the format of business documents such as invoices and credit notes, which can be customised for national requirements while keeping cross-border interoperability. PINT-AE is the UAE version, and the Guidelines say the UAE’s requirements are defined in the corresponding Data Dictionary. Electronic Invoices are issued, transmitted and received in XML, and the Guidelines state that they will not carry a QR code or barcode.

The Guidelines say the detailed contents of an eInvoice, including mandatory and optional fields by document type and scenario, are set out in Peppol’s PINT-AE billing specifications published on Peppol’s website, where XML samples can also be downloaded. Separately, the MoF has published a UAE Electronic Invoice Mandatory Field Requirements document (V1.0, 23 February 2026). We have not reviewed the PINT-AE specification, the Data Dictionary or the mandatory-fields document in detail, so we do not state how many fields there are or which are mandatory. Use those documents and your ASP for that.

Identifiers that route the invoice

  • Participant Identifier. The Guidelines describe it as “0235” followed by your 10-digit Tax Identification Number (TIN). The TIN is the first 10 digits of your TRN; members of a VAT Tax Group use their own TRN, not the representative’s.
  • Buyer not yet on the system. The Guidelines specify the predefined endpoint 0235:9900000098 where the buyer has no Participant Identifier, 0235:9900000099 for exports where the buyer has no Peppol ID, and 0235:9900000097 as the buyer address for deemed supplies.
  • UUID. Each Electronic Invoice carries a unique identifier in addition to its sequential number; the Guidelines’ responsibility table assigns its generation to the ASP.

The Guidelines also state that businesses may not add their own optional fields into PINT-AE; industry-specific needs should be discussed with the ASP.

4. What your ASP does

Drawing on section 5.2 and Appendix 3 of the Guidelines, the ASP’s role includes:

  • validating the data you send, converting it into the UAE XML format where needed, and transmitting it securely with encryption;
  • looking up the buyer’s Peppol participant identifier and generating the UUID for each invoice;
  • reporting Tax Data for each Electronic Invoice to the FTA in a timely manner;
  • onboarding you to the Peppol network, providing your Participant Identifier and enabling testing;
  • keeping up with the latest specifications, retaining transactional logs of transmission statuses and routing, and notifying you and the FTA of service disruptions.

ASPs are accredited by the Ministry. The Guidelines V1.1 still refer to Ministerial Decision 64/2025 for accreditation, but that decision has since been repealed and replaced by Ministerial Decision No. 168 of 2026, in force from 1 October 2026. Our ASP accreditation guide under Decision 168/2026 explains the current rules, and the MoF keeps a list of eInvoicing Accredited Service Providers.

5. What stays with your business

Appointing an ASP does not transfer the legal obligation. A footnote to the Guidelines’ responsibility table says that ASPs carry out the exchange and reporting activities in practice, but the compliance obligation remains with the supplier (or the buyer, for self-billed invoices). According to the same table and Appendix 3, the business remains responsible for:

  • Calculating every invoice value. The ASP transmits; it does not decide your prices, tax categories or totals.
  • Collecting your buyers’ participant identifiers so you can invoice them.
  • Agreeing data security requirements with your ASP.
  • Making sure confirmations arrive for all Tax Data that must be reported to the FTA.
  • Keeping your details current in EmaraTax and with your ASP, for example when joining or leaving a Tax Group.
  • Retention. Appendix 4 says an ASP may store invoices for you by contract, but that delegation does not transfer your storage obligation under Article 11 of Decision 243/2025. See our record-keeping guide.

The underlying duties to issue, transmit, receive and report are set out in Decision 243/2025 as amended by Decision 197/2026; our Issuer and Recipient obligations guide (Article 6) walks through them.

6. How this fits with our other guides

7. Practical checklist

  • Confirm you have appointed one ASP for both sending and receiving, and that it appears on the MoF list.
  • Confirm your TIN and Participant Identifier, and those of each Tax Group member.
  • Collect participant identifiers from your main customers, and know which predefined endpoint applies when a buyer has none.
  • Agree with your ASP the input format you will send (the “agreed format” in step 1).
  • Ask your ASP how you will receive both statuses: exchange from the buyer’s ASP and reporting from the FTA.
  • Decide who monitors negative statuses and how corrected documents are reissued.
  • Get the current PINT-AE specification, Data Dictionary and MoF mandatory-fields document, and map your data against them.
  • Agree data security, storage and outage-notification responsibilities in the ASP contract.
  • Test the full flow, including tax data reporting confirmations, before go-live.

8. Frequently asked questions

Do I send invoices directly to the FTA?

No. In the model the MoF describes, your ASP reports Tax Data to the FTA on your behalf and forwards the FTA’s confirmation to you.

Does a PDF emailed to my customer count?

No. The MoF programme page states that unstructured formats such as PDF, Word documents, images, scans and emails are not eInvoices. The Guidelines note that a separate Tax Invoice (for example a PDF) may still be needed for a buyer that has not yet implemented eInvoicing.

Can my supplier and I use different ASPs?

Yes. That is the point of the model: the supplier’s ASP (C2) and the buyer’s ASP (C3) exchange documents over Peppol. Members of the same Tax Group may also onboard with different ASPs, according to the Guidelines.

How many fields does PINT-AE have?

We have not verified this. The field list and which fields are mandatory are in the PINT-AE specification, its Data Dictionary and the MoF mandatory-fields document.

If my ASP fails to report, am I still responsible?

The Guidelines say the compliance obligation remains with the supplier (or buyer for self-billing). How the FTA would treat a specific ASP failure is not something we have verified; see our penalties guide and take advice.

9. What we have not verified

  • the content, version history and field count of the PINT-AE specification and the UAE Data Dictionary;
  • the contents of the MoF mandatory-fields document;
  • the message formats, codes and timing of MLS and TDD messages, and any time limits for reporting;
  • the legal effect of a rejected or unreported invoice and any resubmission period;
  • whether the Guidelines V1.1 will be revised to reflect Decision 168/2026 and Decision 197/2026.

Important notice

This guide is general information prepared by MINSEONG.COM, an independent website. It is not legal, tax or technical advice and it is not an official government publication. It summarises official MoF material as read on the dates shown, and rules and specifications may change. Always check the current Ministry of Finance and FTA publications, follow your ASP’s documentation and consult a qualified UAE tax adviser before making decisions. You can also run our free eInvoicing readiness check or browse all our guides.