LEGISLATION, TECHNICAL
UAE E-Invoice Mandatory Fields: The Complete Official List Explained for Finance and ERP Teams
The UAE Ministry of Finance requires 51 specific data fields on every electronic Tax Invoice. Most of this data already exists in your ERP — but some fields are new, and one in particular has caused problems in every country that has launched e-invoicing before the UAE. This article explains every field, where it comes from, and what your team needs to prepare.
reading time: 14 min
SOURCES: MOF OFFICIAL PUBLICATIONS
may 2026
aiverix research
When a UAE e-invoice is transmitted through the Electronic Invoicing System, it must contain specific data fields defined in the PINT AE standard — the UAE’s national customisation of the international Peppol invoice format. The Ministry of Finance published the official list of mandatory fields on 23 February 2026 in a separate document called "UAE Electronic Invoice Mandatory Fields V1.0." This document is the definitive reference for what must appear in every invoice. This article translates it into plain language, explaining each field category, what the field means, where the data comes from in a typical ERP system, and where businesses need to prepare new data that they may not currently capture.
There are two types of electronic invoice in the UAE: an electronic Tax Invoice and a commercial Electronic Invoice. Tax Invoices are issued by VAT-registered businesses for taxable supplies. Commercial Invoices are issued by businesses that are not VAT-registered, or for transactions that do not require a Tax Invoice under UAE VAT law. Both have mandatory fields — and the lists are very similar. The key differences are highlighted throughout this article.
There are two types of electronic invoice in the UAE: an electronic Tax Invoice and a commercial Electronic Invoice. Tax Invoices are issued by VAT-registered businesses for taxable supplies. Commercial Invoices are issued by businesses that are not VAT-registered, or for transactions that do not require a Tax Invoice under UAE VAT law. Both have mandatory fields — and the lists are very similar. The key differences are highlighted throughout this article.
51
Mandatory fields in an electronic Tax Invoice
49
Mandatory fields in a commercial Electronic Invoice
6
Field categories: Invoice Details, Seller, Buyer, Totals, Tax, Line
15
Fields new to UAE PINT not covered under existing VAT law
“
OFFICIAL SOURCE:
UAE Electronic Invoice Mandatory Fields V1.0 — Ministry of Finance, 23 February 2026
UAE Electronic Invoicing Guidelines V1.0 — Ministry of Finance, 23 February 2026
UAE Electronic Invoice Mandatory Fields V1.0 — Ministry of Finance, 23 February 2026
UAE Electronic Invoicing Guidelines V1.0 — Ministry of Finance, 23 February 2026
Why the Field List Matters for Your ERP Team
The most common cause of invoice rejection in every country that has launched mandatory e-invoicing — Saudi Arabia, India, Italy, Singapore — is not a technical integration failure. It is data quality. The ERP sends the invoice successfully. The validation system receives it. And then it rejects the invoice because one field is missing, incorrectly formatted, or contains data that does not match the official record.
Most of the 51 mandatory fields are data your ERP already holds — invoice number, invoice date, seller name, buyer address. But several fields are new requirements that existing accounting systems were not designed to capture. Your ERP integration team needs to know about these before implementation, not after the first wave of rejections.
Most of the 51 mandatory fields are data your ERP already holds — invoice number, invoice date, seller name, buyer address. But several fields are new requirements that existing accounting systems were not designed to capture. Your ERP integration team needs to know about these before implementation, not after the first wave of rejections.
“
All Persons and Government Entities should carry out a gap analysis of the requirements against its activities, to understand the specific categories of Electronic Invoices required for each of its transactions and the data points required to be included on those Electronic Invoices.
Category 1: Invoice Details (Fields 1–9)
These fields describe the invoice itself — its identity, type, and payment information. Most come from your accounting system automatically. Two of them are entirely new to UAE e-invoicing and do not exist in traditional invoice formats.
Invoice Details — Fields 1 to 9.
Field 5 in detail: The Invoice Transaction Type Code
This field is the one most likely to cause problems if your ERP team does not prepare for it. It is a sequence of eight digits — each digit is either 1 (meaning that scenario applies to this invoice) or 0 (meaning it does not apply). The eight positions represent eight special transaction scenarios in this exact order:
X
Disclosed Agent Billing
X
E-Commerce
X
Exports
X
Continuous Supply
X
Summary Invoice
X
Margin Scheme
X
Deemed Supply
X
Free Trade Zone
For a standard B2B invoice with none of these scenarios — the most common type — all eight digits are 0: 0
For an invoice that is an export transaction, the eighth digit is 1: 1
For an invoice that involves a free zone buyer and is also a continuous supply, the first and fifth digits are 1: 10 001 000
Why does this matter for your ERP team? Because most ERP systems do not have a single field called "invoice transaction type code." Your team needs to map each of the eight scenarios to logic within your ERP — so that when an invoice is generated for a free zone buyer, or for an export, or for a monthly retainer, the correct flag string is produced automatically. This requires configuration work before go-live. It cannot be fixed manually after the fact for every invoice.
For an invoice that is an export transaction, the eighth digit is 1: 1
For an invoice that involves a free zone buyer and is also a continuous supply, the first and fifth digits are 1: 10 001 000
Why does this matter for your ERP team? Because most ERP systems do not have a single field called "invoice transaction type code." Your team needs to map each of the eight scenarios to logic within your ERP — so that when an invoice is generated for a free zone buyer, or for an export, or for a monthly retainer, the correct flag string is produced automatically. This requires configuration work before go-live. It cannot be fixed manually after the fact for every invoice.
Category 2: Seller Details (Fields 10–20)
These fields identify your business — the company issuing the invoice. Most come from your company master data in the ERP. Two fields are new to UAE e-invoicing and require specific attention.
Seller Details — Fields 10 to 20.
COMMON DATA QUALITY ISSUE — SELLER NAME
Field 10 (Seller name) must match your legal name exactly as it appears in the UAE official registry. Many businesses use shortened names, trading names, or transliterations in their ERP systems that differ from the official registered name. This is one of the most common causes of validation failures. Check your ERP company master record against your actual trade licence before go-live.
Field 10 (Seller name) must match your legal name exactly as it appears in the UAE official registry. Many businesses use shortened names, trading names, or transliterations in their ERP systems that differ from the official registered name. This is one of the most common causes of validation failures. Check your ERP company master record against your actual trade licence before go-live.
Category 3: Buyer Details (Fields 21–29)
These fields identify the buyer — the business receiving the invoice. This category is where most data quality problems occur in practice, because the seller depends on data provided by the buyer, and buyers do not always provide accurate or complete information.
Buyer Details — Fields 21 to 29.
THE MOST IMPORTANT PRE-GO-LIVE TASK: BUYER DATA AUDIT
Fields 22 and 24 — the buyer’s Peppol ID and TRN — are the two fields most likely to be missing or incorrect in your current ERP customer master data. Your ERP was not designed to store Peppol IDs because they did not exist before e-invoicing. And TRNs are often stored inconsistently, or not verified against the FTA’s official registry.
Before go-live, you need to review every active customer record and collect or verify: the buyer’s TRN (for Tax Invoices), the buyer’s Peppol ID (0235: followed by their 10-digit TIN), and the buyer’s legal name as it appears in official registrations.
This is an administrative task, not a technical one — but it takes time. Italy’s SDI rollout showed that businesses that left this for the last two weeks before go-live were still correcting customer data months after their mandatory date.
Fields 22 and 24 — the buyer’s Peppol ID and TRN — are the two fields most likely to be missing or incorrect in your current ERP customer master data. Your ERP was not designed to store Peppol IDs because they did not exist before e-invoicing. And TRNs are often stored inconsistently, or not verified against the FTA’s official registry.
Before go-live, you need to review every active customer record and collect or verify: the buyer’s TRN (for Tax Invoices), the buyer’s Peppol ID (0235: followed by their 10-digit TIN), and the buyer’s legal name as it appears in official registrations.
This is an administrative task, not a technical one — but it takes time. Italy’s SDI rollout showed that businesses that left this for the last two weeks before go-live were still correcting customer data months after their mandatory date.
Category 4: Document Totals (Fields 30–34)
These five fields summarise the financial totals for the entire invoice. All of them come from your accounting system and are calculated automatically. They must be mathematically consistent — the system will reject invoices where the totals do not add up correctly.
Document Totals — Fields 30 to 34.
IMPORTANT: ROUNDING RULES
Rounding is only permitted at the invoice total level — up to 2 decimal places. Rounding is not permitted at the individual line-item level or at the tax category level. This is a technical rule that your ERP must be configured to follow. It is the same issue that caused mass SAP rejections in Italy, where the system calculated at 4 decimal places and then rounded differently from the validation system.
Rounding is only permitted at the invoice total level — up to 2 decimal places. Rounding is not permitted at the individual line-item level or at the tax category level. This is a technical rule that your ERP must be configured to follow. It is the same issue that caused mass SAP rejections in Italy, where the system calculated at 4 decimal places and then rounded differently from the validation system.
Category 5: Tax Breakdown (Fields 35–38)
These four fields provide a detailed breakdown of tax by category. Because UAE invoices can include multiple tax categories on the same invoice — for example, standard-rated items and zero-rated items — this section must be repeated for each tax category that appears on the invoice.
Tax Breakdown — Fields 35 to 38.
The UAE currently uses six tax category codes in electronic invoices: Standard Rate (5% VAT), Exempt from VAT, Out of Scope of VAT, Reverse Charge, Zero Rated, and Margin Scheme. Your ERP must be configured to apply the correct category code to each transaction type your business issues. Using the wrong category code does not always cause immediate rejection — but it creates a VAT reporting discrepancy that the FTA will see in real time.
Category 6: Invoice Line (Fields 39–51)
These fields describe each individual line item on the invoice — each product or service you are billing for. This section is repeated for every line on the invoice. Two fields in this category are new to UAE e-invoicing and are particularly important for businesses that invoice in currencies other than AED.
Invoice Line — Fields 39 to 51.
CRITICAL FOR BUSINESSES THAT INVOICE IN FOREIGN CURRENCIES
Fields 48 and 49 — VAT line amount in AED and Invoice line amount in AED — are mandatory on every Tax Invoice line, regardless of what currency the invoice is issued in. If you invoice in USD, EUR, or any other currency, you must also state both the VAT amount and the total line amount in AED on every single line.
The conversion must use the Central Bank of UAE’s official exchange rate. Most ERP systems do not automatically apply Central Bank rates — they use their own rate tables. This requires specific configuration to ensure the correct rate is applied and the AED amounts are calculated and stored as separate fields on every invoice line.
This is a new requirement that does not exist under current UAE VAT law for paper or PDF invoices. It affects every business that bills international clients in foreign currencies.
Fields 48 and 49 — VAT line amount in AED and Invoice line amount in AED — are mandatory on every Tax Invoice line, regardless of what currency the invoice is issued in. If you invoice in USD, EUR, or any other currency, you must also state both the VAT amount and the total line amount in AED on every single line.
The conversion must use the Central Bank of UAE’s official exchange rate. Most ERP systems do not automatically apply Central Bank rates — they use their own rate tables. This requires specific configuration to ensure the correct rate is applied and the AED amounts are calculated and stored as separate fields on every invoice line.
This is a new requirement that does not exist under current UAE VAT law for paper or PDF invoices. It affects every business that bills international clients in foreign currencies.
Key Differences: Tax Invoice vs Commercial Invoice
The commercial Electronic Invoice — issued by non-VAT-registered businesses or for non-taxable transactions — has 49 mandatory fields compared to 51 for a Tax Invoice. The differences are small but important to understand.
The 15 Fields That Are New to UAE E-Invoicing
The official Mandatory Fields document notes that 15 fields are required under UAE PINT but are not currently covered under existing UAE VAT law. This means your ERP was not designed to capture them. These are the fields that require the most preparation work before go-live.
The most important among these are: the invoice transaction type code (Field 5), the seller electronic address and identifier (Fields 11−12), the seller legal registration identifier type (Field 14), the buyer electronic address and identifier (Fields 22−23), and the VAT line amount in AED and invoice line amount in AED (Fields 48−49). Each of these requires either a new data field in your ERP, a configuration change, or a new data collection process for your customer master records.
The most important among these are: the invoice transaction type code (Field 5), the seller electronic address and identifier (Fields 11−12), the seller legal registration identifier type (Field 14), the buyer electronic address and identifier (Fields 22−23), and the VAT line amount in AED and invoice line amount in AED (Fields 48−49). Each of these requires either a new data field in your ERP, a configuration change, or a new data collection process for your customer master records.
WHAT YOUR ASP HANDLES — SO YOU DO NOT HAVE TO
Your Accredited Service Provider handles the technical conversion and transmission. Specifically, your ASP: converts your ERP data into PINT AE XML format; generates the UUID (a unique identifier for each invoice — you do not need to create this); digitally signs each invoice before transmission; routes the invoice to the buyer’s ASP via the Peppol network; reports tax data to the FTA; and monitors for validation errors.
Your team’s responsibility is to ensure that the source data in your ERP is correct and complete — including all 51 mandatory fields. Your ASP cannot fix missing or incorrect data — it can only validate what you send and alert you when something fails.
Your Accredited Service Provider handles the technical conversion and transmission. Specifically, your ASP: converts your ERP data into PINT AE XML format; generates the UUID (a unique identifier for each invoice — you do not need to create this); digitally signs each invoice before transmission; routes the invoice to the buyer’s ASP via the Peppol network; reports tax data to the FTA; and monitors for validation errors.
Your team’s responsibility is to ensure that the source data in your ERP is correct and complete — including all 51 mandatory fields. Your ASP cannot fix missing or incorrect data — it can only validate what you send and alert you when something fails.
What to Do Before Your Implementation Begins
The most productive preparation your finance and ERP team can do before working with an ASP is a data gap analysis. Go through the 51 mandatory fields listed in this article and ask, for each one: does our ERP currently capture this data? Is it in the correct format? Is it consistently populated for all customers and transactions?
The fields that most commonly reveal gaps are: buyer TRN (field 24), buyer Peppol ID (field 22), seller legal registration identifier type (field 14), invoice transaction type code (field 5), and VAT line amount in AED for non-AED invoices (field 48). These are the fields where the data either does not exist in most ERP systems or exists in an inconsistent format that requires cleansing before go-live.
Aiverix conducts a full data readiness review as part of our no-cost compliance assessment — including a gap analysis of your ERP data against the 51 mandatory fields, an assessment of your customer master records, and a realistic implementation timeline for your specific ERP environment. Request your assessment at aiverix.ae.
The fields that most commonly reveal gaps are: buyer TRN (field 24), buyer Peppol ID (field 22), seller legal registration identifier type (field 14), invoice transaction type code (field 5), and VAT line amount in AED for non-AED invoices (field 48). These are the fields where the data either does not exist in most ERP systems or exists in an inconsistent format that requires cleansing before go-live.
Aiverix conducts a full data readiness review as part of our no-cost compliance assessment — including a gap analysis of your ERP data against the 51 mandatory fields, an assessment of your customer master records, and a realistic implementation timeline for your specific ERP environment. Request your assessment at aiverix.ae.