The UAE PINT-AE billing specification requires mandatory fields on every electronic invoice that depend on data most UAE businesses do not currently hold in their ERP systems. This is not a system development problem. It is a data governance problem — and it is one of the most time-consuming preparation tasks in a Phase 1 compliance programme. The gap exists because the data categories that PINT-AE requires were never needed for UAE VAT compliance before the e-invoicing mandate. They are new categories created by a new regulatory framework, and they must be collected, validated, and maintained at scale before go-live.

The Three Forms of Master Data Gap

Master data gaps for UAE e-invoicing present in three forms. The first is horizontal fragmentation: the same customer exists in multiple systems with different values for the same field. Customer ABC has TIN 100123456 in the SAP billing system but TIN 100-123-456 (with hyphens) in the CRM, and no TIN at all in the standalone POS system. The same entity, three incompatible records. The second is vertical absence: required data exists but in unofficial sources outside the ERP — a spreadsheet maintained by the sales team, a PDF trade licence in a shared drive folder, an email from the customer from 2019. The data is somewhere; it is not in the system. The third is historical absence: the data was never collected because prior compliance did not require it. No existing system, official or unofficial, holds the Peppol Participant Identifier for a single UAE customer.

The Customer Master Data Gaps

Peppol Participant Identifier

Every UAE B2B customer that has implemented electronic invoicing holds a Peppol Participant Identifier — a globally unique identifier in the format 0235:[identifier value] that serves as their electronic address in the Peppol network. The supplier needs this identifier to route electronic invoices to the customer's ASP (Corner 3). Without it, every invoice to that customer must use the predefined endpoint 0235:9900000098 (buyer not yet onboarded), which also means the supplier must continue issuing a parallel PDF or paper Tax Invoice to that customer.

As of the Phase 1 go-live date, Phase 1 customers — those with revenue over AED 50 million — will have Peppol Participant Identifiers because they are mandatory go-live on the same date. But most supplier businesses serve customers across both phases and across international markets. Building and maintaining a live database of customer Peppol identifiers — updated as customers onboard and as identifier details change — is a new and ongoing master data management responsibility.

Legal Registration Type

The UAE PINT-AE specification requires the buyer's Legal Registration Type — the type of identifying document used to register the business with UAE authorities. The four permitted values are TL (Trade License), EID (Emirates ID), PAS (Passport), and CD (Commercial Registration Number). This categorisation determines which registration number format is required on the invoice. Most UAE customer master records do not capture Legal Registration Type as a discrete field — they may hold a Trade License number without categorising it as TL, or hold no registration document data at all. This field must be added as a discrete attribute to the customer master and populated for every B2B customer.

Trade License Number and Issuing Authority Name

The Trade License number and the name of the issuing authority (the relevant emirate's Department of Economic Development, or the relevant Free Zone authority, or the federal licensing body) are mandatory buyer identity fields on a UAE PINT-AE Tax Invoice. For many UAE business customers, the Trade License number is held somewhere in the procurement or credit control system. The issuing authority name — formatted to match the PINT-AE code list — is held almost nowhere. This is a data collection task, not a data format task: the information must be gathered from customers, validated against the registrar's records, and maintained as master data with a defined update process.

Emirate Subdivision Code

Every address field on a PINT-AE invoice must include an emirate subdivision code — a two-character code from the UAE subdivision code list (AE-AZ for Abu Dhabi, AE-DU for Dubai, AE-SH for Sharjah, and so on for all seven emirates). These codes must appear at both the seller's and buyer's address level. Most ERP customer master addresses store a city name or emirate name in free text. The structured subdivision code is a new required attribute that must be mapped from city/emirate free text to the correct ISO subdivision code — and where the free-text data is incomplete or inconsistent, the mapping fails.

The Supplier Master Data Gaps

The AP-side master data requirement is symmetric but serves a different compliance purpose. For the Recipient's obligations under MD 243, the business must validate incoming electronic invoices against its supplier master data. Where the incoming invoice carries a supplier TIN that does not match the supplier's TIN in the ERP, the business must decide whether to accept, reject, or query the invoice. This validation logic depends on the AP system holding accurate supplier TIN, Peppol Participant Identifier, and legal registration data — which, for most UAE businesses, is similarly incomplete.

Beyond validation, the supplier master must capture each supplier's Phase classification and expected electronic invoicing go-live date. During the transition period, Phase 1 businesses will receive electronic invoices from some suppliers and paper or PDF invoices from others, depending on each supplier's mandatory date. The AP system must distinguish between these cases: an electronic invoice from a Phase 1 supplier after 1 January 2027 is the expected format; a paper invoice from the same supplier on the same date is a compliance concern for the supplier (and a potential ITC risk for the buyer if the invoice does not meet the Tax Invoice standard).

The Internal Master Data Requirements

Beyond customer and supplier data, the business must establish master data for its own entities. Each UAE legal entity's TIN, Trade License number, issuing authority name, Peppol Participant Identifier (provisioned through the ASP onboarding), and emirate subdivision code for each billing location must be configured in the ERP at the entity level. For groups with multiple UAE legal entities — some in mainland emirates, some in Free Zones — the entity-level configuration must be precisely aligned to the legal registration details of each entity.

Item master data also requires enhancement. The PINT-AE line-level fields require each item to carry an Item Type Code (goods, services, or mixed), and goods items must carry a classification code from a defined commodity classification scheme. For businesses with large item catalogues — retailers, manufacturers, distributors — the item type code and classification code must be added to the item master for every item that appears on in-scope invoices. For businesses that currently use free-text item descriptions without structured commodity codes, this is a material master data enrichment exercise that runs in parallel with the customer master enrichment.

Practitioner Insight: The most reliable way to estimate the master data enrichment effort is to run a completeness report against the actual customer master — not a theoretical assessment of what might be missing, but an actual count of records with a null, blank, or invalid value for each mandatory PINT-AE field. That report, produced in the first week of the compliance programme, defines the scope of the enrichment task and determines whether the enrichment can be completed before go-live with available resources or whether prioritisation and phasing is required.

Designing the Enrichment Programme

A master data enrichment programme for UAE e-invoicing has four components. The first is a field-by-field completeness audit across all source systems, producing a gap count per field per customer record. The second is a source-of-truth determination: for each field, which system is the authoritative record, and how do records from other systems reconcile to it? The third is the enrichment execution: outreach to customers for Peppol identifiers and legal registration details, internal data gathering for item codes and authority names, and structured update of the ERP master data. The fourth is a governance model: who owns each data domain post-go-live, how are new customer records created with complete data, and how are existing records updated when customer details change?

For GCC, UK, EU, and Indian multinationals managing UAE customer master data through a global master data governance function, the UAE e-invoicing enrichment should be integrated into the global programme rather than run as a local exception. The UAE-specific fields — emirate subdivision codes, Legal Registration Types, UAE TINs — become part of the global customer data model, maintained alongside the country-specific fields required for other jurisdictions' e-invoicing mandates. This integration approach avoids the creation of a separate UAE data silo that sits outside the global governance framework and deteriorates over time.