Accredited service provider UAE: appoint one by 30 October

If your UAE revenue is at or above AED 50 million, you must appoint an accredited service provider UAE businesses can legally exchange invoices through by 30 October 2026, and implement the eInvoicing system by 1 January 2027. That is 28 days from today. The appointment is not a procurement formality — it fixes your integration surface.

The deadline comes from Ministerial Decision No. 66 of 2026, which replaced one paragraph of Ministerial Decision No. 244 of 2025. Everything below is from the Ministry of Finance and Federal Tax Authority texts, dated as read on 2 October 2026.

Who	Appoint an ASP by	Implement by
Revenue at or above AED 50,000,000	30 October 2026	1 January 2027
Revenue below AED 50,000,000	31 March 2027	1 July 2027
Government entities	31 March 2027	1 October 2027
Pilot and voluntary adoption	Open since 1 July 2026	Voluntary

The date moved once, and the old one is still circulating

Ministerial Decision No. 244 of 2025 originally said 31 July 2026. Decision No. 66 of 2026 replaced that paragraph with 30 October 2026, keeping the 1 January 2027 implementation date unchanged. We covered the headline dates when the extension landed, in appoint an ASP by 30 October, live 1 January; this post is about what the appointment commits your systems to. If your compliance calendar still shows a July date, it was built on the superseded text — and if your project plan was built on the extension, note that the go-live date did not move with it. You gained three months to choose a provider, not three months of implementation runway.

The slippage was supply-side as much as demand-side. When the Ministry announced the extension on 10 May 2026, it put the number of approved service providers at 32. The Ministry's published register listed 60 accredited providers when we read it on 2 October 2026, with a further six in final production assessment. The shortlist problem has eased considerably in five months.

Who the obligation binds, and who it does not

This is where most summaries go wrong. Three points from the primary texts:

• VAT registration is irrelevant to scope. The UAE Electronic Invoicing Guidelines v1.1 put all persons making a business transaction in the UAE in scope, "notwithstanding their VAT registration status", and regardless of whether they are established in the UAE.
• Business-to-consumer transactions are out. Article 5(2) of Decision No. 244 keeps B2C transactions outside the system, and a person engaged exclusively in such transactions is not subject to it at all, until a further ministerial decision says otherwise. The guidelines' scope matrix marks B2B, B2G, G2B and G2G in scope and the consumer row out.
• Your customer's readiness is not your excuse. The guidelines state plainly that a customer's onboarding status or tax registration status does not affect your obligations on a transaction.

Named exclusions in Chapter 7 of the guidelines cover sovereign government activity not in competition with the private sector, certain airline passenger services where an electronic ticket is issued, and financial services exempt from VAT under Article 42 of the VAT Executive Regulation. Air freight under an airway bill has a temporary exclusion lasting 24 months from the Article 5 date.

Intra-group transactions are the most frequently misstated item. There is a grace period, but it is narrower than the shorthand suggests: it applies to transactions between members of the same VAT group, runs 24 months from 1 January 2027, and the guidelines are explicit that it "affects the timing of compliance only" and "does not remove intra-group transactions from the scope". Decision No. 244 itself contains no intra-group provision — the grace comes from the guidelines.

Why five corners makes this an integration decision

The UAE runs a decentralised model with five corners: supplier, supplier's ASP, buyer's ASP, buyer, and the Federal Tax Authority as corner five. The guidelines set out an eleven-step exchange. The parts that matter to whoever owns your ERP:

1. Your ASP validates what you send, converts it to the UAE standard XML, and transmits it to the buyer's ASP. In parallel, it reports tax data to the FTA.
2. The buyer's ASP validates independently. On success it reports tax data to the FTA too. On failure it confirms the failure electronically to your ASP and to the FTA, and no tax data is reported by that corner.
3. The FTA sends electronic confirmation once tax data is successfully reported. Your ASP forwards those confirmations back to you.

Read step two again. A rejection is generated by a party you have no contract with, arrives asynchronously after your ERP has already considered the invoice sent, and is relayed to you by a third party. There is no synchronous success. Any design where your invoice posting is complete when the API call returns 200 is wrong on day one.

Three further allocations of responsibility are easy to miss. A person in scope "must appoint only one ASP" for both sending and receiving, so splitting accounts receivable and accounts payable across two providers is not available to you. The ASP generates the UUID for each electronic invoice to prevent duplication, which means the network's identifier is not yours to assign and your own correlation key has to survive alongside it. And the supplier, not the ASP, is responsible for obtaining the buyer's Peppol participant identifier — a master-data problem in your customer records, scheme 0235 plus the ten-digit TIN. The guidelines' own footnote makes the liability clear: ASPs are engaged to carry out these activities, "although the compliance obligation remains with the supplier".

That is the same shape as GST e-invoicing, where the ERP carries the work and the portal carries the authority, and the same validation discipline we wrote about in EN 16931, where a discount has a VAT rate. Peppol's PINT-AE billing specification defines the UAE field set, so a document your ERP considers valid can still be rejected on a rule your finance team has never read.

What to ask an accredited service provider UAE shortlist about the API

The Ministry publishes its own Considerations for Selecting an Accredited Service Provider, dated 23 February 2026. It is a good procurement document — company history, Peppol tenure, data residency, SLAs, pricing model, roadmap. It is worth noting that of its roughly twenty questions, two concern integration, and both are phrased at the level of "does it integrate with your ERP". One useful contractual detail it does surface: under Decision No. 64 of 2025, an ASP commits to 100 free electronic invoice exchange and reporting services per year, and the Ministry recommends you get that into the contract.

The Ministry's list stops where the engineering starts. These are the questions we would put to a shortlist, and they are answerable in a one-hour technical call:

• Error semantics. Give us the full list of rejection codes, separated into those we can fix and retry, those requiring a credit note, and those that are your problem. If the answer is one generic validation error with a free-text message, your ops team becomes the parser.
• Acknowledgement delivery. Webhook, poll, or file drop? What is the retry policy if our endpoint is down, how long do you hold an unacknowledged confirmation, and can we replay a window of confirmations after an outage?
• Idempotency. If we resubmit the same invoice after a timeout, what happens? Name the field you deduplicate on. "We generate the UUID" is not an answer to this question.
• Sandbox. Is there a sandbox that produces real rejections, not just happy paths? Can we trigger a buyer-side validation failure on demand? Without that, your error handling ships untested.
• Rate limits and batch behaviour. What is the ceiling, and what does month-end look like when you submit a day's volume in an hour?
• Exit. Can we export historical invoices, confirmations and their statuses in a machine-readable format without a professional services engagement?

What happens when the ASP is down, or stops being accredited

Two risks sit outside the SLA conversation, and both are in the regulations rather than the vendor's deck.

The first is that outages are a notifiable event. Cabinet Decision No. 106 of 2025 defines a "System Failure" as any malfunction, disruption or unavailability that prevents compliance, and sets an administrative penalty of AED 1,000 for each day of delay, or part thereof, for failing to notify the Authority within the prescribed timeline. Failing to appoint an ASP within the deadline carries AED 5,000 for each month of delay or part thereof. We could not find a stated notification window in the current guidelines, which read as deferring it to a further ministerial decision — so build the alerting and the named owner now, and treat the window as short until it is published.

The second is that accreditation is a two-year licence. Decision No. 64 of 2025 makes an accreditation valid for two years from grant, renewable on application. The Ministry may terminate it if the provider stops meeting the conditions, or receives validated end-user complaints, or simply wants to exit. On termination, the provider must notify its end users within five business days and is delisted within five business days. Your only lawful route to corner five can therefore go away on about a week's notice.

The engineering conclusion is unglamorous: put an adapter between your ERP and the ASP. One interface in your own code, one implementation per provider, your own invoice state machine and your own correlation identifiers persisted on your side. Switching providers should be a configuration change and a re-onboarding in EmaraTax, not a project. This is standard API development and integration discipline applied to a dependency you cannot replace in a hurry.

The case for not over-engineering this

The strongest argument against everything above: with 60 accredited providers, most of them selling pre-built connectors for mainstream ERPs, the whole thing may be a configuration exercise. If you run a standard installation of a mainstream ERP, invoice in one currency, have no intercompany complexity, and your volumes are modest, buy the connector, use the 100 free invoices to test, and spend your engineering attention elsewhere. That is the right answer for a real share of readers, and we would rather say so.

It stops being the right answer at the first customisation. If your invoice numbering is derived, your pricing logic produces line-level discounts, you bill across free zones, you run self-billing arrangements, or your invoicing lives partly outside your ERP, you are not configuring a connector — you are building an integration, and the connector becomes a component in it. That is also where a custom software estate differs from a packaged one: nobody has pre-built the adapter for a system you had built.

What to do in the next four weeks

Onboarding is initiated by you, not the provider, through EmaraTax on the FTA's website. The guidelines' sequence is: understand the requirements and identify the ERP changes; select the ASP and complete the contract; onboard to its system via EmaraTax; obtain a Peppol participant identifier through it; agree how invoice data and confirmation messages will move; then test end-to-end exchange and reporting before go-live. Steps two and three are what 30 October binds. Steps five and six are the ones that decide whether 1 January is calm.

We should be clear about the limits of our standing here. We have not delivered a UAE e-invoicing integration, and this post rests entirely on the published texts linked above — not on project experience. The tax questions in this programme belong with your tax adviser: whether a transaction is in scope, how an exclusion applies to your business, what your revenue figure is for the threshold. What we can help with is the part the tax advice stops short of — the adapter, the state machine, the error handling and the test harness that decide whether a rejection from a stranger's system on 3 January is a ticket or an incident. If that is the half you are short on, talk to us. The deadline four weeks out is for the contract. The engineering deadline is 1 January.