Check Your E-Invoicing Scope

Your transaction, not the licence, decides scope

The Ministry of Finance June 2026 UAE Electronic Invoicing Guidelines place every Business Transaction of a Person conducting Business in the UAE within the system unless a specific exclusion applies. The guide treats B2B, B2G, G2B and G2G transactions as in scope. That makes the invoice flow the starting object, not the trade-name on the licence or the software used to create the document.

VAT registration is not the deciding switch. The same guide says that all Persons making a Business Transaction in the UAE are within scope notwithstanding their VAT registration status. A UAE entity issuing an invoice to another business therefore needs to document that flow even if its finance team has been thinking about e-invoicing as a VAT project only.

If you are making the decision today, write down who supplies, who buys, which legal entity issues the document and what the buyer uses it for. That short transaction record gives an ASP something testable. A general statement that the company is in or out does not.

Free-zone status does not settle the answer

The Ministry guide does not describe a free-zone licence as a blanket exclusion. It has a separate Free Zone scenario because a transaction may involve a free-zone supplier, buyer or beneficiary, or take place within or from a free zone. Treat the licence as evidence about the entity. Treat the purchase order, contract and invoice as evidence about the transaction.

A business that sells to a government entity has a different scope record from one selling only to natural persons outside Business. The guide expressly includes supplies to Government Entities and excludes supplies to or from natural persons who are not in Business. Your customer master and the signed contract make that distinction visible.

A person without a place of residence in the UAE can also need the electronic form where the VAT Decree-Law requires that person to issue a Tax Invoice. The Ministry guide records that point under non-UAE established persons. Do not let the absence of a UAE office end the review before the invoice obligation is checked.

• Trade licence and legal-entity chart
• Customer contract or purchase order
• Invoice series and issuing system
• Written reason for each exclusion

Separate the rule from the evidence

Build one row for each meaningful invoice stream. Record the issuing entity, customer type, place of supply as understood by the business, invoice or credit-note type and the document that supports the classification. A retail outlet may have consumer sales, corporate account sales and government contracts in the same month. One company description cannot stand in for those separate flows.

Keep the source beside the conclusion. For a business customer, that may be the signed order showing the contracting party and the customer record showing its legal identity. For a government customer, retain the government contract or procurement record. For a consumer flow, retain the channel description and the nature of the buyer. The file is useful because another person can reproduce the decision.

Record exceptions instead of forcing them into the nearest category. A credit note, self-billing arrangement, agent arrangement or transaction with a different beneficiary can alter the data that the electronic document needs. The June guide gives scenario rules, but your scope register should show which actual document caused you to select one.

Make the scope call before the ASP briefing

Start with the legal entities that issue invoices, then group their transactions by buyer type. Compare each group with the Ministry of Finance scope chapter and record the exclusion, if any, beside the source document. Once the list is stable, give every shortlisted ASP the same scope pack. Their answers can then be compared against the same facts.

The practical handover is small but specific. It should show the entity name, invoice stream, sample document, system owner, expected buyer type and open question. If two systems create the same kind of invoice, include both. The provider needs to know whether it is testing one clean source or reconciling a sales platform with an accounting ledger.

If your deadline is close, do not start with provider features. Start by confirming the tax invoice, credit note and contract that define the flow. A provider can help with implementation questions after that record exists. It cannot decide which legal entity actually made the supply from a generic licence copy.

• List entities and invoice streams
• Attach a source document to every conclusion
• Mark mixed or unusual flows as open items
• Send the same scope pack to each ASP

Use the official rule, then show the arithmetic

The Ministry guide says other exclusions may be added in future through Ministerial Decisions. That is the boundary of the published evidence. The current guide does not specify every future exclusion, so an unusual flow that is not covered by a stated exclusion should remain an open question rather than being labelled exempt because the business prefers that result.

The guide's sample Electronic Tax Invoice shows the kind of transaction record an implementation team should be able to trace. It has 2,000 pieces at AED 5 each, so 2,000 x AED 5 = AED 10,000 before VAT. The sample adds AED 500 VAT for AED 10,500, records AED 1,000 paid, and leaves AED 9,500 payable. Scope and totals belong in the same test case.

We would not approve an ASP scope briefing until the licence, contract and customer record agree. In our experience, a vague scope file causes the provider to configure the wrong party flow, then finance discovers the mismatch during the first test and has to rebuild evidence under deadline pressure. We settle the source record first, because a defensible exclusion is worth more than a quick answer.