Free-Zone Businesses Need a Scope Review

A free-zone licence is a review point

The Ministry of Finance June 2026 UAE Electronic Invoicing Guidelines do not treat a free-zone licence as a blanket exclusion. They describe a Free Zone scenario where the supplier, buyer or beneficiary is established in a free zone, or where the supply takes place within or from one. The document makes the transaction visible. The licence alone does not make the scope decision.

Start with the legal entity named on the invoice, then identify the customer, the beneficiary and the place where the business says the supply occurs. Keep the trade licence, contract and purchase order together. Those objects answer different questions. The licence identifies the entity. The contract shows the commercial relationship. The invoice shows what the system is being asked to exchange.

Free-zone status also should not be confused with a VAT result. The Ministry guide says electronic invoicing requirements are different from Tax Invoice requirements for VAT purposes. A tax treatment question may sit alongside a scope question, but one document should not be used as a shortcut for the other.

The buyer and end user may be different

For a Free Zone transaction, the Ministry guide says that where the customer is a Free Zone entity, the Electronic Invoice requires beneficiary details in addition to customer details. It describes the beneficiary as the person or entity that ultimately uses, consumes or owns what is supplied. In most standard B2B transactions the buyer and beneficiary may match, but that is a fact to check.

Read the purchase order before filling the beneficiary field. The customer is the person who issued the purchase order or is the contracting party. If the contract says the goods or service will be used by another entity, record that ultimate beneficiary rather than repeating the contracting party in both places. The evidence is the contract, delivery instruction or other business record that names the end user.

The official guide gives the treatment, but it does not state who the beneficiary is in every commercial arrangement where buyer and end user differ. That is a real evidence boundary. Keep the question open when the contract, delivery record and customer master point to different parties. Ask the chosen ASP how its implementation captures the decision.

• Free-zone trade licence
• Signed contract or purchase order
• Beneficiary or delivery record
• Invoice entity and series

Separate the zone, entity and invoice flow

A group may have a mainland company, a free-zone company and a branch using shared finance staff. Do not send the ASP one combined customer list and ask it to infer the issuing entity. Build the map by invoice series and source system. Each row should show the seller, customer, beneficiary where different, currency, tax decision and record owner.

The most useful scope file is built from actual documents. Select one B2B invoice, one government invoice if the business has that stream, one free-zone transaction and one exception such as an export or an agent arrangement. Attach the contract or order that supports each row. A clean file names the fact that caused the classification.

If two entities share an ERP, check the legal registration and tax identifier fields separately. A shared login or common brand does not prove that the seller fields can be shared. The ASP needs the entity boundary because the electronic document is issued by a Person with its own records, not by the group name used in marketing.

Turn the contract trail into a provider test

Give the shortlisted ASP the same free-zone test pack. Include an anonymised contract, the relevant purchase order, the seller record, the buyer record, the beneficiary record and the resulting invoice fields. Ask the provider to show where each party is stored and what happens when the buyer and beneficiary are different. Keep its answer with the test record.

The test should cover the point that makes your business unusual. A warehouse transaction, a service consumed by a related entity or an export from a free zone may not look like the standard sale in your system. Use the actual source fields. A provider that sees only a final PDF cannot tell which value came from the contract and which was typed by hand.

If you are deciding whether the free-zone licence keeps you outside the system, stop at the transaction map. The Ministry's scope material is written around Business Transactions and named scenarios. Resolve the legal entity, buyer and beneficiary first. The answer becomes easier to defend when the source document is attached to the conclusion.

• Choose one free-zone transaction
• Attach contract and beneficiary evidence
• Map every party to a source field
• Retain the ASP response

Do not let a zone label replace the record

The Ministry guide's sample Electronic Tax Invoice contains a useful control even though it is not a free-zone transaction. It shows 2,000 pieces at AED 5, giving 2,000 x AED 5 = AED 10,000. It then records AED 500 VAT and AED 10,500 including VAT. With AED 1,000 paid, the amount due is AED 9,500. Your free-zone test should preserve the same link between party data and totals.

Resolve beneficiary evidence before asking an ASP to configure a free-zone flow, because the provider cannot decide from a licence copy whether the contracting party and ultimate user are the same. The cost of a wrong classification is a test pack that looks complete but names the wrong party. Use the signed contract and delivery record, then put any disagreement in the open-item register.

In our experience, the free-zone entities that struggle are the ones treating scope as a licence question rather than a transaction question. We would not send a free-zone licence to an ASP as the whole brief, because it cannot show who contracted, who benefited or which entity issued the invoice. We attach the contract and beneficiary record first, then ask the provider to test the actual flow.