If your UAE business turns over AED 50 million or more a year, 30 October 2026 is the date you must have an Accredited Service Provider (ASP) appointed for e-invoicing. Go-live is 1 January 2027. The Ministry of Finance already moved the ASP date once, from 31 July, and it said clearly that the January go-live did not move with it.
Most of the project plans we have seen treat the next four weeks as a procurement exercise: compare a few ASPs, sign one, done. Picking the ASP is the easy part. The ASP validates and routes what your systems send it. If your systems send the wrong thing, send it twice, or never find out it was rejected, the ASP won't fix that for you. This article is about the part that sits on your side of the connection.
Where things stand in September 2026
- The legal basis is Ministerial Decisions No. 243 and No. 244 of 2025. Decision 243 sets the framework (scope, ASP role, data model, archiving). Decision 244 sets the phases and deadlines.
- On 10 May 2026 the Ministry of Finance extended the ASP appointment deadline for businesses above AED 50 million from 31 July to 30 October 2026, kept full implementation at 1 January 2027, and reported 32 approved service providers at that point.
- Businesses under AED 50 million appoint an ASP by 31 March 2027 and go live on 1 July 2027. Government entities follow on 1 October 2027. Voluntary adoption opened on 1 July 2026 (Andersen summary).
- Scope is B2B and B2G. B2C is excluded for now, as are some financial services and airline passenger tickets (KPMG).
- Penalties under Cabinet Decision No. 106 of 2025 start from each phase's go-live: AED 5,000 per month for not implementing, AED 100 per invoice sent late (capped at AED 5,000 a month), and AED 1,000 per day for not reporting a system failure or data change (VATupdate).
What actually changes
A PDF attached to an email stops being the invoice. The invoice becomes a structured XML document in the PINT AE format (the UAE profile of Peppol's international invoice), and it travels through a five-corner model. Boru Consulting describes the corners as: the supplier's source system, the supplier's ASP (validates against PINT AE and routes over Peppol), the buyer's ASP, the buyer's receiving system, and the Federal Tax Authority, which gets the tax data from the supplier's ASP.
Two consequences get missed. First, buyers need an ASP as well, so your accounts payable team changes how it receives invoices, not just how sales issues them. Second, the whole thing is only as good as the data your source system produces. A missing buyer TRN or a wrong VAT category no longer gets fixed quietly by someone editing a PDF. It gets rejected, and a rejected invoice that nobody notices becomes a late invoice.
List every system that issues an invoice, not just the ERP
The ERP vendor will usually have a connector. The trouble is the other places that bill customers. In the companies we work with, these are the usual ones:
- a custom billing or subscription app that sends its own invoices,
- an e-commerce or portal checkout that issues tax invoices for B2B buyers,
- a service or maintenance module that bills contract work,
- credit notes done by hand in a spreadsheet and then emailed.
Credit notes are covered by the same rules as invoices, and the Andersen summary notes that both must be issued within 14 days of the transaction. If credit notes live in a spreadsheet today, that is a process to rebuild, not a field to map. This inventory is also the moment to find the point-to-point links between systems that nobody has documented, the same problem we wrote about in why institutional systems don't integrate.
What our own payment integration taught us
We built the checkout on fanpino.com ourselves and connected it to an external payment gateway. It is not an e-invoicing ASP, but the failure modes are the same kind: your system sends a document to a third party, gets an ID back, and has to reconcile later. Two bugs we hit are worth repeating because an ASP integration will produce the same ones.
The gateway returned its reference ID as a JSON number. Our code expected a string. So every call failed on our side after the gateway had already created the payment. The user saw an error, and a real transaction existed on the other end. In e-invoicing terms, that is an invoice the ASP accepted while your ERP thinks the send failed. If the retry logic simply sends again, you have a duplicate invoice with the tax authority.
The second bug came from the same number. The callback looked the payment up using the ID as a string from the query string, while the database stored a number. That lookup would never match, so every paid order would have failed at confirmation. It showed up in testing only because we traced one request end to end.
What we changed, and what we would ask of any ASP integration:
- Normalise IDs at the boundary, once, in the client that talks to the provider. Don't cast in five places.
- Use your own invoice number as the idempotency key. Before any retry, ask the ASP for the status of that number instead of resending.
- Treat "the ASP acknowledged it" and "the invoice was validated and delivered" as different states. Store the ASP message ID and each status change. A redirect or a 200 response is not proof of anything.
- Have one screen or query that answers "which invoices from last week are not in a final state?" If that takes a developer, it won't get checked.
You have to notice failures to report them
The rules require technical failures to be reported to the FTA within 2 business days, and changes to registered data to be notified to your ASP within 5 business days (Andersen). Both assume you know something went wrong. A silent integration is the expensive case: the penalty for not reporting a failure runs daily.
So the integration needs logs you can still read after a restart, and an alert when rejections pile up. We learned the log part the hard way on an unrelated incident, where a container rebuild wiped the only copy of our access logs. The fix was small, and it's described in send container logs to stdout, not files.
Master data and where the data lives
Most early rejections will come from master data rather than from code. Check counterparty TRNs, item codes and the VAT category on each GL line before go-live, not after. Boru's checklist puts master-data cleansing next to ASP selection for exactly this reason.
Decision 243 also includes archiving and data sovereignty rules, and Andersen's summary states that e-invoice data must be stored within the UAE. Ask where every copy actually sits: the ERP if it is SaaS, the ASP, the email archive that still holds PDF copies, and the backups. This is the same question we get about mail servers, and the reasoning in why companies still self-host email in 2026 applies here too. Confirm the exact archiving period and format with your tax adviser; we are not giving tax advice here.
A four-week plan before 30 October
- Week 1: list every system that issues invoices or credit notes, and every system that receives supplier invoices. Name an owner for each.
- Week 2: shortlist ASPs on API quality as well as price. Ask for a sandbox, the status model, how duplicates are handled, and the error codes you will receive. Ask where their data is hosted.
- Week 3: clean master data (buyer TRNs, item codes, VAT categories) and map one real invoice from each source system to PINT AE fields.
- Week 4: sign the ASP, then send test invoices from each source through the sandbox, including one forced failure and one retry, and confirm you can see both in your own records.
After 30 October the work continues until 1 January, but by then the question should be how well the integration works, not which vendor to use.
Where Fanpino fits
We are not an ASP and we don't file anything with the FTA. What we do is the part on your side: connecting in-house billing apps, portals and service systems to the ASP you choose, with idempotent sending, status tracking and logs your finance team can read. If one of your invoice sources is a custom system nobody wants to touch, that is usually where we start.
Sources
- UAE Ministry of Finance: targeted amendments to eInvoicing system decisions (10 May 2026)
- Andersen UAE: Ministerial Decisions No. 243 and 244 of 2025
- KPMG: Implementation of the electronic invoicing system in the UAE
- VATupdate: UAE sets fines for e-invoicing non-compliance (Cabinet Decision No. 106 of 2025)
- Boru Consulting: the 30 October 2026 ASP deadline
