UAE eInvoice format: PINT AE mandatory fields and XML structure

A PINT AE invoice (the UAE's localised version of Peppol's international invoice standard) built from the wrong field list doesn't fail quietly. It fails at validation, gets sent back for correction, and delays the transaction it was meant to confirm. The mismatch is easy to introduce, because the UAE's mandatory-fields guidance sets two different counts for two different invoice categories. An electronic Tax Invoice needs 51 mandatory fields; a Commercial Electronic Invoice needs 49. The two lists overlap almost completely. The Tax Invoice list carries two fields the Commercial Electronic Invoice list doesn't require at all, and three more fields keep the same position number across both lists while meaning something different in each. A template built for one invoice category and reused for the other carries the wrong set without anyone noticing until the file bounces. For an ERP owner or finance-systems lead building or validating eInvoicing output, getting that distinction right is what decides whether a file goes through clean the first time. The same goes for knowing which of six document type codes an invoice carries, and how the underlying XML is actually structured.

An overview of the mandatory-field categories and XML structure, what's mandatory, how it's coded, and what a compliant file looks like. For how Peppol, PINT AE and the UAE's Continuous Transaction Controls (CTC) classification relate to each other at a standards level, see our guide to UAE eInvoicing standards and classification. For how an invoice actually moves through the 5-corner model end to end, see our guide to how UAE eInvoicing works.

“Mandatory” here has a specific meaning. The original eInvoicing Data Dictionary, released for consultation around 19 March 2025, classifies well over 135 fields across 16 invoice scenarios as mandatory, conditional, or optional, per Deloitte's account of that release. It's a broader, more granular catalogue covering every scenario the UAE's model anticipates. The 51-or-49 figures below are narrower. They're the confirmed mandatory set for the two most common invoice categories specifically, published in a later, settled technical guidance document. They aren't the full conditional field set a business might need for a less common scenario, such as a Free Zone transaction, a summary invoice, or an agent-billing arrangement. That fuller scenario detail is covered in our guide to UAE eInvoicing use cases and scenarios. A business handling only standard sales is working from the smaller, more relevant list; one handling a wider range of transaction types needs to check the fuller catalogue against its own scenarios.

What are the six UAE eInvoice document type codes?

Every PINT AE invoice or credit note carries a type code identifying which of three categories it belongs to, and whether it's an invoice or a credit note within that category. The Peppol PINT AE Billing and Self-Billing specifications confirm six codes in total:

The pattern is three categories, each with its own invoice code and credit note code: standard tax billing (380/381), self-billing (389/261), and the Commercial Invoice category (480/81).

Two naming details are worth pinning down before any mapping work starts. Peppol's underlying code list names 380 "Commercial invoice" in the generic sense of a commercial document. In UAE terms 380 is the Tax Invoice code, and the UAE's own Commercial Invoice category uses 480. And 480/81 are not restricted to supplies outside the scope of VAT: the Guidelines' Commercial Invoice definition covers exempt supplies as well as out-of-scope ones, and sales by a person who isn't registered for VAT.

The document type code and the invoice transaction type code do different jobs, and both can appear on the same invoice. The document type code says which category of document this is — invoice or credit note, tax or self-billed or commercial — and sits in cbc:InvoiceTypeCode or cbc:CreditNoteTypeCode. The invoice transaction type code records the circumstances of the transaction, such as a summary invoice or a margin-scheme supply, and sits in cbc:ProfileExecutionID.

What's the difference between a Tax Invoice and a Commercial Invoice?

Both the 51-field list and the 49-field list describe the same kind of document: a structured Electronic Invoice, exchanged over the Peppol network. The difference between them isn't “human-readable” versus “XML”; every Electronic Invoice under this system is XML. The difference is which invoice category the transaction falls into. The Ministry of Finance's Electronic Invoicing Guidelines, version 1.1 (Section 10.1) name six invoice categories in total. They are an electronic Tax Invoice and its self-billed equivalent, an electronic Tax Credit Note and its self-billed equivalent, a Commercial Invoice, and an Electronic Credit Note. A Tax Invoice is issued for a Taxable Supply under the VAT Decree-Law. A Commercial Invoice, by contrast, is the Guidelines' own term (Section 10.2.1) for an invoice issued on a sale that doesn't require a Tax Invoice at all. That covers a supply that's exempt or out of scope for VAT purposes, or a sale made by someone who isn't VAT-registered. The mandatory-fields guidance's two lists map directly onto this split. Its Section 4.1 sets out the 51 fields required in an electronic Tax Invoice; its Section 4.2 sets out the 49 fields required in a Commercial Electronic Invoice. Getting the category right, before checking either field list, is the first decision a business or its ERP actually has to make.

What are the mandatory fields, by category?

The UAE Electronic Invoice Mandatory Fields, version 1.0, 23 February 2026 groups the required fields into six categories, in the same order for both invoice types. They are Invoice Details, Seller Details, Buyer Details, Document Totals, Tax Breakdown and Invoice Line. Almost every field carries the same name and definition in both lists. Three fields sit at the same position number in each list but mean something different. Position 15 is “Seller tax identifier” (the seller's Tax Registration Number (TRN) or Tax Identification Number (TIN)) in the Tax Invoice list. In the Commercial Electronic Invoice list, the same position is “Seller tax registration identifier,” worded to also cover a seller who has no TRN at all. Positions 24 and 25 are “Buyer tax identifier” and “Buyer tax scheme code” in the Tax Invoice list, but “Buyer legal registration identifier” and its type in the Commercial Electronic Invoice list. Two fields exist only in the Tax Invoice list and aren't required at all in the Commercial Electronic Invoice list. Both are at the invoice-line level: “VAT line amount in AED” and “Invoice line amount in AED.”

What are the tax category codes on a UAE eInvoice?

Every mandatory field list includes a tax category code (field 37 in both lists) and its rate (field 38), assigned per transaction. Neither the mandatory-fields guidance nor Guidelines v1.1 publishes single-letter codes for these. Guidelines v1.1, Section 10.5, describes six treatments in plain terms:

• Standard Rate: a taxable supply at the standard VAT rate.

• Exempt from VAT: goods or services within the scope of UAE VAT but qualifying for exemption, such as certain real estate services, financial services or local passenger transportation.

• Goods and services outside the scope of VAT: the place of supply is outside the UAE, or a specific exclusion applies.

• Reverse Charge: the domestic supply of certain goods, such as electronic devices, precious metals and precious stones, crude or refined oil, natural gas, or metal scrap, where the buyer accounts for the VAT instead of the seller.

• Zero rated: supplies taxed at 0%, including qualifying exports and certain healthcare, education or real estate supplies.

• Margin scheme: a supply where VAT is calculated only on the seller's margin, such as a qualifying resale of second-hand goods.

Those are the Guidelines' own descriptions. The codes come from the PINT AE specification, which carries the tax category in cac:TaxCategory/cbc:ID and defines five values: S for standard rate, Z for zero-rated, E for exempt, O for goods or services outside the scope of tax, and AE for reverse charge. Apply the specification's own rate and validation rules for each one, rather than assuming every category needs a numeric rate.

That leaves the margin scheme, which is the one item in the Guidelines' list of six that is not a tax category. PINT AE records it as an invoice transaction type instead, in cbc:ProfileExecutionID. The transaction type is an eight-position string of 1s and 0s, one flag per circumstance: Free Trade Zone, deemed supply, profit margin scheme, summary invoice, continuous supply, disclosed agent billing, supply through e-commerce, and exports. A single invoice can carry more than one flag. Mapping the margin scheme onto a sixth letter code is a common way to get this wrong.

What does a UAE PINT AE XML invoice look like?

The Ministry of Finance's Guidelines don't just describe the field list. Guidelines v1.1, Appendix 5, publishes an actual worked example, built around an advance-payment scenario, showing what the underlying XML elements look like in practice. The excerpt below is drawn directly from that published example (trimmed here to the Document Totals and Tax Breakdown elements), not an invented skeleton:

<Invoice>

  <cbc:ID>ADV-001</cbc:ID>

  <cbc:IssueDate>2026-05-01</cbc:IssueDate>

  <cbc:InvoiceTypeCode>380</cbc:InvoiceTypeCode>

  <cac:LegalMonetaryTotal>

    <cbc:LineExtensionAmount currencyID="AED">1000.00</cbc:LineExtensionAmount>

    <cbc:TaxExclusiveAmount currencyID="AED">1000.00</cbc:TaxExclusiveAmount>

    <cbc:TaxInclusiveAmount currencyID="AED">1050.00</cbc:TaxInclusiveAmount>

    <cbc:PayableAmount currencyID="AED">1050.00</cbc:PayableAmount>

  </cac:LegalMonetaryTotal>

  <cac:TaxTotal>

    <cbc:TaxAmount currencyID="AED">50.00</cbc:TaxAmount>

  </cac:TaxTotal>

</Invoice>

This is one worked scenario (an advance payment against a later final invoice), not a full template covering every mandatory field on this page. Treat it as an illustration rather than a starting point: it has been trimmed, and it carries no namespace declarations, no party details and no invoice lines. It will not validate as it stands, and it should not be used as a production template. Guidelines v1.1's own Appendix 5 has the complete advance-payment and retention examples, including the follow-on final invoice this excerpt's advance payment leads into. What it confirms directly, rather than as an inference from general Peppol/UBL convention, is the actual element naming. cbc: labels simple values (ID, IssueDate, InvoiceTypeCode, the individual amounts); cac: labels the aggregate groups that contain them (LegalMonetaryTotal, TaxTotal). Document Totals maps onto LegalMonetaryTotal; Tax Breakdown maps onto TaxTotal and its TaxSubtotal children, though the excerpt above shows only the total tax amount, not the per-category breakdown. A full invoice carries considerably more structure than this excerpt, including the Seller Details, Buyer Details and Invoice Line groups, but the nesting convention holds throughout.

What identifiers appear on a UAE eInvoice?

A UAE eInvoice's Participant Identifier on the Peppol network combines scheme 0235 with the entity's 10-digit Tax Identification Number (TIN). For a taxpayer already registered for Corporate Tax, the TIN is the first 10 digits of its Corporate Tax Registration Number (TRN). For one that isn't required to register for Corporate Tax, the TIN is generated directly through EmaraTax instead. That Participant Identifier is a separate thing from the seller and buyer identifier fields inside the document, and those fields are not one pair governed by a single fallback rule. The two mandatory-field lists put different fields in the same positions. Position 15 is "Seller tax identifier" in the Tax Invoice list and "Seller tax registration identifier" in the Commercial Electronic Invoice list. Positions 24 and 25 are "Buyer tax identifier" and "Buyer tax scheme code" in the first, but "Buyer legal registration identifier" and its type in the second. Populate each according to the rule for that field in whichever list applies, rather than applying one TRN-to-TIN substitution across all of them. How the Participant Identifier gets assigned during EmaraTax onboarding is covered in our guide to EmaraTax onboarding, TIN, TRN, Participant IDs and invoice statuses. So is what an invoice's confirmation actually looks like once exchange starts.

Where does PINT AE implementation commonly go wrong?

A few patterns show up repeatedly once a business starts producing PINT AE-compliant data. Tax category code assignment is one: the code depends on the transaction's VAT treatment, not the product category, and it's easy to default every line to a single code rather than evaluating each one. The 51-versus-49 field split is another, and it's easy to get the direction backwards. A template built for a Commercial Electronic Invoice and then reused for a Tax Invoice can quietly drop the two AED-denominated line-amount fields the Tax Invoice list specifically requires. Or it can leave the seller and buyer identifier fields in the Commercial Electronic Invoice's broader legal-registration form, instead of the Tax Invoice's narrower tax-identifier form. Checking that a business is even issuing the right invoice category for a given transaction, a Tax Invoice or a Commercial Invoice, comes before checking either field list. The category decision determines which field list applies.

A further pattern is specific to identifiers rather than fields: mismatching the Participant Identifier's scheme value. The 0235 scheme prefix identifies the UAE's own numbering convention on the Peppol network. A system carried over from a different Peppol-participating country, or configured from a template built for one, can end up with the wrong scheme value attached to a correct TIN. Scheme values appear both in the Participant Identifier used for routing and in the party identification inside the document, so a mismatch can surface as a routing failure, a validation error, or both. Check the scheme code and the identifier together, and read the ASP's error message to find which one failed rather than assuming where the problem is. Mapping a UAE eInvoice's mandatory-field categories onto a specific ERP's own master-data objects is its own detailed subject. Our guide to ERP integration, master data and PINT AE field mapping for UAE eInvoicing covers it directly.

What do these PINT AE requirements mean for finance and IT teams?

Getting these details right doesn't change what has to happen operationally. An Accredited Service Provider (ASP) still validates what an ERP or accounting system produces, and converts it into this structure where the source data isn't already in the required format. Conversion isn't a step that always runs. Getting the invoice category, the field count that follows from it, the type code, and the tax category right at the source is what determines how much of that validation step actually catches a problem. The alternative is sending a file back for correction after the fact.

Zoho Software Trading LLC is an Accredited Service Provider for UAE eInvoicing. See how Zoho Books supports UAE eInvoicing.

Frequently asked questions

How many mandatory fields does a UAE eInvoice need?

It depends on the invoice category: 51 fields for an electronic Tax Invoice, or 49 for a Commercial Electronic Invoice, per the UAE Electronic Invoice Mandatory Fields guidance (version 1.0, 23 February 2026). The Tax Invoice list requires two AED-denominated line-amount fields the Commercial Electronic Invoice list doesn't.

What is the invoice type code for a UAE tax invoice?

380. A UAE tax credit note uses 381. Self-billing uses 389 (invoice) and 261 (credit note). Commercial invoices use 480, and commercial credit notes use 81.

What format is a UAE eInvoice sent in?

Structured XML, following the PINT AE specification: the UAE's localised version of Peppol's International (PINT) invoice model. OpenPeppol revises the specification periodically, so check the current release rather than a version number quoted in an article.

Where can I find the full PINT AE technical specification?

The PINT AE Billing and Self-Billing specifications are published directly by Peppol at docs.peppol.eu, and the UAE's own mandatory-fields guidance and Electronic Invoicing Guidelines are published on the Ministry of Finance's website. All three are the primary sources this page draws from.