System failures are a reality of live technology operations. Every business that implements the UAE Electronic Invoicing System will experience connectivity interruptions, ASP outages, ERP issues, or integration failures at some point after go-live. What determines whether those failures become a compliance event — with a penalty of AED 1,000 per day — is not whether the failure occurred, but how it was managed. Article 12 of Ministerial Decision No. 243 of 2025 establishes specific obligations for both Issuers and Recipients when a System Failure occurs, and those obligations have tight timelines and defined notification requirements that must be embedded in operational protocols before go-live.

What Constitutes a System Failure Under MD 243

Article 12 defines a System Failure as any situation preventing the Issuer or Recipient from issuing or exchanging Electronic Invoices or Electronic Credit Notes through the Electronic Invoicing System. The definition is broad by design: it covers failures in the business's own systems (ERP downtime, integration layer failures, network connectivity issues that prevent transmission to the ASP), failures in the ASP's systems (ASP platform outages, Corner 2 or Corner 3 processing failures), and failures in the Corner 5 reporting infrastructure. Any technical condition that prevents the normal exchange of electronic invoices constitutes a System Failure for the purposes of Article 12.

The practical implication is that planned maintenance windows — where the business intentionally takes its ERP or integration layer offline — also fall within the Article 12 definition if they prevent electronic invoice exchange. Planned maintenance should be notified to the FTA proactively under the same protocol as unplanned failures, even where the business has full control over the timing and duration.

The 2 Business Day Notification Obligation

Article 12 requires the Issuer or Recipient experiencing a System Failure to notify the FTA within 2 Business Days of the failure occurring. Business Days in the UAE context means Sunday through Thursday (excluding public holidays). A system failure that occurs on a Wednesday must be notified by the close of business on the following Sunday — a 2-Business-Day window that spans a weekend. For businesses that experience failures on a Thursday afternoon, the notification window runs from Thursday to the following Tuesday — a period that includes the full weekend.

The notification is made through EmaraTax, the FTA's digital portal. The notification must describe the nature of the failure, the date and time it occurred, and the expected resolution timeline. The FTA may respond with instructions or requirements following notification — Article 12 provides that the FTA may issue guidance on the handling of transactions during the failure period, which the business must follow.

The Consequence of Late or Missing Notification

Cabinet Decision No. 106 of 2025 establishes the penalty for failure to notify the FTA of a System Failure within the required timeframe: AED 1,000 per day for each day the notification is delayed beyond the 2 Business Day window. This penalty is uncapped — it continues to accrue daily until notification is made. A business that experiences a system failure on 5 January 2027, fails to notify the FTA, and is identified in an FTA compliance review in April 2027 would face a penalty calculated across the entire intervening period. At AED 1,000 per day, a 90-day notification delay generates AED 90,000 in penalty exposure on a single failure event.

The penalty structure reflects the FTA's dependence on the business's own notification as the mechanism for identifying disruptions to the real-time data flow into Corner 5. Where the FTA's Corner 5 data shows a gap in invoice reporting from a Phase 1 business, the FTA needs to know whether that gap reflects a system failure (permissible with notification and remediation) or a compliance failure (non-reporting of taxable supplies). The notification obligation is what enables the FTA to distinguish between the two.

The Additional Data Notification Obligation

Article 12 also requires the Issuer to notify their appointed ASP of any change to data registered in the Electronic Invoicing System within 5 Business Days of receiving confirmation from the FTA that the change has been approved. This covers changes to legal entity registration data, TIN updates, address changes, and other registered information that affects the Peppol Participant Identifier or the identity fields on electronic invoices. The 5-Business-Day data notification obligation is separate from the System Failure notification and carries its own separate penalty under CD 106: AED 1,000 per day for each day the notification to the ASP is delayed beyond the 5-Business-Day window.

What the Protocol Must Cover

An operational System Failure protocol for UAE e-invoicing must cover four elements. The first is detection: how does the business identify that a System Failure has occurred? For ERP-side failures, the detection mechanism may be an internal monitoring alert. For ASP-side failures, it requires the ASP to proactively notify the business within a contracted timeframe. For Corner 5 failures, it requires monitoring of the ASP's Corner 5 confirmation data. The detection mechanism for each failure type must be defined and operational before go-live — not designed retrospectively when the first failure occurs.

The second element is the internal escalation path: who in the business is responsible for assessing whether a detected technical issue meets the MD 243 Article 12 definition of a System Failure, and who has the authority to initiate the EmaraTax notification? For large organisations with separate IT, tax, and finance functions, this escalation path crosses departmental boundaries and must be agreed in advance. The third element is the notification execution: who has EmaraTax access to submit the failure notification, and what information must the notification contain? The fourth element is the transaction remediation plan: for invoices that were not issued or exchanged during the failure period, what is the process for issuing them after the system is restored, and how is the 14-day issuance clock managed during the failure period?

The ASP's Role in the System Failure Protocol

Where the System Failure is on the ASP's side — an ASP platform outage or Corner 2 processing failure — the business remains responsible for the FTA notification within 2 Business Days. The ASP's outage does not transfer the notification obligation to the ASP. The business must have a mechanism for detecting ASP-side failures (through ASP status communications or monitoring of transmission confirmation data) and triggering its own notification process without waiting for the ASP to resolve the issue.

This has contractual implications for the ASP agreement. The business should require the ASP to notify it of platform outages within a defined timeframe — for example, within 4 Business Hours — so that the 2 Business Day notification window is not consumed waiting for the ASP to communicate the issue. Where the ASP's notification to the business is delayed, and the FTA notification deadline is consequently missed, the business bears the penalty. The ASP agreement should address the allocation of liability for that penalty.

Practitioner Insight: The system failure protocol is the governance deliverable that businesses are most likely to defer until after go-live, on the grounds that it addresses a scenario that may never occur. That logic underestimates both the probability of a go-live period technical issue — when new integrations typically experience their first failures in production — and the consequence of having no protocol in place when it does. The protocol should be designed, signed off, and tested in the pre-go-live period. The 2 Business Day window is too short to design and execute a new process in real time.

Aligning the Protocol With the Broader Business Continuity Framework

For most Phase 1 businesses, the UAE e-invoicing System Failure protocol should be integrated into the existing Business Continuity Plan (BCP) rather than created as a standalone document. The BCP already addresses ERP downtime, network failures, and third-party service outages. The UAE e-invoicing protocol adds a specific regulatory notification obligation to those existing escalation and remediation processes.

The key addition is the FTA notification step — which has no equivalent in most existing BCP processes — and the 2 Business Day clock. Every IT outage or connectivity issue that affects invoice exchange must trigger an assessment against the Article 12 definition. Where the assessment concludes that the issue constitutes a System Failure, the FTA notification is initiated regardless of the expected resolution time. Notifying the FTA and then resolving the failure the same day generates no penalty. Resolving the failure without notifying the FTA generates AED 1,000 per day from day 3 onwards.