Every Phase 1 business under the UAE Electronic Invoicing System needs to understand, before any implementation work begins, the distance between where its systems and processes are today and where they must be on 1 January 2027. That distance is not uniform — it varies by transaction type, by source system, by legal entity structure, and by the completeness of existing master data. A UAE e-invoicing gap assessment that treats the question as a binary (do you have an ERP? yes — you're fine) will produce a compliance programme built on faulty foundations. What a rigorous gap assessment actually covers is the subject of this post.

What a Gap Assessment Is For

The gap assessment has a single purpose: to produce an evidence-based picture of what the business needs to do, in what sequence, and with what resources, to achieve PINT-AE compliance by the mandatory go-live date. It is the input to the implementation programme plan, not a parallel exercise to it. A programme that launches without a completed gap assessment is navigating without a map — the gaps will surface during implementation, at greater cost and with less time to resolve them than if they had been identified upfront.

The gap assessment should produce five outputs: a transaction universe inventory, a system landscape map, a field-level data availability matrix, a legal entity and organisational hierarchy register, and a complexity-weighted gap register with remediation effort estimates. Each of these outputs answers a specific question that the implementation programme cannot answer without it.

The Transaction Universe Inventory

The starting point for any UAE e-invoicing gap assessment is a complete inventory of every in-scope transaction type the business generates. In-scope means: generated by a UAE-registered entity, constituting a taxable supply or commercial transaction between business parties, and meeting the revenue threshold for Phase 1. Within that universe, the assessment must identify the document type (Tax Invoice, Commercial Invoice, Credit Note), the counterparty type (domestic B2B, government, FTZ entity, overseas buyer), the system that generates the transaction, the volume and frequency per transaction type, and the PINT-AE scenario flags that apply (FTZ, deemed supply, export, continuous, summary, agent billing, e-commerce, margin scheme).

The transaction universe inventory typically reveals transactions that the business had not initially considered in scope. Self-billing arrangements — where the buyer issues the invoice on behalf of the supplier under Article 9 of MD 243 — are frequently overlooked. Intercompany transactions between UAE entities within a corporate group are in scope until the VAT Group grace period exemption under MD 243 applies. Cross-border intercompany charges from non-UAE group entities to UAE entities may generate Commercial Invoice obligations. The inventory exercise surfaces these edge cases before they become go-live day surprises.

The System Landscape Map

Phase 1 businesses rarely generate all their invoices from a single system. The system landscape map documents every source system that produces in-scope transactions: the primary ERP, any standalone billing or invoicing systems for specific business lines, POS systems that generate B2B invoices, lease management systems for real estate portfolios, subscription billing platforms, and any manual or spreadsheet-based invoice processes. Each system in the map is assessed for its PINT-AE generation capability: can it produce UBL 2.1 XML with PINT-AE compliant field structure? If yes, what configuration or development is required? If no, what are the remediation options?

The system landscape map also covers the integration architecture between source systems and the ASP. Where multiple source systems feed a single ASP, the integration architecture for each system must be individually designed and tested. Where different systems connect to the ASP through different integration paths, the error handling and monitoring architecture must cover all paths independently. A failure in one integration path should not mask failures in another.

The Field-Level Data Availability Matrix

The field-level data availability matrix is the most granular and most revealing output of the gap assessment. For every mandatory PINT-AE field across all 51 Tax Invoice fields (49 for Commercial Invoice), it documents: whether the data exists in the current system at the required level of completeness, whether it is in the correct format and uses the correct code values from the PINT-AE code lists, whether it can be extracted in a structure that supports PINT-AE XML generation, and — where the data is missing or non-conformant — what the remediation path is and an effort estimate.

This matrix is built from a combination of data profiling (running completeness and conformance reports against actual ERP data) and technical architecture review (mapping ERP table structures to PINT-AE field requirements). It should cover every mandatory field for every transaction type in the transaction universe inventory — not a generic assessment against the full field list without regard to which fields are mandatory for which transaction types. A field that is mandatory only for export invoices (such as BTAE-21 customs reference) needs to be assessed only where export invoices are in scope; omitting it from the matrix for a business with no exports is not a gap.

The Legal Entity and Organisational Hierarchy Register

The legal entity register documents every UAE legal entity that is in scope for Phase 1, its revenue (to confirm it meets the AED 50M threshold), its Tax Identification Number, its Trade License details, the ERP company codes through which it processes transactions, and the alignment (or misalignment) between the entity structure and the ERP structure. This register is the input for the ASP onboarding process — each in-scope entity needs its own Peppol Participant Identifier — and for the company code alignment analysis described in the Technology pillar.

The Complexity-Weighted Gap Register

The gap register consolidates the findings from the transaction universe inventory, system landscape map, data availability matrix, and entity register into a single structured document that classifies each gap by severity, assigns a complexity weight, and estimates the remediation effort. Severity reflects the compliance risk: a gap in seller TIN population on the invoice is a fatal schematron failure; a gap in an optional descriptive field is informational. Complexity reflects the effort required: a master data enrichment task for emirate subdivision codes is lower complexity than a company code restructuring exercise. Effort estimates — in person-days or weeks — provide the input for resource planning and timeline validation.

Practitioner Insight: The gap assessment I conduct for Phase 1 businesses consistently reveals that the number of gaps discovered scales with the rigour of the assessment methodology, not with the age or complexity of the ERP system. A well-maintained S/4HANA implementation assessed superficially produces fewer apparent gaps than reality warrants. An older ECC system assessed at field level against actual data produces a comprehensive and accurate gap picture. The assessment methodology is the variable — not the system.

Scoping the Assessment for Multi-Jurisdiction Businesses

For UK, EU, and Indian multinationals with UAE Phase 1 entities, the gap assessment must be scoped to the UAE entity level — not the global system level. A global ERP implementation that is VAT-compliant across 20 jurisdictions is not automatically PINT-AE compliant in the UAE. The PINT-AE requirements are UAE-specific: the BTAE extension fields, the UAE code lists, the emirate subdivision codes, the Central Bank exchange rate requirement, the specific schematron validation rules. These do not exist in any other Peppol jurisdiction and are therefore absent from any global ERP configuration that has not specifically addressed UAE e-invoicing.

The practical scoping rule is: assess the UAE entities and the systems that serve them, regardless of where those systems are managed or hosted. If a UK-managed shared service centre runs the UAE entity's AP and AR processes through a European SAP instance, that European instance is within the scope of the UAE e-invoicing gap assessment for those UAE entity transactions. The geographical location of the system management team does not determine the scope — the legal entity generating the in-scope transactions does.

Timeline for the Assessment

A thorough gap assessment for a single UAE Phase 1 entity with one primary ERP typically requires three to four weeks, with direct access to the ERP system, the ability to run data extraction queries, and participation from the ERP team, the tax team, and the finance operations team. For a corporate group with multiple UAE Phase 1 entities across different ERPs and business lines, the assessment scales in duration with the number of entities and systems. For Phase 1 businesses that have not yet begun their gap assessment, the window to complete it, design the remediation programme, implement the changes, and test before go-live is compressing. The assessment should be the first action taken, not deferred until after the ASP is selected.