Peppol and the UAE 5-corner model

What is Peppol, and why does the UAE use it?

Peppol stands for Pan-European Public Procurement Online. It is a framework of specifications and agreements for exchanging business documents such as e-invoices, maintained by OpenPeppol, an international non-profit association, and documents travel on it between service providers that OpenPeppol has authorised. Those are the definitions in the Ministry of Finance's Guidelines.

The Ministry's e-invoicing page names one benefit of that choice: by adopting a proven standard such as OpenPeppol, businesses gain access to a wider network and can exchange e-invoices with businesses outside the UAE. The UAE rules sit in PINT AE, which the Mandatory Fields V1.1 call the Peppol United Arab Emirates electronic document specification. It allows national requirements while keeping e-invoices interoperable across regions.

You do not join Peppol yourself. Under MD 243/2025, the issuer and the recipient of an e-invoice meet their exchange and reporting obligations through an accredited service provider they appoint (Art. 6(7)), and the Ministry publishes the list of accredited providers (Art. 5(2)). Each ASP must keep its Peppol membership to stay accredited (Guidelines V2.0, Appendix 3).

Sources: ^[1][2][4][3]

How does an e-invoice move through the five corners?

In eleven steps, set out in §5.1 of the Guidelines V2.0. Steps 1 to 3 move the e-invoice from you to your buyer's ASP; the rest deliver it, report tax data and send confirmations back. The diagram groups the steps by the link they travel on, and the list under it gives each step in order.

1. Corner 1, the supplier, submits the e-invoice data to its ASP in an agreed format.
2. Corner 2 validates the data and, if it arrived in another format, converts it into the UAE standard e-invoice in XML.
3. Corner 2 transmits the XML e-invoice to the buyer's ASP, corner 3.
4. In parallel, corner 2 reports tax data to the FTA, corner 5.
5. Once it has validated the e-invoice, corner 3 sends an electronic confirmation to corner 2.
6. Corner 3 delivers the e-invoice to the buyer, corner 4, in a format the two of them agreed.
7. If validation succeeded, corner 3 also reports tax data to corner 5. If it failed, corner 3 confirms that to corners 2 and 5, and reports no tax data.
8. Corner 5 confirms to corner 2 that the tax data was successfully reported.
9. Corner 5 confirms the same to corner 3.
10. Corner 2 forwards the confirmations it received to corner 1.
11. Corner 3 forwards the confirmations it received to corner 4.

The Ministry's e-invoicing page tells the same flow in ten steps and names the two kinds of message: the tax data sent to the FTA is a Tax Data Document (TDD), and each confirmation is a Message Level Status (MLS).

Sources: ^[1][2]

What does DCTCE mean?

DCTCE is the Ministry of Finance's name for the UAE model: Decentralized Continuous Transaction Control and Exchange. The Guidelines describe the same framework as a modern approach that leverages decentralized technologies.

The official texts do not explain the name word by word, but the steps show what it describes. Decentralized: the e-invoice travels from your ASP to the buyer's ASP (step 3), not through the FTA, which receives tax data from both ASPs (steps 4 and 7). Continuous transaction control: tax data for each individual e-invoice reaches the FTA in a timely manner, as Appendix 3 asks of ASPs, and the Ministry says this reporting will help pre-populate certain fields of the VAT return. Exchange: the e-invoice itself passes from supplier to buyer through their two ASPs (steps 1, 3 and 6).

Sources: ^[2][1]

What is a Tax Data Document (TDD)?

It is the tax data an ASP reports to the FTA for an e-invoice. The Ministry's page calls it the Tax Data Document (TDD); the Guidelines define the content, Tax Data, as information required for tax reporting and compliance, including tax registration numbers, transaction details and tax amounts payable.

One e-invoice is reported from both sides. Your ASP reports it in parallel with sending the invoice (step 4), and the buyer's ASP reports it once the invoice passes its validation (step 7). If the buyer's ASP rejects the invoice, it reports no tax data and tells your ASP and the FTA instead.

You do not build the TDD; in practice your ASP produces and reports it. The obligation stays with you, though: the Guidelines note that ASPs carry out exchange and reporting while the compliance obligation remains with the supplier (§5.2). Appendix 4 adds that your ASP must tell you, event by event and without undue delay, when e-invoices and Tax Data Documents have reached the Authority (§16.2.4).

Sources: ^[2][1]

What are status messages (Message Level Status)?

They are the electronic confirmations that travel back along the chain, and the Ministry calls each one a Message Level Status (MLS). The buyer's ASP sends one to your ASP after validating the e-invoice (step 5), or a negative one to your ASP and the FTA if validation fails (step 7). The FTA sends one to each ASP once the tax data is reported (steps 8 and 9). Each ASP then forwards what it received to its own client (steps 10 and 11).

Receiving them is part of your job, not an extra. The Guidelines list exchange and reporting, including receiving confirmation messages, among the supplier's responsibilities (§5.2), and Appendix 1 asks you to agree with your ASP how you will receive the messages on the exchange and on the tax-data reporting, and to test both (§13.3). Appendix 3 adds that you should make sure your ASP confirms all the tax data that must reach the FTA.

A negative status means the e-invoice did not complete the exchange. Find out from your ASP why it failed and how a corrected invoice is sent again, then fix the data at its source, in your accounting system, so the next invoice does not fail the same way.

Sources: ^[2][1]

Where does a connector sit in the five corners?

On your side, inside corner 1. Step 1 has the supplier submit invoice data to its ASP in an agreed format, and step 2 lets the ASP convert it to the UAE XML when it arrives in another format. Getting data out of your accounting system and into a format your ASP accepts is therefore a corner-1 task. Your ERP vendor's own e-invoicing option, your ASP's tools or connector software can each do it.

A connector is not a sixth corner and not a Peppol service provider. It does not exchange e-invoices with other ASPs or report tax data to the FTA; those remain your ASP's work. And the compliance obligation stays with you whoever moves the data (Guidelines §5.2).

Appendix 1 describes the same work in project terms: agree with your ASP how the data for each invoice will be shared, integrate your applications with the ASP's systems in time, and test the whole exchange before go-live (§13.3).

Sources: ^[1][2]

What does the buyer's side need?

Its own ASP and a Peppol Participant Identifier. MD 243/2025 asks the recipient, like the issuer, to appoint an accredited service provider (Art. 5(1)) and to process e-invoices through the e-invoicing system (Art. 6(3)). The Participant Identifier is 0235 followed by the buyer's 10-digit TIN, the first 10 digits of its own TRN, and the ASP shares it once onboarding is complete (Guidelines V2.0, important terms and Appendix 3).

Collecting that identifier is your job as the supplier: the Guidelines list contacting the buyer and gathering its Peppol Participant Identifier under the supplier, and looking it up under the ASP (§5.2).

Until a buyer is on the system, you still issue the e-invoice. Where the buyer has not implemented e-invoicing and has no Participant Identifier, the supplier puts the predefined endpoint 0235:9900000098 on the e-invoice, and for a tax invoice the supplier must also give such a buyer a regular tax invoice, for example a PDF (§10.2.2). For an export to a receiver that is not registered on Peppol, the value is 0235:9900000099. Neither is used on its own: each goes with the transaction classification and the buyer's status (§18.3.3).

Sources: ^[3][1]

Where Vattora fits, and when you do not need it

Vattora is connector software for corner 1. It reads posted invoices and credit notes from your accounting system, builds each one as a checked PINT AE e-invoice, hands it to the ASP you appointed and shows you the status messages that come back. Vattora connects to the ASP you choose through that provider's API; each link is built and tested in the provider's test environment before your first real invoice. It is not an ASP, not a Peppol service provider and never a corner. You do not need it if your accounting system or your ASP's own tools already deliver your invoice data in a format your ASP accepts. Each system's real status is on the systems page.