The Five-Corner Model: How UAE E-Invoices Reach the FTA

Ask three vendors to explain the UAE's e-invoicing architecture and you may get three pictures: one with the FTA in the middle approving every invoice, one with no tax authority in the flow at all, and one that is roughly right. The difference matters, because the architecture decides where invoices can fail, who sees the failure and what your team has to monitor.

This article takes the five-corner model apart corner by corner, using the Ministry of Finance (MoF) flow and the published OpenPeppol specifications. It covers the Tax Data Document, the Message Level Status, what happens when the buyer is not on the network, and how the UAE model compares with plain four-corner Peppol and Saudi Arabia's clearance system. Details are as of October 2026.

What Is the Five-Corner Model?

The five-corner model is the UAE's e-invoicing architecture, which the MoF calls Decentralised Continuous Transaction Control and Exchange (DCTCE). It keeps Peppol's four-corner exchange between businesses and their service providers and adds the Federal Tax Authority (FTA) as a fifth corner that receives tax data from both providers.

Two design choices define it. It is decentralised: invoices move between private Accredited Service Providers (ASPs), not through a government portal. And it applies continuous transaction control: the FTA receives invoice data as transactions happen, not just in periodic VAT returns. The background on the four-corner network itself is in what Peppol is and how it works.

What Does Each Corner Do?

Each corner has a distinct legal and technical role, and a business occupies Corner 1 for its sales and Corner 4 for its purchases. Both roles need an ASP.

• Corner 1, the supplier: produces invoice data in its ERP or billing system and sends it to its ASP in an agreed format. It owns the accuracy of the data.
• Corner 2, the supplier's ASP: validates the data, converts it into the UAE XML format (PINT AE), delivers it over Peppol and reports tax data to the FTA.
• Corner 3, the buyer's ASP: receives and validates the invoice, sends a status back to Corner 2, passes the invoice to the buyer and reports its own tax data to the FTA.
• Corner 4, the buyer: receives the structured invoice into its accounts payable process for matching and approval.
• Corner 5, the FTA: receives tax data from both ASPs and sends confirmations back to each.

The double reporting is what makes the model distinctive. Every domestic B2B invoice reaches the FTA twice, once as "issued" from the supplier's side and once as "received" from the buyer's side. That lets the FTA match the two and spot mismatches between what a supplier declares and what a buyer claims.

How Does an Invoice Move Through the Five Corners, Step by Step?

The MoF's programme documentation sets out the flow in eleven steps:

1. Corner 1 submits invoice data to Corner 2 in an agreed format.
2. Corner 2 validates the data and converts it into the UAE standard XML e-invoice.
3. Corner 2 transmits the XML invoice to Corner 3.
4. In parallel, Corner 2 reports tax data to Corner 5.
5. Corner 3 sends an electronic validation confirmation back to Corner 2.
6. Corner 3 delivers the invoice to Corner 4 in an agreed format.
7. Corner 3 reports tax data to Corner 5. If validation fails, Corner 3 notifies both Corner 2 and Corner 5 and does not report the tax data.
8. Corner 5 sends a confirmation to Corner 2.
9. Corner 5 sends a confirmation to Corner 3.
10. Corner 2 forwards the confirmations to Corner 1.
11. Corner 3 forwards the confirmations to Corner 4.

Two points stand out. The supplier's report to the FTA (step 4) runs in parallel with delivery (step 3), so the FTA is never a gate the invoice must pass. And confirmations flow back to the business on both sides (steps 10 and 11), so your ERP should be able to receive and store them, not just send invoices out.

What Is the Tax Data Document?

The Tax Data Document (TDD) is the Peppol message an ASP uses to report an invoice to the FTA. Corner 2 sends one reporting the issued invoice, and Corner 3 sends one reporting the received invoice.

OpenPeppol's UAE TDD specification (version 1.0.2, updated July 2026) defines it precisely:

• Identifiers: CustomizationID urn:peppol:taxdata:ae-1 and ProfileID urn:peppol:taxreporting, which separate it from ordinary billing messages.
• Three sections: TDD metadata (parties, dates, function codes), key data values extracted from the invoice, and the full reported invoice embedded as XML.
• Functions: submit, update and withdraw, so a report can be corrected or withdrawn through the same channel.
• Failure reporting: a Tax Data Status with type code F covers invoices that failed validation, where the usual data extracts may not be possible.
• Timing: the specification allows the TDD to be sent at a different time from the invoice exchange, which is how reporting stays off the critical path of delivery.

For businesses, the TDD is invisible: your ASP builds it from the PINT AE invoice. What you control is the invoice data it is built from. Errors in the invoice flow straight into what the FTA sees. The PINT AE guide covers the fields that matter most.

What Is the Message Level Status?

The Message Level Status (MLS) is a standard Peppol message that the buyer's service provider (Corner 3) sends back to the supplier's provider (Corner 2) to report what happened to a document after receipt. In the UAE flow it carries the validation confirmation in step 5.

The OpenPeppol MLS specification (version 1.0.0, May 2025) defines three response codes:

The MLS is sent only from Corner 3 to Corner 2, never in reply to another MLS, and it must be sent as soon as the status is known. It is separate from the FTA's own confirmations in steps 8 and 9. Some vendor material describes the MLS as coming from the FTA; in the Peppol specification it is a message between the two service providers.

What Happens When the Buyer Is Not on Peppol?

When an invoice cannot be delivered to a UAE buyer's ASP, because it is an export, a deemed supply or the buyer is not subject to UAE e-invoicing, the supplier's ASP reports it to the FTA only. A placeholder address is used in place of a real buyer endpoint.

Vertex's PINT AE notes give the placeholders as 9900000099 for exports and 9900000098 for deemed supplies and buyers not subject to UAE e-invoicing. In these cases the document must not be exchanged with Corner 3 and is reported only to Corner 5. The model therefore collapses from five corners to a supplier, its ASP and the FTA, and you send the buyer its copy outside the network.

The transition period adds a fourth case: a UAE buyer that is in scope but not yet live. Here MoF guidance says the supplier should issue both a traditional VAT-compliant tax invoice and an electronic invoice in XML. Because phases go live between January and October 2027, many large suppliers will run this dual process for part of the year. The dates are in the UAE e-invoicing deadlines guide.

How Does the Five-Corner Model Compare with Four-Corner and Clearance Models?

The three models differ mainly in where the tax authority sits. In four-corner Peppol it is absent; in the UAE's five-corner model it receives reports in parallel; in Saudi Arabia's clearance model it approves invoices before they reach the buyer.

Each model has a trade-off. Clearance gives the authority certainty but makes its platform a single point of failure for every sale. Pure four-corner exchange gives speed but no live tax visibility. The UAE model sits in between: delivery never waits for the FTA, yet the FTA sees both sides of each transaction. For groups trading in both countries, Saudi ZATCA vs UAE Peppol compares data formats and integration effort in detail.

Why Did the UAE Choose a Decentralised Model?

The design reflects a choice to give the tax authority continuous data without making it run the invoice exchange. Licensed private providers carry and validate documents; the FTA receives reports and confirms them.

That approach has practical effects for businesses. Competition among ASPs is real, because any accredited provider can reach any other: the MoF's May 2026 decision to allow white-label partnerships with international providers extended that competition. International interoperability comes built in, because the exchange runs on the same Peppol network used in Europe and Asia-Pacific. And the rules can evolve through PINT AE releases without rebuilding a national platform.

The cost is that responsibility is spread out. When something goes wrong, the cause could be your ERP, your ASP, the buyer's ASP or the reporting leg. Contracts and monitoring need to show clearly which party saw what, and when.

What Does the Five-Corner Model Mean for Your Systems and Team?

It means e-invoicing is a two-way, monitored process rather than a send-and-forget export. Plan for these capabilities:

1. Outbound integration from ERP to ASP, with every PINT AE field and transaction flag populated at source.
2. Inbound integration from ASP to accounts payable, because you are Corner 4 for every supplier.
3. Status handling: store MLS codes and FTA confirmations against each invoice, and alert on RE.
4. Placeholder logic for exports, deemed supplies and out-of-scope buyers, so those documents are reported but not routed to a buyer endpoint.
5. Dual issuing during the transition for buyers not yet live.
6. Outage procedures that include the two-business-day FTA notification.

The ERP integration guide explains how these map onto SAP, Oracle, Dynamics, Odoo, Zoho and Tally, and the complete UAE e-invoicing guide covers scope and obligations.

How VEATEX Helps

VEATEX is a Shopify, web and software development agency that also builds Peppol e-invoicing platforms for the GCC, working with clients in the US, UK and the Gulf for over 11 years. We built a Peppol platform for a client that passed OpenPeppol testing and is now on the UAE pre-approved ASP list, so we have engineered the corner-to-corner flows described here. For businesses we build ERP connections, status handling and placeholder logic; for service providers we engineer platform components. Learn about our e-invoicing services or contact us.