The UAE Electronic Invoice – Mandatory Fields document (Version 1.0 – 23 February 2026) establishes a structured data framework that every electronic tax invoice must follow. Unlike traditional PDF invoices, the UAE system requires invoices to be generated in a structured XML format containing predefined mandatory data elements.

This blog breaks down the FTA’s mandatory field list into business-friendly sections, so finance teams, tax teams, and IT teams can align on what needs to be captured in the ERP.

Before we go ahead, let’s first take a simple look at how invoices are created today compared to how electronic invoices are generated.

So, this article focuses specifically on the structure and importance of these mandatory fields in an Electronic Tax Invoice.

1. Invoice-Level Mandatory Fields:

At the highest level, the electronic tax invoice must include core invoice identifiers such as:

• Invoice number
• Invoice date
• Invoice type code
• Invoice currency code
• Invoice transaction type code

While these may appear similar to conventional invoice elements, in the electronic environment they perform additional functions:

• The Invoice type code determines the functional classification of the document within the system

• The Invoice currency code means the currency in which all Invoice amounts are given, except for the Total tax amount in accounting currency.

• The Invoice transaction type code is a sequence of flags that identify the invoice transaction types to identify specific supply conditions such as Free Trade Zone transactions, deemed supplies, margin scheme, summary invoice, continuous supply, disclosed agent billing, e-commerce supply, and exports.
• The Specification identifier confirms that the invoice complies with the applicable semantic and technical rules under the prescribed specification.
• The Business process type ensures that the buyer’s system can process the invoice correctly.

2. Seller Identification:

The seller section requires a combination of legal and electronic identifiers, including:

• Seller name
• Seller electronic address (TIN-based)
• Seller electronic identifier
• Legal registration identifier
• Legal registration identifier type
• Seller tax identifier (TRN, where applicable)
• Seller tax scheme code
• Full address details

The requirement to include both electronic and legal identifiers ensures:

• Clear identification of the supplier within the electronic network
• Alignment with Tax Identification Number (TIN) structure
• Consistency between commercial registration and tax registration records

3. Buyer Identification:

The buyer section mirrors similar structured identification elements, including:

• Buyer name
• Buyer electronic address
• Buyer electronic identifier
• Buyer tax identifier (where applicable)
• Buyer address details

For VAT-registered buyers in the UAE, the TRN must be included. This ensures proper tax reporting and correct reverse charge or VAT treatment where relevant.

In a digital environment, incomplete buyer identification may result in rejection or processing failure within the network.

4. Document Totals: Automated Mathematical Integrity

The document totals section requires:

• Sum of invoice line net amounts
• Total amount without tax
• Total tax amount
• Total amount with tax
• Amount due for payment

These totals are not simply summary figures. Because the invoice is structured in XML, the system can automatically:

• Recalculate totals
• Compare line-level data with aggregated totals
• Detect inconsistencies

This reduces manual interpretation and enhances automated validation.

5. Tax Breakdown: Mandatory VAT Structuring

The tax breakdown section introduces structured VAT classification, including:

• Tax category taxable amount
• Tax category tax amount
• Tax category code
• Tax category rate

This means VAT reporting is embedded within the invoice itself at structured level.

Each tax category must correspond to a specific coded classification. The rate must align with the applicable VAT treatment. This structure ensures that tax reporting is digitally traceable and categorized before submission.

6. Invoice Line-Level Detail:

At invoice line level, mandatory fields include:

• Quantity
• Unit of measure code
• Line net amount
• Item net price
• Item gross price
• Base quantity
• Item tax category code
• Item tax rate
• VAT line amount in AED
• Invoice line amount in AED
• Item name
• Item description

This level of granularity allows:

• Line-by-line VAT validation
• Accurate tax categorization per item
• Cross-verification between quantity, price, and total
• Clear traceability for audit purposes

The requirement to express VAT line amounts in AED ensures consistent reporting in accounting currency.

7. Structural Significance of Transaction Type Flags

One of the most technically significant elements is the invoice transaction type code sequence.

This coded sequence identifies whether the invoice involves:

• Free Trade Zone treatment
• Deemed supply
• Margin scheme
• Summary invoice
• Continuous supply
• Disclosed agent billing
• E-commerce supply
• Export transaction

Rather than describing these in narrative form, the system requires binary indicators (applicable / not applicable). This ensures machine-readable compliance classification.

8. Why Mandatory Fields Matter:

As mentioned in the table above, the mandatory field structure achieves three core objectives:

1. Interoperability – Ensures consistent processing across different systems.
2. Tax Reporting Accuracy – Embeds VAT categorization within invoice data.
3. Automated Validation – Enables system-based error detection before acceptance.

In a structured electronic invoicing system, omission or incorrect population of mandatory fields may result in rejection, transmission failure, or reporting inconsistencies.

With this understanding in place, you can now refer to the sample electronic Tax Invoice below, shown in a human-readable format for clarity.