- HOME
- Taxes & compliance
- UAE eInvoicing use cases: scenarios, document types and required data
UAE eInvoicing use cases: scenarios, document types and required data
Most invoices a business issues are the same transaction, repeated. A domestic sale, standard VAT rate, one supplier, one buyer, paid in the ordinary course of business. A UAE eInvoice built for that transaction is straightforward. Real business activity doesn't stay that simple. The Ministry of Finance's rules account for it: a Free Zone counterparty, an export, a client billed monthly instead of per job, or an invoice an agent issues on someone else's behalf. Misclassify one of these and the invoice doesn't just look slightly off. It's missing a field the network requires, carries the wrong electronic address, or gets built as the wrong document type entirely. These mistakes can cause validation failures or leave an invoice with incorrect tax or transaction information.
The Ministry of Finance (MoF) sets out exactly which situations change something, and what, in its Electronic Invoicing Guidelines. This guide walks through them: how many scenarios are officially recognised and what each one requires. It also connects that detail to the document type codes covered in UAE eInvoice Format: PINT AE Mandatory Fields and XML Structure.
Why do UAE eInvoicing scenarios get counted as both 8 and 16?
Two different Ministry documents each name a set of invoice “scenarios,” at two different levels of detail. Section 10.4 of the MoF’s Electronic Invoicing Guidelines v1.1 lists eight scenarios with specific data or invoice-issuance requirements. The Ministry's earlier eInvoicing Data Dictionary, released for public consultation on 19 March 2025, works at a more granular level: 16 invoice scenarios in total. These aren't two counts of the same thing. The Data Dictionary is a consultation-stage document working at field level; This article follows the eight scenarios listed in Guidelines v1.1. A business checking whether its own transaction type needs special handling should start with the 8 below.
Does a scenario change which document type code an invoice uses?
Every UAE eInvoice or credit note carries a type code from a confirmed set of six. Tax invoices use 380, and tax credit notes use 381. Self-billing invoices and credit notes use 389 and 261. Commercial Invoices and commercial credit notes use 480 and 81, which cover exempt as well as out-of-scope supplies, and sales by a person who isn't registered for VAT (full detail in UAE eInvoice Format: PINT AE Mandatory Fields and XML Structure). Guidelines v1.1 doesn't map its 8 scenarios onto a specific one of these six codes. A scenario by itself doesn't determine the code. The code follows the invoice category and the VAT treatment: a Free Zone sale that requires a Tax Invoice is coded 380 or 381, while a Free Zone sale that falls into the Commercial Invoice category is coded 480 or 81. Free Zone status alone decides neither. What a scenario changes is which fields are mandatory and what values they carry. PINT AE records the applicable scenarios separately from the document type, in cbc:ProfileExecutionID. This guide covers what each scenario itself requires.
What are the 8 confirmed UAE eInvoicing scenarios?
Guidelines v1.1, Section 10.4, states this plainly: “There are 8 different scenarios with specific requirements attached to them in terms of mandatory fields and issuance criteria for Electronic Invoices.” Here's what each one changes. This includes whether it applies to a Commercial Invoice (a sale that doesn't require a Tax Invoice at all) as well as to a Tax Invoice:
Scenario | What triggers it | What's specifically required | Commercial Invoice? |
Free Zone | Supplier, buyer, or beneficiary is a Free Zone entity, or the supply takes place within or from a Free Zone | Beneficiary details required when the customer is a Free Zone entity; the customer is whoever issued the purchase order or holds the contracting relationship | Yes |
Deemed supply | A VAT-registered person's supply is deemed a taxable supply for VAT purposes | Buyer's electronic address must always carry the fixed value 0235:9900000097 | No |
Margin scheme | VAT is calculated only on the supplier's margin (resale price minus purchase price) | VAT amount field shows 0, even though PINT AE otherwise mandates the inclusion of VAT information | No |
Summary invoice | Multiple transactions with the same customer over a defined period are consolidated onto one invoice | Certain document-level fields can be zero or a positive number to pass Peppol validation; a negative total has to go on a credit note instead | Yes |
Continuous supply | A supply is provided on an ongoing or recurring basis, or invoiced periodically | Retention-payment calculations (milestone amount, amount withheld) go on a separate commercial document, not the Electronic Invoice itself | Yes |
Agent billing | A disclosed agent issues invoices on behalf of a principal | Obligation to issue the Electronic Invoice stays with the supplier, even when an agent issues it on their behalf | Yes |
Supply through e-Commerce | An electronic commerce supply through an Electronic Commerce Medium (Ministerial Decision No. 26 of 2023) | Obligation to issue the Electronic Invoice stays with the supplier, even when the e-commerce platform issues it | Yes |
Exports | Goods or services are supplied to a customer outside the UAE | If the buyer has no Peppol ID, supplier must include the fixed endpoint 0235:9900000099 | No |
Source: Guidelines v1.1, Section 10.4
Deemed supply and exports to a buyer not registered on Peppol share a mechanism: both use a fixed, predefined Peppol electronic address in place of the buyer's own. The address does more than fill a gap. It identifies a reporting-only case. The PINT AE specification is explicit that in these cases the document need not be exchanged with the buyer's Accredited Service Provider (ASP), and should instead be reported only to the Federal Tax Authority (FTA). So these are not ordinary invoices carrying a substitute address.
A third fixed Peppol address works differently, and it isn't tied to one of the 8 scenarios above at all. Guidelines v1.1, Section 10.2.2, covers standard billing to a buyer that hasn't yet implemented Electronic Invoicing. This can happen, for instance, when that buyer's own mandatory-implementation date under the roll-out plan hasn't arrived yet. In that case, the supplier still has to issue a regular Tax Invoice (in PDF or paper form) to the buyer directly. The supplier also has to issue an Electronic Invoice for reporting purposes. Guidelines v1.1 is explicit that where the buyer has no Participant Identifier, the supplier must include the fixed endpoint 0235:9900000098 on that Electronic Invoice. It's a general fallback for a not-yet-onboarded buyer, not a scenario-specific rule like the other two.
What happens when a business qualifies for more than one scenario at once?
None of the 8 are mutually exclusive, and a single business often qualifies for several. A manufacturer exporting goods from a Free Zone can have both the Free Zone and exports scenarios apply to the same eInvoice. It must meet the requirements of both. A construction contractor billing a client monthly against a project milestone schedule is a continuous-supply case. If that same contractor uses a subcontracted billing agent for part of its portfolio, agent billing applies there too. A retailer selling through both a physical Free Zone showroom and a third-party e-commerce marketplace is working across two of the eight at once.
The document type code still depends on the invoice category and VAT treatment. Your accounting system must also identify every scenario that applies to a transaction and include its required data before generating the eInvoice.
What mistakes do businesses commonly make with these scenarios?
Agent billing and self-billing get treated as the same thing more often than they should. They're not. Agent billing is a disclosed agent issuing an invoice on a principal's behalf, while the principal remains the supplier of record. Self-billing is a separate arrangement, where the buyer issues the invoice for what it purchased, under its own agreement with the supplier. Self-Billing Under UAE eInvoicing: Rules, Workflow and Template covers that second arrangement in full.
The fixed Peppol addresses are easy to miss because they look like placeholder or test data rather than a required field value. A deemed-supply invoice, a no-Peppol-ID export, or a Tax Invoice to a not-yet-onboarded buyer each has its own required fixed endpoint: 0235:9900000097, 0235:9900000099, and 0235:9900000098, respectively. Omitting it means the invoice is missing a mandatory field, not skipping an optional nicety.
Summary invoices are the other common trip point. Building one that nets out to a negative balance, and sending it as an invoice rather than switching to a credit note, fails at the document-type level. That's true regardless of whether the individual fields are otherwise correct.
What do these scenarios change about how a business issues invoices?
The scenarios can affect invoice data and reporting. The PINT AE specification identifies special reporting treatment for deemed supplies, exports where the buyer is not registered on Peppol, and certain buyers outside the ordinary exchange process. In these cases, the electronic document need not be exchanged with the buyer’s ASP and is reported to the FTA instead. The buyer-onboarding case is separate from the eight scenarios discussed above. What changes is what the invoice has to contain and, in a few cases, who's allowed to issue it. Identifying which of these scenarios actually apply to a business's own transaction types is an initial classification exercise against the full customer and transaction list. It's worth revisiting whenever a counterparty, supply model, or the Ministry's own guidance changes, rather than treating it as a one-off check performed once and never returned to.
Zoho is an Accredited Service Provider for UAE eInvoicing.
See how Zoho Books supports UAE eInvoicing.
Frequently asked questions
How many invoice scenarios does UAE eInvoicing recognise?
Guidelines v1.1 names 8 confirmed scenarios, each with its own field or issuance requirements: Free Zone, deemed supply, margin scheme, summary invoice, continuous supply, agent billing, supply through e-commerce, and exports. A separate, earlier Ministry document, the eInvoicing Data Dictionary, works at a more granular level. It covers 16 scenarios in total, at field level rather than at the issuance-rule level Guidelines v1.1 works at.
What changes about an invoice for a Free Zone transaction?
Beneficiary details become required when the customer is a Free Zone entity. The customer itself is defined as whoever issued the purchase order or holds the contracting relationship. That isn't always the same party physically receiving the goods or services.
Do the Margin scheme and Exports scenarios apply to Commercial Invoices?
No. Guidelines v1.1, Section 10.4, marks both as not applying to Commercial Invoices. Free Zone, Summary invoice, Continuous supply, Agent billing and Supply through e-Commerce do apply to Commercial Invoices.
Does a disclosed agent issuing an invoice change who's responsible for it?
No. The supplier remains responsible for the Electronic Invoice even when a disclosed agent issues it on their behalf. The same rule applies when an e-commerce platform issues an invoice for a supplier selling through it.
What happens if an export customer has no Peppol ID?
The supplier includes a fixed, predefined Peppol endpoint (0235:9900000099) on the invoice instead of the buyer's own address. A similar fixed address (0235:9900000097) applies to deemed-supply transactions. A third (0235:9900000098) applies to a buyer that hasn't yet implemented Electronic Invoicing at all.