A UAE e-invoice is a structured data file based on the PINT AE data dictionary, which sets mandatory, conditional and optional fields for each invoice scenario. Core groups are seller and buyer identity, tax registration numbers, invoice number and dates, line items, tax category and amounts, and totals. Some guides cite 51 mandatory fields for a standard tax invoice; check the official dictionary for the exact list.
What the data dictionary is
The Ministry of Finance publishes an e-invoicing data dictionary that defines every field an invoice may carry, which are mandatory, which are conditional on the scenario and which are optional, together with validation rules and code lists. Because it is a technical standard, it also sets the format of each field, such as dates, amounts, units and country codes. The dictionary covers several invoice scenarios, such as standard tax invoices, credit notes, simplified cases and special supplies. Secondary guides report a count of mandatory fields and of scenarios, but those counts depend on the version, so always work from the current official document.
The main groups of data
| Group | Typical content |
|---|---|
| Invoice header | Invoice number, issue date, invoice type, currency, payment terms |
| Seller | Legal name, address, tax registration number, trade licence details where required |
| Buyer | Legal name, address, tax registration number where applicable, network identifier |
| Lines | Description, quantity, unit of measure, unit price, discount, line total |
| Tax | Tax category (standard, zero-rated, exempt, out of scope), rate, taxable amount, tax amount |
| Totals | Total before tax, total tax, total payable, amounts paid or due |
| References | Order or contract number, original invoice for credit notes |
Mandatory, conditional and optional
A mandatory field must always be present. A conditional field is required only in certain cases, such as a credit note reference when the document corrects an earlier invoice, or a reverse charge indicator when the buyer accounts for the tax. An optional field may be sent but is not required. Some items are required only in the human-readable PDF rendering, and others only in the XML. Your ASP will check these rules before sending and will reject a document that fails.
Master data to fix first
- Customer records: exact legal names, tax registration numbers, addresses and country codes.
- Product and service records: clear descriptions, units of measure that map to standard codes and a tax category for each item.
- Tax codes: one code for each treatment you use, including zero-rated, exempt and reverse charge.
- Numbering: one unique invoice number series with no duplicates across systems.
- Currency and rounding: consistent rounding so line totals agree with the invoice total.
Typical rejection causes
- A missing or mistyped buyer tax number.
- A tax amount that does not equal the rate times the taxable amount after rounding.
- A unit of measure that does not map to a standard code.
- A credit note without a reference to the original invoice.
- Free-text fields that exceed the allowed length.
How to test
Build a set of sample invoices that cover each scenario you use: normal sales, discounts, credit notes, advance payments, zero-rated exports and reverse-charge purchases. Run them through your ASP's test environment as soon as it is available. Fix the errors at the source, in master data, not by editing invoices one by one. For the current VAT invoice rules see tax invoice requirements, and for the legal timeline see the e-invoicing timeline.
Scenarios that change the field set
The data dictionary groups its rules by scenario. A normal domestic tax invoice needs the full set of seller, buyer, line and tax data. A credit note needs a reference to the original invoice. An advance payment invoice needs to show how the advance is later applied. A reverse charge supply needs an indicator that the buyer accounts for the tax. An export needs the export treatment and often a customs reference. Map each document type you issue to a scenario in the dictionary and write down the extra fields it needs.
Examples of common data problems
| Problem | Fix |
|---|---|
| Customer name differs between the invoice and the tax record | Use the legal name exactly as on the tax registration |
| Unit of measure entered as free text, for example 'pcs' or 'nos' | Map to the standard code list |
| Tax category left blank on an exempt item | Assign a tax category to every product |
| Discount entered as a negative line | Use the discount fields so totals reconcile |
| Two invoice numbers the same across branches | Use a prefix per branch or one central series |
Checklist before the first test
- Export your customer list and check names and tax numbers against registration records.
- Export your product list and add units and tax categories.
- List document types and scenarios.
- Agree rounding rules with your ASP.
- Decide who fixes data when a validation error appears.
Frequently asked questions
The official definition of the fields, rules and code lists that a UAE e-invoice must follow, published by the Ministry of Finance.
Secondary guides cite 51 for a standard tax invoice, but the number depends on the dictionary version and scenario. Check the official document.
It is required where the buyer is a taxable person in the scenario. Check the dictionary for the case you use.
A field that is required only in specific cases, such as a reference to an original invoice on a credit note.
Missing mandatory data, wrong code values, rounding differences or a failed validation rule.
In master data and system settings, so every invoice benefits, not on individual invoices.