Three exceptions land in your queue this morning: a rejected XML file, a held tax classification, and a zero-rated export missing its evidence — and if all three go to the same inbox with the same priority, your exception process has already failed.
An exception is a transaction the Continuous Controls Environment™'s controls have flagged as needing human attention before it can proceed, or that has transmitted in a state requiring post-transmission action. At the individual transaction level, exceptions split into three categories with meaningfully different owners, costs and resolution paths — and treating them as one undifferentiated to-do list is the default pattern as UAE pilot-phase businesses run their first live queues.
Three Categories, Three Clocks
Format and schema failures rejected by the ASP need correction and resubmission. The cost of a delayed fix is a business process delay — the buyer cannot process the invoice — and the resolution path is mechanical: find the format error, correct it in the ERP or at the ASP, resubmit. Tax determination issues held pending review at the Control Gate need the tax function to examine the specific facts and reach a classification decision; the cost of getting that wrong is a transmitted position the authority will later query, and the resolution path requires tax judgement, not a technical fix. Evidence gaps on a transmitted zero-rated supply need the supporting documentation confirmed within the statutory deadline; miss that window and the cost is a tax liability on a supply that was correctly zero-rated at the moment it transmitted.
Each of those categories needs a named owner from the moment it surfaces — not a team inbox, but a named individual carrying the obligation to resolve or escalate within a defined period. The exception record has to carry enough context for that owner to act without reconstructing the transaction from scratch. An error code and a transaction reference number is a notification that something needs attention. Governance requires the context the owner needs to act.
Resolving an Exception Is Not the Same as Governing It
Clearing an individual exception is the operational response. Reading the pattern across exceptions is the governance response, and the two are not interchangeable. An exception that recurs across multiple transactions in the same period, for the same transaction type or supply category, is a signal that something upstream — in the master data, the determination logic, or the system configuration — needs a design review, not another round of individual fixes.
The governed question to ask at every review cycle is simple: are any of this period's exceptions repeating exceptions from prior periods? A yes means the recurrence is a Continuous Controls Environment™ design signal, and addressing it means returning it to the control layer that should have prevented the first instance and checking whether that control is still correctly configured. Resolving the same exception type individually, month after month, is the clearest sign that the upstream control was never actually fixed. The monthly resolution makes the number go away; it does not stop the number from reappearing.
A queue that only tracks resolution time is measuring half the problem. The other half — whether this month's exceptions are new or the same ones wearing a different transaction ID — is what separates an exception process that is actually governed from one that is simply busy.