A failed transmission is not, by itself, an exposure. A failed transmission nobody notices for eleven days is. The penalty regime measures months, so what matters operationally is not that a document failed but how long it stays failed and whether anything is still trying.

The module's answer has three moving parts, and all three are yours to set at Accounting → Configuration → Settings → UAE E-Invoicing: maximum attempts, backoff base and backoff ceiling.

• Backoff base — how long the dispatcher waits after the first failure before trying again.
• Doubling — each subsequent wait is twice the one before it, so a provider that is briefly slow is retried quickly and a provider that is properly down is not hammered.
• Backoff ceiling — the point at which waits stop doubling. Every wait from there on is the ceiling.
• Maximum attempts — after this many, the dispatcher gives up, and records why on the document.

The guide does not publish the values the module ships with, so open that settings page and read your own before you rely on any of the arithmetic below. What follows is a worked ladder for one common choice: a base of 15 minutes, a ceiling of 4 hours, and a maximum of 6 attempts.

That ladder runs 7 hours 45 minutes end to end, and its shape is the point. The first three attempts are done inside the first hour, which catches every transient failure — a dropped connection, a provider restarting a node. The last two stretch across the afternoon, which is the correct response to an outage. The ceiling is what keeps the ladder inside a working day. Without one, the wait before a twelfth attempt would be 15,360 minutes — 10 days and 16 hours — and the document would sit untouched for longer than most businesses take to close a month. That is the "weeks away" the guide is protecting you from.

Retries stop, and stopping is a feature. Three reasons, and they compound. A document the FTA will never accept fails identically at the four hundredth attempt as at the fourth, so retrying is not diagnosis. A queue that never drains is not a work list, because you cannot tell what is progressing from what is stuck. And the stop itself writes the reason onto the document, which converts an invisible loop into a work item with a cause attached.

Then the counterpart: pressing Retry resets the counter. That is what makes the stop safe rather than final — nothing is lost, and a document that gave up at 16:45 gets a full ladder again the moment you press the button. It also sets the order of operations, and getting it backwards is the most common mistake in this whole course. Diagnose, fix the cause, then Retry. Pressing Retry first buys you another 7 hours 45 minutes of exactly the same failure and moves the document further from the month it belongs to. Note that Retry appears only when a document is failed or rejected, and that a user in the User group can press it — this is not a manager-only action.

The failure mode here is behavioural rather than technical, and it shows up as a pattern on the report: the same documents reappearing in the retry queue, stopping, being retried and stopping again, while the rejection reasons panel shows one cause with a rising count. Forty rejections with one cause is not forty problems. It is one configuration problem, and it is usually fixable in an afternoon.

MISSING FACT: the mechanism, channel and deadline for notifying a system failure, and what qualifies as one. Cabinet Decision 106/2025 prices a failure to notify a system failure, or a change in data, at AED 1,000 per day — the most expensive of the three penalties in that decision, and the one a two-day transport outage puts you nearest to. The sources cited by this course establish the penalty but not the procedure. Settle it with your ASP and your tax advisor before you need it, and write the answer into your incident runbook.

The idea to carry forward: the ladder is a diagnostic instrument, not just a delay. Fix, then Retry — and if you find yourself pressing Retry twice on the same document, the cause is not the transport.