The UAE PINT-AE billing specification mandates 51 fields on every Electronic Tax Invoice. The equivalent number for a Commercial Invoice is 49 fields. These are not merely fields that must be present in the XML — they are fields that must be present, populated with conformant data, and validated against the 302 schematron rules that govern the PINT-AE standard before the invoice is accepted for transmission. For finance and technology teams used to thinking about invoice data in terms of what appears on the printed invoice, this field count requires a fundamental shift in perspective: the PINT-AE standard reaches into ERP master data, transaction configuration, and system architecture to a depth that printed invoices never exposed.

How the 51 Fields Are Structured

The PINT-AE mandatory fields are organised into groups that correspond to the UBL 2.1 XML document hierarchy. The document-level fields cover the invoice itself: the invoice number, invoice date, document type code (380 for Tax Invoice, 480 for Commercial Invoice), the ProfileExecutionID, the CustomizationID, the currency code, and the transaction type flag (BTAE-03). Seller and buyer identity fields cover the full legal identity of both parties: TIN, Trade License number and issuing authority name, Peppol Participant Identifier, Legal Registration Type, and full address including emirate subdivision code. Tax totals and document totals cover the calculated amounts at the aggregate level. Line-level fields cover item description, unit of measure, quantity, unit price, line net amount, and tax category at the line level.

On top of the core PINT fields, the UAE extension fields — the BTAE fields — add UAE-specific business terms that have no equivalent in the standard PINT framework. These include the eight-position transaction type flag (BTAE-03), the Central Bank exchange rate for non-AED invoices (BTAE-04), AED-equivalent line amount fields (BTAE-08 and BTAE-10), the Free Trade Zone beneficiary identity (BTAE-01), the disclosed agent principal identity (BTAE-14), export customs reference (BTAE-21), Incoterms code (BTAE-22), and e-commerce delivery address (BTAE-23).

The Three Categories of Data Gap

When mapping existing ERP invoice output against PINT-AE mandatory fields, gaps typically fall into three categories. The first is data that exists in the ERP but is not currently used on the invoice output — for example, a customer TIN that is stored in the customer master but not printed on the PDF invoice. This is a mapping gap: the data is available; the invoice generation process must be configured to include it. The second is data that exists in the ERP but is in the wrong format or uses a different code set — for example, country codes stored as country names, or tax category codes that do not correspond to the PINT-AE permitted values. This is a conformance gap: the data must be transformed or recoded. The third is data that does not exist anywhere in the ERP — for example, Peppol Participant Identifiers for customers, or emirate subdivision codes at the address level. This is an existence gap: the data must be collected, enriched, and maintained.

Where the Data Lives in Your ERP

Seller Identity Fields

The seller identity fields on a PINT-AE invoice derive from the legal entity master data of the issuing entity. In SAP, this is the Company Code master data combined with the Customer/Vendor master record for the company's own identity (if configured). In Oracle, it is the Legal Entity definition in the HR and Financials Legal Entities setup. The mandatory seller fields — TIN, Trade License number, issuing authority name, emirate subdivision code, Peppol Participant Identifier — must all be maintained at the entity level and made available to the PINT-AE generation process. Most ERP implementations store Trade License numbers informally, issuing authority names inconsistently (or not at all), and emirate subdivision codes never.

Customer Identity Fields

The buyer identity fields on a PINT-AE invoice derive from the customer master record. In SAP, the Business Partner or Customer Master holds the relevant data across multiple views: general data (address, country), tax data (TIN, VAT registration), and company-specific data. In Oracle TCA, the Party, Account, and Site hierarchy holds customer identity across party-level and account-level attributes. The PINT-AE mandatory buyer fields that are typically absent from existing customer master records include: Peppol Participant Identifier, Legal Registration Type (TL/EID/PAS/CD), Trade License number and issuing authority name, and emirate subdivision code at the billing address level.

Line-Level Data

The PINT-AE line-level fields require each invoice line to carry an Item Type Code (one of three permitted values: goods, services, or mixed), a tax category code at the line level (not merely at the document level), and — for goods items — a classification code from a defined code list. For UAE businesses that currently issue invoices with single-line summaries or free-text item descriptions, the PINT-AE line-level requirements represent a significant invoice structure change. Each taxable supply must be broken down to the item type code level, with the correct tax category code applied at the line.

The UAE Extension Fields as a Pre-Assessment Target

The BTAE extension fields represent the most concentrated area of data existence gaps in UAE e-invoicing readiness assessments. These fields were created specifically for the UAE and have no heritage in earlier ERP configurations or invoice templates. The BTAE-03 transaction type flag must be determined dynamically per transaction from the transaction's attributes. The BTAE-04 Central Bank exchange rate must be sourced from the UAE Central Bank's published daily rate. The BTAE-08 and BTAE-10 AED-equivalent line amount fields require calculation from the foreign currency line amounts using BTAE-04. None of these fields exist anywhere in the current ERP of a UAE business that has not yet begun e-invoicing preparation.

Practitioner Insight: When conducting data availability assessments for Phase 1 businesses, I ask the finance team to pull the raw ERP data for a sample of last month's B2B invoices — not the PDF output, the table-level extract. The exercise consistently reveals that between 20% and 35% of the mandatory PINT-AE fields have no corresponding data in the ERP at all. The invoice print report creates an illusion of completeness. The field-level extract reveals the reality.

Completeness Rate as a Readiness Metric

A useful pre-go-live metric for Phase 1 businesses is the completeness rate per mandatory field across the customer master. For a business with 2,000 B2B customers, a completeness rate of 45% on the Peppol Participant Identifier field means 1,100 customers do not yet have the identifier recorded. Enriching that data requires outreach to each of those 1,100 customers, tracking their ASP onboarding status, and updating the customer master when the identifier is confirmed. At a rate of 20 customer enrichments per day, that is 55 working days of enrichment effort for that field alone.

Running this arithmetic across the full set of mandatory customer identity fields — TIN, Trade License number, issuing authority name, emirate subdivision code, Peppol Participant Identifier, Legal Registration Type — gives a realistic picture of the data enrichment effort required and the resources needed to complete it before the go-live date. This calculation is one of the first things a UAE e-invoicing compliance programme should produce, and it should drive resourcing decisions before the integration build begins.

The Commercial Invoice Field Difference

The Commercial Invoice's 49 mandatory fields differ from the Tax Invoice's 51 primarily in the absence of the VAT Registration Number fields and certain VAT-specific calculation fields. The document type code changes from 380 to 480, and the ProfileExecutionID changes to the Commercial Invoice profile variant. The buyer identity fields remain mandatory at the same level of detail. The seller identity fields remain mandatory at the same level of detail. The line-level fields remain mandatory with the same item type code and tax category requirements. For businesses that issue both Tax Invoices and Commercial Invoices across their transaction portfolio, the data requirements are substantially similar, and the master data enrichment programme covers both document types.