UAE eInvoicing system failure: how to report it, keep working and recover

Under UAE eInvoicing, an invoice depends on a chain of systems: your accounting or billing system, your Accredited Service Provider (ASP), the buyer's ASP, the buyer's system, and the Federal Tax Authority (FTA). Businesses with revenue of AED 50 million or more go live on 1 January 2027, and smaller businesses follow on 1 July 2027. From then on, if one link in that chain breaks, it is no longer only an IT problem. It can start a legal deadline of two business days.

This guide explains how to tell a system failure from an ordinary rejected invoice, who must notify the FTA and by when, what to do while the system is down, and how to recover queued invoices without creating duplicates.

What counts as a system failure under UAE eInvoicing?

Ministerial Decision No. 243 of 2025 defines a system failure in Article 1 as "any technical malfunction, disruption, or unavailability of the Electronic Invoicing System that prevents the Issuer or Recipient from complying with their obligations under this Decision".

Two points follow from that wording. The cause must be technical. And it must stop you from meeting an obligation, such as issuing, sending, receiving or reporting invoices.

So a single rejected invoice is almost never a system failure. A wrong field, a wrong code or a user mistake is an ordinary error. A three-hour ASP outage that blocks every outgoing invoice is a system failure. So is an integration that has stopped sending invoices to your ASP while the queue keeps growing. For ordinary errors, see UAE eInvoice errors, rejections and statuses.

Use three questions to decide:

The length of the outage is not the test. A short outage that stopped you from meeting an obligation can still count. A long one that did not stop anything does not.

Where can a system failure happen?

A failure can sit at different points in the chain. The point affects who is hit and whose duty applies.

One incident can be a system failure for the supplier, the buyer and both ASPs at the same time. Each business still has its own duty to notify.

Who must notify the FTA of a system failure, and by when?

Article 12 of Ministerial Decision No. 243 of 2025 states: "Every Issuer and Recipient shall notify the Authority of a System Failure within 2 Business Days from the date of occurrence of the System Failure, in the mechanism and procedures determined by the Authority."

The clock starts on the day the failure happened. It does not start when IT finds the cause or when the system comes back. If a system stopped at 09:00 on Monday and the fix took until Wednesday, you still count from Monday.

The same Decision defines a business day as any day except weekends and official federal government holidays. So two business days is not the same as 48 hours.

Late notification is expensive. Under Cabinet Decision No. 106 of 2025, it costs AED 1,000 for each day or part of a day of delay. The issuer and the recipient are fined separately. If both miss the deadline for the same outage, both pay. For the full list, see UAE eInvoicing penalties.

Does your ASP's notice cover your own duty?

Treat your duty as your own. Article 12 places the notification duty on every issuer and every recipient, not on the ASP.

ASPs have their own role. Appendix 3 of the UAE Electronic Invoicing Guidelines, version 1.1 (Guidelines v1.1) requires an ASP to tell its customers and the FTA about any disruption to its service. It does this by email to e-invoicingsupport@tax.gov.ae. The same appendix asks businesses to make sure their ASP notifies the FTA in a timely manner.

So do three things. Before go-live, agree with your ASP how disruption notices work and ask for a copy of any notice sent on your behalf. During an incident, confirm in writing whether your ASP has notified the FTA. And keep your own dated record of how and when your business notified the FTA.

What should you do in the first hour of an eInvoicing outage?

The first hour decides how smoothly the rest goes. A simple sequence:

1. Confirm the outage is real. Try the same action a second way, for example with another user or a monitoring check.

2. Record when it started. Use the earliest reliable signal, such as a monitoring alert, an error log or a user ticket. Note the time in UAE time.

3. Name one person in charge. This person owns the timeline, the decision log and the decision to notify.

4. Stop automatic retries. Uncontrolled retries can create duplicates later. Hold new invoices in a clearly marked queue instead.

5. Contact your ASP in writing. Ask how many customers are affected, when service should return, and whether the ASP has already notified the FTA.

6. Tell the internal teams. This usually means tax, finance operations, AR, AP and IT.

7. Keep external messages short. Tell customers and suppliers only that an issue is being handled. Do not promise a reissue time until your ASP has replied.

How can you plan the two business days?

The law sets the outer limit. How you use the time inside it is up to you. A practical plan:

Notify early. Once you know the incident is a system failure, there is no benefit in waiting until the last day.

What should you record during the outage?

Good records support both the notice and the later reconciliation. Keep a running log of:

• The time the problem was first detected, and how it was detected.

• The number of each affected invoice, at the start and whenever the queue changes.

• Every retry, with its time and result.

• Your ASP ticket number, the ASP's updates, and any confirmation that it notified the FTA.

• Every internal decision, with the time and the person who made it.

• Every message to customers or suppliers, with its content and recipient.

Can you send PDF invoices during an eInvoicing outage?

You can send a PDF copy so the customer knows what is coming and can plan payment. But the PDF does not replace the eInvoice. Plan to issue every affected eInvoice through your ASP as soon as the system is back.

Appendix 3 of Guidelines v1.1 says the same from the other side. Once a disruption is resolved, businesses should make sure their ASP exchanges and reports all pending eInvoices in a timely manner.

How do you recover after an eInvoicing outage?

How do you release queued invoices without duplicates?

Two risks come up most often after an outage. The same invoice gets sent twice from two retry paths, or invoices go out in a different order from how they were created.

Before release, identify each queued invoice by its original number, remove any duplicates, and keep the original date order. Release in batches rather than all at once. A sudden flood straight after an outage can cause new rejections that look like a second incident. Check a small first batch before releasing the rest.

When is a released invoice really done?

A released invoice is done only when both confirmations have arrived: the exchange confirmation from the buyer's ASP, and the reporting confirmation from the FTA for your own tax data. Your ASP accepting the invoice is not enough. Invoices that stay unconfirmed during recovery are the clearest sign that a problem remains.

Which numbers should match at the end?

When recovery is complete, these counts should tie out:

Affected should equal sent, plus any invoices withdrawn because the sale was cancelled during the outage. Sent should equal completed plus failed plus still open. Investigate any difference before you close the incident.

What should your system failure record include?

Keep one record per incident, with these fields:

Keep this record with your other eInvoicing records. See UAE eInvoice retention periods and audit records.

How should you test your system failure plan?

A plan that has never been tested rarely works on the day. A tabletop exercise before go-live, and once a year after that, is a sensible rhythm. Test again after any incident or change of ASP.

Four scenarios cover the main risks:

• ASP outage. Your ASP is down for six hours. Who declares the incident, who writes the FTA notice, and what will the queue look like when service returns?

• Accounting system outage. Your billing system is down, but the ASP is fine. Which invoices are affected: those already in progress, those not yet raised, or both?

• Partial connection failure. Some invoices go through and others hang. At what point do you treat it as a system failure?

• Problems during recovery. When the queue is released, some invoices come back as duplicates or with structure errors. Does your process catch them, and do the counts still tie out?

Write down what worked, what did not, and what you will change. Update your list of owners where the test showed a gap.

Zoho Software Trading LLC is a Ministry of Finance-accredited eInvoicing service provider for the UAE, with accreditation number 121988, as shown on the MoF register of accredited service providers. When your accounting system connects directly to your ASP, queued invoices and their later confirmations stay on the same record as the original invoice, which makes recovery and reconciliation easier to check.

Explore UAE eInvoicing with Zoho Books

Frequently asked questions

Is every rejected eInvoice a system failure?

No. A rejected invoice is usually a data problem, such as a missing field or a wrong identifier, and goes through the normal error process. A system failure is a technical malfunction, disruption or outage that stops you from meeting your eInvoicing obligations.

When does the two-business-day clock start?

On the date the system failure happened, under Article 12 of Ministerial Decision No. 243 of 2025. It does not start when the cause is found or when the system is fixed. Weekends and official federal government holidays are not business days.

Can my ASP notify the FTA for my business?

Your ASP must notify the FTA of disruptions to its own service, under Appendix 3 of Guidelines v1.1. Your business still has its own duty under Article 12. Agree the process with your ASP in advance, get a copy of any notice it sends, and keep a record of your own notification.

What evidence shows that the FTA was notified on time?

A copy of the notice with the time it was sent and the recipient, plus the records that show when the failure started, such as monitoring logs and ticket times. The start time and the notice time together show whether you met the two-business-day deadline.

Related guides

• UAE eInvoice errors, rejections and statuses: how to find and fix them

• UAE eInvoicing penalties and non-compliance risks

• How UAE eInvoicing works: the 5-corner model, end to end

• UAE eInvoice retention: periods, storage and audit records

• UAE eInvoicing readiness and implementation guide