On this page
UAE e-invoicing is a government-mandated programme requiring businesses to issue structured electronic invoices in the PINT-AE format, transmitted through an accredited Access Service Provider (ASP) to the Federal Tax Authority (FTA). The legal basis is Cabinet Decision No. 106 of 2025, which establishes the framework, alongside supporting Ministerial Resolutions from 2025 and 2026 that define mandatory field requirements and provider accreditation rules. An invoice is only compliant when it conforms to the PINT-AE schema, carries every mandatory field the FTA specifies, and reaches the FTA via an accredited ASP. Every step in that chain matters equally. If your invoice data is malformed before it reaches your ASP, it will be rejected, and the FTA never sees it at all.
That is the practical reality most businesses discover too late. The rest of this article explains how the programme works, what actually causes submissions to fail, and what a functioning compliance stack looks like in practice.
How the UAE E-Invoicing Programme Works
The UAE programme follows a clearance model, meaning the FTA validates each invoice before it is considered legally issued. Your invoice does not go directly from your accounting system to the FTA. It travels through an accredited ASP, which acts as the certified transmission channel. The ASP is responsible for the connection to the FTA; it is not responsible for whether your invoice data is correct before it arrives.
The accreditation of an ASP says nothing about whether your ERP can produce a valid PINT-AE invoice. Those are two entirely separate questions, and conflating them is the most common compliance mistake businesses make when they first engage with the programme.
The Ministry of Finance publishes the list of accredited ASPs. Choosing one gets you the transmission channel. It does not solve the data problem.
What PINT-AE Actually Requires
PINT-AE is the UAE-specific adaptation of the international PINT (Peppol International) invoice standard. It defines a fixed data structure: required fields, permitted code lists, data types, and the relationships between invoice elements. The FTA has published mandatory field requirements as a formal document. Missing a single required field, supplying a value in the wrong format, or using a code not on the permitted list will cause rejection.
The mandatory fields include, among others: supplier and buyer identification using the correct UAE identifier types, invoice type codes that distinguish between standard invoices and credit notes, tax category codes, and line-level amounts expressed in the required precision. These are not suggestions. They are schema constraints that an automated validator checks before the invoice is accepted.
The FTA has stated that the only official source of UAE e-invoicing information is the Ministry of Finance portal at mof.gov.ae, which lists six distinct legislative documents governing the programme.
The consequence is that businesses running standard ERP configurations, whether that is SAP, Oracle, Microsoft Dynamics, or any regional accounting package, need to verify whether their system's invoice output actually satisfies every one of those constraints. Most do not, out of the box.
Why Most ERP Outputs Fail PINT-AE Validation
This is the gap the market underestimates. An ERP system is designed to run your business operations. Its invoice output is optimised for its own data model, its own export formats, and its own integrations. PINT-AE was not in scope when most of these systems were built or most of these configurations were set.
Common failure modes include:
- Missing or incorrect identifier types: The UAE programme requires specific identifier schemes for supplier and buyer tax registration numbers. An ERP that stores these as free-text strings may output them without the required scheme identifier wrapper.
- Incorrect tax category codes: PINT-AE uses a defined code list for VAT categories. An ERP using its own internal tax codes will not automatically map to the correct PINT-AE values.
- Credit note structure errors: A credit note in PINT-AE must reference the original invoice using a specific element. ERP systems that generate credit notes internally often do not include this reference in any exportable format.
- Decimal precision mismatches: PINT-AE specifies precision requirements for monetary amounts. Rounding differences between an ERP's internal representation and the required output format cause validation failures that are difficult to diagnose without field-level error reporting.
The problem is structural, not a configuration tweak. Fixing it properly requires a layer that understands both your ERP's output format and the PINT-AE schema simultaneously.
How to Select an Accredited Service Provider
The Ministry of Finance publishes selection considerations for choosing an ASP. Practically, the factors that matter most in an actual procurement decision are:
| Consideration | What to Actually Evaluate |
|---|---|
| Accreditation status | Confirmed on the official MoF ASP list, not self-reported |
| Supported input formats | Whether the ASP can accept your data as-is, or requires pre-formatted PINT-AE |
| Error reporting detail | Field-level rejection reasons vs. generic failure codes |
| Status tracking | Real-time invoice lifecycle visibility from submission to clearance |
| Credit note handling | Full lifecycle support, not just standard invoice transmission |
| Audit trail | Append-only records suitable for an FTA audit |
One point deserves specific attention: many ASPs expect to receive PINT-AE-structured data. They are transmission channels, not data transformation engines. If your input data is not already valid PINT-AE, the ASP cannot fix it for you. This is precisely why the question "which ASP should we use" is the wrong first question. The right first question is "what does our invoice data look like before it reaches the ASP?"
Where Middleware Fits
A middleware layer sits between your ERP or accounting system and your chosen ASP. Its job is to accept whatever invoice format your existing system produces, normalize it into a single internal schema, validate it against the PINT-AE rules, and only then pass a valid, correctly mapped invoice to the ASP.
Kodowo's platform is built specifically for this position in the stack. It accepts invoice data via API, CSV, XLSX, or JSON, which means the input format is irrelevant. The ERP does not need to be replaced or reconfigured to produce PINT-AE output. Validation happens before transmission, so rejections surface inside the middleware with the specific field and rule that failed, not as a generic error code arriving back from the ASP hours later.
The practical consequence is that a business running any ERP or accounting system can achieve PINT-AE compliance without replacing its existing software stack. The solutions for finance and tax teams and IT and ERP administrators are different by design: finance teams need visibility into invoice status and failure reasons; IT teams need a clean, documented integration surface that does not create a new maintenance burden.
Every invoice moving through Kodowo carries a real lifecycle status from received through cleared. Every status change is recorded in an append-only audit trail. When an invoice fails, the actual reason appears, not a generic failure state requiring manual investigation. Credit notes go through the same full lifecycle, with cancellation possible before submission.
This is what a compliance-grade invoice stack looks like in practice. It is not a plugin. It is not the ASP. It is the layer that makes the ASP's job possible.
What Businesses Should Do Before the Mandate Affects Them
The UAE e-invoicing rollout is phased. Larger businesses and those in specific sectors will come into scope first. Waiting until a mandate deadline to audit your invoice data quality is the predictable way to face a rushed, expensive remediation.
A readiness audit has three components:
- Map your current invoice output. Export a sample of real invoices from your ERP and compare each field against the FTA's published mandatory field requirements. This is not theoretical: run the actual data.
- Identify your ASP. Confirm the provider is on the official accredited list. Understand what format they require as input and whether your ERP can produce it without transformation.
- Close the gap. If your ERP output does not satisfy PINT-AE, decide whether a middleware layer, an ERP-specific plugin, or a full ERP reconfiguration is the right path. Middleware is typically the fastest route for businesses with non-standard or mixed ERP environments.
Kodowo's readiness check is a starting point for businesses that want to understand where their current setup stands before committing to an integration approach.
Frequently Asked Questions
What is PINT-AE and why does it matter for UAE e-invoicing? PINT-AE is the UAE-specific invoice data standard derived from the international PINT framework, adapted to meet FTA requirements. Every invoice submitted through an accredited Access Service Provider must conform to this structure, including mandatory fields, correct data types, and valid code lists. If your invoice does not match the PINT-AE schema, your ASP will reject it before it ever reaches the FTA.
Do I need a separate system if my ERP already generates invoices? Almost certainly yes, unless your ERP vendor has been certified to produce PINT-AE-compliant output. Most standard ERP and accounting systems output invoices in their own proprietary format, not in the PINT-AE structure the FTA requires. A middleware layer validates and maps your existing invoice data into the correct format without requiring you to replace your ERP.
What happens if a submitted invoice is rejected by the ASP or FTA? A rejected invoice needs to be corrected and resubmitted. The critical issue is knowing exactly why it was rejected: a generic failure message means you are guessing at the fix. A proper middleware layer surfaces the specific field or validation rule that failed, so the correction is targeted rather than speculative.
What is the difference between an accredited ASP and a middleware provider? An accredited Access Service Provider is a company approved by the UAE Ministry of Finance to transmit e-invoices to the FTA on your behalf. Middleware sits upstream of the ASP, ensuring the invoice data you send to the ASP is already valid and correctly mapped. Middleware is not an ASP and does not replace one; it makes the ASP's job possible and your submissions cleaner.
Frequently asked questions
- What is PINT-AE and why does it matter for UAE e-invoicing?
- PINT-AE is the UAE-specific invoice data standard derived from the international PINT (Peppol International) framework, adapted to meet FTA requirements. Every invoice submitted through an accredited Access Service Provider must conform to this structure, including mandatory fields, correct data types, and valid code lists. If your invoice does not match the PINT-AE schema, your ASP will reject it before it ever reaches the FTA.
- Do I need a separate system if my ERP already generates invoices?
- Almost certainly yes, unless your ERP vendor has been certified to produce PINT-AE-compliant output. Most standard ERP and accounting systems output invoices in their own proprietary format, not in the PINT-AE structure the FTA requires. A middleware layer validates and maps your existing invoice data into the correct format without requiring you to replace your ERP.
- What happens if a submitted invoice is rejected by the ASP or FTA?
- A rejected invoice needs to be corrected and resubmitted. The critical issue is knowing exactly why it was rejected: a generic failure message means you are guessing at the fix. A proper middleware layer surfaces the specific field or validation rule that failed, so the correction is targeted rather than speculative.
- What is the difference between an accredited ASP and a middleware provider?
- An accredited Access Service Provider is a company approved by the UAE Ministry of Finance to transmit e-invoices to the FTA on your behalf. Middleware sits upstream of the ASP, ensuring the invoice data you send to the ASP is already valid and correctly mapped. Middleware is not an ASP and does not replace one; it makes the ASP's job easier and your submissions cleaner.