The 51 Fields, Explained

Guide·Updated 4 August 2026

In February 2026 the Ministry of Finance published the list of mandatory fields for UAE electronic invoices: 51 for a Tax Invoice, 49 for a commercial invoice. Most coverage stops at the count. The interesting question is what the list implies, because at least a dozen of those fields do not exist in the invoice template most UAE businesses use today, and several are not fields at all so much as decisions your business has never had to make explicitly.

First, who this applies to

Wider than most people assume. The mandatory field document states it plainly: electronic invoicing is mandatory for any person conducting business in the UAE, regardless of VAT registration status, unless specifically excluded under Article 4 of Ministerial Decision No. 243 of 2025. A business below the VAT threshold does not escape the mandate; it issues commercial electronic invoices instead of electronic Tax Invoices, with 49 mandatory fields rather than 51. The difference between the two lists is essentially the tax identifiers and the per-line AED VAT amounts. Everything else, the endpoints, the flags, the line structure, applies to both.

The field that is really an identity: your TIN

Your address on the e-invoicing network, the Peppol participant identifier your Accredited Service Provider registers, is built on your Tax Identification Number: the first ten digits of your 15-digit Corporate Tax TRN. Three consequences hide in that sentence.

• Corporate Tax registration is the gateway. If you registered for Corporate Tax, you already have a TIN. If you are in e-invoicing scope but not required to register for Corporate Tax, you must register with the FTA to receive a TIN before an ASP can onboard you at all.
• Tax Group members use their own TIN, not the representative member’s. The document says this explicitly, because groups were getting it wrong: your VAT returns may run through the representative, but your e-invoicing identity is your own.
• The endpoint also carries a fixed scheme identifier, 0235, for UAE businesses. Together they form the electronic address your customers’ systems deliver to, which is why the buyer’s electronic address is itself a mandatory field: invoices are delivered to endpoints now, not to inboxes.

The eight decisions disguised as one field

Field five is the invoice transaction type code: eight flags, each set to 1 or 0, on every single invoice.

Today, these classifications live in your accountant’s head, if they live anywhere. From go-live they are structured data on every document, transmitted to the FTA, and inconsistency between the flags and your VAT returns is exactly the kind of pattern the system exists to surface. Deciding each flag per transaction type, once, in your master data, is the real work behind this field.

The fields your current template does not have

Run down the list against a typical UAE invoice and the gaps cluster in five places:

• Buyer electronic address and identifiers. You need your customer’s delivery endpoint and, for Tax Invoices, their TRN. Customer masters built for PDF email have no field for either. This is a data collection exercise across your whole customer base, and it is the slowest item on the list to fix.
• Per-line AED VAT amounts. A Tax Invoice must state, for every line, the VAT amount and line amount in AED, whatever the invoice currency. Foreign-currency billing systems must carry the exchange rate and compute AED values per line, not just at the total.
• Unit of measure on every line. Quantity and a unit code, per line. Service businesses that bill a single unqualified amount fail this by default.
• Legal registration identifiers. Seller and, on commercial invoices, buyer registration numbers, typed by source: trade licence, Emirates ID, passport, or Cabinet Decision. Another master data field that has never been on an invoice.
• Payment means and due date. How the invoice is expected to be settled, coded, plus the due date. Trivial to add; rarely present.

What the list is actually telling you

Read as a form, the list is tedious. Read as a diagnostic, it is precise: the mandatory fields are the FTA specifying, in advance, exactly what your billing data must be able to produce on demand, per document, in structured form. Every gap between the list and your systems is a future validation failure, and every ambiguity in your VAT treatment becomes a flag or a category code you must commit to in public.

That is why we treat the field list as the agenda for the readiness work rather than a technical appendix to it. Map your invoice data against all 51 fields, and the gaps are your project plan: customer data collection, item tax mapping, currency handling, flag decisions. Our rejection self-check runs the short version of that exercise in two minutes, and the readiness service runs the full one.

Common questions