The UAE e-invoicing system uses the Peppol five-corner model. The seller (corner 1) sends an invoice through its Accredited Service Provider (corner 2) to the buyer's provider (corner 3), which delivers it to the buyer (corner 4), while both providers report tax data to the tax authority (corner 5). The model is called DCTCE and uses the PINT AE data format.
The five corners
| Corner | Who | Role |
|---|---|---|
| 1 | Seller (supplier) | Creates the invoice data in its system |
| 2 | Seller's ASP | Converts, validates and sends the invoice; reports tax data |
| 3 | Buyer's ASP | Receives the invoice and passes it on; reports tax data |
| 4 | Buyer | Receives the invoice in its system |
| 5 | Tax authority | Receives tax data from both providers and checks it |
In the UAE, secondary guides describe corners 2 and 3 as Accredited Service Providers, and corner 5 as the Federal Tax Authority, which receives the tax data from both. The Ministry of Finance oversees the scheme and the FTA monitors tax compliance; sources describe the split of roles differently, so use the official announcements for the exact allocation.
How one invoice travels
- Your system creates the invoice data.
- Your ASP checks it against the rules and converts it to the structured format.
- The invoice goes over the Peppol network to the buyer's ASP.
- The buyer's ASP delivers it to the buyer.
- Both ASPs send tax data to the authority.
- Acknowledgements and status messages return along the same path.
Why it is called DCTCE
DCTCE is the name the UAE gives its model, and sources expand the abbreviation in different ways. It is a model in which invoices are validated and tax data is reported close to real time as part of the exchange, rather than after the period ends. The UAE chose a decentralised approach, in which providers exchange invoices directly, and the authority receives a copy of the tax data. This differs from a model where every invoice is first cleared by a central government platform.
PINT AE: the data format
Invoices follow PINT AE, the UAE customisation of the Peppol International invoice model. Guides describe it as structured XML based on UBL 2.1, with a data dictionary that sets mandatory, conditional and optional fields, validation rules and code lists. A PDF is not enough: a PDF may be shown to humans, but the structured data is what counts. See mandatory fields.
What it means for your business
- You cannot send an invoice from your system directly to a customer and call it an e-invoice; it must go through an ASP.
- Your customer data must include the identifiers the network needs, such as tax registration numbers.
- Errors are caught at the point of sending, so data quality must be good before the invoice is created.
- Credit notes and corrections follow the same path.
- You will keep records of the structured invoices as well as any PDF copies.
How to prepare
Start with your master data: customer names, tax numbers, addresses, product codes and units. Then map your invoice scenarios to the data dictionary. Then choose your provider; see how to choose an ASP. The dates are covered in the ASP deadline guide and the timeline.
Why a decentralised model
In a centralised clearance model, each invoice is sent to a government platform for approval before it goes to the buyer. In the UAE's decentralised approach, the sellers' and buyers' providers exchange invoices directly over the Peppol network and send the tax data to the authority. Advocates of this design point to lower load on a central system, use of an open international standard and easier connection for businesses that already trade with Peppol-enabled partners. The trade-off is that data quality checks sit with providers, so providers' validation is a key control.
Network identifiers
In a Peppol exchange, each business is addressed by an identifier registered with its provider, so the sender knows where to deliver the invoice. Your provider will explain which identifier is used for UAE businesses and how to register it. Make sure the identifier your customers hold for you matches the one registered. A mismatch is a common reason for a delivery failure in other Peppol countries and is worth testing early.
Messages and status
The exchange is not a one-way send. Providers pass back messages that say whether the invoice was received, accepted or rejected, and the authority acknowledges tax data. Your finance team needs a way to see these statuses and a rule for how fast rejected invoices are fixed and resent. Without that rule, invoices can sit in a rejected state while the customer waits to pay.
Where the UAE sits among e-invoicing models
Several countries use central clearance, others use post-audit reporting and some use the Peppol network. The UAE has chosen the Peppol-based five-corner exchange with real-time tax reporting. If you operate in more than one country, treat each country's model separately, because the data format, provider rules and deadlines differ.
Frequently asked questions
A model in which the seller and buyer exchange invoices through their own access points, with the tax authority receiving tax data as the fifth party.
The seller's and buyer's Accredited Service Providers.
The name of the UAE e-invoicing model, in which invoices are exchanged and tax data is reported close to real time.
The UAE customisation of the Peppol international invoice data model, used for the structured e-invoice.
No. The structured data file is the e-invoice. A PDF may be a human-readable copy.
The Ministry of Finance oversees it, and the FTA monitors tax compliance. Sources describe the split differently, so check official announcements.