Table of Contents
- The UAE Electronic Invoicing Framework — Overview
- The 5-Corner Model at a Glance
- Corner 1 — The Supplier
- Corner 2 — The Supplier's ASP
- Corner 3 — The Buyer's ASP
- Corner 4 — The Buyer
- Corner 5 — The FTA / Ministry of Finance
- The Complete Invoice Flow — Step by Step
- What Happens When Validation Fails?
- Electronic Confirmations — The Full Cycle
- PINT AE — The UAE Invoice Data Standard
- Accredited Service Providers (ASPs)
- Implementation Deadlines 2026–2027
- Penalties for Non-Compliance
- How to Prepare Your Business
- FAQs
The UAE Electronic Invoicing Framework — Overview
The UAE electronic invoicing framework is the government's mandated system for issuing, exchanging, and storing invoices in a structured, machine-readable digital format. Rather than building a single centralised platform through which all invoices must pass, the UAE has adopted a Decentralised Continuous Transaction Control and Exchange (DCTCE) architecture — also known as the Peppol 5-Corner Model.
This framework was established through a series of legislative instruments: Federal Decree-Law No. 16 of 2024 amended the UAE VAT Law to provide the legal basis, Ministerial Decisions No. 243 and 244 of 2025 defined the system scope and phased implementation, Ministerial Decision No. 64 of 2025 set the accreditation criteria for service providers, Cabinet Decision No. 106 of 2025 established penalties, and the UAE Electronic Invoicing Guidelines (Version 1.0, February 2026) published by the Ministry of Finance provided the complete operational and technical framework.
The core idea is straightforward: businesses do not send invoices directly to the government. Instead, invoices flow between businesses through certified intermediaries called Accredited Service Providers (ASPs), while tax data is simultaneously reported to the Federal Tax Authority (FTA) by those same ASPs. This decentralised approach means business transactions are never delayed by government processing — the invoice reaches the buyer and the FTA at virtually the same time.
Unlike some countries' e-invoicing systems (such as Italy's SDI), the UAE model does not require the FTA to approve or clear an invoice before it reaches the buyer. The invoice and tax data flow in parallel — ensuring no business delays while still giving the FTA near real-time visibility.
The 5-Corner Model at a Glance
Every compliant e-invoice exchange in the UAE involves five participants. Here is the model visually, before we dive deep into each corner:
UAE E-Invoicing: The Peppol 5-Corner Model (DCTCE)
How electronic invoices flow from supplier → buyer → FTA
Supplier
Generates invoice data and submits to their ASP in an agreed format
Buyer
Receives the validated e-invoice from their ASP in an agreed format
Supplier's ASP
Validates data, converts to PINT AE XML, transmits to Corner 3
Buyer's ASP
Validates received invoice, confirms to Corner 2, delivers to Corner 4
Federal Tax Authority (FTA) / Ministry of Finance
Receives tax data from both Corner 2 and Corner 3 · Cross-references in near real-time · Sends electronic confirmations back to both ASPs
Now let's break down exactly what each corner does, its responsibilities, and how data flows between them.
Corner 1 — The Supplier
The business that generates the invoice
The supplier is the starting point of every e-invoice transaction. This is the business that supplies goods or services and needs to issue an invoice to the buyer.
What Corner 1 does:
- Generates the electronic invoice data from their ERP, accounting software, POS, or billing system
- Submits the invoice data to their ASP (Corner 2) in an agreed format — this could be any internal format (CSV, JSON, proprietary ERP export, etc.) as long as the data is complete
- Receives the electronic confirmation forwarded from Corner 2 once the full cycle is complete
The supplier does not send invoices directly to the buyer, the FTA, or the Peppol network. The supplier's only direct interaction is with their own ASP. The ASP handles everything else.
Even though the ASP handles validation and transmission, the legal responsibility for invoice accuracy remains with the supplier (or the buyer in a self-billing scenario) — not the ASP. This is explicitly stated in the February 2026 Guidelines.
Corner 2 — The Supplier's ASP
Accredited Service Provider appointed by the supplier
Corner 2 is the supplier's Accredited Service Provider — the critical technical intermediary that validates, converts, and transmits the invoice. This is where the e-invoicing framework's real processing begins.
What Corner 2 does — in sequence:
- Receives the electronic invoice data from Corner 1 (the supplier) in whatever format has been agreed between both parties
- Validates the invoice data against the PINT AE schema — checking all mandatory fields, VAT classifications, TIN accuracy, and data integrity
- Converts the data into the UAE standard electronic invoice in XML format (if the data was received from Corner 1 in a different format)
- Transmits the electronic invoice (now in XML format) to the buyer's ASP (Corner 3) via the Peppol network
- In parallel, reports tax data to Corner 5 (the FTA/MoF) — this happens simultaneously with the transmission to Corner 3, not sequentially
- Receives electronic confirmation from Corner 3 upon successful validation of the invoice by the buyer's ASP
- Receives electronic confirmation from Corner 5 once the FTA has successfully processed the reported tax data
- Forwards the electronic confirmation from Corner 5 back to Corner 1 (the supplier)
Corner 2 is effectively the gatekeeper on the supplier side. If your invoice data doesn't pass its validation checks, it never enters the Peppol network.
Corner 3 — The Buyer's ASP
Accredited Service Provider appointed by the buyer
Corner 3 is the buyer's Accredited Service Provider. It receives invoices from the supplier's ASP, performs its own validation, and delivers the invoice to the buyer. Critically, Corner 3 also has tax reporting obligations to the FTA.
What Corner 3 does — in sequence:
- Receives the electronic invoice (in XML format) from Corner 2 via the Peppol network
- Validates the electronic invoice against the PINT AE schema and UAE requirements
If validation is SUCCESSFUL:
- Sends an electronic confirmation to Corner 2 (the supplier's ASP), confirming successful receipt and validation
- Submits the electronic invoice to Corner 4 (the buyer) in a format that has been agreed between both parties — this may be the raw XML, a human-readable format, or an ERP-compatible import
- Reports tax data to Corner 5 (the FTA/MoF) — this is the second independent tax report the FTA receives for the same transaction
If validation FAILS:
- Sends an electronic rejection notification to Corner 2 (the supplier's ASP)
- Sends an electronic rejection notification to Corner 5 (the FTA)
- Does NOT report tax data to Corner 5 — since the invoice is invalid, there is no tax data to report
- The invoice is not delivered to Corner 4 (the buyer)
Corner 4 — The Buyer
The business receiving the invoice
Corner 4 is the buyer — the business receiving goods or services and the corresponding invoice. The buyer's interaction with the e-invoicing framework is primarily through their ASP (Corner 3).
What Corner 4 does:
- Receives the electronic invoice from their ASP (Corner 3) in a format that has been agreed between both parties
- Uses the structured invoice data for accounting, VAT input tax recovery, and record-keeping
- Receives the electronic confirmation forwarded from Corner 3 (originally sent by Corner 5) once the FTA has successfully processed the tax data
Like the supplier, the buyer does not interact directly with the Peppol network or the FTA for invoice purposes — everything flows through their ASP.
Corner 5 — The FTA / Ministry of Finance
The tax authority — receives tax data from both ASPs
Corner 5 is what makes this a "5-corner" model rather than a standard 4-corner Peppol exchange. The FTA/Ministry of Finance sits at the centre of the framework, receiving tax data from both sides of every transaction.
What Corner 5 does:
- Receives tax data from Corner 2 (the supplier's ASP) — this is reported in parallel with the invoice transmission to Corner 3
- Receives tax data from Corner 3 (the buyer's ASP) — upon successful validation of the invoice
- Cross-references the tax data received from both ASPs for the same transaction — enabling near real-time compliance monitoring
- Sends electronic confirmation to Corner 2 once the tax data from the supplier's side has been successfully reported
- Sends electronic confirmation to Corner 3 once the tax data from the buyer's side has been successfully reported
- Stores and monitors all transaction data for VAT compliance oversight
The dual reporting from both ASPs is the framework's most powerful compliance mechanism. The FTA can instantly detect discrepancies between what the supplier reports and what the buyer reports — making tax evasion, underreporting, and invoice fraud significantly more difficult.
The Complete Invoice Flow — Step by Step
Here is the exact sequence of events when an e-invoice is issued, validated, and reported under the UAE electronic invoicing framework. This is the successful scenario:
✅ Successful Invoice Flow — 8 Steps
Supplier Submits Invoice Data
Corner 1 (supplier) generates invoice data and submits it to Corner 2 (their ASP) in an agreed format.
Supplier's ASP Validates & Converts
Corner 2 validates the data against PINT AE and converts it into the UAE standard XML format (if received in a different format from Corner 1).
Invoice Transmitted to Buyer's ASP + Tax Data Reported to FTA
Corner 2 transmits the XML e-invoice to Corner 3 (buyer's ASP) via the Peppol network. In parallel, Corner 2 reports tax data to Corner 5 (FTA). These happen simultaneously.
Buyer's ASP Validates the Invoice
Corner 3 receives and validates the electronic invoice against the PINT AE schema.
Buyer's ASP Confirms, Delivers & Reports
Upon successful validation: Corner 3 sends electronic confirmation to Corner 2, delivers the invoice to Corner 4 (buyer) in their agreed format, and reports tax data to Corner 5.
FTA Sends Confirmation to Supplier's ASP
Corner 5 sends electronic confirmation to Corner 2 once the tax data (from the supplier side) has been successfully reported and processed.
FTA Sends Confirmation to Buyer's ASP
Corner 5 sends electronic confirmation to Corner 3 once the tax data (from the buyer side) has been successfully reported and processed.
Confirmations Forwarded to Businesses
Corner 2 forwards the electronic confirmation received from the FTA to Corner 1 (supplier). Corner 3 forwards the electronic confirmation received from the FTA to Corner 4 (buyer). The full cycle is now complete.
What Happens When Validation Fails?
Not every invoice will pass validation. When the buyer's ASP (Corner 3) fails to validate an incoming e-invoice, a different sequence of events kicks in:
❌ Failed Validation Scenario
- Corner 3 receives the electronic invoice from Corner 2 via the Peppol network
- Corner 3 attempts validation against the PINT AE schema — validation fails (e.g., missing mandatory fields, invalid TIN, incorrect tax classification, data format errors)
- Corner 3 sends an electronic rejection notification to Corner 2 (supplier's ASP), specifying the reason for rejection
- Corner 3 also sends an electronic rejection notification to Corner 5 (FTA), informing the tax authority that the invoice was rejected
- Corner 3 does NOT report tax data to Corner 5 — since the invoice is invalid, there is no valid tax data to report from the buyer's side
- The invoice is not delivered to Corner 4 (the buyer) — the buyer never sees a rejected invoice
- The supplier must correct the data and resubmit through Corner 2 to restart the process
Remember: invoices must be issued within 14 days of the taxable event (AED 2,500 penalty per late case). If your data quality is poor and invoices keep getting rejected by the buyer's ASP, you risk breaching this deadline. Data cleanup and PINT AE field mapping before go-live are essential.
Electronic Confirmations — The Full Cycle
Electronic confirmations are the framework's feedback mechanism — they tell each party that the process completed successfully. Here is exactly how confirmations flow:
| Confirmation | From | To | Triggered When |
|---|---|---|---|
| Invoice validation confirmation | Corner 3 (Buyer's ASP) | Corner 2 (Supplier's ASP) | Corner 3 successfully validates the e-invoice |
| Tax data confirmation (supplier side) | Corner 5 (FTA) | Corner 2 (Supplier's ASP) | FTA successfully processes tax data reported by Corner 2 |
| Tax data confirmation (buyer side) | Corner 5 (FTA) | Corner 3 (Buyer's ASP) | FTA successfully processes tax data reported by Corner 3 |
| FTA confirmation forwarded to supplier | Corner 2 (Supplier's ASP) | Corner 1 (Supplier) | Corner 2 receives confirmation from Corner 5 |
| FTA confirmation forwarded to buyer | Corner 3 (Buyer's ASP) | Corner 4 (Buyer) | Corner 3 receives confirmation from Corner 5 |
PINT AE — The UAE Invoice Data Standard
PINT AE (Peppol International Invoice — UAE profile) is the structured data dictionary that defines exactly what an e-invoice must contain. It defines over 135 data elements, with approximately 50 mandatory fields for a standard tax invoice.
| Category | Required Fields | Notes |
|---|---|---|
| Invoice Identification | Unique invoice number, issue date, invoice type code, transaction type code | Transaction type code must flag: standard supply, zero-rated, reverse charge, free zone, etc. |
| Supplier Details | Name, address, TIN (first 10 digits of TRN) | Must match FTA registration data exactly |
| Buyer Details | Name, address, TIN | Required for B2B; specific rules for B2G |
| Line Items | Description, quantity, unit price, net amount per line | Each line must be individually detailed |
| VAT Details | VAT rate, VAT amount in AED, tax category code per line | VAT must be at line-item level in AED, regardless of invoice currency |
| Totals | Total net amount, total VAT, total payable | Must mathematically reconcile with line items |
| Currency | Document currency, tax currency (always AED) | Foreign currency invoices must still show AED amounts |
Once your mandatory go-live date arrives, only structured XML invoices in PINT AE format qualify as legally valid. PDFs, scanned images, Word documents, and paper invoices will not meet compliance requirements for B2B and B2G transactions.
Accredited Service Providers (ASPs)
ASPs are the technical backbone of the UAE electronic invoicing framework. Key facts:
- Mandatory appointment — Every in-scope business must appoint exactly one ASP for both sending and receiving invoices
- Accredited by MoF — Only providers accredited by the Ministry of Finance can operate as ASPs
- VAT group members — Each member of a VAT group must have a separate endpoint connection with the ASP, while still using the group's TRN
- Legal accountability — The ASP validates and transmits, but legal responsibility for invoice accuracy remains with the supplier
- Critical business decision — ASPs become an extension of your finance and operational control framework — choose carefully
Implementation Deadlines 2026–2027
Penalties for Non-Compliance
| Violation | Penalty | Cap / Notes |
|---|---|---|
| Failure to implement e-invoicing or appoint an ASP | AED 5,000/month | Per month of delay or part thereof |
| Failure to issue/transmit e-invoice | AED 100/invoice | Capped at AED 5,000/month |
| Failure to issue/transmit electronic credit note | AED 100/credit note | Capped at AED 5,000/month |
| Failure to issue tax invoice within 14 days | AED 2,500/case | Per detected case |
| Failure to report system outage within 2 business days | AED 1,000/day | Per day of delay |
| Failure to notify ASP of data changes | AED 1,000/day | Per day of delay |
| Failure to keep required records/data | AED 10,000 | AED 20,000 for repeat violations within 24 months |
How to Prepare Your Business
- Determine your phase — Calculate annual revenue, identify your ASP appointment deadline and go-live date
- Impact assessment — Map your current invoicing data fields against the ~50 mandatory PINT AE fields. Identify gaps.
- Select and appoint an ASP — Evaluate providers based on Peppol certification, PINT AE compliance, ERP compatibility, and onboarding support
- Upgrade systems & clean data — Ensure your ERP can output structured XML. Verify TRNs, addresses, and VAT classifications across your master data
- Test end-to-end — Run pilots: create invoices, validate, transmit, receive confirmations, and test rejection scenarios
- Establish governance — Processes for monitoring validation failures, reporting outages within 2 days, updating ASP records, and archiving for 5–15 years
Frequently Asked Questions
The UAE electronic invoicing framework is a government-mandated system for issuing, exchanging, and storing invoices in structured digital format (XML using PINT AE standards). It operates on a Peppol-based 5-corner model where invoices flow between suppliers and buyers through Accredited Service Providers (ASPs), with tax data reported in near real-time to the FTA.
The 5-corner model is the DCTCE architecture behind UAE e-invoicing. Corner 1 is the Supplier, Corner 2 is the Supplier's ASP, Corner 3 is the Buyer's ASP, Corner 4 is the Buyer, and Corner 5 is the FTA/MoF. Invoices flow between businesses through their ASPs, while tax data is simultaneously reported to the FTA by both ASPs.
When Corner 3 (buyer's ASP) fails to validate an invoice, it sends an electronic rejection to both Corner 2 (supplier's ASP) and Corner 5 (FTA). No tax data is reported by Corner 3, and the invoice is not delivered to the buyer. The supplier must correct and resubmit.
PINT AE is the UAE profile of the Peppol International Invoice standard. It defines 135+ data elements including ~50 mandatory fields. Only structured XML invoices in PINT AE format are legally valid — PDFs and paper invoices do not qualify.
An ASP is the technical bridge between businesses and the Peppol network. ASPs validate invoice data, convert formats to XML, transmit invoices, report tax data to the FTA, handle confirmations and rejections, and archive records. Every in-scope business must appoint exactly one ASP.
Pilot starts July 1, 2026. Revenue ≥ AED 50M: appoint ASP by July 31, 2026, go live by January 1, 2027. Revenue < AED 50M: appoint by March 31, 2027, go live by July 1, 2027. Government entities by October 1, 2027.
Yes. Free zone companies conducting B2B or B2G transactions are fully within scope, with deadlines based on their revenue tier.
No. Only structured XML e-invoices in PINT AE format transmitted through an ASP are legally valid for B2B/B2G transactions. You may send a PDF copy alongside for reference, but the XML is the official document.
The FTA (Corner 5) receives tax data from both the supplier's ASP (Corner 2) and the buyer's ASP (Corner 3) independently and in parallel with the invoice exchange. This dual reporting enables real-time cross-referencing and compliance monitoring.
Minimum 5 years after the relevant tax period. For real estate and capital assets, up to 15 years. All records must be stored within the UAE (including cloud) and maintained in Arabic or English.
Office No 33, 2nd Floor, Sheikh Rashid Building, Al Souq Street, Bur Dubai. UAE e-invoicing, corporate tax, and VAT advisory for 1,000+ businesses. Contact: +971 55 127 3479 · Enquire online