Peppol UBL vs PINT-AE: Which XML Format Does the UAE FTA Actually Require?
Finance teams across the UAE are asking the same question: “We support UBL 2.1 — are we compliant?”
Well the answer is: probably not.
And the reason matters.
Peppol UBL UAE, Peppol BIS Billing 3.0 UAE, UBL 2.1, and PINT-AE are not four names for the same thing. There are four different layers of one technical stack:
- XML is the file language.
- UBL 2.1 gives the invoice structure.
- Peppol BIS Billing 3.0 adds invoice business rules.
- PINT-AE localises those rules for the UAE.
For PINT-AE UAE e-invoicing, this final UAE layer is the part that finance teams cannot afford to miss. The MoF’s mandatory fields document expressly links UAE electronic invoices to the UAE Electronic Invoicing System Guidelines, Ministerial Decisions No. 243 and 244 of 2025, and the Peppol UAE electronic document specifications — PINT-AE.
An invoice submitted in plain UBL 2.1 without the PINT-AE customisation layer may look structured, but it will not be enough for UAE validation. An invoice missing UAE-specific fields, such as the TIN-based Participant Identifier, transaction type flags, the Specification Identifier, or AED-denominated line-level VAT, can be rejected before it reaches the buyer.
This is where PINT-AE vs UBL 2.1 becomes more than a technical debate. It becomes a compliance risk. The MoF’s mandatory fields list includes UAE-specific invoice requirements such as invoice transaction type code, seller tax identifier, VAT line amount in AED, and invoice line amount in AED.
This guide explains each layer clearly.
- What it is.
- What it does.
- And how it connects to the UAE FTA XML format expected under the Electronic Invoicing System.
It is written for finance directors, ERP leads, and tax managers who need to understand the framework without reading hundreds of pages of Peppol specifications. The aim is simple: help your team avoid e-invoice validation failures in the UAE before go-live, not after the ASP starts rejecting files.
The Terminology Problem: Four Terms, One Compliance Obligation
The confusion starts because every vendor says they “support e-invoicing.” That is too vague. For e-invoicing UAE FTA readiness, the real question is not whether your ERP can produce XML. It is whether it can produce PINT-AE-compliant XML with the correct UAE fields, codes, and validation logic.
The hierarchy is simple:
XML → UBL 2.1 → Peppol BIS Billing 3.0 → PINT-AE.
Each layer builds on the one before it. PINT-AE is the UAE-specific end product. Peppol’s UAE specification describes PINT-AE as a national customisation of global PINT for the UAE, built to meet UAE legal and business requirements.
Your ERP may support UBL 2.1. Your ASP may be Peppol-certified. But neither fact guarantees PINT-AE compliance — which is the only compliance that matters under UAE law.
| Term | What It Is | UAE Compliance? |
| XML | Base markup language — the container format | Required as the file format, but not sufficient alone |
| UBL 2.1 | Invoice syntax standard built on XML | Required as the syntax base, but not sufficient alone |
| Peppol BIS Billing 3.0 | Global Peppol invoice ruleset | Foundation only. UAE does not use vanilla BIS 3.0 |
| PINT-AE | UAE-specific Peppol standard localised for FTA reporting | Mandatory under the UAE Electronic Invoicing System |
For implementation, this means the ERP, ASP, and finance master data must be tested against the PINT-AE data dictionary, UAE e-invoice mandatory fields, and PINT AE validation rules — not just generic XML output.
What Is Peppol? And Why Did the UAE Adopt It?
Peppol stands for Pan-European Public Procurement On-line. It started in Europe for public procurement, but today it works as a global network for exchanging business documents in a structured and secure way.
Peppol is not software. It is not an ERP. It is not an invoicing app.
It is a framework. It sets the rules for exchanging invoices, credit notes, purchase orders, and other trade documents. It allows different systems to speak one common language, so a seller using one ERP can send an e-invoice to a buyer using another system.
This is one reason the UAE adopted Peppol for FTA e-invoicing. Instead of forcing every business to manually upload invoices to one government portal, the UAE chose a network model. This reduces pressure on finance teams, IT teams, and the FTA system.
Under this model, businesses connect through Accredited Service Providers, or ASPs. The supplier sends the invoice through its ASP. The buyer receives it through its ASP. The FTA receives the tax data through the approved e-invoicing framework. The UAE MoF Guidelines define ASPs as accredited providers of electronic invoicing services in the UAE.
That is why choosing an FTA-approved ASP is not just an IT procurement step. It is part of compliance. The ASP validates the invoice, checks the file, and helps transmit it in the required format.
Peppol is already used in Australia, New Zealand, Singapore, Japan, Malaysia, several EU countries, and other markets. Singapore’s InvoiceNow, for example, runs on the Peppol framework.
For UAE finance teams, the lesson is simple:
- Peppol is the network.
- UBL 2.1 is the technical structure.
- PINT-AE is the UAE-specific invoice format.
So, when a vendor says it supports Peppol UBL UAE, ask one more question:
Does it support PINT-AE UAE e-invoicing?
That is the real test. The UAE does not require a generic Peppol invoice. It requires an invoice that follows the UAE’s local Peppol specification, mandatory fields, tax rules, and validation requirements.
What Is UBL 2.1? The Syntax Layer
UBL 2.1 stands for Universal Business Language version 2.1. It is an international standard developed by OASIS. In simple words, it defines the structure of electronic business documents.
For e-invoicing, UBL 2.1 tells the system how an invoice file should be organised. It covers:
- the basic invoice structure,
- including the invoice number,
- invoice date,
- supplier details,
- buyer details,
- line items,
- VAT amount,
- payment details,
- and totals.
OASIS describes UBL 2.1 as a set of XML schemas for common business documents such as invoices, orders, and despatch advice.
This makes UBL 2.1 important. But it does not make it complete.
A plain UBL 2.1 invoice may have the correct structure, but that does not mean it is ready for the UAE. It may still miss UAE-specific requirements. It may not include the right tax fields. It may not carry the correct UAE invoice type. It may not show VAT amounts in the required way. It may also fail the checks applied by the ASP before transmission.
That is where PINT-AE vs UBL 2.1 becomes important.
UBL 2.1 gives the invoice its base structure. PINT-AE adds the UAE rules on top of that structure.
This is also why Peppol BIS Billing 3.0 UAE should not be treated as the final answer. Peppol BIS Billing 3.0 is an important foundation, but the UAE uses its own localised version through PINT-AE.
The UAE MoF mandatory fields document confirms that electronic invoicing is aligned with the UAE Electronic Invoicing System, the Ministerial Decisions, and the Peppol UAE electronic document specifications.
It also lists the required UAE invoice fields, including invoice type, business process type, seller and buyer identifiers, tax category details, AED-related VAT values, and line-level invoice data.
For finance teams, the practical point is clear.
Your ERP must not only create an XML invoice. It must create the right XML invoice.
That means the invoice file should follow UBL 2.1 structure, but it must also include the UAE-specific PINT-AE requirements. It should carry the correct seller and buyer identification details, the right invoice type, proper VAT treatment, complete line-level details, and all required fields from the PINT-AE data dictionary.
This is the real UAE FTA XML format issue.
A system that “supports UBL” is not automatically compliant. A system that creates a normal XML invoice is also not automatically compliant. For a valid xml e-invoice UAE implementation, the ERP and ASP must apply the UAE e-invoice mandatory fields and the PINT AE validation rules.
In short:
- UBL 2.1 gives the structure.
- PINT-AE gives the UAE compliance layer.
- The ASP checks whether both are correct.
That is why finance teams should not ask, “Can our ERP export XML?”
They should ask:
“Can our ERP produce a PINT-AE compliant invoice that our ASP can validate and transmit under the UAE e-invoicing system?”
What Is Peppol BIS Billing 3.0? The Global Ruleset
Peppol BIS Billing 3.0 stands for Peppol Business Interoperability Specification — Billing version 3.0.
If UBL 2.1 gives the invoice its basic structure, Peppol BIS Billing 3.0 adds the business rules. It explains which invoice fields are mandatory, which fields are optional, and which checks should apply before an invoice can move through the Peppol network.
In simple terms, UBL 2.1 tells the system how the invoice is arranged. Peppol BIS Billing 3.0 tells the system what the invoice must contain.
But here is the part finance teams must not miss.
Peppol BIS Billing 3.0 is not the final answer for UAE compliance. It was built mainly around the European e-invoicing framework and the EN 16931 standard. The Peppol BIS Billing documentation itself links the invoice content to EU VAT reporting rules and Directive 2006/112/EC. That makes it useful as a global reference point, but not enough for UAE implementation.
This is where Peppol BIS Billing 3.0 UAE can become a confusing phrase. The UAE does not simply take the standard European Peppol BIS invoice and use it as-is. The UAE uses PINT-AE, which is the UAE-localised version of the Peppol international invoice model.
Think of it like this:
- UBL 2.1 gives the invoice structure.
- Peppol BIS Billing 3.0 gives global business rules.
- PINT creates a more international model.
- PINT-AE localises that model for the UAE.
That is why a vendor statement such as “we are Peppol BIS Billing 3.0 compliant” is not enough. It may show that the system understands Peppol rules. It does not prove that the system can handle PINT-AE UAE e-invoicing.
For UAE purposes, the system must handle local requirements such as:
- UAE seller and buyer identification,
- TIN and TRN logic,
- UAE transaction classifications,
- AED tax reporting,
- free zone indicators,
- credit note reason requirements,
- and the full PINT-AE data dictionary.
The MoF mandatory fields document confirms UAE-specific requirements, including:
- TIN,
- TRN,
- invoice type,
- transaction classifications,
- invoice line data,
- tax category details,
- and AED-related tax values.
This matters for ERP teams because many systems already support “Peppol” or “UBL”. That sounds reassuring. But it may only mean the system can create a general Peppol invoice. It may still fail UAE validation if it cannot generate the local UAE fields required by the UAE FTA XML format.
There is also discussion in the Peppol market about Peppol BIS 4.0, which is expected to bring BIS and PINT closer together. Storecove notes that Peppol BIS 4.0 is under development and expected to merge Peppol BIS and PINT formats.
For UAE businesses, this does not change the immediate question.
The question is not: “Are we ready for the next Peppol version?”
The question is: “Can our ERP and ASP produce and validate a PINT-AE invoice under UAE rules?”
That is the only question that matters for FTA e-invoicing.
What Is PINT-AE? The UAE-Specific Format — The One That Actually Matters
PINT-AE stands for Peppol International Invoice — UAE. It may also appear as PINT AE or PINTAE.
This is the UAE-specific e-invoice format. It is not a generic XML file. It is not plain UBL 2.1. It is not vanilla Peppol BIS Billing 3.0.
PINT-AE is the UAE-localised version of the Peppol international invoice model. It tells businesses exactly how an e-invoice should be structured, validated, exchanged, and reported under the UAE Electronic Invoicing System.
This is where PINT-AE UAE e-invoicing becomes the core compliance issue.
The MoF Guidelines and Mandatory Fields document, both issued on 23 February 2026, set the UAE e-invoicing framework and provide the field-level requirements for electronic invoices.
The mandatory fields document also confirms that electronic invoicing applies to any person conducting business in the UAE, unless specifically excluded under Ministerial Decision No. 243 of 2025, and that implementation follows the phased plan under Ministerial Decision No. 244 of 2025.
In practical terms, PINT-AE is the format your ERP and ASP must get right.
A PINT-AE invoice must include the UAE-required business details, tax details, invoice classification, buyer and seller identification, line-level invoice information, AED tax values, and validation logic. These are not “nice to have” fields. They are part of the UAE e-invoice mandatory fields framework.
That is why an invoice can look correct in your ERP and still fail when submitted through the ASP.
The ERP may have:
- the invoice number.
- the VAT amount.
- the customer name.
- even export XML.
But if the invoice is not mapped correctly to the PINT-AE data dictionary, the ASP validation can reject it. That is how e-invoice failed validation UAE issues usually start.
How PINT-AE Differs from Plain UBL 2.1
Plain UBL 2.1 is the base structure. PINT-AE is the UAE compliance format.
| Area | Plain UBL 2.1 | PINT-AE |
| Main purpose | Gives the invoice its basic XML structure | Adds the UAE e-invoicing rules on top of that structure |
| UAE seller and buyer tax details | Not designed specifically for UAE TRN and TIN logic | Requires UAE-specific identification details for seller and buyer |
| Participant identification | Not a UAE-specific requirement | Uses the UAE participant identification approach based on the 0235 scheme and TIN logic |
| Transaction classification | Does not define UAE-specific transaction flags | Covers UAE transaction types such as free zone, margin scheme, deemed supply, reverse charge, and other classifications |
| VAT reporting | Does not automatically apply UAE VAT reporting rules | Requires UAE VAT treatment and AED-related tax values where applicable |
| Validation | Checks structure only | Applies UAE field rules, business rules, and ASP validation checks |
| Digital trust | Not the focus of the base structure | Requires secure exchange through the approved UAE e-invoicing framework |
| Transmission | Not linked to a UAE transmission model | Transmitted through ASPs under the UAE Peppol-based model |
So, PINT-AE vs UBL 2.1 is not a small technical distinction. It is the difference between an invoice that only has structure and an invoice that can pass UAE validation.
UBL 2.1 is like the invoice skeleton.
PINT-AE adds the UAE tax brain, compliance muscles, and ASP-ready logic.
How PINT-AE Differs from Peppol BIS Billing 3.0
Peppol BIS Billing 3.0 is a global business ruleset with a strong European base. PINT-AE is built for the UAE.
| Area | Peppol BIS Billing 3.0 | PINT-AE |
| Geographic focus | Mainly European framework | UAE-specific localisation |
| Tax framework | Built around EU VAT concepts | Built around UAE VAT and UAE tax reporting |
| Legal identifiers | Uses European-style identifiers | Uses UAE identifiers such as TRN, TIN, Trade Licence, Emirates ID, Passport, and Customs Declaration where relevant |
| Participant identification | Depends on jurisdiction-specific schemes | Uses the UAE participant identification approach required under the UAE framework |
| Mandatory fields | Covers the standard Peppol billing field set | Adds UAE-specific mandatory and conditional fields |
| Free zone treatment | Not a core EU billing concept | Covered through UAE transaction classification |
| AED tax values | Not a UAE requirement under BIS 3.0 | Required where UAE rules demand AED-based tax reporting |
| Credit note reason | Not treated the same way under the UAE update | Mandatory under the PINT-AE v1.0.1 update |
This is why Peppol UBL UAE cannot be treated as a shortcut phrase for compliance. A UAE invoice must follow the UAE-localised Peppol rules, not only the general Peppol structure.
The UAE FTA XML format is therefore not “any XML”. It is not “any Peppol invoice”. It is an XML invoice aligned with PINT-AE and checked through the UAE ASP framework.
PINT-AE v1.0.1 — July 2025 Update: What Changed
Finance teams should also check which version their ERP vendor or ASP is using.
This is important because PINT-AE was updated after the earlier release.
Deloitte Middle East reported that PINT AE v1.0.1 was released on 31 July 2025. The update introduced clearer field naming around VAT references, made credit note reason codes mandatory, and removed unused or redundant rules.
For finance teams, the action point is simple.
If your e-invoicing project started before 31 July 2025, do not assume the setup is still current. Review the implementation against PINT-AE v1.0.1.
This review should cover:
| Area to Check | Why It Matters |
| Credit notes | Reason codes must be properly captured and transmitted |
| VAT field mapping | VAT references should follow the updated field clarity |
| Validation rules | Old or redundant rules should not create false rejections |
| ERP-to-ASP mapping | The ERP output must match the latest PINT-AE expectations |
| Master data | Seller, buyer, TIN, TRN, and transaction classifications must be complete |
This is where many PINT AE validation rules issues appear. The system may have been configured once, but the rules may have moved since then.
A safe finance team should not ask, “Did we configure e-invoicing last year?”
It should ask:
“Is our configuration aligned with the current PINT-AE version, the latest mandatory fields, and our ASP’s current validation engine?”
That is the cleaner question. And it saves weeks of rework later.
The PINT-AE Data Dictionary: What Finance Teams Must Map
The PINT-AE data dictionary is where UAE e-invoicing becomes practical. It tells finance teams what data the invoice must carry before it can pass ASP validation.
The MoF’s UAE Electronic Invoice Mandatory Fields document, issued on 23 February 2026, lists the required fields for electronic tax invoices and commercial electronic invoices. It should be read with the UAE E-Invoicing Guidelines, Ministerial Decision No. 243 of 2025, Ministerial Decision No. 244 of 2025, and the Peppol UAE specifications for PINT-AE.
For PINT-AE UAE e-invoicing, fields fall into three categories:
| Field Type | Meaning | Finance Team Impact |
| Mandatory | Always required | Must be available in the ERP, billing system, or source data |
| Conditional | Required when a condition applies | Must trigger correctly based on currency, VAT treatment, invoice type, or transaction nature |
| Optional | Additional detail | Useful for processing, but not always needed for validation |
Most e-invoice failed validation UAE issues start here. One missing field, wrong format, or incorrect transaction flag can stop the invoice before it reaches the buyer.
The 50+ Mandatory Fields — Key Categories
The MoF Mandatory Fields document lists more than 50 mandatory fields for a UAE electronic tax invoice. Finance teams should map them by category, not as one long technical list.
Invoice Header Fields
These fields identify the invoice, its date, type, currency, process, and UAE transaction classification.
| Field | Common Mapping Code | What Finance Teams Should Check |
| Invoice number | IBT-001 | Must be unique and not reused. |
| Invoice date | IBT-002 | Must show the actual issue date in the required format. |
| Invoice type code | IBT-003 | Must identify tax invoice, credit note, commercial invoice, or other permitted type. |
| Invoice currency code | IBT-005 | Must follow ISO currency codes such as AED, USD, EUR, or GBP. |
| Business process type | IBT-023 | Must identify the correct e-invoicing process scenario. |
| Specification identifier | IBT-024 | Must confirm that the invoice follows PINT-AE, not generic Peppol or plain UBL. |
| Invoice transaction type code | UAE-specific field | Must identify UAE flags such as free zone, deemed supply, margin scheme, continuous supply, disclosed agent billing, e-commerce supply, and exports. |
This field group affects VAT treatment, buyer processing, ASP checks, and FTA reporting.
Seller Details
Seller details must identify the supplier clearly across the UAE Peppol network.
| Field | What Finance Teams Should Check |
| Seller name | Must match the registered business name. |
| Seller electronic address | Based on the seller’s TIN. |
| Seller electronic identifier | For UAE businesses, this uses the fixed value 0235. |
| Seller legal registration identifier | Usually the trade licence or other official registration number. |
| Seller legal registration identifier type | Includes TL for trade licence, EID, PAS, or CD where applicable. |
| Seller tax identifier | VAT-registered sellers should provide the TRN. |
| Seller tax scheme code | Default tax scheme is VAT. |
| Seller address | Must include address line, city, subdivision, and country code. UAE country code is AE. |
If the seller’s TIN, TRN, trade licence, or address is incomplete, the issue will appear during validation.
Buyer Details
Buyer master data is often the weak point. Old customer records, missing TRNs, and incomplete addresses can break UAE e-invoice mandatory fields mapping.
| Field | What Finance Teams Should Check |
| Buyer name | Must be complete and consistent with customer records. |
| Buyer electronic address | Must identify where the invoice should be delivered. |
| Buyer electronic identifier | Required for the buyer endpoint. |
| Buyer TRN | Required where the buyer is VAT-registered in the UAE. |
| Buyer tax scheme code | Default tax scheme is VAT where applicable. |
| Buyer address | Must include the required address elements. |
| Buyer country code | Must be correct, especially for cross-border and export invoices. |
The ASP cannot repair poor customer master data. It can only validate what it receives.
Document Totals
Document totals must reconcile exactly. Small rounding differences can still create rejection risk under PINT AE validation rules.
| Field | Common Mapping Code | What Finance Teams Should Check |
| Sum of invoice line net amount | IBT-106 | Must equal the sum of all line net amounts. |
| Invoice total amount without tax | IBT-109 | Must reconcile to taxable and non-taxable line totals. |
| Invoice total tax amount | IBT-110 | Must match tax breakdown and line-level tax values. |
| Invoice total amount with tax | IBT-112 | Must equal amount before tax plus tax. |
| Amount due for payment | IBT-115 | Must show the final payable amount after adjustments. |
Test this using real invoices with discounts, credit notes, foreign currency, zero-rated supplies, and mixed VAT lines. Perfect sample invoices rarely expose weak mapping.
Tax Breakdown
The tax breakdown explains how VAT has been applied. Showing “5% VAT” at the bottom is not enough.
| Field | What Finance Teams Should Check |
| Tax category taxable amount | Must show the taxable base for each VAT category. |
| Tax category tax amount | Must show the VAT amount for each category. |
| Tax category code | Must identify VAT treatment. |
| Tax category rate | Must show the applicable VAT rate. |
UAE tax categories may include standard-rated, zero-rated, exempt, reverse charge, export, and other classifications. This is where generic Peppol UBL UAE setups often fail.
Invoice Line Level
Line-level data must be complete enough for validation, VAT review, and buyer-side processing.
| Field | Common Mapping Code | What Finance Teams Should Check |
| Invoice line identifier | IBT-126 | Each line must have its own identifier. |
| Invoiced quantity | IBT-129 | Must match the billed item or service. |
| Unit of measure code | IBT-130 | Should use accepted unit of measure codes. |
| Invoice line net amount | IBT-131 | Must match the line calculation before tax. |
| Item net price | IBT-146 | Must reflect price after discount. |
| Item gross price | IBT-148 | Must reflect price before discount. |
| Invoiced item tax category code | IBT-151 | Must show VAT treatment at line level. |
| Invoiced item tax rate | IBT-152 | Must show the VAT rate at line level. |
| VAT line amount in AED | UAE-specific field | Must show VAT amount for each line item in AED. |
| Invoice line amount in AED | UAE-specific field | Must show total payable amount for each line item in AED. |
| Item name and description | IBT-153 / IBT-154 | Must clearly identify what is being billed. |
This is important for businesses invoicing in USD, EUR, GBP, or any non-AED currency. The invoice may be foreign currency, but UAE validation still needs AED values at line level where required. That is a common xml e-invoice UAE failure point.
UAE-Specific Fields Not Found in Global Peppol
This is where generic Peppol setups usually break. A system may support Peppol and UBL 2.1, but still miss UAE-localised fields required for UAE FTA XML format compliance.
Exchange Rate
Exchange rate becomes critical when the invoice currency is not AED. If the invoice is in USD, EUR, GBP, or another currency, the system must still support AED-based reporting values where required.
Finance action: test whether the ERP exchange rate flows into the e-invoice file used by the ASP.
Service Accounting Code
Service invoices need careful mapping. Many businesses bill services as generic “items” in the ERP. That may work internally, but it can fail PINT-AE mapping.
Finance action: do not map all revenue lines as goods unless that reflects the actual transaction.
Transaction Type Flags
The invoice transaction type code identifies special UAE scenarios.
| Transaction Flag | Why It Matters |
| Free trade zone | Impacts transaction classification and tax review. |
| Deemed supply | Supports VAT reporting treatment. |
| Margin scheme | Relevant for eligible margin scheme transactions. |
| Summary invoice | Identifies summary billing scenarios. |
| Continuous supply | Relevant for recurring or continuous supplies. |
| Disclosed agent billing | Required where agent billing applies. |
| Supply through e-commerce | Identifies e-commerce supply scenarios. |
| Exports | Supports export classification. |
The ASP can validate the file. It cannot decide the VAT treatment for the business. That remains a finance and tax responsibility.
PINT-AE Specification Identifier
Every UAE e-invoice must show that it follows the correct PINT-AE specification. This tells the ASP that the invoice is not plain UBL 2.1 or a generic Peppol invoice.
Finance action: ask the ERP vendor whether the exported invoice clearly identifies the current UAE PINT-AE specification accepted by the ASP.
Conditional Fields: Finance Teams Commonly Miss
Conditional fields are risky because they only appear when a condition applies. A clean AED invoice may pass testing, while a real USD service invoice fails on go-live day.
| Field | Code / Mapping Reference | When It Becomes Mandatory | Consequence of Missing |
| Exchange rate | BTUAE-04 / UAE currency mapping | Invoice currency is not AED | Non-AED invoice may fail validation or produce incorrect AED tax reporting. |
| Service accounting code | BTUAE-17 / BTAE-17 | Invoice involves services | Service invoices may fail validation or be incorrectly classified. |
| Credit note reason | PINT-AE credit note reason field | Any credit note | Credit note may be rejected if the reason code is missing. |
| Buyer TRN | IBT-048 | Buyer is VAT-registered in the UAE | B2B tax invoice data may be incomplete. |
| Buyer legal registration identifier | IBT-047 | Required based on buyer identification scenario | Buyer identity may not validate correctly. |
| VAT line amount in AED | UAE-specific line field | Required for tax invoice line reporting | Foreign currency invoices may fail or reconcile incorrectly. |
| Invoice transaction type code | UAE-specific field / BTAE-02 | Always required for UAE transaction classification | Incorrect classification may cause validation or tax reporting issues. |
Deloitte reported that PINT-AE v1.0.1, released on 31 July 2025, made credit note reason codes mandatory, improved VAT-related field naming, and removed unused rules. Finance teams that started implementation before this update should review their mapping again.
Test More Than One Clean Invoice
Do not test e-invoicing with one standard sales invoice. Test the scenarios that actually happen in the business.
| Use Case | Why It Should Be Tested |
| AED tax invoice | Basic validation check. |
| USD or EUR invoice | Exchange rate and AED value check. |
| Credit note | Reason code and reference check. |
| Service invoice | Service accounting code check. |
| Free zone transaction | Transaction flag check. |
| Export invoice | Export classification and VAT treatment check. |
| Reverse charge transaction | Tax category and buyer treatment check. |
| Mixed VAT invoice | Line-level VAT and tax breakdown check. |
This is the practical heart of PINT-AE vs UBL 2.1.
UBL 2.1 can carry invoice data. PINT-AE decides whether that data is complete, valid, and usable under the UAE framework.
Before implementation, finance teams should build a field mapping sheet. Every mandatory and conditional field in the PINT-AE data dictionary should be mapped to the ERP source field, owner, validation rule, and fallback process.
| Question | Why It Matters |
| Where does this field come from? | ERP, customer master, tax master, product master, manual upload, or ASP portal. |
| Who owns the field? | Finance, tax, sales operations, procurement, IT, or master data team. |
| What happens if the field is missing? | Block invoice, send for review, reject upload, or trigger correction. |
| Has it been tested with real invoices? | Sample invoices rarely expose the real errors. |
That is how finance teams reduce rework: by fixing source data before the first invoice is transmitted, not after the ASP rejects it.
The Participant Identifier: The 0235 Format Explained
The Participant Identifier is one of the most common pain points in PINT-AE UAE e-invoicing.
Every entity on the UAE Peppol network needs a Peppol Participant ID. It is also called a Peppol ID or endpoint. This ID tells the network where the invoice should go. Without the correct ID, the invoice cannot be routed to the right buyer.
In the UAE, the format is fixed:
0235:10-digit TIN
For example:
0235:1234567890
The “0235” is the UAE scheme code. The 10-digit number after it is the entity’s TIN.
This is where finance teams often mix up TRN and TIN.
| Term | Meaning | Use in E-Invoicing |
| TRN | 15-digit Tax Registration Number for VAT | Used for VAT identification |
| TIN | First 10 digits of the TRN | Used to create the UAE Peppol Participant ID |
| Peppol ID | 0235 + 10-digit TIN | Used to route e-invoices through the network |
So, if a customer gives you only its TRN, that is not the final Peppol ID. The Peppol ID must be created in the correct 0235 format.
Tax groups need extra care. Each tax group member must use its own individual TIN, not the representative member’s TIN. This point is commonly missed by group finance teams. If the wrong TIN is used, the invoice may be routed incorrectly or fail validation.
Businesses that are not yet registered for corporate tax also need to act. They must register with the FTA to obtain a TIN for e-invoicing. No TIN means no Peppol ID. No Peppol ID means the business cannot properly send or receive compliant e-invoices under the UAE framework.
The buyer Peppol ID is also a master data challenge. To issue a compliant e-invoice, you need the buyer’s Peppol ID. This is not the same as simply storing the buyer’s TRN. Finance teams should start collecting 0235-format Peppol IDs from B2B customers early. For a business with 500 customers, this is not a two-hour IT task. It can take weeks of outreach, follow-ups, and customer record cleanup.
There are also fallback endpoint codes for special cases:
| Fallback Endpoint | When It Is Used |
| 0235:9900000098 | Buyer is in scope but not yet onboarded on the e-invoicing system |
| 0235:9900000097 | Deemed supply transactions |
| 0235:9900000099 | Exports where the buyer has no Peppol ID |
The risk is simple. If the Peppol ID is wrong, the invoice may not reach the buyer. No delivery confirmation means the invoice process is not complete. Under the UAE model, this is not a minor admin error. It can directly affect the validity of the e-invoice.
For UAE FTA XML format readiness, Peppol ID collection should sit inside the master data workstream. It should not be left until ASP onboarding.
Internal link placement: Our UAE e-invoicing ERP readiness checklist covers the full Peppol ID data collection process.
Source to link: MoF Guidelines V1.0, Chapter on Participant Identifiers; Alvarez & Marsal UAE E-Invoicing Guidelines alert.
How the XML Is Transmitted: AS4 Protocol + 5-Corner Model
A UAE e-invoice cannot simply be exported as XML and emailed to the buyer.
That is not how FTA e-invoicing works.
Under the UAE model, the invoice must move through the Peppol network using an accredited ASP and the required transmission protocol. This is why an ERP that only creates an XML file is not enough. The XML must be validated, signed, transmitted, reported, and confirmed.
AS4 is the required transmission standard for PINT-AE invoice exchange. It supports reliable messaging, encryption, digital signatures, delivery confirmation, and non-repudiation. In plain language, it proves that the invoice was sent securely, received properly, and not altered in the process.
This means invoices cannot be sent by email, FTP, or a direct API to the FTA. They must move through the Peppol network via an FTA approved ASP using AS4. Any other route may create an invoice file, but not a valid UAE e-invoice.
The UAE 5-Corner Model
The UAE uses a five-corner model, also called the DCTCE model. Each corner has a clear role.
| Corner | Role |
| Corner 1 | Supplier — the business issuing the invoice from its ERP or finance system |
| Corner 2 | Supplier’s ASP — validates the PINT-AE format, signs the invoice, and transmits it |
| Corner 3 | Buyer’s ASP — receives, validates, and delivers the invoice to the buyer |
| Corner 4 | Buyer — the customer receiving the invoice in its ERP or finance system |
| Corner 5 | FTA Control Data Platform / E-Billing System — receives the tax data report |
This model explains why the ASP role is so important. The ASP is not just a software vendor. It is the approved network gateway for the invoice.
What Happens Step by Step
The process looks like this:
- The supplier creates the PINT-AE XML invoice in its ERP or billing system.
- The invoice is sent to the supplier’s ASP.
- The ASP validates it against the PINT-AE rules and signs it digitally.
- The supplier’s ASP sends it to the buyer’s ASP through Peppol using AS4.
- At the same time, the supplier’s ASP reports tax data to the FTA platform.
- The buyer’s ASP sends delivery confirmation back to the supplier’s ASP.
- The buyer’s ASP also reports tax data to the FTA platform.
- The FTA platform confirms successful receipt of tax data.
- The message-level status confirms end-to-end delivery.
This is why delivery confirmation matters. A file sitting in the ERP is not enough. A file emailed to the buyer is not enough. A compliant invoice must travel through the approved route and receive the required confirmations.
Digital Signature Requirement
Every PINT-AE invoice must include a digital signature with certificate references and timestamps. This supports authenticity and tamper-evidence.
For finance teams, the point is simple. Once the invoice leaves the ERP, the business still needs proof that the invoice was validated, signed, transmitted, and received. This is what the ASP and AS4 process help evidence.
System Failure Protocol
System failure does not remove the obligation to report.
If the FTA’s E-Billing System is unavailable, invoice data must be retained and transmitted once the system is restored. The FTA must also be notified of the system failure within two business days.
This is why businesses should not treat e-invoicing as a “send invoice” project only. It also needs a failure-handling process, audit trail, and recovery procedure.
For xml e-invoice UAE implementation, the real question is not only whether your ERP can create PINT-AE XML. The stronger question is whether your ERP and FTA approved ASP for e invoicing can transmit, validate, sign, report, and confirm the invoice through the UAE 5-corner model.
Invoice Types Under PINT-AE: Tax Invoice vs Commercial Invoice
Finance teams often assume there is one UAE e-invoice format. There is not.
Under PINT-AE UAE e-invoicing, the UAE framework recognises different document types. The two main invoice types are the Electronic Tax Invoice and the Electronic Commercial Invoice. Both follow PINT-AE, but they do not carry the same field requirements.
An Electronic Tax Invoice is used for standard B2B VAT transactions, mainly where the supplier and buyer are VAT-registered. It requires full UAE VAT invoice content, including seller and buyer TRN/TIN details, VAT breakdown, line-level tax data, and all relevant UAE e-invoice mandatory fields.
An Electronic Commercial Invoice is used where a tax invoice is not required, such as certain transactions involving non-VAT-registered buyers, exempt supplies, or zero-rated exports. It still follows PINT-AE, but the mandatory field list is adapted. For example, buyer TRN is not required where the buyer is not VAT-registered.
Credit notes follow the same logic. An Electronic Tax Credit Note adjusts a Tax Invoice. An Electronic Credit Note adjusts a Commercial Invoice. Both must refer to the original invoice number and include a credit note reason code. Deloitte reported that credit note reason codes became mandatory under the PINT-AE v1.0.1 update released on 31 July 2025.
There is no separate “provisional invoice” category under the UAE e-invoicing framework. A provisional invoice must still be issued as a full PINT-AE compliant e-invoice. Any later change should be handled through a credit note or an additional invoice.
Self-billing is also allowed, but only for electronic Tax Invoices and only where there is an agreement between the supplier and buyer. It is not available for Commercial Invoices. In a self-billing setup, the buyer issues the invoice on behalf of the supplier. Once the supplier is in scope, self-billing applies to all business transactions for that supplier.
| Invoice Type | When Used | Key Difference from Other Type |
| Electronic Tax Invoice | B2B — both parties VAT-registered | Requires seller and buyer TRN, plus full VAT breakdown per line |
| Electronic Commercial Invoice | Buyer not VAT-registered / exempt | Buyer TRN not required; adapted mandatory field list |
| Electronic Tax Credit Note | Adjustment to Tax Invoice | References original invoice; credit note reason code mandatory |
| Electronic Credit Note | Adjustment to Commercial Invoice | References original; follows the lighter field requirements |
For finance teams, the point is simple. Do not map every document as a tax invoice. The ERP must identify the correct invoice type before the file reaches the ASP.
The Most Common PINT-AE Validation Errors and How to Avoid Them
A PINT-AE invoice usually fails for one of two reasons: missing data or wrong format. The VAT calculation may be correct, but the file can still fail ASP checks if the structure, identifiers, totals, or transaction flags do not match the PINT AE validation rules.
Here are the errors finance teams should test before go-live.
1. Wrong or missing PINT-AE specification identifier
The invoice must clearly show that it follows the UAE PINT-AE specification. The required value should match the UAE PINT-AE billing specification exactly. Any typo, missing value, wrong version, or generic Peppol reference can trigger immediate rejection.
How to avoid it: ask the ERP vendor and ASP to confirm that the invoice output is aligned with the current UAE PINT-AE specification, not plain UBL 2.1 or vanilla Peppol BIS 3.0.
2. Incorrect TRN, TIN, or Peppol ID format
The UAE TRN is 15 digits. The TIN is the first 10 digits of the TRN. The Peppol ID must use the 0235 scheme followed by the 10-digit TIN.
Wrong digit count, wrong scheme, or using the full TRN instead of the TIN can cause routing failure.
How to avoid it: clean customer and supplier master data before ASP testing.
3. Wrong date format
Dates must follow the required system format. Formats such as 15/07/2025, 15-Jul-25, or 15.07.2025 can fail validation.
How to avoid it: configure the ERP date output once. Do not rely on manual date entry.
4. Total reconciliation failure
Line totals, VAT subtotals, tax category totals, and invoice totals must reconcile exactly. Even a small rounding difference can cause rejection.
How to avoid it: test real invoices with discounts, credit notes, mixed VAT lines, and foreign currency. Rounding logic should sit inside the ERP output, not in a manual adjustment file.
5. Missing exchange rate on non-AED invoices
If the invoice is in USD, EUR, GBP, or any non-AED currency, the file must support AED-related values where required. Missing exchange rate or AED line-level values is a common xml e-invoice UAE failure.
How to avoid it: check that the ERP exchange rate flows into the e-invoice mapping used by the ASP.
6. Missing credit note reason code
Credit note reason codes became mandatory under the PINT-AE v1.0.1 update. This is a major risk for businesses that started implementation before 31 July 2025 and never updated their configuration.
How to avoid it: make the credit note reason field mandatory in the ERP or ASP upload process.
7. Invalid unit of measure codes
The invoice must use accepted unit of measure codes. Self-created abbreviations such as “pcs”, “ltr”, or “unit” may not validate if they do not match the required code list.
How to avoid it: map ERP units to the accepted codes before testing.
8. Missing transaction type flags
UAE-specific flags such as free zone, margin scheme, deemed supply, reverse charge, e-commerce supply, and export classification are not optional notes. They are part of the invoice classification logic.
How to avoid it: do not track these items only in spreadsheets. Build them into ERP tax logic or the ASP mapping workflow.
9. Using fallback endpoints incorrectly
Fallback endpoints should only be used for the specific scenarios they are designed for. Using 0235:9900000098 for a buyer who is already registered can send the invoice to the wrong route instead of the buyer’s actual Peppol ID.
How to avoid it: collect buyer Peppol IDs early and use fallback endpoints only where the scenario genuinely applies.
10. Missing AED-equivalent amounts at line level
Even when an invoice is issued in a foreign currency, the UAE framework may require AED-equivalent VAT and invoice line amounts. This requirement is commonly missed because it does not exist in the same way in generic Peppol BIS Billing 3.0 UAE discussions.
How to avoid it: test foreign currency invoices line by line, not only at invoice total level.
The real issue is not whether the ERP can create an invoice. The issue is whether it can create the right invoice, with the right fields, in the right format, for the right buyer.
That is the difference between generic Peppol UBL UAE support and real UAE FTA XML format compliance.
What Finance Teams Need to Do: ERP Readiness Checklist
This is where the PINT-AE UAE e-invoicing discussion becomes a project plan. Finance should not leave this only to IT. The ERP can generate the file, but finance owns the data, VAT logic, invoice types, TRNs, TINs, credit notes, and transaction classifications.
Step 1 — Confirm Your ERP Can Output PINT-AE XML, Not Just UBL
Ask your ERP vendor one direct question:
Can the system generate a PINT-AE compliant XML invoice with the correct UAE specification identifier and all 50+ mandatory PINT-AE fields?
Generic UBL support is not enough. That only means the system can create a structured XML file. It does not prove UAE FTA XML format compliance.
Request a sample PINT-AE XML output from the vendor and validate it against the MoF Mandatory Fields document and the PINT-AE data dictionary. SAP, Oracle Fusion, Microsoft Dynamics, Tally, and other ERPs may require specific PINT-AE configuration, middleware, or ASP mapping. None should be assumed compliant out of the box.
Step 2 — Map All 50+ PINT-AE Fields to ERP Master Data
Every mandatory and conditional field must have a clear source. It should come from the ERP, tax master, customer master, supplier master, product master, manual upload template, or ASP portal.
Focus first on the highest-risk gaps:
| High-Risk Field Area | Why It Matters |
| AED line-level VAT amounts | Required even where invoices are issued in foreign currency. |
| Exchange rate for non-AED invoices | Missing exchange rate can cause validation failure. |
| UAE legal registration type codes | Required for correct seller and buyer identification. |
| Transaction type flags | Free zone, margin scheme, deemed supply, reverse charge, exports, and similar classifications must be mapped. |
| Credit note reason codes | Mandatory from PINT-AE v1.0.1 and must be populated in the credit note process. |
This is the core difference between generic Peppol UBL UAE support and proper PINT-AE vs UBL 2.1 readiness.
Step 3 — Clean Your Master Data: TRNs, TINs, and Peppol IDs
Before testing, clean the data. Bad master data will not become good just because it enters an ASP platform.
| Master Data Area | What to Check |
| TRN audit | Verify every customer and supplier TRN is 15 digits and valid with the FTA. |
| TIN derivation | Confirm the first 10 digits of the TRN are correctly used as the TIN. |
| Peppol ID collection | Collect each B2B customer’s 0235-format Peppol ID. |
| Tax group members | Ensure each entity uses its own TIN, not the representative member’s TIN. |
Peppol ID collection is a serious outreach project. For businesses with 200+ customers, allow at least 4–8 weeks. This is not just an IT field update. It is a customer master data exercise.
Step 4 — Appoint an Accredited Service Provider
Only an accredited ASP can transmit compliant PINT-AE invoices through the UAE Peppol network. This makes the FTA approved ASP decision central to implementation.
The MoF extended the ASP appointment deadline for businesses with annual revenues exceeding AED 50 million from 31 July 2026 to 30 October 2026, while keeping the mandatory implementation date of 1 January 2027 unchanged.
| ASP Selection Area | What to Check |
| FTA accreditation | Confirm the provider is approved for UAE e-invoicing. |
| ERP compatibility | Check whether it supports SAP, Oracle, Dynamics, Tally, or your specific system. |
| Integration readiness | Ask for connectors, APIs, Excel upload options, and testing environment. |
| SLA and uptime | Confirm support, downtime handling, and failure notification process. |
| Data residency | Check UAE storage and retention requirements. |
| Pricing model | Compare per-invoice pricing, flat fee, setup fee, and extra retention charges. |
The ASP commercial contract and EmaraTax appointment are separate steps. Both are required. Do not assume signing with an ASP automatically completes the regulatory appointment.
Step 5 — End-to-End Test Before Go-Live
Do not test only one clean tax invoice. That gives false comfort.
Test all 16 use cases covered in the UAE e-invoice mandatory fields framework, including edge cases that normally break mapping.
| Test Scenario | Why It Matters |
| Standard AED tax invoice | Basic validation check. |
| Non-AED invoice | Tests exchange rate and AED line-level values. |
| Exempt supply | Tests tax category logic. |
| Reverse charge | Tests buyer-side VAT treatment. |
| Free zone transaction | Tests transaction flags. |
| Self-billing | Tests buyer-issued invoice flow. |
| Credit note | Tests original invoice reference and reason code. |
| Mixed VAT invoice | Tests line-level VAT and total reconciliation. |
A typical integration timeline can take 8–16 weeks, depending on ERP complexity and data readiness. The UAE pilot programme is available from 1 July 2026, so businesses should use it to test real flows before mandatory go-live.
The goal is simple: find the errors before the ASP finds them. That is how finance teams avoid e-invoice failed validation UAE issues during live operations.
How ADEPTS Can Help
PINT-AE UAE e-invoicing is not a simple software update. It affects ERP configuration, VAT data, customer master records, invoice logic, credit note workflows, and ASP selection. ADEPTS helps finance teams assess these areas before validation errors start appearing during implementation.
We begin with a PINT-AE technical readiness assessment. This includes reviewing your current ERP invoice output against the MoF Data Dictionary and identifying gaps in mandatory and conditional fields. The objective is to know what is missing before your ASP appointment and testing phase begins.
ADEPTS also supports ERP field mapping. Our team maps the 50+ mandatory PINT-AE fields to your ERP master data, tax master, customer records, supplier records, product/service records, and billing workflows. This includes UAE-specific BTUAE fields that generic Peppol UBL UAE implementations often miss.
Peppol ID and TIN collection is another major workstream. ADEPTS helps finance teams design the customer outreach process needed to collect valid 0235-format Peppol IDs from B2B customers. This reduces routing errors and avoids last-minute master data pressure.
We also provide ASP selection advisory. The focus is neutral and practical: which FTA approved ASP fits your ERP, invoice volume, data requirements, integration model, and internal process maturity. We also help teams understand the difference between signing a commercial ASP contract and completing the required regulatory appointment.
For businesses that started implementation before 31 July 2025, ADEPTS can review the credit note process against PINT-AE v1.0.1 requirements. This is important because credit note reason codes are now a common validation risk.
Finally, ADEPTS trains finance and tax teams on the PINT-AE data dictionary, invoice types, mandatory fields, transaction flags, Peppol IDs, and common validation failures. The training is not a generic “e-invoicing is coming” session. It is designed to help finance teams understand the field-level detail that actually affects compliance.
Conclusion
Peppol UBL UAE, UBL 2.1, Peppol BIS Billing 3.0, and PINT-AE are not interchangeable. They sit in the same technical stack, but they do not mean the same thing. For the UAE, the required format is PINT-AE.
A plain UBL 2.1 file may have the right structure. A generic Peppol invoice may follow global rules. But neither automatically satisfies the UAE FTA XML format requirement. PINT-AE adds the UAE-specific fields that matter: TRN and TIN logic, the 0235 Participant Identifier, transaction type flags, AED line-level VAT values, credit note reason codes, and digital trust requirements.
That is why PINT-AE vs UBL 2.1 is not a technical side issue. It is the difference between an invoice that only looks complete and an invoice that can actually pass ASP validation.
The most common failures are usually data problems, not pure IT problems. Missing Peppol IDs, wrong TRN formats, missing exchange rates, weak customer master data, and outdated credit note workflows can all trigger e-invoice failed validation UAE issues during testing or live operations.
With the pilot programme open from 1 July 2026 and mandatory go-live from 1 January 2027 for large businesses, finance teams should not wait for the ASP appointment deadline. Field mapping, master data cleanup, Peppol ID collection, and real invoice testing should start early.
ADEPTS works directly with finance teams on PINT-AE UAE e-invoicing readiness, from ERP field mapping and ASP selection to master data cleanup and team training. The earlier the gaps are found, the easier they are to fix.
FAQs:
No. PINT is the wider international Peppol invoice model. PINT-AE is the UAE-localised version used for PINT-AE UAE e-invoicing, with UAE tax fields, identifiers, and validation rules added on top. The MoF Guidelines refer to Peppol’s PINT-AE billing specifications as the source for UAE electronic invoice content.
Yes, in some cases. The UAE model allows the supplier’s ASP to convert invoice data into the UAE standard XML format if it receives data in another agreed format. But this does not remove the finance team’s responsibility to provide complete and correct source data.
XML is the required format for UAE electronic invoices. The MoF Guidelines state that electronic invoices are issued, transmitted, and received in XML format, without QR codes or barcodes. JSON may be used internally by software systems, but it is not the final UAE FTA XML format.
CustomizationID is the system field that tells the ASP which e-invoice rulebook the file follows. For UAE e-invoicing, it must identify the correct PINT-AE specification. If this value is missing or wrong, the ASP may treat the file as generic Peppol or invalid XML instead of a UAE-compliant invoice.
Yes, if the free zone entity conducts business transactions in the UAE and is within the e-invoicing scope. Free zone status does not automatically remove the obligation. It mainly affects the transaction classification that must be reflected correctly in the e-invoice.
A Tax Data Document, or TDD, is the tax reporting data sent to the FTA platform as part of the e-invoicing process. In practice, the ASP handles the reporting of tax data to the FTA, but the business must make sure the invoice data is complete and accurate. The compliance obligation still remains with the supplier, or the buyer in self-billing cases.
The invoice exchange may be delayed until the disruption is resolved. The ASP must notify the relevant stakeholders and the FTA of service disruptions, and pending invoices must be exchanged and reported once the service resumes. Finance teams should agree this failure-handling process with the ASP before go-live.
Yes. In fact, the MoF Guidelines state that a person within scope must appoint only one ASP for both sending and receiving electronic invoices. Tax group members may have separate onboarding because each member has its own TIN and Peppol participant identifier.
Electronic invoice data must generally be retained for five years, while real estate records must be retained for seven years. Extra retention may apply during disputes, audits, or voluntary disclosure situations. The records must remain accessible, reproducible, and verifiable for the FTA, even if the storage infrastructure is cloud-based.
MLS stands for Message Level Status. It confirms whether the invoice exchange or reporting message has succeeded or failed. Finance teams should not treat an invoice as fully processed until the required confirmation messages are received from the ASP.
Each tax group member uses its own TIN, not the representative member’s TIN. The MoF Guidelines state that the TIN is the first 10 digits of the entity’s own TRN. This is important because each group member’s Peppol ID is generated from its own TIN.
Yes, export transactions can be in scope where they are business transactions carried out by a person subject to UAE e-invoicing. The MoF Guidelines specifically address exports and explain that if the overseas buyer does not have a Peppol ID, the prescribed export fallback endpoint should be used.
The 14-day rule means the invoice must be issued within the required UAE VAT timeline, not whenever the month-end billing cycle closes. UAE VAT law requires a registrant to issue a tax invoice within 14 days from the date of supply. Under e-invoicing, finance teams should treat this as a system-timing rule, not just a tax filing rule.
Usually, yes, where each licensed entity is a separate person that must onboard for e-invoicing. The Peppol ID is linked to the entity’s TIN, not simply to the group brand name. Where group companies have separate legal registrations and TINs, each should be assessed separately during onboarding.
The commercial contract is your business agreement with the ASP. The EmaraTax appointment is the regulatory onboarding step that connects your entity to the selected ASP under the UAE e-invoicing framework. The MoF Guidelines make clear that businesses must finalise the ASP contract and commercial obligations before onboarding through EmaraTax.
References
- ‘Accreditation of eInvoicing Service Providers’. Ministry of Finance – United Arab Emirates,
https://mof.gov.ae/en/services/accreditation-of-einvoicing-service-providers - ‘eInvoicing’. Ministry of Finance – United Arab Emirates, https://mof.gov.ae/en/about-us/initiatives/einvoicing/
- EN 16931 compliance. https://ec.europa.eu/digital-building-blocks/sites/digital-building-blocks/sites/spaces/DIGITAL/pages/467108950/EN+16931+compliance
- List and Contact Details of the Ministry of Finance Pre-Approved eInvoicing Service Providers.
https://mof.gov.ae/wp-content/uploads/2025/10/Pre-approved-service-providers-page.pdf. - Ministerial Decision No. 243 of 2025 on the Electronic Invoicing System . https://mof.gov.ae/wp-content/uploads/2025/09/Ministerial-Decision-no.-243-of-2025-on-the-Electronic-Invoicing-System.pdf.
- Ministerial Decision No. 244 of 2025 on the Implementation of the Electronic Invoicing System .
https://mof.gov.ae/wp-content/uploads/2025/09/Ministerial-Decision-No.-244-of-2025-on-the-Implementation-of-the-Electronic-Invoicing-System.pdf. - MoF Publishes PINT AE Specifications for E-Invoicing. https://www.deloitte.com/middle-east/en/services/tax/perspectives/mof-publishes-pint-ae-specifications-for-e-invoicing.html.
- Peppol BIS Billing. https://docs.peppol.eu/poacc/billing/3.0/bis/
- Peppol BIS Billing 3.0 – November 2023 Release | Rules.
https://docs.peppol.eu/poacc/billing/3.0/2023-Q4/codelist/vatex/. - Peppol BIS Billing 3.0 – November 2025 Release. https://docs.peppol.eu/poacc/billing/3.0
- ‘The Future Is Open’. OpenPeppol, https://peppol.org/
- UAE E-Invoicing News: Peppol UAE Data Dictionary Updates. https://www.deloitte.com/middle-east/en/services/tax/perspectives/uae-e-invoicing-news-peppol-uae-data-dictionary-updates.html.
- UAE Electronic Invoice Mandatory Fields. https://mof.gov.ae/wp-content/uploads/2026/02/UAE-Electronic-Invoice-mandatory-fields_V-1.0-23Feb2026.pdf.
- ‘UAE Electronic Invoicing – Ministry of Finance Issues Detailed Implementation Guidelines’. KPMG, https://kpmg.com/ae/en/insights/tax-insights/uae-electronic-invoicing-ministry-of-finance-issues-detailed-implementation-guidelines.html
- ‘UAE: Framework, Scope, and Implementation of e-Invoicing System’. KPMG, https://kpmg.com/us/en/taxnewsflash/news/2025/10/uae-framework-scope-implementation-e-invoicing-system.html
- ‘UAE PINT AE: E-Invoicing Mandate 2026-2027’. E-Invoice.App, 20 Apr. 2026,
https://www.e-invoice.app/blog/uae-pint-ae-guide. - ‘Universal Business Language (UBL) v2.1’. OASIS Open, https://www.oasis-open.org/standard/ublv2-1/
