UAE E-Invoicing Outage: Silence Is the Breach Itself

Picture the first bad Tuesday after go-live. It is 9:14 in the morning, your sales team has raised forty invoices, and none of them are moving. Your Accredited Service Provider has an outage. The portal shows a polite maintenance banner. Your IT manager shrugs and says the provider will sort it out. Under the UAE e-invoicing outage rules, that shrug is where the real problem starts — because the clock that matters is not your provider's repair clock. It is yours.

Most e-invoicing project plans we review obsess over formats, fields and deadlines for appointing a provider. Almost none of them answer a simpler question: when the technology fails, who in your business tells the Federal Tax Authority, how fast, and with what evidence? Ministerial Decision No. 243 of 2025 answers the timing part clearly. The ownership part is still missing in most companies we speak to.

UAE E-Invoicing Outage Rule: Both Sides Owe the Notice

Here is the rule that catches people out. If a technical malfunction or system outage prevents compliance with the Electronic Invoicing System, both the issuer and the recipient must notify the FTA within two business days through the designated reporting route.

Read the second half of that sentence again. Recipient. Not just the business that sent the invoice. Not just the provider whose system failed. If you were supposed to receive e-invoices and the failure stops you complying, you carry a notification duty of your own. You can breach the rules by staying silent about somebody else's failure.

That design is deliberate, once you think about it. In a five-corner model, an outage rarely affects one business in isolation. A single provider failure can stall hundreds of issuers and thousands of recipients on the same morning. If only issuers had to report, the FTA would see half the picture. By putting the duty on both sides of the transaction, the system gets two independent signals about the same failure — and neither side can hide behind the other.

We have started calling this the silence rule in client workshops, because it flips the instinct most finance teams have. The instinct is to wait. Wait for the provider to confirm the root cause. Wait for service to come back. Wait for someone senior to decide whether this is serious enough to report. Two business days is not a waiting window. It is a reporting window, and it starts while the facts are still messy.

The Other Three Clocks Nobody Has Written Down

The outage notice does not sit alone. The same framework summary published this week sets out three companion duties that belong in the same operating procedure, because they share the same weakness: each one needs a named human, not a software feature.

Fourteen days to issue and transmit

E-invoices and credit notes must generally be issued and transmitted within 14 days of the transaction. For VAT-registered businesses, the VAT time-of-supply rules run alongside this, so do not treat the 14 days as permission to sit on an invoice the VAT rules want issued sooner. The practical point stands either way: the era of raising a month of invoices in one lazy batch at month-end is over. A billing backlog is now a compliance failure, not an admin habit. Our piece on how one wrong TRN kills an invoice before it reaches the buyer shows what validation does to sloppy data — slow data fails in a different way, but it still fails.

Storage inside the UAE, with FTA access

All e-invoices, credit notes and associated transaction data must be stored within the UAE for the periods set by the Tax Procedures Law, and the FTA can access and use that stored data. This is a selection question, not an archive question. If your provider or cloud configuration stores the invoice record outside the State, you find that out when you sign the contract — or you find it out during an FTA enquiry, which is a much worse meeting. Ask where the data lives before go-live, and get the answer in writing.

Five business days to tell your ASP your details changed

If the FTA confirms a change to your registered tax details, you must tell your ASP in writing within five business days of that confirmation. A new TRN detail, a changed legal name, an amended address — if the registration record moved and your provider is still working from the old version, every invoice it validates carries the stale data. Five days sounds generous until you realise nobody in most finance teams owns the job of passing a registration change to the invoicing provider. It falls between tax, company secretarial and IT, which means it falls on the floor.

Why Smart Businesses Will Still Miss the Two-Day Window

We stress-test this rule with clients using one scenario, and the failure pattern is always the same. See if you recognise your own office in it.

First, nobody can tell an outage from a delay. Invoices queue for an hour during a busy morning and nobody blinks. By the time the team accepts this is a genuine malfunction, half a business day has gone. Your procedure needs a trigger that does not require certainty — something like: if transmission has been impossible for four working hours and the provider has confirmed an incident, the notification process starts. You can always update the FTA. You cannot rewind the clock.

Second, everyone assumes the provider reports for them. Your ASP may well notify the FTA about its own platform failure. That does not discharge your duty. The obligation in the framework sits on issuers and recipients — the businesses — not only on the middleman. A provider's status page is not evidence that you complied. If your contract does not say, in plain language, who notifies whom and what confirmation you receive, you do not have an outage procedure. You have a hope.

Third, the person who knows is away. Outages do not book appointments. The one employee who understands the e-invoicing setup will, at some point, be on leave, in a meeting, or gone from the company when the system fails on a deadline week. If the notification duty lives in one person's head, your compliance has a single point of failure — the same weakness you just paid a provider to remove from your invoicing. Name an owner and a deputy, and write the steps down where both of them can reach them at 9:14 on a bad Tuesday.

Fourth, there is no evidence file. When the FTA asks what happened, "the system was down for a bit" is not an answer. You need the provider's incident reference, timestamps for when transmission failed and resumed, the list of invoices affected, and a copy of your notification with its date. Businesses that keep that file as they go can close the conversation in one exchange. Businesses that reconstruct it afterwards spend weeks doing archaeology. This is the same discipline we push for everyday records in why a bank statement on its own is not bookkeeping — contemporaneous records beat reconstructed stories, every time.

UAE E-Invoicing Outage Duties in the Wider Timetable

None of this is distant. Businesses with revenue of AED 50 million or more go live on 1 January 2027 — weeks away, not quarters. Smaller businesses follow on 1 July 2027, and government entities on 1 October 2027. The phase question itself trips groups up, as we covered in why the phase test applies per company, not per group: each legal entity is tested on its own, so a group can easily have one entity already inside the operating regime while its sister companies are still planning.

Two more points from the framework deserve a place in your plan.

Voluntary opt-in binds you. An excluded person who chooses to opt in to the Electronic Invoicing System becomes bound by its rules, even though the penalty decisions do not apply to them in the same way. Opting in early to test is sensible — plenty of businesses should use the voluntary window to bed the process in. Just do it knowing the operating duties come with the test. A voluntary system run casually teaches your team habits you will have to unteach at go-live.

Accreditation language has already moved once. The provider market shifted in October when the rules on ASP approval changed, which we explained in why 'approved' no longer means 'accredited' for e-invoicing providers. If your outage clause was drafted against an old provider status or an old contract, re-read it. And remember that e-invoicing is only one of the payment-and-invoice rules tightening this quarter — the new VAT cash payment rule shows the same pattern from the other direction: the FTA is increasingly testing how a transaction was executed, not just how it was documented.

On penalties, keep your feet on the ground. Cabinet Decision No. 106 of 2025 sets the e-invoicing penalty framework, including AED 5,000 per month for failing to implement the system or appoint an ASP by the deadline, and per-invoice penalties for invoices not issued or transmitted correctly. A missed failure notification sits inside that same enforcement framework. The exact dirham figure matters less than the principle: silence is a separate failure from the outage itself. The outage may not be your fault. The silence always is.

A Two-Day Procedure You Can Set Up This Week

You do not need new software for any of this. You need five decisions, written down.

• Name the owner and the deputy. One person owns FTA failure notifications, one covers their absence. Put both names, with mobile numbers, in the procedure document — not in a chat thread.
• Define the trigger. Agree the point at which a delay becomes a reportable failure: provider-confirmed incident, or transmission impossible beyond a set number of working hours. Starting the process early costs nothing. Starting it late costs the window.
• Fix the ASP contract wording. Your provider must tell you about incidents immediately, give you an incident reference, and confirm in writing what it has notified on its side. Your duty stays yours — the contract just makes sure you hear about the failure while you can still act.
• Pre-draft the notification. A one-page template with your TRN, licence details, ASP name and the fields the designated route asks for, saved where the owner and deputy can both reach it. Nobody should be composing this document for the first time during an outage.
• Keep the evidence file automatically. Every incident gets a folder: provider notice, timestamps, affected invoice list, your notification and its acknowledgement. Build the folder during the incident, not after it.

Then rehearse it once before go-live. Pick a quiet afternoon, declare a pretend outage, and watch what actually happens. In our experience the rehearsal finds the real gaps in about twenty minutes: the deputy does not have portal access, the template has last year's TRN, the provider's support line goes to a ticket queue. Every one of those is free to fix in a rehearsal and expensive to discover for real.

The Outage Is Forgivable. The Silence Is Not.

Systems fail. Providers have bad mornings, connections drop, platforms go down for maintenance at the worst possible moment. The framework knows this — that is exactly why it built a notification route instead of simply punishing every failure. What it does not forgive is a business that knew and said nothing, on either side of the invoice.

So before 1 January, ask your team the Tuesday question: if the system went down at 9:14 tomorrow, who tells the FTA, by when, and where is that written? If the answer takes longer than thirty seconds, you have found your next job.

Want a second pair of eyes on your e-invoicing operating procedure — outage duties, storage, ASP terms and all? Book a free consultation at escrowconsultinggroup.com and we will walk through your go-live readiness, including the parts of the regime that only bite after the invoices start flowing.

Sources: Ministry of Finance e-invoicing framework under Ministerial Decision No. 243 of 2025, as summarised by Regfollower (16 October 2026) and Deloitte's release note on Decisions 243 and 244 of 2025. Confirm the designated notification route for your circumstances against the current Ministry guidelines before relying on any timeline.