Your finance team is not preparing for a new invoice template. You are preparing for a system where every field on every invoice will be validated against the UAE data dictionary before it reaches the buyer or the tax authority. One wrong VAT category code, one missing party identifier, one incorrectly formatted date, and the invoice is rejected at the Accredited Service Provider (ASP) layer. This guide walks through the fields that matter most, where UAE implementations typically break, and what your ERP and master data need to look like before the go-live window closes.
The UAE data dictionary is the field-level rulebook that sits under the Peppol International Invoice UAE Profile (PINT-AE). It defines which fields are mandatory, which are conditional, which formats are accepted, and which code lists apply. It is not a suggestion. Under the Federal Tax Authority (FTA) framework and Cabinet Decision No. 106 of 2025, invoices that fail validation are not transmitted, which means they are not legally issued.
For finance teams, this shifts the compliance question from “did we send the invoice” to “did every field pass validation.” The dictionary applies to e-invoicing B2B B2G UAE transactions alike, with additional conditional rules for public sector buyers.
Header fields describe the invoice as a whole. In our implementation reviews, this is where the first wave of validation failures shows up. The fields finance teams should audit first include:
ERP defaults rarely match these requirements out of the box. Numbering series often need to be restructured, and date fields frequently need format conversion at the integration layer.
Party fields identify who is transacting. The UAE dictionary requires structured identifiers, not free text. Common fields include:
A frequent gap we see is buyer master data. Sales teams enter buyer names as they appear on purchase orders, not as they appear on trade licences. That mismatch does not fail a PDF invoice today. It will fail a PINT-AE invoice tomorrow.
Every invoice line carries its own required fields. The dictionary treats line items as structured data, not descriptive text. Key fields:
Legacy ERPs and older accounting systems often store units as free text (“box”, “pcs”, “each”). The dictionary requires a coded value. This mapping work sits between the accounting team and the ERP configuration team, and it needs to happen before integration testing, not during it.
Tax fields are the most scrutinised part of any UAE invoice. The dictionary requires:
Exemption reasons are where finance teams most often get stuck. A zero rated export needs a different reason code than a zero rated healthcare supply. Getting this wrong does not just fail validation. It creates VAT return reconciliation problems downstream.
Payment fields cover how the invoice will be settled. Payment means code, payee financial account in IBAN format, and payment terms including due date and early settlement discount are all conditional but commonly required. For public sector invoices, payment fields often need to align with the buyer procurement system reference, which is a separate field again.
Credit notes, debit notes, and adjustment invoices must reference the original transaction. The dictionary requires the original invoice number, issue date, and in some cases the reason code for the adjustment. Missing references are one of the most common causes of rejection during the ASP testing phase.
Across the implementations we support, the recurring issues are consistent:
Solving these problems is less about software and more about a disciplined field-by-field audit of what your ERP produces and what the dictionary expects. That is the work we sit alongside finance teams to complete before ASP selection is finalised, so integration testing is a confirmation step, not a discovery exercise.
The finance teams that transition smoothly treat the data dictionary as an ongoing governance responsibility, not a one-time project deliverable. That means assigning field owners across finance, sales, and IT, running periodic master data reviews, and building validation checks into the ERP before invoices reach the ASP layer.
The UAE data dictionary is not a document you read once. It is the operating standard your ERP, master data, and finance workflows will be measured against on every invoice you issue. Header fields, party identifiers, line items, tax codes, payment references, and document links each carry their own validation logic, and each represents a place where compliance can quietly break. Teams that map, clean, and govern these fields before go-live avoid the rejection cycles that stall billing later.
If your team is preparing for PINT-AE go-live and needs a structured, field-level readiness review of ERP and master data, book a compliance assessment with our UAE advisory team.
The UAE data dictionary is the field-level specification published under the PINT-AE profile. It defines every mandatory, conditional, and optional field an e-invoice must contain, the format each field must follow, and the code lists that apply. It sits under Cabinet Decision No. 106 of 2025 and governs validation at the Accredited Service Provider layer. Invoices that fail any field-level check are rejected before reaching the buyer.
In our implementation work, the recurring rejection triggers are buyer Tax Registration Number mismatches, missing VAT exemption reason codes, unit of measure values that do not map to UN/ECE codes, incorrect document type codes on credit notes, and missing exchange rate fields on foreign currency invoices. Most of these are master data issues, not integration bugs, and they need to be resolved before ASP testing starts.
Yes. Business to Government invoices in the UAE require additional conditional fields, including procurement references from the buyer entity, specific payment routing fields, and in some cases mandatory buyer identifiers that are optional for private sector transactions. The core PINT-AE structure is shared, but the conditional field logic differs. Finance teams supplying government entities should review the B2G field checklist separately from their standard B2B configuration.
Structured data at the invoice level flows directly into VAT return reconciliation. When VAT category codes, exemption reasons, and taxable amounts are captured correctly at issuance, the return filing process becomes largely automated. Errors at the invoice level, particularly wrong exemption codes or misclassified zero rated supplies, create reconciliation gaps that surface during audit. The dictionary effectively enforces the data quality VAT returns have always needed.
Field mapping should begin as soon as your ERP and master data scope is confirmed, ideally well before ASP selection is finalised. Waiting until integration testing to discover master data gaps is the most common cause of delayed go-live. A structured field audit covering header, party, line, tax, and payment fields typically takes several weeks and should sit at the front of the readiness roadmap, not the end.
