UAE E-Invoicing Requirements: What Your ERP Must Handle Before 2027

UAE e-invoicing requirements are the rules a business's invoicing system must meet once structured e-invoices become mandatory: every B2B and B2G invoice issued as PINT AE XML, sent through an Accredited Service Provider on the Peppol network, and reported to the Federal Tax Authority. For an ERP, that means around 50 mandatory data fields, validation before sending, acknowledgement tracking and XML archiving, ready for 1 January 2027 or 1 July 2027.

For businesses on SAP, Oracle, Odoo or Zoho, much of this arrives as a vendor module that still needs configuring and testing. For businesses running custom ERPs, legacy billing platforms or SaaS products with invoicing built in, it is a development project. This guide sets out each requirement in turn, what it asks of the invoicing system, and what drives the scope of the build.

What the UAE E-Invoicing Requirements Cover

The framework comes from Ministerial Decisions No. 243 and No. 244 of 2025, issued by the Ministry of Finance with the FTA as the operating authority, and the UAE Electronic Invoicing Guidelines published in February 2026 confirmed the technical model. The operational change can be stated in one line: after a business's go-live date, a PDF invoice sent by email has no compliance value for B2B and B2G transactions. The compliant invoice is a structured XML file in PINT AE format, carried by an ASP and reported to the FTA as it is exchanged.

That last part is what separates the UAE model from simple digital invoicing. The FTA receives tax data for every invoice from the ASPs as the exchange happens rather than waiting for a VAT return, so errors that once sat unnoticed in a quarterly reconciliation become visible within days. The requirements below are written with that in mind: the invoicing system has to get each invoice right the first time, and it has to know quickly when one has been rejected.

Timeline and Scope

Businesses with annual revenue of AED 50 million or more must appoint an ASP by 30 October 2026 and go live on 1 January 2027. That appointment date was moved from 31 July 2026 by Ministerial Decision No. 66 of 2026, but the go-live date stayed where it was. Businesses below AED 50 million appoint by 31 March 2027 and go live on 1 July 2027, and government entities appoint by the same March date and go live on 1 October 2027. A voluntary pilot has been open since 1 July 2026 for businesses that want to test against live infrastructure before their mandatory date.

The mandate covers VAT-registered businesses, free zone businesses and non-VAT-registered businesses that conduct business transactions. B2C-only businesses are currently outside scope. Cabinet Decision No. 106 of 2025 sets the penalties: AED 5,000 for each month of delay in implementing the system or appointing an ASP, and AED 100 for each invoice or credit note not issued through the system, capped at AED 5,000 per month for each category. Our guide to the ASP appointment deadline covers the timeline and provider selection in detail.

How the Five-Corner Model Shapes Your ERP's Job

The UAE runs a decentralised continuous transaction control and exchange model on Peppol, usually described as five corners. The supplier's ERP is corner one and creates the invoice. The supplier's ASP, corner two, validates it, applies the digital signature and sends it over Peppol. The buyer's ASP, corner three, receives it and delivers it into the buyer's ERP, corner four. Corner five is the FTA, which receives a Tax Data Document from the ASPs for each invoice.

The ERP never talks to the FTA directly, and it does not sign invoices itself. Its job is narrower but unforgiving: produce complete, correct invoice data in a form the ASP accepts, pass it to the ASP reliably, record what comes back, and receive inbound invoices from suppliers through the same route. Every requirement that follows is a part of that job.

Requirement 1: PINT AE Data Fields

PINT AE is the UAE's version of the Peppol International invoice specification, built on UBL 2.1 and Peppol BIS Billing 3.0, and its data dictionary defines around 50 mandatory fields for a standard tax invoice. These include the supplier's and buyer's TRNs, Peppol participant identifiers for both parties, a unique invoice number, issue date, invoice type code, currency, payment terms, delivery details and a VAT breakdown on every line.

Tax treatment has to be explicit at line level, using category codes for standard-rated, zero-rated, exempt and out-of-scope supplies, and invoices in foreign currency must carry AED equivalents. The most common gap is not technical at all. Many UAE customer databases were built without reliable buyer TRNs, and an invoice without a valid buyer TRN will not pass validation. A data audit against the full PINT AE dictionary is the first piece of work in any integration, and the cleansing it uncovers often takes two to four weeks on its own.

Requirement 2: Validation Before Sending

An invoice that is well-formed XML can still fail PINT AE. Validation has two layers: schema checks for structure and data types, and business-rule checks for meaning, such as whether line totals add up to the invoice total with no rounding difference, whether tax categories match the rates applied and whether mandatory UAE-specific fields are present. Both layers should run inside the business's own systems before the invoice reaches the ASP. Relying on the ASP to catch errors means learning about them after the customer has been told an invoice is on its way.

Requirement 3: Credit Notes, Debit Notes and Corrections

Credit notes and debit notes follow the same structured format and route as invoices, and each must reference the original invoice it adjusts. Penalties apply to credit notes in their own right. This catches out businesses whose credit notes are raised in a different module, by a different team or as manual documents outside the ERP, because each of those paths now needs the same data quality and the same connection to the ASP as standard invoices.

Requirement 4: Acknowledgements and Exception Handling

Submission to the ASP is not the end of an invoice's journey. The network returns status messages confirming acceptance, delivery or rejection, and the ERP needs to store each one against the invoice it relates to. Transmission failures need retry logic that does not create duplicates, and rejected invoices need a clear route back to the finance team with an error they can act on rather than a raw XML message. Businesses must also notify the authority of system failures, and the penalty for late notification is AED 1,000 per day, so monitoring belongs in the design from the start.

Requirement 5: Receiving E-Invoices

E-invoicing is two-way. From its go-live date, every in-scope business must be able to receive PINT AE invoices from its suppliers through its ASP. That means accounts payable workflows built around scanned PDFs and manual entry have to accept structured data, match it to purchase orders and route it for approval. For many businesses the inbound side turns out to be the faster efficiency gain, because structured supplier invoices can be posted without retyping.

Requirement 6: Archiving

Electronic invoices must be retained in line with the Tax Procedures Law: at least five years for VAT purposes, seven where Corporate Tax applies and fifteen for real estate records. What has to be kept is the original XML, the acknowledgements and the audit trail, not a PDF rendering. The taxpayer remains responsible for retention even where storage is outsourced to an ASP, so businesses should know where their archive lives and how to retrieve it for an FTA review. Businesses that run property management and real estate platforms should plan for the longest retention period from day one.

Why Custom and Legacy ERPs Face the Hardest Build

Mainstream ERP vendors have published UAE e-invoicing modules or ASP connectors, so their customers mostly configure, map and test. Businesses whose invoicing runs on custom ERPs, bespoke billing software, ageing accounting platforms or SaaS products have no module to switch on. They need a PINT AE data layer, a validation engine, an ASP connector with retry and acknowledgement handling, an inbound invoice pipeline and an archive, built around systems that were usually designed to produce printable invoices.

The same applies to industry platforms where invoicing is buried inside another workflow, such as school fee billing, clinic management, logistics or property management. These systems often hold the commercial data but not in the shape PINT AE expects, and the integration work sits between the platform and the ASP. Most custom integrations take between six and sixteen weeks depending on data quality, the number of systems and the quality of the chosen ASP's API, which is why late starters lose their testing window first.

A Five-Step Build Sequence

1. Audit data against the PINT AE dictionary

Start with the invoice and customer records, not the code. Map every mandatory field to its source, flag missing buyer TRNs and inconsistent tax categories, and begin cleansing straight away. This step can run before a development partner or an ASP is chosen.

2. Build the PINT AE data and validation layer

Configure or build the ERP to output PINT AE-compliant data on the UBL 2.1 structure, with schema and business-rule validation running before any invoice is released. Credit and debit notes are built in the same step, not left for later.

3. Connect to the ASP

Choose a provider from the Ministry of Finance pre-approved list based on API quality, fit with the existing platform and pricing model, then build the connector using the provider's sandbox. Acknowledgement handling, retries and inbound invoices are part of this step.

4. Register and onboard

Complete onboarding with the ASP through the FTA's EmaraTax portal and formally appoint the provider before the applicable date: 30 October 2026 for Phase 1 or 31 March 2027 for Phase 2.

5. Test, train and go live

Run full flows for standard invoices, credit notes, debit notes, rejections and resubmissions, using the voluntary pilot where possible. Agree the procedures finance staff will follow for rejected invoices and system failures, then cut over with a short parallel run.

Integration Scope Tiers

A connector for a simple billing system with clean data, where the main work is linking it to the ASP, typically takes three to five weeks and sits at the lower end of the AED range for this work. A full integration for a custom or legacy ERP, with a new PINT AE layer, data cleansing support, error handling and archiving, typically takes eight to fourteen weeks and sits in a mid-range AED band. Multi-entity groups and SaaS platforms issuing invoices on behalf of many clients need multi-entity architecture, high-availability ASP connectivity and broader testing, which places them at the upper end. ASP subscription fees are charged separately by the provider and scale with invoice volume.

UAE E-Invoicing Requirements: Summary

Frequently Asked Questions

What are the UAE e-invoicing requirements?

Every B2B and B2G invoice must be issued as structured PINT AE XML, sent through an Accredited Service Provider on the Peppol network and reported to the FTA. The invoicing system must populate the mandatory data fields, validate invoices before sending, track acknowledgements, handle credit notes the same way, receive supplier e-invoices and archive the original XML.

What is ERP e-invoicing integration?

ERP e-invoicing integration is the work of connecting an ERP or billing system to an Accredited Service Provider so it can send and receive compliant e-invoices. It covers data mapping to PINT AE, validation, the ASP connector, acknowledgement handling and archiving.

What role does the FTA play in UAE e-invoicing?

The FTA is the fifth corner of the model. It receives a Tax Data Document from the ASPs for every invoice exchanged, which gives it near-live visibility of B2B and B2G transactions. Businesses do not connect to the FTA directly; their ASP reports on their behalf.

Do SAP, Oracle and Odoo users still need integration work?

Usually less than custom-system users, because those vendors offer UAE modules or ASP connectors. They still need data cleansing, configuration, testing of credit notes and rejections, and agreed procedures for exceptions before go-live.

How long does a custom ERP e-invoicing integration take?

Most custom integrations take between six and sixteen weeks, depending on data quality, the number of systems involved and the quality of the ASP's API. Data cleansing alone often takes two to four weeks.

Does my ERP apply the digital signature?

No. In the UAE model the supplier's ASP applies the digital signature after validating the invoice. The ERP's responsibility is to send complete, correct invoice data to the ASP.

Getting Started Before the Deadline

Two steps can start this week without waiting for anything else: an audit of invoice and customer data against the PINT AE dictionary, and a shortlist of providers from the Ministry of Finance list. Both reduce risk on every later step, and both tell you whether your build sits in the simple or the complex tier.

Pixbit builds ERPs, CRMs and business platforms in Laravel, React, Next.js and Flutter, and has delivered more than 100 projects across more than 15 countries. E-invoicing integration fits that work because the challenge is system architecture rather than accounting theory. If your invoicing runs on custom or legacy software and you need the PINT AE layer, the ASP connector and the archive built before your go-live date, talk to our team. Pixbit scopes exact cost and timeline in a single discovery session.