Under Ministerial Decision No. 243 of 2025, the UAE's Electronic Invoicing System (EIS) does not place every obligation on a single party. Instead, responsibilities are divided across three distinct roles: the Supplier, the Buyer, and the Accredited Service Provider (ASP).
Understanding who owns which duty is critical — not just for compliance, but to avoid disputes over penalties and audit findings. This article provides a definitive responsibility matrix and practical business scenarios to illustrate how the process flows end-to-end.
Need hands-on help? Our E-Invoicing Service covers everything Fastlane does to get your business compliant — for a fixed fee of AED 3,000.
The Complete E-Invoicing Responsibility Matrix
The table below sets out the seven core e-invoicing activities and clearly identifies which party bears responsibility for each one under the UAE framework.
| Activity | Supplier | Buyer | ASP |
|---|---|---|---|
| 1. Exchange & reporting of electronic invoices, including receiving confirmation messages | Yes | Self-billed only | No |
| 2. Calculating all electronic invoice values (amounts, VAT, totals) | Yes | No | No |
| 3. Secure transmission of electronic invoices using encryption | No | No | Yes |
| 4. Agreeing business-specific data security requirements with ASPs | Yes | Yes | No |
| 5. Contacting the Buyer and gathering their Peppol Participant Identifier for invoice routing | Yes | No | No |
| 6. Looking up the Peppol Participant Identifier provided by the Supplier | No | No | Yes |
| 7. Generating a UUID for every Electronic Invoice to ensure uniqueness and prevent duplication | No | No | Yes |
🔔 Large businesses (AED 50M+) must appoint an ASP by 31 July 2026. Is your business ready?
View Our E-Invoicing Service →Responsibilities by Party
- Exchange and report electronic invoices to the Buyer via the EIS, and receive confirmation messages from the network
- Calculate all values on every electronic invoice — including taxable amounts, VAT, and totals — before submission
- Agree and document business-specific data security requirements in the contract with your chosen ASP
- Contact each Buyer to collect their Peppol Participant Identifier before issuing e-invoices to them
- Exchange and report electronic invoices only in the specific case of self-billed invoices — where the Buyer issues the invoice on behalf of the Supplier
- Agree and document business-specific data security requirements with your own ASP
- Provide your Peppol Participant Identifier to Suppliers who request it, so they can route invoices correctly to you
- Ensure secure, encrypted transmission of all electronic invoices through the Peppol network — this technical layer is the ASP's exclusive domain
- Look up and validate the Peppol Participant Identifier provided by the Supplier to correctly route the invoice to the Buyer
- Generate a UUID (Universally Unique Identifier) — a 128-bit algorithmically created number — for every electronic invoice to ensure global uniqueness and prevent duplicate processing
Each Responsibility Explained — With Practical Scenarios
1. Exchanging & Reporting Electronic Invoices
The Supplier is the primary party responsible for initiating the exchange of electronic invoices with Buyers and reporting them to the FTA through the EIS. This includes receiving and acknowledging confirmation messages that the invoice was successfully delivered and accepted in the network.
The Buyer only carries this responsibility in a specific circumstance: self-billed invoices. A self-billed invoice is one where the Buyer raises the invoice on behalf of the Supplier — a practice that exists in certain industries such as freight, construction sub-contracting, and commodity trading, where the Buyer has better visibility of the quantities delivered.
Standard Invoice vs. Self-Billed Invoice
Standard scenario: Al Baraka Trading LLC (Supplier) sells goods to Gulf Retail Group (Buyer). Al Baraka issues the invoice through their ASP. Al Baraka receives a confirmation message when the invoice is successfully delivered. Gulf Retail Group simply receives the invoice.
Issues invoice
Transmits via Peppol
Receives invoice
Receives confirmation
Self-billed scenario: A logistics firm (Buyer) contracts independent hauliers (Suppliers) and issues invoices on their behalf based on loads completed. Here, the logistics firm (Buyer) is responsible for exchanging and reporting those self-billed invoices through the EIS.
2. Calculating Electronic Invoice Values
Every figure on an electronic invoice — the net amount, applicable VAT rate, VAT amount, discounts, and gross total — is the Supplier's sole responsibility to calculate accurately before submitting the invoice through the system. The ASP does not verify or correct these figures; it simply transmits what the Supplier provides. The Buyer has no role in this calculation unless it is a self-billed arrangement.
VAT Calculation Error — Who Bears the Risk?
Precision Engineering FZC (Supplier) invoices a Dubai-based client AED 100,000 for services but mistakenly applies a 0% VAT rate instead of 5%. The invoice passes through the ASP and is transmitted on the Peppol network — the ASP has no obligation to flag the error.
When the FTA identifies the discrepancy during a routine audit, the liability falls entirely on Precision Engineering FZC as the Supplier. The ASP has fulfilled its role. This underscores why internal invoice review processes — and ERP mapping to the PINT-AE format — are critical before go-live.
3. Secure Transmission Using Encryption
Once an invoice leaves the Supplier's system, it is the ASP's exclusive responsibility to ensure it is transmitted securely and encrypted across the Peppol network to the Buyer's access point. Neither the Supplier nor the Buyer manages encryption — this is a technical function entirely owned by the accredited provider.
This is one of the core reasons why businesses cannot simply email a PINT-AE XML file to their Buyer and call it compliant. The secure, encrypted Peppol transmission is a non-negotiable part of UAE e-invoicing, and it only works through a certified ASP.
Why Emailing an XML File Is Not Compliant
A CFO at a mid-size Dubai distributor asks their IT team to generate PINT-AE XML invoices and email them directly to clients, believing this satisfies the e-invoicing mandate. It does not.
Under MD No. 243 of 2025, secure encrypted transmission via the Peppol network — facilitated by an accredited ASP — is a mandatory technical requirement. An emailed XML file bypasses the FTA's reporting infrastructure entirely. The Supplier remains non-compliant and exposed to penalties regardless of the XML format used.
4. Agreeing Business-Specific Data Security Requirements with ASPs
Both the Supplier and the Buyer are responsible for negotiating and formalising business-specific data security requirements in their respective contracts with their chosen ASPs. This is a commercial and contractual obligation — the ASP itself does not drive this agenda.
In practice, this means reviewing your ASP service agreement carefully and ensuring provisions around data retention, access controls, breach notification timelines, and confidentiality of invoice data are explicitly agreed and documented.
What to Include in Your ASP Data Security Agreement
A healthcare supplies company in Dubai (Supplier) appoints an ASP for e-invoicing. Given the sensitivity of their client data, they include the following specific requirements in their ASP contract:
➜ Data residency: Invoice data must be stored on UAE-based servers
➜ Retention period: Invoices to be retained for a minimum of 5 years
➜ Breach notification: ASP must notify within 24 hours of any security incident
➜ Access logging: Full audit trail of who accessed invoice data required
The Buyer (a hospital network) independently agrees similar terms with their own ASP. Both parties have fulfilled their respective obligations under Activity 4.
💬 Confused about what to look for in an ASP agreement? Our team can review your contract terms.
WhatsApp Us Now5. Contacting the Buyer & Gathering the Peppol Participant Identifier
Before a Supplier can issue an electronic invoice to any Buyer, they must know the Buyer's Peppol Participant Identifier — a unique address on the Peppol network that tells the ASP where to route the invoice. The Supplier is responsible for proactively contacting each Buyer to collect this information.
This is a practical, relationship-level activity. Suppliers should establish a process to collect and maintain a register of Peppol Participant Identifiers for all their buyers before go-live.
Supplier Onboarding a New Client for E-Invoicing
Falcon Industrial Supplies LLC (Supplier) is onboarding Emirates Steel (Buyer) as a new client ahead of the January 2027 mandatory go-live. Falcon's finance team sends a formal e-invoicing onboarding communication:
"In line with UAE's mandatory e-invoicing requirements under Ministerial Decision No. 243 of 2025, please provide your Peppol Participant Identifier so we can route electronic invoices directly to your EIS access point."
Requests Peppol ID
Provides Peppol ID
Stores ID, passes to ASP
Falcon logs this identifier in their ERP system and provides it to their ASP when configuring the invoice routing for Emirates Steel.
6. Looking Up the Peppol Participant Identifier
Once the Supplier has collected the Buyer's Peppol Participant Identifier and passed it to their ASP, it is the ASP's responsibility to look it up in the Peppol directory — the distributed network registry — and validate that it is active and correctly registered. This ensures the invoice is routed to the right destination and not rejected by the network.
What Happens When an Identifier Is Invalid
A Supplier passes their Buyer's Peppol Participant Identifier to their ASP. The ASP's system queries the Peppol directory and discovers the identifier is not yet registered — the Buyer has not completed their own ASP onboarding.
The ASP alerts the Supplier that delivery cannot be completed. The Supplier then follows up with the Buyer to confirm their registration status. This is a common scenario expected during the transition period and highlights why starting early — before the mandatory deadlines — is essential.
7. Generating a UUID for Every Electronic Invoice
A UUID — Universally Unique Identifier — is a 128-bit number algorithmically generated to ensure that every electronic invoice issued in the UAE is uniquely identifiable across the entire EIS system, with no possibility of duplication. The ASP is responsible for generating this UUID automatically for every invoice it processes.
The UUID is separate from your invoice's sequential number (e.g. INV-2026-001). You cannot manually assign or override a UUID — it is system-generated by your ASP. Its purpose is to give the FTA a globally unique, tamper-proof reference for real-time audit and verification.
UUID in Action — Preventing Invoice Duplication
A business accidentally submits the same invoice data twice through a system error. In a traditional paper or PDF world, this could result in a duplicate payment being raised. Under the UAE EIS framework, the ASP has already assigned a unique UUID to the first submission (e.g. f47ac10b-58cc-4372-a567-0e02b2c3d479). When the duplicate arrives, the system detects that the underlying invoice data produces a conflicting record and flags it for rejection, preventing the duplicate from reaching the Buyer or the FTA's records.
- Suppliers own the most obligations: invoice exchange, value calculation, Peppol ID collection, and data security agreements with their ASP
- Buyers are largely recipients — their only active obligation is providing their Peppol ID, agreeing ASP security terms, and exchange responsibility in self-billed scenarios
- ASPs own all technical infrastructure duties: encrypted transmission, Peppol directory lookup, and UUID generation
- No party can delegate their obligations to another — each responsibility is fixed under the UAE framework
- The mandatory deadlines are binding regardless of whether your counterparties are ready — start your ASP onboarding now
Reviewed by the Fastlane Compliance Team, Dubai
This article has been reviewed for accuracy against the UAE Ministry of Finance's Electronic Invoicing Guidelines v1.0 (published 23 February 2026) and Ministerial Decision No. 243 of 2025. Fastlane Management Consultancy is a Dubai-based audit, tax and compliance firm registered with the Ministry of Economy and the Federal Tax Authority (TRN: 104218042400003).
Last reviewed: March 2026 · Full E-Invoicing Service Details →Frequently Asked Questions
📞 Ready to appoint an ASP and get compliant? Fastlane is ready to help — fixed fee, no surprises.
Submit an Enquiry