From your phase's go-live date, the obligation is not to generate documents. It is to transmit them.

Cabinet Decision 106 of 2025 prices the failure to issue or transmit an e-invoice or e-credit note at AED 100 per document, capped at AED 5,000 per month. The cap bites at 50 documents, which means that on any day busier than fifty invoices the fine stops measuring the size of your problem. The number that measures it is the one on your status report, and Lesson 5 is about reading it. Source: Cabinet Decision 106/2025. The full penalty table is taught in course 3.1.

Start with what changed at the moment of sending. Send & Print no longer waits for the ASP. Pressing it queues the document and returns your PDF immediately, and a scheduled action transmits it in the background. That is the whole design in one sentence: a slow or unavailable provider now delays the transmission, not the person issuing the invoice. The queue it goes into is the outbox, and the scheduled action that empties it is the dispatcher.

The dispatcher ships switched off. The scheduled action is called E-Invoice: dispatch outbox, and until a manager enables it, documents queue and wait. The guide calls that "the safe direction". It is worth taking that phrase apart, because the reasoning behind it is the reasoning you will use for every other automation decision in this module.

The argument is about which failure you can undo. A queue that waits fails in one way: documents are late, and every one of them is still there, generated, validated and hash-stamped, in the order it was created. One switch drains it. A dispatcher that fires on a fresh install fails in a different way, because on day one it fires at whatever happens to be configured — no ASP account, an account that has never passed Test Connection, or worst, a Production environment holding credentials someone copied from a test tenant. A transmitted e-invoice is immutable: SHA-256 stamped, and it cannot be regenerated or reset to draft. Lateness is recoverable. A transmission is not.

There is a second half to the argument, and it is arithmetic rather than principle. Failed attempts count towards the configured maximum, after which the dispatcher stops and records why. A dispatcher running against an endpoint nobody had finished configuring would therefore not merely fail — it would spend each document's attempts, and you would arrive on go-live day to an outbox of documents that had already given up, each needing a manual Retry. Off by default costs you one click. On by default costs you a click per document, and a conversation about why the first week of live invoices was transmitted from a sandbox.

The click path, once your ASP account shows Verified: Settings → Technical → Scheduled Actions, find E-Invoice: dispatch outbox, and enable it. This is a manager's job, not the invoicing clerk's. The guide does not publish the interval the action ships with, so read it on the record itself before you promise anyone a transmission time — and note it in your runbook, because it is the number that decides whether "sent this morning" means minutes or hours.

A worked go-live. Your ASP account passes Test Connection on the afternoon of 3 December. Since 1 December your team has posted invoices normally, so 214 documents are sitting in the outbox, generated and validated. A manager enables the dispatcher; from that point the queue is transmitted in the background and nobody re-issues anything, because nothing was lost — it was queued. Had the dispatcher been enabled on 1 December against an account that was not yet verified, those same 214 documents would have spent three days failing, and a good number of them would have exhausted their attempts before the provider was ever live.

The failure mode is quiet, and it is the one to watch for in week one. Nothing errors. Send & Print returns a PDF every time, the invoice looks sent, and the outbox fills up behind it. If the dispatcher is off, you will not find out from an error message — you will find it in the not reported column of the status report, or not at all until someone asks. And if you enable the dispatcher before the account is verified, you get the opposite symptom, an explicit one: sending fails with "No ASP account is configured for company …", which means neither the document nor the company has an ASP account to send through.

The idea to carry forward: the default is off because waiting is recoverable and transmitting is not. Enable it deliberately, on the day the provider is live, and write down the interval you enabled it at.