UAE E-Invoicing Responsibilities: Supplier, Buyer & ASP Explained

What is the UAE Electronic Invoicing System, and who are the three parties?

The UAE's Electronic Invoicing System (EIS) is a mandatory framework that requires businesses to issue and report invoices electronically through the Peppol network in the standardised PINT AE format, rather than as paper or PDF documents. Crucially, it does not place every obligation on one party — responsibilities are divided across three distinct roles: the Supplier, the Buyer, and the Accredited Service Provider (ASP).

The framework is set out in Ministerial Decision No. 243 of 2025 [VERIFY], which established the EIS and the roles within it. Understanding who owns which duty is critical — not just for compliance, but to avoid disputes over penalties and audit findings when something goes wrong. This guide provides a definitive responsibility matrix and practical scenarios that show how the process flows end-to-end.

If you need hands-on help getting ready, our e-invoicing service covers PINT AE mapping, ASP integration and Peppol setup for a fixed fee of AED 3,000 — without changing your existing ERP.

The e-invoicing responsibility matrix: who owns each activity?

There are seven core e-invoicing activities, and each one sits squarely with a single party. The table below sets out who bears responsibility for each activity under the UAE framework — the fastest way to see, at a glance, where your duties begin and end.

What are the Supplier's responsibilities?

The Supplier carries the majority of the active obligations under the EIS. In short, the Supplier owns everything about the content of the invoice and the relationship with the Buyer, up to the point the invoice is handed to the ASP for transmission.

What are the Buyer's responsibilities?

The Buyer is, in most transactions, largely a recipient. Its active duties are limited and specific — but they still matter, because a missing Peppol Participant Identifier will stop an invoice from being delivered at all.

What are the Accredited Service Provider's (ASP) responsibilities?

The ASP owns the entire technical layer. This is the ASP's exclusive domain — neither the Supplier nor the Buyer manages it — and it is the reason a certified provider is non-negotiable for UAE e-invoicing.

Choosing the right provider is a decision in itself. Our UAE ASP comparison helps you weigh accredited providers side by side before you commit.

Who exchanges and reports invoices — and how do self-billed invoices differ?

The Supplier is the primary party responsible for initiating the exchange of e-invoices with Buyers and reporting them to the FTA through the EIS, including receiving and acknowledging confirmation messages that the invoice was delivered and accepted. The Buyer only carries this duty in one circumstance: self-billed invoices, where the Buyer raises the invoice on the Supplier's behalf — common in freight, construction sub-contracting and commodity trading, where the Buyer has better visibility of quantities delivered.

Practical scenario — standard vs self-billed. In a standard sale, Al Baraka Trading LLC (Supplier) issues the invoice through its ASP, which transmits it via Peppol to Gulf Retail Group (Buyer); Al Baraka then receives a confirmation message, and Gulf Retail simply receives the invoice. In a self-billed arrangement, a logistics firm (Buyer) that contracts independent hauliers (Suppliers) and raises invoices on their behalf based on loads completed is itself responsible for exchanging and reporting those invoices through the EIS.

Who calculates the invoice values, and who is liable for a VAT error?

Every figure on an e-invoice — net amount, VAT rate, VAT amount, discounts and gross total — is the Supplier's sole responsibility to calculate accurately before submission. The ASP does not verify or correct these figures; it transmits exactly what the Supplier provides. The Buyer has no role here unless it is a self-billed arrangement.

Worked scenario — a VAT error. Precision Engineering FZC (Supplier) invoices a Dubai client AED 100,000 for services but mistakenly applies 0% VAT instead of 5% — understating VAT by AED 5,000. The invoice passes through the ASP and onto the Peppol network; the ASP has no obligation to flag it. When the FTA identifies the discrepancy on audit, the liability falls entirely on Precision Engineering as the Supplier — the ASP has fulfilled its role. This is exactly why internal invoice review and correct VAT treatment, plus clean ERP mapping to the PINT AE format, are critical before go-live.

Why is emailing a PINT AE XML file not compliant?

Once an invoice leaves the Supplier's system, secure, encrypted transmission across the Peppol network is the ASP's exclusive responsibility. This is why a business cannot simply email a PINT AE XML file to its Buyer and call it compliant — the encrypted Peppol transmission is a mandatory technical step that only works through a certified ASP.

Practical scenario. A CFO at a mid-size Dubai distributor asks IT to generate PINT AE XML invoices and email them directly to clients, believing this meets the mandate. It does not. An emailed XML file bypasses the FTA's reporting infrastructure entirely, so the Supplier remains non-compliant and exposed to penalties regardless of the file format used. The format is only half the requirement; the reporting channel is the other half.

What is a Peppol Participant Identifier and who manages it?

A Peppol Participant Identifier is a unique address on the Peppol network that tells the ASP where to route an invoice. The responsibility is shared in sequence: the Supplier must proactively contact each Buyer to collect their identifier before issuing e-invoices, and the ASP then looks it up in the Peppol directory to validate that it is active and correctly registered, so the invoice reaches the right destination and is not rejected.

Scenario — onboarding a new client. Falcon Industrial Supplies LLC (Supplier) onboarding Emirates Steel (Buyer) sends a formal request: "please provide your Peppol Participant Identifier so we can route electronic invoices directly to your EIS access point." Falcon logs the identifier in its ERP and passes it to its ASP when configuring routing.

Scenario — an invalid identifier. If the ASP queries the directory and finds the identifier is not yet registered — because the Buyer has not completed its own ASP onboarding — the ASP alerts the Supplier that delivery cannot be completed, and the Supplier follows up with the Buyer. This is a common transition-period issue and a strong reason to start early. Suppliers should maintain a register of Peppol Participant Identifiers for all buyers before go-live.

What is a UUID, and who generates it?

A UUID (Universally Unique Identifier) is a 128-bit number, algorithmically generated to ensure every e-invoice in the UAE is uniquely identifiable across the entire EIS with no possibility of duplication. The ASP generates it automatically for every invoice it processes. It is separate from your sequential invoice number (e.g. INV-2026-001), and you cannot manually assign or override it — its purpose is to give the FTA a globally unique, tamper-proof reference for real-time audit and verification.

Scenario — preventing duplication. If a business accidentally submits the same invoice data twice through a system error, the ASP has already assigned a unique UUID to the first submission (for example f47ac10b-58cc-4372-a567-0e02b2c3d479). When the duplicate arrives, the system detects the conflicting record and flags it for rejection, preventing the duplicate from reaching the Buyer or the FTA's records — the kind of error that could trigger a duplicate payment in a paper or PDF world.

What are the e-invoicing deadlines and how should you prepare?

The UAE is rolling e-invoicing out in phases, and the deadlines are binding regardless of whether your counterparties are ready. Both the Supplier and the Buyer must also agree business-specific data security requirements in their respective ASP contracts — a commercial and contractual duty the ASP does not drive. The indicative timeline below reflects the phased rollout under Ministerial Decision No. 243 of 2025 [VERIFY]; because the schedule has been revised before, confirm the current dates against the latest Ministry of Finance and FTA announcements.

Whatever the confirmed dates, the preparation is the same. A short readiness checklist:

1. Select and appoint an accredited ASP — compare providers on our ASP comparison and formalise data-security terms in the contract.
2. Map your ERP to PINT AE — ensure amounts, VAT and totals output in the required format before go-live.
3. Collect Peppol Participant Identifiers — build a register of your buyers' identifiers and confirm each is registered.
4. Test end-to-end — run standard and self-billed flows through the ASP and confirm you receive confirmation messages.

When to include a specific requirement in your ASP agreement is a common question — a healthcare supplier, for example, might insist on UAE data residency, a minimum 5-year retention period, 24-hour breach notification and full access logging. If you are unsure what to look for, our team can review your ASP contract terms.

Key terms in this guide