Article 12 of Ministerial Decision No. 243 of 2025 addresses what happens when the Electronic Invoicing System itself fails: "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."

Two elements define the compliance obligation: the 2-Business-Day notification window, and the Authority's determination of the notification mechanism. Both require operational preparation well before any failure actually occurs.

What Qualifies as a System Failure

System Failure is defined in Article 1 of MD 243 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." The definition contains a consequentiality requirement: the malfunction must prevent compliance. A degraded system that processes invoices slowly but successfully does not qualify. An intermittent outage that delays transmission but allows eventual successful processing within the 14-day window does not qualify. A complete unavailability of the ASP's exchange service that prevents any invoice from being transmitted — and therefore makes timely compliance impossible — does qualify.

The definition also specifies that the failure must be of the Electronic Invoicing System — meaning the accredited service provider network or the central exchange infrastructure — not merely of the business's own internal systems. An ERP crash, a local network failure, or an internal AP/AR system outage is not a System Failure under MD 243. If the ASP's network is operational but the business's own systems prevent it from generating or transmitting invoices, Article 12 does not apply. The business remains responsible for its compliance obligations regardless of its own internal system performance.

The 2-Business-Day Notification Window

The clock starts from "the date of occurrence of the System Failure" — not from the date the business discovers the failure, and not from the date the failure is confirmed as a System Failure rather than a minor disruption. If a System Failure begins at 11pm on a Sunday and is detected at 8am Monday, the occurrence date is Sunday. Where Sunday is a weekend day (not a Business Day), the 2-Business-Day window runs from the next Business Day — but the occurrence date for counting purposes is still Sunday. Businesses should maintain an incident log that captures the exact time and date of every service disruption from the ASP, not just the internal detection timestamp.

The Notification Mechanism

Article 12 delegates the notification mechanism to the Authority — "in the mechanism and procedures determined by the Authority." The FTA has the power to determine how the notification must be submitted: through EmaraTax, through a specific notification form, or through another channel the Authority designates. Before the mandatory go-live date, Issuers and Recipients should confirm the current notification mechanism with the FTA or through the ASP, and include it in operational documentation. A business that experiences a System Failure on 2 January 2027 and does not know the notification mechanism will be in breach of Article 12 regardless of how quickly it responds once it figures out the process.

Operational Preparation: What Article 12 Requires in Practice

Article 12 compliance has four practical components. First, the business needs a monitoring arrangement with its ASP that provides real-time or near-real-time notification of ASP service disruptions — the business cannot discover a System Failure only when its own invoice transmissions begin to fail. Second, the business needs an internal escalation workflow that moves a detected System Failure from the IT or operations team to whoever is responsible for FTA regulatory notifications within the 2-Business-Day window. Third, the notification mechanism — whichever form the FTA prescribes — must be tested and understood before any failure occurs. Fourth, the business's incident log should capture the exact occurrence date and time for every ASP service disruption, distinguishing between events that meet the System Failure definition and those that do not.

The ASP service agreement is the first place to look for System Failure support. A well-structured ASP agreement includes: the ASP's obligation to notify the customer of service outages within a specified timeframe, SLAs covering service availability and maximum permitted outage periods, and provisions allocating responsibility for regulatory notifications between the ASP and the customer where the outage is on the ASP's side. Without these contractual provisions, a business may find itself with a 2-Business-Day notification obligation and no timely information from its ASP about whether the outage qualifies as a System Failure under the Article 1 definition.

The Penalty Context

Cabinet Decision No. 106 of 2025 establishes the administrative penalties for Electronic Invoicing violations. Failure to notify the FTA of a System Failure within 2 Business Days is a violation under MD 243, and the penalty regime applies to it. Planning and preparation for Article 12 compliance is therefore not an administrative detail — it is part of the penalty exposure management that any structured e-invoicing implementation programme should address.