Section 5 of the UAE Electronic Invoicing Guidelines V1.1 describes the technical and operational architecture of the Electronic Invoicing System. The UAE has adopted a decentralised model built on the Peppol 5-Corner framework. Understanding the precise flow of data and the allocation of responsibilities between Corners is essential for both implementers and compliance practitioners.
The 5-Corner Model: Data Flow Step by Step
The Guidelines describe eleven discrete steps in the invoice exchange process:
- Corner 1 (Supplier) submits Electronic Invoice data to Corner 2 (Supplier's ASP) in an agreed format.
- Corner 2 validates the data and converts it to PINT-AE XML if received in a different format.
- Corner 2 transmits the XML Electronic Invoice to Corner 3 (Buyer's ASP).
- In parallel, Corner 2 reports Tax Data to Corner 5 (FTA).
- Corner 3 validates the Electronic Invoice and sends electronic confirmation to Corner 2.
- Corner 3 delivers the Electronic Invoice to Corner 4 (Buyer) in a mutually agreed format.
- Upon successful validation, Corner 3 reports Tax Data to Corner 5. If validation fails, Corner 3 notifies Corner 2 and Corner 5; no Tax Data is reported in that scenario.
- Corner 5 sends electronic confirmation to Corner 2 once Tax Data is successfully received.
- Corner 5 sends electronic confirmation to Corner 3 once Tax Data is successfully received.
- Corner 2 forwards confirmations to Corner 1.
- Corner 3 forwards confirmations to Corner 4.
Responsibilities Matrix
Section 5.2 of the Guidelines provides a formal responsibilities table. Key allocations are:
- Exchange and reporting of Electronic Invoices (including confirmation messages): Supplier and ASP (the compliance obligation rests with the Supplier; the ASP carries it out practically).
- Calculating all Electronic Invoice values: Supplier.
- Secure transmission using encryption: ASP.
- Agreeing business-specific data security requirements with ASPs: Supplier and Buyer.
- Contacting the buyer to gather their Peppol participant identifier: Supplier.
- Looking up the Peppol participant identifier provided by the supplier: ASP.
- Generating a UUID for every Electronic Invoice to prevent duplication: ASP (for standard invoices); Buyer (for self-billed invoices).
Format of Electronic Invoices
Section 5.3 confirms that Electronic Invoices are issued, transmitted, and received exclusively in XML format. Critically, the Guidelines state that Electronic Invoices will not feature a QR code or barcode. This distinguishes the UAE 5-Corner model from Saudi Arabia's ZATCA Fatoora system, which requires QR codes on simplified invoices. The PINT-AE billing specification governs the specific XML content.
Data Storage and Archival
Section 5.4 sets out retention obligations with precision:
- For Taxable Persons: 5 years following the Tax Period to which the data relates.
- For all other Persons: 5 years from the end of the calendar year in which the document was created.
- For real estate records: 7 years from the end of the calendar year of creation.
- Additional 4-year extension applies in the event of a dispute with the FTA, an ongoing tax audit, or notification of an intended audit.
- Additional 1-year extension applies where a voluntary disclosure is submitted within the fifth year from the end of the relevant tax period.
Article 11 of MD No. 243 of 2025 requires storage within the State. However, the Guidelines interpret this policy intent as requiring that data be retrievable and reproducible by the FTA, not that servers must be physically located in the UAE. Cloud-based storage outside the UAE satisfies the obligation where records can be retrieved promptly and provided in complete, readable form.
Bilingual Capability
The Guidelines confirm that the Electronic Invoicing framework supports both Arabic and English, ensuring compliance with any Arabic reporting requirements mandated in the UAE.
Practitioner Implications
The 5-Corner architecture places the compliance obligation squarely on the Supplier for invoice accuracy and the ASP for technical transmission. Businesses cannot outsource compliance liability to their ASP. The UUID generation requirement — and the ASP's role in preventing duplicates — also means that ERP-side invoice numbering must be carefully aligned with the ASP's de-duplication logic during implementation.
