On this page
PINT-AE is the structured data standard the UAE Federal Tax Authority requires for all e-invoices. It defines the exact fields, formats, and schema that an invoice must conform to before it is transmitted through an accredited Access Service Provider (ASP) to the FTA's network. The standard is derived from the global PINT framework, which is the PEPPOL International (PINT) billing specification adapted for individual jurisdictions. In the UAE, that adaptation is called PINT-AE. Every business inside the UAE e-invoicing mandate must produce invoices that validate against this schema. The core compliance question is not whether your accounting system can print a tax invoice, but whether the data structure it outputs maps correctly to every required PINT-AE field. That distinction is where most compliance gaps actually live, and it is what the rest of this article unpacks.
Where PINT-AE Comes From and What It Actually Is
The PEPPOL International billing specification is a globally consistent invoice data model designed to let different countries implement structured e-invoicing without each building from scratch. A jurisdiction adopts the base PINT model and then adds its own mandatory extensions, known as business rules, that reflect local tax law.
The UAE's version of this, PINT-AE, layers FTA-specific business rules on top of the international base. Those rules govern things like the mandatory inclusion of a Tax Registration Number in a specific format, line-level VAT breakdown requirements, the treatment of zero-rated and exempt supplies, and the structured representation of credit notes alongside standard invoices.
The specification is not a PDF template or a paper format. It is a machine-readable schema, typically expressed in UBL (Universal Business Language) XML. An invoice either validates against that schema in full or it does not. There is no partial compliance. This binary nature of PINT-AE validation is what makes the format feel demanding for businesses used to more flexible document-based invoicing.
The UAE E-Invoicing Mandate: What Is Actually Required
The UAE's e-invoicing framework is being rolled out in phases by the FTA. Rather than a single overnight switch, the mandate is targeting business segments progressively, starting with larger enterprises before expanding to mid-market and smaller businesses.
The structure of the mandate rests on three components that every covered business must address:
- A structured invoice format. Every invoice must conform to PINT-AE, not just contain the right information in a readable form, but encode it in the exact field structure the schema defines.
- Transmission through an accredited ASP. Businesses do not send invoices directly to the FTA. They send them to an FTA-accredited Access Service Provider, which validates and forwards them. The ASP is the gatekeeper, and it will reject invoices that fail PINT-AE validation before they ever reach the authority.
- Lifecycle tracking and audit readiness. Compliance does not end at submission. Businesses must be able to demonstrate the status of any invoice from receipt through clearance, and maintain an audit trail that the FTA can inspect.
The diagram above reflects the real flow. Notice that the middleware validation layer sits between the ERP and the ASP, not after it. By the time an invoice reaches an ASP, it must already be correct. Catching errors upstream is not a nice-to-have feature; it is the architecture the mandate assumes.
Why Most ERPs Do Not Produce PINT-AE Natively
This is the practical reality that surprises most finance teams when they first read the mandate requirements. Major ERP platforms, including widely used mid-market accounting systems, export invoice data in their own proprietary structures. Those structures were not designed with PINT-AE in mind.
The gap between a typical ERP invoice export and a valid PINT-AE document is not a small formatting adjustment. It is a structural transformation. Fields that PINT-AE requires as discrete, typed data elements are often combined into free-text fields in ERP outputs. VAT amounts that must appear at line level in PINT-AE are sometimes only available at document level in legacy systems. Party identifiers, unit codes, and allowance or charge structures all have specific PINT-AE representations that ERP exports rarely match.
This creates a real operational problem. A business running SAP, Oracle, Microsoft Dynamics, or any regional accounting system cannot simply switch on e-invoicing by pointing its existing invoice output at an ASP. Something must normalize and map that output into a valid PINT-AE document first.
The approaches businesses use fall into three broad categories:
| Approach | How It Works | Key Limitation |
|---|---|---|
| ERP-native plugin | Vendor-built add-on for a single ERP | Tied to one ERP; breaks during ERP upgrades |
| Custom in-house integration | Engineering team builds directly to ASP API | High build cost; ongoing maintenance burden |
| Middleware platform | ERP-agnostic layer that normalizes, validates, and maps | Adds a dependency, but works across ERPs and ASPs |
The middleware approach is the one gaining traction among businesses running more than one ERP, or those who want the flexibility to switch ASPs without rebuilding their entire integration.
What PINT-AE Validation Actually Checks
A valid PINT-AE document must pass several layers of checks before it is accepted. Understanding these layers explains why validation cannot be treated as a checkbox at the end of the process.
Schema validation confirms that the document structure itself is correct: every mandatory element is present, every data type matches, and the document is well-formed XML. This is the most mechanical layer and the easiest to check automatically.
Business rule validation is where most real-world failures happen. The PINT-AE specification includes a set of business rules that govern the logical consistency of the invoice. A common example: the sum of line-level VAT amounts must equal the document-level VAT total within a defined tolerance. Another: if a supply is classified as zero-rated, the exemption reason code must be present and must be drawn from the FTA-approved code list. These rules are not obvious from reading the schema alone.
Code list validation checks that values in controlled fields, such as currency codes, VAT category codes, unit-of-measure codes, and country codes, come from the exact code lists the UAE implementation specifies. Using a code that is valid in another PEPPOL jurisdiction but not in PINT-AE will fail this check.
An invoice that passes schema validation but fails a business rule check is still a non-compliant invoice. The ASP will reject it, and the FTA clock does not start until a valid invoice is cleared.
This is precisely why validation must happen before the invoice leaves your own systems, not at the ASP boundary. A rejection at the ASP level means a delayed invoice, a frustrated buyer, and a potential VAT compliance gap.
Credit Notes and the Full Invoice Lifecycle
PINT-AE compliance is not limited to standard tax invoices. Credit notes, which are issued to correct or cancel a previously submitted invoice, must also conform to the PINT-AE structure and follow a defined lifecycle.
A credit note in the PINT-AE framework must reference the original invoice by its unique identifier, include the correct document type code, and carry the same level of structured field completeness as the original invoice. Businesses that treat credit notes as informal adjustments, a common practice in paper-based invoicing, will find that approach incompatible with the UAE mandate.
The practical implication is that compliance tooling must handle the full invoice lifecycle, not just initial submission. That includes tracking whether a credit note has been submitted and cleared, and ensuring that the audit trail connects the credit note back to the original cleared invoice.
For businesses processing high volumes of invoices across multiple trading partners, this lifecycle management is often the operationally harder part of compliance, not the initial format conversion.
What Compliance Looks Like in Practice
A business that is genuinely PINT-AE compliant can answer yes to all of the following:
Every invoice, regardless of which ERP or accounting system generated it, is converted to a valid PINT-AE document before it reaches the ASP. Validation failures surface the specific field or business rule that failed, not a generic error state. Every invoice has a tracked status from receipt through clearance. Credit notes follow the same structured lifecycle. The full audit trail is available on demand, either for internal review or for an FTA audit.
Middleware platforms like Kodowo are built specifically around this operational model, sitting between whatever ERP a business runs and whichever accredited ASP it uses, handling normalization, validation, mapping, and status tracking as a single continuous layer rather than a collection of point integrations.
For finance and tax teams who want to understand how the compliance requirements map to their day-to-day workflow, the Finance and Tax solutions page is a practical reference for what AR/AP teams and finance managers are actually responsible for under the mandate.
The mandate is not going to simplify over time. As more business segments come into scope and the FTA's enforcement posture matures, the operational bar for PINT-AE compliance will rise, not fall. Getting the foundational architecture right now, with validation upstream of the ASP and a full audit trail behind it, is the decision that determines how much friction your team absorbs at each subsequent phase.
Frequently Asked Questions
What exactly is PINT-AE? PINT-AE is the UAE-specific invoice data standard derived from the PEPPOL International (PINT) framework. It defines the exact fields, data types, and structure that every e-invoice must conform to before it is transmitted to an accredited Access Service Provider and on to the FTA.
Does my ERP automatically produce PINT-AE compliant invoices? Very rarely. Most ERP and accounting systems output invoices in their own proprietary formats, which must be normalized and mapped to the PINT-AE schema before transmission. A middleware layer or specialized integration is almost always needed to bridge that gap.
What is an accredited Access Service Provider and how does PINT-AE relate to it? An accredited Access Service Provider (ASP) is an FTA-approved intermediary that receives your structured invoices and forwards them to the tax authority's network. PINT-AE compliance is a prerequisite: if your invoice does not conform to the schema, the ASP will reject it before it ever reaches the FTA.
What happens if an invoice fails PINT-AE validation? A failed invoice is rejected either by the middleware layer or by the ASP, and it does not count as a submitted tax invoice. The business must correct the specific field error and resubmit, which is why surfacing the exact rejection reason, not a generic error state, matters for finance teams operating at volume.
Frequently asked questions
- What exactly is PINT-AE?
- PINT-AE is the UAE-specific invoice data standard derived from the PEPPOL International (PINT) framework. It defines the exact fields, data types, and structure that every e-invoice must conform to before it is transmitted to an accredited Access Service Provider and on to the FTA.
- Does my ERP automatically produce PINT-AE compliant invoices?
- Very rarely. Most ERP and accounting systems output invoices in their own proprietary formats, which must be normalized and mapped to the PINT-AE schema before transmission. A middleware layer or specialized integration is almost always needed to bridge that gap.
- What is an accredited Access Service Provider and how does PINT-AE relate to it?
- An accredited Access Service Provider (ASP) is an FTA-approved intermediary that receives your structured invoices and forwards them to the tax authority's network. PINT-AE compliance is a prerequisite: if your invoice does not conform to the schema, the ASP will reject it before it ever reaches the FTA.
- What happens if an invoice fails PINT-AE validation?
- A failed invoice is rejected either by your middleware layer or by the ASP, and it does not count as a submitted tax invoice. The business must correct the specific field error and resubmit, which is why surfacing the exact rejection reason, not a generic error state, matters for finance teams operating at volume.