UAE E-Invoicing Mandatory & Optional Fields: The Complete Guide

Most guides to UAE e-invoicing describe field requirements in general terms — "TRN is mandatory," "invoice date is required" — without pointing to where that comes from or how many fields there actually are in total. This guide works directly from the Ministry of Finance's own published reference, field by field, and cross-checks it against a real, working PINT-AE XML generator to show what "mandatory" and "optional" actually look like in practice.

Two Field Lists, Not One

Almost every third-party guide to UAE e-invoicing talks about "the mandatory fields" as a single list. The Ministry of Finance's own reference document doesn't work that way — it publishes two separate mandatory-field lists, depending on the document type:

The document also says it should be read alongside three other official references: the UAE Electronic Invoicing System Guidelines, Ministerial Decision No. 243 of 2025 (on the Electronic Invoicing System itself), and Ministerial Decision No. 244 of 2025 (on the phased implementation timeline) — plus the Peppol United Arab Emirates electronic document specifications (PINT-AE) for the underlying technical XML structure. One important note for anyone cross-referencing technical specs: the Ministry's mandatory-fields document itself uses plain-English field names only — it does not use IBT/BT-style Peppol field codes anywhere. Codes like IBT-001 come from the underlying Peppol/UBL technical specification, not from this particular Ministry document.

The 51 Mandatory Fields for a Tax Invoice

Per the Ministry of Finance's §4.1, grouped into the same six categories the official document uses:

Invoice Details (9 fields)

Seller Details (11 fields)

Buyer Details (9 fields)

Document Totals (5 fields)

Tax Breakdown (4 fields)

Invoice Line (13 fields)

Tax Invoice vs. Commercial Invoice — What Actually Changes

The Commercial Invoice list (§4.2) is 49 fields — identical to the Tax Invoice list except for the two buyer tax fields dropped (#24 and #25 above). Everything else — seller details, totals, tax breakdown, every line-item field — stays exactly the same. In practice, this means: if you're issuing an invoice to a buyer who isn't VAT-registered or where the transaction itself isn't a taxable supply, you're not exempt from field-completeness requirements generally — you're specifically exempt from populating the buyer's TRN and tax scheme code, and everything else on the 51-field list still applies.

What Counts as "Optional" (and "Conditional") in PINT-AE

The Ministry of Finance's mandatory-fields document doesn't publish a matching consolidated "optional fields" table the way it does for the 51/49 mandatory fields — but that doesn't mean optional fields are undefined or unofficial. The underlying technical specification that document itself references — the Peppol International (PINT) model for Billing, UAE specialisation (PINT-AE), published by OpenPeppol AISBL (v1.0.3) — explicitly classifies every field using a three-tier system, not just mandatory-vs-everything-else:

• Mandatory — "the option must be used in all messages"
• Conditional — "whether the option is used or not, and in what way, is dependent on other data in the message"
• Optional — "whether the option is used or not is the choice of the users, independently from other data in the message"

Rather than a single summary table, these classifications are documented field-by-field throughout the specification's narrative rather than as one discrete list. Concrete examples the specification marks this way include the Payment Receiver (a separate party from the seller, when payment is collected by someone else) as explicitly Optional, and the Project Reference as Optional — while delivery date and place are described as "recommended," sitting between the two categories rather than cleanly in either. In everyday UAE e-invoicing implementations, fields commonly left optional include:

• Invoice note — free-text remarks on the invoice
• Invoice issue time — beyond the mandatory issue date
• Buyer accounting reference — a buyer-side cost-center or PO reference code
• Payment terms text and additional payment identifiers (e.g. IBAN) beyond the mandatory payment means type code
• Delivery details — actual delivery date, delivery address, if different from the buyer's billing address
• Document references — purchase order number, contract reference, despatch/receipt advice numbers

How a Real System Handles Mandatory vs. Optional Fields

Reading a specification is one thing; seeing what a working PINT-AE generator actually does with it is another. InvoiceUAE's own XML generation service always populates the full mandatory set on every invoice — the invoice number, UUID, issue date, invoice type code, both currency codes, complete seller and buyer party blocks (including the 0235 Peppol scheme ID), the full payment-means block, complete tax totals and monetary totals, and every line item's identifier, quantity, price, and tax category.

Optional fields are populated conditionally — only written into the XML when the underlying invoice record actually has that data: due date, invoice notes, buyer reference, invoice period, order/despatch/receipt/contract document references, delivery details, bank/IBAN details, and per-line notes or cost-center codes. None of these block a valid invoice from being generated or submitted when absent — they're genuinely optional in the running system, not just in theory.

Why Different Guides Cite Different Field Counts

If you compare enough sources on this topic, you'll find the total field count varies quite a bit — some cite roughly 50 mandatory fields out of "over 130" total data elements; others cite around 34 mandatory out of "88" total. This isn't necessarily anyone being wrong — it usually comes down to what's being counted:

• Business-level fields (what the Ministry of Finance's document counts) — a single plain-English concept like "Seller address" as one field.
• Technical XML elements — the same "Seller address" concept can decompose into several underlying UBL/Peppol Business Terms (street line, city, postal code, country subdivision, country code) when counted at the schema level.

Neither counting method is inherently more correct — they're answering different questions. For compliance purposes, the Ministry of Finance's own 51/49 business-level counts are the most directly citable reference, since they come from the primary regulatory source rather than a third-party recount.

Frequently Asked Questions

How many mandatory fields does a UAE e-invoice need?

Per the UAE Ministry of Finance's official "UAE Electronic Invoice Mandatory Fields" document (v1.0, February 2026), a Tax Invoice requires 51 mandatory fields and a Commercial Invoice (a non-tax electronic invoice) requires 49. The two fields dropped for a Commercial Invoice are the buyer's tax identifier and tax scheme code.

What is the difference between a Tax Invoice and a Commercial Invoice under the UAE mandate?

A Tax Invoice is a VAT-relevant invoice and must include both parties' tax identifiers. A Commercial Invoice is defined by the Ministry of Finance as an electronic invoice that is not a Tax Invoice — it uses nearly the same mandatory field set minus the buyer's TRN and tax scheme code.

Is there an official list of optional fields for UAE e-invoicing?

Not as a single consolidated table like the mandatory list. The Ministry of Finance's document only enumerates the 51/49 mandatory fields. However, the underlying Peppol PINT-AE technical specification (published by OpenPeppol AISBL) explicitly classifies fields as Mandatory, Conditional, or Optional field-by-field throughout the full specification — invoice notes, payment terms text, delivery details, and buyer accounting references are common examples of fields typically left optional in practice.

Why do different guides give different total field counts for UAE e-invoicing?

Different sources count at different levels of granularity — some at the plain-English business-field level (as the Ministry of Finance does, giving 51/49), others at the underlying technical XML Business Term level, where one business field can decompose into multiple XML elements. Treat the Ministry of Finance's figures as the primary reference.