A paper or PDF invoice uses free text for most of its descriptive fields. A tax category appears as "Zero Rated" or "5% VAT" in human-readable form. A credit note might carry "Returned goods" as a reason. These free-text conventions are legally adequate for paper invoices but technically meaningless in the PINT-AE XML world. The UAE Electronic Invoicing System replaces free-text descriptions with structured code values from defined code lists. Every coded field on a PINT-AE invoice must carry a value from the permitted list for that field — no alternatives, no free text substitutes, no abbreviations. The schematron rules enforce this with fatal validation errors on any non-conformant code value.

The Scope of Code Lists in PINT-AE

The PINT-AE specification references 19 code lists. Some are international standards used in other Peppol jurisdictions. Some are UAE-specific additions. Together, they govern the coded fields across the full invoice: the document type, the tax categories, the exemption reasons, the credit note adjustment reasons, the payment means, the item types, the unit of measure, the emirate location, the billing frequency for continuous supplies, and more. The practical compliance task is to map every code value used in current business systems to the correct PINT-AE permitted value — and where no direct map exists, to remediate the data at source.

The Six VAT Category Codes

Tax category codes identify the VAT treatment applicable to each line item on the invoice. PINT-AE uses six permitted values: S for Standard Rate (5%), E for Exempt from VAT, O for goods and services outside the scope of VAT, R for Reverse Charge, Z for Zero Rated, and N for Margin Scheme. These six values must be applied at the invoice line level — one code per line based on the actual VAT treatment of that line item. Where a business issues invoices that mix tax categories on the same document (a common scenario in healthcare, real estate, and mixed-use properties), each line must carry its own correct tax category code.

The mapping challenge for most businesses is that their ERP applies tax codes at the line level, and those internal tax codes do not map one-to-one to the PINT-AE category codes. SAP condition types, Oracle tax regime codes, and similar constructs use business-specific naming conventions that must be mapped to the six PINT-AE values. Where multiple internal tax codes map to the same PINT-AE category (for example, various zero-rate exemption codes all mapping to Z), the mapping is straightforward. Where an internal tax code maps to a PINT-AE category that requires additional fields — such as O (out of scope) requiring a specific exemption reason code — the mapping is conditional and must activate the correct additional fields.

The Four Tax Exemption Reason Codes

Where a supply is coded as Exempt from VAT (tax category E), PINT-AE requires an exemption reason code. The UAE-specific code list provides four permitted values, each referencing the specific article of UAE VAT law that governs the exemption. These are: the exemption under the financial services article, the exemption under the residential real estate article, the exemption under bare land article, and the exemption under local passenger transport article. Applying the wrong exemption reason code — or omitting it when the tax category is E — produces a schematron failure. For businesses in the real estate, financial services, or transport sectors with significant exempt supply volumes, the exemption reason code mapping is a material pre-go-live configuration task.

The Six Credit Note Reason Codes

Credit note reason codes map to the grounds for issuing an Electronic Credit Note under Article 6(2) of MD 243 and Article 61 of the UAE VAT Decree-Law. The UAE-specific code list provides values for: cancellation of the business transaction, reduction of agreed consideration, return of consideration, administrative error, numerical error, and voluntary disclosure. Each reason code is identified by a reference code in the format DL8.61.1.A through DL8.61.1.E plus the voluntary disclosure code. The voluntary disclosure code is operationally significant: where a business issues a credit note in connection with a voluntary disclosure to the FTA, the specific reason code must reflect that, creating a link in the FTA's Corner 5 data between the credit note and the voluntary disclosure.

The Seven Emirate Subdivision Codes

Every address field in a PINT-AE invoice — seller address, buyer address, delivery address — must include an emirate subdivision code from the UAE Emirate Subdivision code list. The seven values are: AE-AZ (Abu Dhabi), AE-DU (Dubai), AE-SH (Sharjah), AE-AJ (Ajman), AE-UQ (Umm Al Quwain), AE-RK (Ras Al Khaimah), and AE-FU (Fujairah). These are the ISO 3166-2:AE subdivision codes for the seven emirates.

The practical gap is that ERP address records for UAE entities and customers hold emirate data in free text — "Dubai", "Abu Dhabi", "Sharjah" — or abbreviations that do not match the ISO codes. The mapping from free-text emirate names to subdivision codes is not complicated, but it must be applied consistently across every address record in the customer master, supplier master, and entity master. Where the free-text emirate field is inconsistent or missing, the mapping fails and the invoice cannot carry the correct subdivision code.

Payment Means Codes

Payment means codes identify how the invoice is expected to be paid. PINT-AE permits nine values covering: instrument (cash, cheque, bank transfer, credit or debit card, bank draft, standing order or direct debit, payment card, SEPA credit transfer, and credit transfer). The payment means code is an optional field on the invoice, but where a business chooses to include it — and many businesses do, for operational and reconciliation reasons — it must use one of the nine permitted values. Internal payment terms codes or free-text payment method descriptions do not satisfy the PINT-AE requirement.

The Reverse Charge Goods Type Codes

For supplies subject to the domestic reverse charge mechanism under UAE VAT, PINT-AE requires a Reverse Charge Goods Type code identifying the specific goods category. The UAE reverse charge mechanism applies to certain electronic devices (Cabinet Decision 91 of 2023), precious metals and precious stones (Cabinet Decision 127 of 2024), and metal scrap (Cabinet Decision 153 of 2025). The permitted code values correspond to these categories. Businesses in the electronics, precious metals, and scrap metal trading sectors must configure the correct goods type code for reverse charge transactions — a field that has no equivalent in existing invoice templates.

Practitioner Insight: The code list compliance task is underestimated because it looks like a simple mapping exercise. The complexity emerges when the mapping reveals gaps: internal tax codes that do not map to any permitted PINT-AE value because the internal code combines two tax treatments into one code, or credit note reason codes that are free text in the current system rather than structured values. Where the gap is at the data capture point — the system records a credit note reason as a free-text field — the fix is not a mapping; it is a system change to capture the reason as a structured selection from the PINT-AE code list. That change affects every person who issues a credit note in the organisation.

Building the Code List Mapping Register

The code list mapping register is a pre-go-live deliverable that every Phase 1 business should produce. For each of the 19 PINT-AE code lists, it documents: the internal system values currently in use, the PINT-AE permitted value each maps to, whether the map is direct (one-to-one), conditional (depends on additional attributes), or absent (no current internal value maps to the required PINT-AE value). Where the map is absent, the register identifies the remediation required: master data enrichment, system configuration change, or process change to capture the required structured value at source.

This register serves as both a gap document and a configuration specification for the ERP development team and the ASP integration team. It ensures that the PINT-AE XML generated by the business carries code values that will pass schematron validation — not just values that look plausible but fail the fatal rules on day one.