MARKET INSIGHTS
UAE E-Invoicing Special Scenarios: Free Zones, Tax Groups, Exports, Deemed Supply and More
The UAE Electronic Invoicing Guidelines identify eight specific transaction scenarios — each with additional data requirements, different field rules, and specific ERP configuration needs. If your business operates in a free zone, exports goods or services, issues invoices on behalf of another party, or has continuous supply arrangements, this article explains exactly what applies to you.
reading time: 13 min
SOURCES: MOF OFFICIAL PUBLICATIONS
may 2026
aiverix research
Most explanations of UAE e-invoicing focus on the standard case — a business issues a straightforward invoice to another business, the invoice is transmitted through the Peppol network, the buyer receives structured data. That standard case covers the majority of B2B transactions in the UAE. But a large number of UAE businesses have transaction types that fall outside the standard case — and for those transactions, the rules are more specific. The UAE Electronic Invoicing Guidelines identify eight special scenarios in Section 10.4, each with its own additional requirements. This article covers every scenario, explains what makes it different from a standard invoice, and tells you what your ERP team needs to configure before go-live.
“
OFFICIAL SOURCE:
UAE Electronic Invoicing Guidelines V1.0, Sections 6.3 and 10.4 — Ministry of Finance, 23 February 2026
UAE Electronic Invoice Mandatory Fields V1.0, Section 4 — Ministry of Finance, 23 February 2026
UAE Electronic Invoicing Guidelines V1.0, Sections 6.3 and 10.4 — Ministry of Finance, 23 February 2026
UAE Electronic Invoice Mandatory Fields V1.0, Section 4 — Ministry of Finance, 23 February 2026
Before the Scenarios: The Transaction Type Code
Every UAE electronic invoice contains a mandatory field called the Invoice Transaction Type Code — an 8-character binary string where each position represents one of the eight special scenarios. When a scenario applies to a transaction, the corresponding digit is 1. When it does not apply, the digit is 0.
For a completely standard invoice with none of these scenarios, all eight digits are zero: 00000000. Each scenario described in this article corresponds to one of these eight digit positions. The positions, from left to right, are: Free Trade Zone, Deemed Supply, Margin Scheme, Summary Invoice, Continuous Supply, Disclosed Agent Billing, E-Commerce, Exports.
Your ERP must be configured to set this code correctly for every transaction type your business issues. Getting this wrong does not always cause an immediate hard rejection — but it creates a classification error in the FTA’s records that will surface during reconciliation. Understanding which scenarios apply to your business is therefore the essential first step before your ERP team touches any configuration.
For a completely standard invoice with none of these scenarios, all eight digits are zero: 00000000. Each scenario described in this article corresponds to one of these eight digit positions. The positions, from left to right, are: Free Trade Zone, Deemed Supply, Margin Scheme, Summary Invoice, Continuous Supply, Disclosed Agent Billing, E-Commerce, Exports.
Your ERP must be configured to set this code correctly for every transaction type your business issues. Getting this wrong does not always cause an immediate hard rejection — but it creates a classification error in the FTA’s records that will surface during reconciliation. Understanding which scenarios apply to your business is therefore the essential first step before your ERP team touches any configuration.
8
Special transaction scenarios with additional data requirements
8
Digits in the invoice transaction type code — one per scenario
6
UAE tax category codes — each scenario may require a specific one
3
Predefined Peppol endpoints for non-standard buyer routing
The Eight Special Scenarios
1. Free Trade Zone
Transaction type code position 1 · Flag: 10000000
A free zone transaction is any transaction where the supplier, buyer, or beneficiary is a free zone entity — or where the supply itself takes place within or from a free zone. Examples include: a supply made to a company established in DIFC, JAFZA, or any other UAE free zone; goods supplied within a free zone; goods exported from a free zone; and services provided by a free zone entity to a mainland business.
Additional Data Requirement
When the buyer is a free zone entity, the invoice must include beneficiary details in addition to the standard customer information. The beneficiary is the person or entity that ultimately uses, receives, or owns what is being supplied. In most standard B2B transactions, the beneficiary and the customer are the same legal entity — so the same information simply appears in both fields. But if the ultimate user of the supply is different from the contracting party, both must be separately identified on the invoice.
Practical Rule for Most Free Zone Invoices
The customer is the entity that issued the purchase order or is the contracting party. If the end user declared a different person as the beneficiary, that person’s details go in the beneficiary field. If no other beneficiary is declared, duplicate the customer details in the beneficiary fields. This ensures the invoice is technically complete without implying a third party is involved.
This scenario applies to both Tax Invoices and Commercial Invoices.
Applies to: Tax Invoices ✓ Commercial Invoices ✓
ERP action: Add beneficiary fields to free zone customer records. Configure flag position 1 = 1 for free zone transactions.
Applies to: Tax Invoices ✓ Commercial Invoices ✓
ERP action: Add beneficiary fields to free zone customer records. Configure flag position 1 = 1 for free zone transactions.
2. Deemed Supply
Transaction type code position 2 · Flag: 01000000
A deemed supply is a transaction that UAE VAT law treats as a taxable supply even though no commercial sale has taken place. Common examples include: goods given free of charge that exceed the prescribed threshold, such as gifts or promotional items; private use of business assets or inventory by the owner or employees; and goods and services owned by a taxable person at the date their VAT registration is cancelled.
Fixed Buyer Peppol Address
For deemed supply transactions, the buyer’s electronic address (the Peppol ID field) must always be set to the fixed predefined endpoint: 0235:9 900 000 097. This value does not change based on who the ultimate recipient is. It is a fixed routing value that tells the Peppol network this is a deemed supply with no specific buyer endpoint.
When No Invoice is Issued to a Recipient
In some deemed supply situations — for example, a business disposing of assets — no invoice is actually sent to a recipient. In these cases there is no exchange of electronic invoices between parties. Only the supplier’s ASP reports the tax data to the FTA (Corner 5). The buyer side of the 5-corner model does not apply.
This scenario does not apply to Commercial Invoices — deemed supply is a VAT concept that only applies to taxable persons issuing Tax Invoices.
Applies to: Tax Invoices ✓ Commercial Invoices ✗
ERP action: Set buyer Peppol address to 0235:9 900 000 097 for deemed supply transactions. Configure flag position 2 = 1.
Applies to: Tax Invoices ✓ Commercial Invoices ✗
ERP action: Set buyer Peppol address to 0235:9 900 000 097 for deemed supply transactions. Configure flag position 2 = 1.
3. Margin Scheme
Transaction type code position 3 · Flag: 00100000
The margin scheme applies to transactions where UAE VAT is calculated only on the supplier’s profit margin — the difference between the purchase price and the resale price — rather than on the full transaction value. It is most commonly used by car dealers selling second-hand vehicles, art galleries reselling works purchased from private collectors who are not VAT-registered, and dealers in second-hand goods of various kinds.
VAT Amount Display Rule
Under UAE VAT law and the VAT Executive Regulation, the VAT amount is not required to be shown on the invoice for margin scheme transactions — the margin itself is not disclosed to the buyer. The VAT amount field on the invoice must therefore be set to zero (0). This is intentional and correct — it is not an error. The tax is reported to the FTA by the supplier’s ASP in the background, even though it does not appear on the face of the invoice.
This scenario does not apply to Commercial Invoices — the margin scheme is a VAT mechanism and applies only to taxable persons.
Applies to: Tax Invoices ✓ Commercial Invoices ✗
ERP action: Configure VAT amount = 0 for margin scheme transactions. Set tax category code to M (Margin Scheme). Configure flag position 3 = 1.
Applies to: Tax Invoices ✓ Commercial Invoices ✗
ERP action: Configure VAT amount = 0 for margin scheme transactions. Set tax category code to M (Margin Scheme). Configure flag position 3 = 1.
4. Summary Invoice
Transaction type code position 4 · Flag: 00010000
A summary invoice consolidates multiple transactions with the same customer over a defined billing period into a single invoice. This is a common practice in industries where many small transactions occur with the same party — for example, a bank that issues a monthly consolidated invoice for all fees charged to a corporate client, or a utilities company that consolidates multiple service charges into a single monthly document.
Validation Rule for Totals
For summary invoices, certain fields at the document level — including the total payable amount — can be zero or a positive number and will still pass Peppol validation. However, there is an important rule: if the total payable amount across all consolidated transactions is negative — meaning the customer is owed money rather than owing money — the transaction must be documented using an Electronic Credit Note, not a summary invoice. A summary invoice cannot carry a negative total.
Summary invoices apply to both Tax Invoices and Commercial Invoices.
Applies to: Tax Invoices ✓ Commercial Invoices ✓
ERP action: Ensure billing period fields are populated. If consolidated total is negative, issue Credit Note instead. Configure flag position 4 = 1.
Applies to: Tax Invoices ✓ Commercial Invoices ✓
ERP action: Ensure billing period fields are populated. If consolidated total is negative, issue Credit Note instead. Configure flag position 4 = 1.
5. Continuous Supply
Transaction type code position 5 · Flag: 00001000
Continuous supply covers transactions that are provided on an ongoing or recurring basis, or that include periodic invoicing. Common examples in the UAE context are: monthly advisory or consultancy retainer fees, instalment deliveries of construction materials where each delivery triggers a partial invoice, milestone-based payments on project contracts, and any subscription-type service billed regularly.
Retention Payment Rule – Important for Construction and Projects
For business transactions that involve retention payments — where a percentage of each invoice is held back by the buyer and released at project completion — the calculation of the milestone amount and the deduction of the retained amount must appear in a separate commercial document, not on the electronic invoice itself. The electronic invoice should show only the amount due for payment at that billing point. When the retained amount is eventually released and payment is due, a new electronic Tax Invoice is issued for the retained amount, with the applicable VAT.
This rule affects many UAE businesses in construction, engineering, professional services, and long-term project delivery. If your contracts include retention clauses, your invoicing process needs to separate the retention calculation from the invoice transmission before go-live.
Continuous supply applies to both Tax Invoices and Commercial Invoices.
Applies to: Tax Invoices ✓ Commercial Invoices ✓
ERP action: Separate retention calculations from invoice data. Configure billing period fields. Configure flag position 5 = 1 for recurring invoices.
Continuous supply applies to both Tax Invoices and Commercial Invoices.
Applies to: Tax Invoices ✓ Commercial Invoices ✓
ERP action: Separate retention calculations from invoice data. Configure billing period fields. Configure flag position 5 = 1 for recurring invoices.
6. Disclosed Agent Billing
Transaction type code position 6 · Flag: 00000100
Disclosed agent billing applies when a person acts as a disclosed agent — meaning the buyer knows they are dealing with an agent, not the principal — and issues invoices on behalf of the principal. A common UAE example is an insurance broker that collects premiums from corporate clients on behalf of a VAT-registered insurance company. The broker issues the invoice but is acting as agent for the insurer.
Compliance Responsibility Stays with the Supplier
Even when an agent issues an invoice on behalf of a principal, the legal responsibility for e-invoicing compliance remains with the supplier — the principal, not the agent. If the agent issues the invoice, the agent is acting on the supplier’s behalf. The supplier cannot transfer their compliance obligation to the agent. This means the invoice must still be transmitted through an ASP that is either the supplier’s ASP or an ASP authorised to act on the supplier’s behalf.
This scenario does not apply to undisclosed agents — where the buyer does not know they are dealing with an agent. Undisclosed agent transactions follow standard invoicing rules. Only disclosed agent arrangements activate this scenario flag.
Applies to: Tax Invoices ✓ Commercial Invoices ✓
ERP action: Confirm whether agent has authority to transmit via supplier’s ASP. Configure flag position 6 = 1 for disclosed agent invoices.
Applies to: Tax Invoices ✓ Commercial Invoices ✓
ERP action: Confirm whether agent has authority to transmit via supplier’s ASP. Configure flag position 6 = 1 for disclosed agent invoices.
7. Supply Through E-Commerce
Transaction type code position 7 · Flag: 00000010
This scenario applies to electronic commerce supplies made through an Electronic Commerce Medium as defined by Ministerial Decision No. 26 of 2023. In practice, this covers businesses that sell products or services through online platforms, websites, or digital marketplaces — either directly to buyers or through third-party e-commerce platforms.
Platform Invoice Rule
Where an e-commerce platform issues an invoice on behalf of the seller, the compliance responsibility still sits with the supplier — the seller, not the platform. The platform may issue the invoice as agent, but the underlying obligation to ensure that invoice is transmitted correctly through a certified ASP remains with the business that made the supply. Sellers using third-party platforms need to confirm that the platform either handles EIS compliance correctly or that the seller has a separate ASP integration to handle it.
This scenario applies to both Tax Invoices and Commercial Invoices. Note that B2C e-commerce transactions — where the buyer is an individual consumer, not a business — are not in scope for the e-invoicing mandate. This scenario only activates for B2B e-commerce transactions.
Applies to: Tax Invoices ✓ Commercial Invoices ✓ (B2B only)
ERP action: Confirm e-commerce platform’s EIS compliance approach. Configure flag position 7 = 1 for B2B e-commerce invoices.
Applies to: Tax Invoices ✓ Commercial Invoices ✓ (B2B only)
ERP action: Confirm e-commerce platform’s EIS compliance approach. Configure flag position 7 = 1 for B2B e-commerce invoices.
8. Exports
Transaction type code position 8 · Flag: 00000001
Export transactions are supplies of goods or services made to customers located outside the UAE. A UAE wholesaler exporting cosmetics to a retailer in Kuwait, or a UAE IT company providing software development to a client in France, are both export transactions. For VAT purposes, qualifying exports are zero-rated — meaning VAT is charged at 0%. The invoice must still be issued as an electronic invoice and transmitted through the EIS, and the VAT Tax Invoice for customs purposes should also be issued as an electronic invoice.
When the Buyer Has No Peppol ID
Export buyers — companies outside the UAE — will not in most cases have a UAE Peppol Participant Identifier. When the buyer does not have a Peppol ID, the supplier must use the predefined FTA export endpoint: 0235:9 900 000 099. This routes the invoice through the FTA’s system correctly and ensures the tax data is reported, even though no buyer ASP is involved in the delivery.
Customs Information Fields
For export transactions where the supplier wants to declare customs information, two optional fields are available: the Customs Reference Number and the Incoterms field. These are not mandatory but are available for businesses that need to align their electronic invoice with customs documentation.
This scenario does not apply to Commercial Invoices — export Tax Invoices are issued by VAT-registered taxable persons and must include the applicable zero-rated VAT treatment.
Applies to: Tax Invoices ✓ Commercial Invoices ✗
ERP action: Set buyer Peppol address to 0235:9 900 000 099 for export buyers without UAE Peppol ID. Configure flag position 8 = 1 for all export invoices.
Applies to: Tax Invoices ✓ Commercial Invoices ✗
ERP action: Set buyer Peppol address to 0235:9 900 000 099 for export buyers without UAE Peppol ID. Configure flag position 8 = 1 for all export invoices.
Additional Special Situations from Section 6.3
Beyond the eight transaction scenarios in Section 10.4, the Guidelines also address two specific entity types in Section 6.3 that have their own distinct rules: investment holding companies and tax groups.
Investment Holding Companies
A holding company that generates only passive income — dividends, interest, or rental income from subsidiaries — and conducts no business transactions is not in scope for electronic invoicing. The absence of business transactions is the key test.
However, if a holding company performs any recharges to related or third parties — management fees, shared service costs, intercompany loans with interest, or any other commercial arrangement — those recharges constitute business transactions. The holding company is then in scope and must issue electronic invoices for those transactions from its mandatory date.
However, if a holding company performs any recharges to related or third parties — management fees, shared service costs, intercompany loans with interest, or any other commercial arrangement — those recharges constitute business transactions. The holding company is then in scope and must issue electronic invoices for those transactions from its mandatory date.
HOLDING COMPANIES — THE COMMON TRAP
Most UAE holding companies do conduct intercompany transactions — even if they were structured to minimise them. A management services agreement between the holdco and its subsidiaries, a shared services arrangement, or an intercompany loan with a documented interest charge are all business transactions that bring the holding company into scope.
Do not assume a holding company is out of scope without specifically reviewing its intercompany transaction history and contractual arrangements. The test is whether any transaction constitutes a business activity — not whether the entity is structured as a holding vehicle.
Most UAE holding companies do conduct intercompany transactions — even if they were structured to minimise them. A management services agreement between the holdco and its subsidiaries, a shared services arrangement, or an intercompany loan with a documented interest charge are all business transactions that bring the holding company into scope.
Do not assume a holding company is out of scope without specifically reviewing its intercompany transaction history and contractual arrangements. The test is whether any transaction constitutes a business activity — not whether the entity is structured as a holding vehicle.
Tax Groups
UAE VAT groups — where two or more entities are registered with the FTA as a single taxable person — require careful handling under the e-invoicing framework. The key rules are:
Transactions between members of the same VAT group are in scope under MD No. 243 of 2025 and are not excluded simply because they are intra-group. However, a 24-month grace period applies for intra-group transactions only, starting January 1, 2027 and running through January 1, 2029. During this period, electronic invoicing is not required for transactions between VAT group members. After January 1, 2029, it becomes fully mandatory.
Each Tax Group member has its own TIN — the first 10 digits of its own Corporate Tax TRN. The group representative’s TIN does not cover other members. Each member must be individually onboarded via EmaraTax and may use a different ASP from other group members. Transactions with parties outside the group are fully in scope from the standard mandatory date — the grace period only covers intra-group transactions.
Transactions between members of the same VAT group are in scope under MD No. 243 of 2025 and are not excluded simply because they are intra-group. However, a 24-month grace period applies for intra-group transactions only, starting January 1, 2027 and running through January 1, 2029. During this period, electronic invoicing is not required for transactions between VAT group members. After January 1, 2029, it becomes fully mandatory.
Each Tax Group member has its own TIN — the first 10 digits of its own Corporate Tax TRN. The group representative’s TIN does not cover other members. Each member must be individually onboarded via EmaraTax and may use a different ASP from other group members. Transactions with parties outside the group are fully in scope from the standard mandatory date — the grace period only covers intra-group transactions.
The Three Predefined Peppol Endpoints — Quick Reference
Several special scenarios require the use of predefined FTA endpoint addresses when a buyer does not have or cannot be identified by a standard Peppol ID. Here is the complete reference:
Four Scenarios: The Real Cost Comparison
The following four scenarios show what non-compliance actually costs — compared to what planned compliance costs — for a typical Wave 1 business issuing 200 invoices per month.
Which Scenarios Apply to Your Business?
Most businesses in the UAE will have at least one or two of these scenarios active. Use this quick reference to identify which apply to you.
ONE INVOICE CAN HAVE MULTIPLE SCENARIOS ACTIVE
The Guidelines confirm that an invoice can capture multiple different scenarios within a single electronic invoice. If more than one scenario applies to a supply, the specific requirements for each applicable scenario must all be included.
For example: an invoice for goods exported from a UAE free zone to a buyer in Saudi Arabia would have both the Free Trade Zone flag (position 1) and the Exports flag (position 8) set to 1. The invoice transaction type code would be 10000001. It would also need to include beneficiary details for the free zone and use the export predefined endpoint for the foreign buyer.
Your ERP must be configured to handle combinations, not just individual scenarios in isolation.
The Guidelines confirm that an invoice can capture multiple different scenarios within a single electronic invoice. If more than one scenario applies to a supply, the specific requirements for each applicable scenario must all be included.
For example: an invoice for goods exported from a UAE free zone to a buyer in Saudi Arabia would have both the Free Trade Zone flag (position 1) and the Exports flag (position 8) set to 1. The invoice transaction type code would be 10000001. It would also need to include beneficiary details for the free zone and use the export predefined endpoint for the foreign buyer.
Your ERP must be configured to handle combinations, not just individual scenarios in isolation.
What to Do with This Information
The practical output of reading this article should be a list of which scenarios apply to your business. Go through each of the eight scenarios and ask: do we have transactions of this type? For most UAE businesses the answer will be yes to at least two or three — free zone customers and export transactions are particularly common across trading, professional services, and manufacturing sectors.
Once you know which scenarios apply, you have two preparation tasks before working with your ASP on integration. First, confirm that your ERP customer master records contain the additional data required for each scenario — particularly beneficiary details for free zone customers and the correct Peppol endpoint or predefined address for each buyer type. Second, brief your ERP configuration team on the invoice transaction type code and which flag positions must be set to 1 for which transaction types. This is the field that causes the most silent errors — invoices that transmit successfully but carry incorrect classification data.
Aiverix conducts a transaction type assessment as part of our no-cost compliance assessment — reviewing your business’s transaction mix, identifying which of the eight scenarios apply, and configuring the invoice transaction type code correctly for each category. Request yours at aiverix.ae.
Once you know which scenarios apply, you have two preparation tasks before working with your ASP on integration. First, confirm that your ERP customer master records contain the additional data required for each scenario — particularly beneficiary details for free zone customers and the correct Peppol endpoint or predefined address for each buyer type. Second, brief your ERP configuration team on the invoice transaction type code and which flag positions must be set to 1 for which transaction types. This is the field that causes the most silent errors — invoices that transmit successfully but carry incorrect classification data.
Aiverix conducts a transaction type assessment as part of our no-cost compliance assessment — reviewing your business’s transaction mix, identifying which of the eight scenarios apply, and configuring the invoice transaction type code correctly for each category. Request yours at aiverix.ae.