UAE eInvoicing Data Mapping: Mandatory, Optional Fields and XML Structure

UAE eInvoicing data mapping is not a simple exercise of taking the fields visible on a PDF invoice and placing them into XML tags.

The target is a structured PINT-AE document with defined business terms, code lists, cardinalities and validation rules. Some data comes directly from the invoice transaction. Some comes from supplier or buyer master data. Some is derived from the business scenario. And some technical values, such as the UUID, are generated as part of the Electronic Invoicing process rather than entered by a business user.

This guide takes an ERP-neutral view. It explains the data that an enterprise needs to identify and govern before deciding where a particular field is stored in SAP, Oracle, Microsoft Dynamics or a custom billing platform.

Quick answer

For an Electronic Tax Invoice, the UAE Ministry of Finance Mandatory Fields publication identifies 51 mandatory business fields across six groups:

The full PINT-AE semantic model contains additional optional and conditional business terms for references, delivery, payment instructions, allowances, charges, supporting documents, tax representatives, billing periods, item classifications and special UAE scenarios.

The safest mapping approach is:

Mandatory does not always mean XML cardinality 1..1

This is one of the most important points in the UAE data model.

The Ministry of Finance Mandatory Fields publication identifies the business data that is mandatory for an Electronic Tax Invoice. The PINT-AE semantic model separately defines XML cardinality and conditional business rules.

These concepts are related, but they are not identical.

For example:

• the MoF Mandatory Fields document lists Payment due date as mandatory;
• the PINT-AE semantic model defines IBT-009 Payment due date with cardinality 0..1;
• other PINT rules and invoice conditions determine when it must actually be present.

The same pattern occurs with tax identifiers, tax rates and scenario-specific information.

Do not convert a PINT cardinality into a business rule by itself. The semantic model, AE-specific Schematron rules and Ministry guidance need to be read together.

Where the data usually comes from

Before looking at individual fields, it helps to separate the data into source domains.

A field should have a single governed source wherever possible. If the same TRN, address or invoice total can be populated from two systems independently, reconciliation problems are almost guaranteed.

Mandatory field catalogue — Electronic Tax Invoice

The tables below use the Ministry of Finance field names. The “Value / format” column gives the official format, governing code list, or a safe example where the source provides one.

Invoice details — 9 mandatory fields

Seller details — 11 mandatory fields

Buyer details — 9 mandatory fields

Document totals — 5 mandatory fields

The core total relationship should be designed so that the source system can explain each number, not only produce a final value.

Tax breakdown — 4 mandatory fields

Current PINT-AE VAT category codes include:

Invoice line — 13 mandatory fields

Common UNECE UoM examples include:

Packaging codes from UNECE Recommendation 21 are used with the required X prefix where applicable.

Electronic Tax Invoice vs Commercial Electronic Invoice

The Ministry Mandatory Fields document distinguishes the mandatory dataset for an Electronic Tax Invoice from a Commercial Electronic Invoice.

Do not assume one mapping template can be applied blindly to every document category. Document type, VAT status and transaction scenario determine the applicable rules.

Important system-generated or technical fields

The MoF’s 51-field list focuses on business invoice data. The final PINT-AE XML contains additional technical elements that still matter.

This separation is useful in interface design:

Business / ERP data
        +
Derived compliance data
        +
ASP / technical data
        =
Final PINT-AE XML

Optional and conditional fields worth mapping deliberately

PINT-AE provides many more business terms than the 51-field minimum. They should not all be forced into every invoice.

Use them when the transaction needs them.

References and document context

Payment terms and preceding invoices

Seller, Buyer and party detail enrichments

Delivery and billing period

Payment instructions

Allowances, charges and totals

Supporting documents

Invoice-line enrichments

Key code lists and controlled values

Good data mapping should not hard-code descriptions where an official code list is required.

Invoice and credit-note document types

Credit Notes use the PINT-AE Credit Note transaction; do not simply change the number while keeping an Invoice XML root.

Invoice transaction type code

The value is exactly 8 positions. Each position is 1 when the scenario applies and 0 when it does not. Multiple positions can be active.

Interactive transaction-type decoder

UAE participant endpoints

The UAE scheme identifier is 0235.

The Guidelines / PINT-AE business guidance define special predefined endpoints for specific situations:

For a normal UAE participant, the endpoint uses the entity’s TIN.

Legal registration identifier type

If TL is used, the applicable issuing Authority Name is required by the relevant AE rule. If PAS is used, the passport-issuing country becomes relevant.

Billing frequency

Item type

A practical mapping worksheet

A field-by-field implementation document should record more than “source field → XML field”.

Use a structure like this:

A useful mapping design distinguishes four types of transformation:

Sample PINT-AE XML structure

The example below is an illustrative mapping skeleton for a simple UAE standard-rated Tax Invoice in AED.

It intentionally uses sample identifiers and values. It is designed to show where the mandatory business data sits in UBL/PINT-AE, not to replace the official PINT-AE Schematron or ASP validation.

It includes:

• all 51 fields listed as mandatory by the MoF for an Electronic Tax Invoice;
• the PINT-AE UUID and technical identifiers;
• a few common optional fields to make the hierarchy easier to understand.

<?xml version="1.0" encoding="UTF-8"?>
<Invoice
  xmlns="urn:oasis:names:specification:ubl:schema:xsd:Invoice-2"
  xmlns:cac="urn:oasis:names:specification:ubl:schema:xsd:CommonAggregateComponents-2"
  xmlns:cbc="urn:oasis:names:specification:ubl:schema:xsd:CommonBasicComponents-2">

  <!-- =========================================================
       PROCESS CONTROL / DOCUMENT IDENTIFICATION
       ========================================================= -->

  <!-- M: Specification Identifier -->
  <cbc:CustomizationID>urn:peppol:pint:billing-1@ae-1</cbc:CustomizationID>

  <!-- M: Business process type -->
  <cbc:ProfileID>urn:peppol:bis:billing</cbc:ProfileID>

  <!-- M: Invoice transaction type code
       00000000 = no special UAE scenario -->
  <cbc:ProfileExecutionID>00000000</cbc:ProfileExecutionID>

  <!-- M: Invoice number -->
  <cbc:ID>INV-2026-000123</cbc:ID>

  <!-- S: UUID / Unique Identifier Number.
       Official guidance assigns UUID generation to the ASP. -->
  <cbc:UUID>19e2c9a3-b000-4fb0-9bd5-a9c4ebda2358</cbc:UUID>

  <!-- M: Invoice date -->
  <cbc:IssueDate>2026-09-07</cbc:IssueDate>

  <!-- M: Payment due date -->
  <cbc:DueDate>2026-10-07</cbc:DueDate>

  <!-- M: Invoice type code: 380 = UAE Tax Invoice -->
  <cbc:InvoiceTypeCode>380</cbc:InvoiceTypeCode>

  <!-- O: Invoice note -->
  <cbc:Note>Standard UAE Tax Invoice example for data-mapping illustration.</cbc:Note>

  <!-- M: Invoice currency code -->
  <cbc:DocumentCurrencyCode>AED</cbc:DocumentCurrencyCode>

  <!-- O: Buyer reference -->
  <cbc:BuyerReference>BUYER-REF-10001</cbc:BuyerReference>


  <!-- =========================================================
       SELLER
       ========================================================= -->
  <cac:AccountingSupplierParty>
    <cac:Party>

      <!-- M: Seller electronic address
           M: Seller electronic identifier / scheme = 0235
           Endpoint value is the 10-digit TIN -->
      <cbc:EndpointID schemeID="0235">1234567890</cbc:EndpointID>

      <!-- O: Seller trading / additional identifier example -->
      <cac:PartyIdentification>
        <cbc:ID>SUPPLIER-001</cbc:ID>
      </cac:PartyIdentification>

      <cac:PostalAddress>
        <!-- M: Seller address line 1 -->
        <cbc:StreetName>Sheikh Zayed Road</cbc:StreetName>

        <!-- M: Seller city -->
        <cbc:CityName>Dubai</cbc:CityName>

        <!-- M: Seller country subdivision -->
        <cbc:CountrySubentity>Dubai</cbc:CountrySubentity>

        <cac:Country>
          <!-- M: Seller country code -->
          <cbc:IdentificationCode>AE</cbc:IdentificationCode>
        </cac:Country>
      </cac:PostalAddress>

      <!-- M: Seller tax identifier
           M: Seller tax scheme code -->
      <cac:PartyTaxScheme>
        <cbc:CompanyID>123456789012003</cbc:CompanyID>
        <cac:TaxScheme>
          <cbc:ID>VAT</cbc:ID>
        </cac:TaxScheme>
      </cac:PartyTaxScheme>

      <cac:PartyLegalEntity>
        <!-- M: Seller name -->
        <cbc:RegistrationName>Supplier Name LLC</cbc:RegistrationName>

        <!-- M: Seller legal registration identifier
             M: Seller legal registration identifier type
             schemeAgencyID = TL
             Authority name held in schemeAgencyName for TL -->
        <cbc:CompanyID
          schemeAgencyID="TL"
          schemeAgencyName="Dubai Economy and Tourism">1122334455</cbc:CompanyID>
      </cac:PartyLegalEntity>

    </cac:Party>
  </cac:AccountingSupplierParty>


  <!-- =========================================================
       BUYER
       ========================================================= -->
  <cac:AccountingCustomerParty>
    <cac:Party>

      <!-- M: Buyer electronic address
           M: Buyer electronic identifier / scheme -->
      <cbc:EndpointID schemeID="0235">1245780912</cbc:EndpointID>

      <cac:PostalAddress>
        <!-- M: Buyer address line 1 -->
        <cbc:StreetName>Business Bay</cbc:StreetName>

        <!-- M: Buyer city -->
        <cbc:CityName>Dubai</cbc:CityName>

        <!-- M: Buyer country subdivision -->
        <cbc:CountrySubentity>Dubai</cbc:CountrySubentity>

        <cac:Country>
          <!-- M: Buyer country code -->
          <cbc:IdentificationCode>AE</cbc:IdentificationCode>
        </cac:Country>
      </cac:PostalAddress>

      <!-- M: Buyer tax identifier
           M: Buyer tax scheme code -->
      <cac:PartyTaxScheme>
        <cbc:CompanyID>124578091212003</cbc:CompanyID>
        <cac:TaxScheme>
          <cbc:ID>VAT</cbc:ID>
        </cac:TaxScheme>
      </cac:PartyTaxScheme>

      <cac:PartyLegalEntity>
        <!-- M: Buyer name -->
        <cbc:RegistrationName>Buyer Name LLC</cbc:RegistrationName>

        <!-- O for this Tax Invoice example:
             Buyer legal registration details are supported in PINT-AE -->
        <cbc:CompanyID
          schemeAgencyID="TL"
          schemeAgencyName="Dubai Economy and Tourism">2233557788</cbc:CompanyID>
      </cac:PartyLegalEntity>

    </cac:Party>
  </cac:AccountingCustomerParty>


  <!-- =========================================================
       OPTIONAL ORDER / BILLING CONTEXT
       ========================================================= -->

  <!-- O: Purchase order reference -->
  <cac:OrderReference>
    <cbc:ID>PO-4500012345</cbc:ID>
  </cac:OrderReference>

  <!-- O: Billing period / frequency -->
  <cac:InvoicePeriod>
    <cbc:StartDate>2026-08-01</cbc:StartDate>
    <cbc:EndDate>2026-08-31</cbc:EndDate>
    <cbc:Description>MTH</cbc:Description>
  </cac:InvoicePeriod>


  <!-- =========================================================
       PAYMENT
       ========================================================= -->
  <cac:PaymentMeans>
    <!-- M: Payment means type code
         30 = credit transfer -->
    <cbc:PaymentMeansCode>30</cbc:PaymentMeansCode>

    <!-- O: Remittance information -->
    <cbc:PaymentID>INV-2026-000123</cbc:PaymentID>

    <!-- C: Credit transfer details when used -->
    <cac:PayeeFinancialAccount>
      <cbc:ID>AE000000000000000000001</cbc:ID>
      <cbc:Name>Supplier Name LLC</cbc:Name>
    </cac:PayeeFinancialAccount>
  </cac:PaymentMeans>

  <!-- O: Payment terms -->
  <cac:PaymentTerms>
    <cbc:Note>Payment due within 30 days.</cbc:Note>
  </cac:PaymentTerms>


  <!-- =========================================================
       DOCUMENT TAX TOTAL + TAX BREAKDOWN
       ========================================================= -->
  <cac:TaxTotal>

    <!-- M: Invoice total tax amount -->
    <cbc:TaxAmount currencyID="AED">500.00</cbc:TaxAmount>

    <cac:TaxSubtotal>

      <!-- M: Tax category taxable amount -->
      <cbc:TaxableAmount currencyID="AED">10000.00</cbc:TaxableAmount>

      <!-- M: Tax category tax amount -->
      <cbc:TaxAmount currencyID="AED">500.00</cbc:TaxAmount>

      <cac:TaxCategory>

        <!-- M: Tax category code -->
        <cbc:ID>S</cbc:ID>

        <!-- M where applicable: Tax category rate -->
        <cbc:Percent>5</cbc:Percent>

        <cac:TaxScheme>
          <cbc:ID>VAT</cbc:ID>
        </cac:TaxScheme>
      </cac:TaxCategory>

    </cac:TaxSubtotal>
  </cac:TaxTotal>


  <!-- =========================================================
       DOCUMENT TOTALS
       ========================================================= -->
  <cac:LegalMonetaryTotal>

    <!-- M: Sum of Invoice line net amount -->
    <cbc:LineExtensionAmount currencyID="AED">10000.00</cbc:LineExtensionAmount>

    <!-- M: Invoice total amount without tax -->
    <cbc:TaxExclusiveAmount currencyID="AED">10000.00</cbc:TaxExclusiveAmount>

    <!-- M: Invoice total amount with tax -->
    <cbc:TaxInclusiveAmount currencyID="AED">10500.00</cbc:TaxInclusiveAmount>

    <!-- M: Amount due for payment -->
    <cbc:PayableAmount currencyID="AED">10500.00</cbc:PayableAmount>
  </cac:LegalMonetaryTotal>


  <!-- =========================================================
       INVOICE LINE
       ========================================================= -->
  <cac:InvoiceLine>

    <!-- M: Invoice line identifier -->
    <cbc:ID>1</cbc:ID>

    <!-- M: Invoiced quantity
         M: Unit of measure code -->
    <cbc:InvoicedQuantity unitCode="H87">2000</cbc:InvoicedQuantity>

    <!-- M: Invoice line net amount -->
    <cbc:LineExtensionAmount currencyID="AED">10000.00</cbc:LineExtensionAmount>

    <!-- O: Line PO reference -->
    <cac:OrderLineReference>
      <cbc:LineID>10</cbc:LineID>
      <cac:OrderReference>
        <cbc:ID>PO-4500012345</cbc:ID>
      </cac:OrderReference>
    </cac:OrderLineReference>

    <!-- M: Line amounts in AED -->
    <cac:ItemPriceExtension>

      <!-- M: Invoice line amount in AED -->
      <cbc:Amount currencyID="AED">10500.00</cbc:Amount>

      <cac:TaxTotal>
        <!-- M: VAT line amount in AED -->
        <cbc:TaxAmount currencyID="AED">500.00</cbc:TaxAmount>
      </cac:TaxTotal>
    </cac:ItemPriceExtension>

    <cac:Item>

      <!-- M: Item description -->
      <cbc:Description>Fountain Pen</cbc:Description>

      <!-- M: Item name -->
      <cbc:Name>Pen</cbc:Name>

      <!-- O: Item type G = Goods -->
      <cac:CommodityClassification>
        <cbc:ItemClassificationCode listID="AE-ItemType">G</cbc:ItemClassificationCode>
      </cac:CommodityClassification>

      <!-- M: Invoiced item tax category code
           M where applicable: Invoiced item tax rate -->
      <cac:ClassifiedTaxCategory>
        <cbc:ID>S</cbc:ID>
        <cbc:Percent>5</cbc:Percent>
        <cac:TaxScheme>
          <cbc:ID>VAT</cbc:ID>
        </cac:TaxScheme>
      </cac:ClassifiedTaxCategory>

    </cac:Item>

    <cac:Price>

      <!-- M: Item net price -->
      <cbc:PriceAmount currencyID="AED">5.00</cbc:PriceAmount>

      <!-- M: Item price base quantity -->
      <cbc:BaseQuantity unitCode="H87">1</cbc:BaseQuantity>

      <!-- Item gross price is carried in the price allowance structure -->
      <cac:AllowanceCharge>
        <cbc:ChargeIndicator>false</cbc:ChargeIndicator>

        <!-- O: Item price discount; zero here for illustration -->
        <cbc:Amount currencyID="AED">0.00</cbc:Amount>

        <!-- M: Item gross price -->
        <cbc:BaseAmount currencyID="AED">5.00</cbc:BaseAmount>
      </cac:AllowanceCharge>

    </cac:Price>

  </cac:InvoiceLine>

</Invoice>

What is not shown in the single XML example?

PINT-AE contains valid optional/conditional groups that do not belong together in every invoice. The example therefore does not force in:

• Free Zone beneficiary;
• deemed-supply predefined endpoint;
• export predefined endpoint;
• disclosed-agent Principal ID;
• tax representative;
• card payment;
• direct debit;
• document allowances/charges;
• multiple instalment payment terms;
• foreign-currency exchange rate;
• supporting binary attachments;
• Reverse Charge item classification;
• multiple tax categories;
• multiple lines;
• credit-note-specific fields.

Adding unused groups simply to make an XML look “complete” can create the opposite result: an invalid or misleading document.

Foreign-currency mapping deserves its own control

The June 2026 Ministry Guidelines state that VAT line amount and the total amount payable must be available in AED for applicable supplies even where the invoice is issued in another currency.

Where the document currency differs from AED and the tax accounting currency is AED, current PINT-AE rules also require the relevant tax accounting currency totals.

This should not be left to a generic currency-conversion routine without Tax/Finance ownership.

Data-quality rules that should fail before transmission

A good eInvoicing solution validates data before it reaches the ASP.

Identity checks

• Seller and Buyer endpoint scheme/value are present and valid.
• TIN/TRN values belong to the correct legal entity.
• Legal registration type is valid.
• Authority name is present when Trade Licence rules require it.
• Buyer endpoint follows the correct normal or predefined endpoint scenario.

Document checks

• Invoice number is not blank.
• Invoice date follows YYYY-MM-DD.
• Invoice type matches the intended document category.
• Transaction type code is exactly eight binary positions.
• Currency code is valid ISO 4217.

Arithmetic checks

• line quantities × price logic reconcile to line net amounts after allowances/charges;
• sum of line net amounts reconciles to document line total;
• tax category totals reconcile to invoice tax total;
• tax-inclusive and payable amounts reconcile;
• required AED values reconcile with the transaction currency/exchange rate.

Tax checks

• tax category is an allowed PINT-AE code;
• rate is appropriate for the tax category;
• exemption reason is present when required;
• Reverse Charge classification is present when required;
• tax line amount in AED follows the applicable AE rules.

Code-list checks

• UoM is a valid UNECE code;
• country is ISO 3166-1 alpha-2;
• currency is ISO 4217;
• payment method is from the UAE PINT-AE payment means list;
• attachment MIME type is supported.

Common mapping mistakes

Mapping the PDF label instead of the business meaning

A field called Customer No. on a printed invoice is not automatically the PINT-AE Buyer identifier. Map by semantic meaning, not screen label.

Using an internal code directly

Internal values such as EA, PCS, KG, MONTHLY or custom tax codes may need conversion to the official PINT-AE / UNECE code.

Treating addresses as one free-text string

PINT-AE separates address line, city, country subdivision and country. Splitting a legacy free-text address during transmission is fragile; improve master data instead.

Hard-coding 00000000 for every transaction

The transaction type code carries eight UAE scenario indicators. It must be derived from actual business context.

Assuming TRN and TIN are interchangeable

They have different roles. The Participant Identifier is based on the TIN, while VAT tax identification uses the TRN where applicable.

Generating a local UUID inside the ERP without checking the operating model

The Ministry Guidelines assign UUID generation to the ASP. Do not create a parallel identity scheme unless the official interface contract requires a separate technical correlation ID.

Adding custom XML fields

The June 2026 Guidelines state that Persons and Government Entities are not allowed to add their own optional fields to PINT-AE. Industry-specific requirements should be discussed with the ASP.

Recommended mapping ownership

Data mapping is not an “integration team only” activity.

The mapping workshop should therefore include Tax, Finance, Master Data, business process owners, ERP functional teams, integration and the selected ASP.

Three actions to take now

1. Build a PINT-AE data dictionary against your actual source systems

Do not stop at a 51-row checklist. Record the PINT term, source application, source field, transformation rule, code list, owner, validation and sample value.

2. Separate “missing data” from “mapping logic”

If a required buyer address, tax identifier or legal registration value does not exist in the source system, that is a data-readiness gap, not an interface mapping problem.

3. Validate with the current specification, not a spreadsheet frozen early in the project

The current published PINT-AE Billing specification is version 1.0.4 as of this article. Treat the semantic model, code lists and Schematron as version-controlled implementation dependencies.

Frequently asked questions

How many mandatory fields are there in a UAE Electronic Tax Invoice?

The Ministry of Finance Mandatory Fields V1.0 publication identifies 51 mandatory business fields for an Electronic Tax Invoice.

How many mandatory fields are there in a Commercial Electronic Invoice?

The same Ministry publication identifies 49 mandatory business fields for a Commercial Electronic Invoice.

Are all PINT-AE fields mandatory?

No. The PINT-AE semantic model contains mandatory, optional and conditional terms. Groups such as tax representative, delivery, payment card, direct debit, allowances, charges and supporting documents are used according to the transaction.

Is the UUID one of the 51 fields a business must map?

The 51-field MoF list does not include UUID, while the PINT-AE semantic model requires a Unique Identifier Number. The UAE Guidelines state that UUID generation is an ASP responsibility.

What is the UAE eInvoice format?

Electronic Invoices are exchanged in XML and follow PINT-AE. The underlying syntax is based on UBL 2.1 structures used by PINT.

Can a company add its own custom XML elements to PINT-AE?

The June 2026 Guidelines state that businesses are not permitted to add their own optional fields into PINT-AE. Industry-specific needs should be discussed with the appointed ASP.

What is the electronic address scheme for UAE participants?

The UAE scheme identifier is 0235, and the electronic address is based on the TIN for normal UAE participants.

What should be mapped first?

Start with legal-entity identity, buyer identity, invoice header, tax treatment and line data. Then add scenario-specific, payment, delivery and supporting fields.

Official references

• UAE Ministry of Finance — eInvoicing portal
• UAE Electronic Invoice Mandatory Fields V1.0 — 23 February 2026
• UAE Electronic Invoicing Guidelines V1.1 — 01 June 2026
• OpenPeppol — UAE Electronic Document Specifications
• OpenPeppol — PINT-AE Billing 1.0.4
• OpenPeppol — PINT-AE Invoice Semantic Model
• OpenPeppol — PINT-AE Invoice Code Lists
• OpenPeppol — PINT-AE Invoice Rules

Disclaimer: this article is to provide you the general info for your business specific requirements, get the advise from your appointed legal advisor.

Continue your trail

Previous concept The Dawn of E-Invoicing in the UAE: Concepts, Ecosystem and the 5-Corner Model Continue along E-Invoicing instead of jumping to a loosely related post.

→

You are here UAE eInvoicing Data Mapping: Mandatory, Optional Fields and XML Structure E-Invoicing

→

Recommended next UAE eInvoicing Regulatory Baseline: What Businesses Need to Know Why next? Continue along E-Invoicing instead of jumping to a loosely related post.

Knowledge completion

You now have the E-Invoicing context.

Save this guide, continue to the next concept or return to the Knowledge Library with your context intact.

Save Back to Knowledge Explore Taxes

Library

← Browse Taxes knowledge

Next guide

UAE eInvoicing Regulatory Baseline: What Businesses Need to Know →

Knowledge Area

E-Invoicing

3 resources in this area.

E-Invoicing 3 ›

Sachin H. Patil

Taxes · E-Invoicing

Practical SAP notes, structured for review, reuse and long-term maintenance.

View profile →