Finance processes were designed on an assumption that no longer holds: that most of the work is the same and a small part of it is unusual. The standard path was built first, carefully, with the exception route added afterwards as a side door — an email to a supervisor, a manual journal, a note in a spreadsheet. Invert the ratio and the design collapses. When ninety-five per cent of transactions never touch a person, the side door becomes the main entrance, and it was never built to carry traffic.
Your standard process is now the part nobody works on. The exception route — the least designed thing in the function — is where all the remaining effort, risk and expertise actually live
Here is how to design the thing you have been treating as an afterthought.
What is wrong with the side door
It has no queue, so nobody knows how much is waiting. It has no ageing, so nothing escalates on its own. It has no categorisation, so you cannot tell whether the same problem is arriving two hundred times. It has no resolution record, so the fix is not reusable. And it usually has no owner, because it was the overflow from a process that did have one. Every one of those is fine at three per cent of volume and untenable when exceptions are the work.
The five design decisions
Categorise at entry, not at resolution. An exception should be classified when it is raised, by whatever raised it. Categories that are assigned afterwards by the person fixing the problem are descriptions of the fix, not of the cause, and they cannot be used to reduce recurrence. Give exceptions an ageing profile and a service level. Not because anyone will be disciplined against it, but because an unaged queue hides its own growth until month-end. Route by cause, not by department. Most exception routing sends the item to the team that owns the process, when the cause frequently sits upstream in procurement, sales or master data. Routing by cause is what makes recurrence visible to the people who can stop it. Record the resolution as structured data. What was wrong, what was done, was it a one-off. A free-text note is a record for the auditor and useless for improvement. Set a recurrence threshold that triggers redesign. If the same category appears more than some number of times a month, it is not an exception. It is an unhandled case in the standard process, and it belongs in the configuration backlog.
The metric that matters
Not exception volume, which falls naturally as automation improves. Track the proportion of exceptions that are genuinely novel. A queue where eighty per cent of items are repeats of known categories is a configuration problem being absorbed as labour, and it is extremely common.
Classify and age
Record cause, owner, queue depth and elapsed time at entry.
Route and resolve
Send the item to the team able to correct the cause; record resolution.
Review recurrence
Use an agreed threshold to move repeating cases into redesign work.
Qualitative summary of this article's source text, not a measured outcome or performance estimate.
Practical Guidance for Process Redesign Workshop
- Build a real queue with ageing and visible depth.
- Categorise at entry by cause, not by symptom.
- Route upstream to where the cause sits.
- Capture resolutions as structured data.
- Set a recurrence threshold that forces redesign.
- Track the novel proportion, not the total.
- Give the queue a named owner with configuration authority.
- Review categories quarterly and retire the ones you fixed.
The Regional Angle
The first regional pattern worth designing for is that a large share of exceptions in Gulf finance functions originate in document quality rather than in system logic. Supplier invoices arriving as photographs, bilingual documents where the Arabic and English differ, handwritten delivery notes and trade licence details that do not match the registered name are all upstream causes that produce downstream exceptions, and they are invisible if you categorise by what finance had to do rather than by what arrived. Add document-quality categories explicitly, because the fix is a supplier conversation rather than a configuration change. The second concerns escalation culture, which affects whether an exception queue works at all. In many regional organisations escalation is read as a complaint about a colleague, so items sit with the person who received them rather than moving to the person who can resolve them, and the ageing profile you carefully designed measures politeness rather than difficulty. Make routing automatic and rule-based so that escalation is a property of the system rather than a decision by an individual, which removes the interpersonal cost entirely. The third is about the statutory dimension, which changes what an exception means here. An exception on a transaction that feeds a Saudi e-invoicing submission or an Emirati tax return is not merely a delayed posting; it is a filing that may go out wrong or late, with a regulatory consequence rather than an accounting one. Flag exceptions that sit on the statutory path as a distinct class with its own service level, because in this region the deadline is external and does not negotiate.
The objection worth taking seriously
The strongest objection is that formalising the exception path institutionalises it. Give a workaround a queue, a service level, an owner and a reporting line and you have converted a temporary irregularity into permanent infrastructure, with a team whose existence depends on a steady supply of broken transactions. The purist position is that exceptions should be eliminated at source, and that every hour spent making the exception process comfortable is an hour not spent making it unnecessary. There is genuine risk in that, and functions that build elaborate exception operations do sometimes stop asking why the exceptions exist. The defence is that the two are not alternatives, and the structured version is the only one that supports elimination. You cannot remove causes you have not categorised or counted; the informal side door is precisely the design that makes root causes invisible, which is why organisations have tolerated the same recurring problems for a decade. The recurrence threshold is the safeguard against the failure mode described — it is a standing commitment that any category appearing often enough stops being handled and starts being fixed. If you build the queue without that threshold, the objection is correct and you have built a permanent workaround factory.
Common Questions
What proportion of exceptions should be novel?
There is no universal number, but if the majority are repeats of known categories, the queue is substituting for configuration work.
Who should own the exception queue?
Someone with authority to change the upstream configuration. An owner who can only resolve items and not prevent them is a supervisor of a backlog.
Does this need new software?
Usually not. Most systems can support categorisation, ageing and routing; the missing element is almost always design rather than tooling.
What should we expect over the next twelve months?
Expect exception handling to become the explicit centre of back-office design rather than its margin. Expect vendors to market exception management as a category. Expect the recurrence data to embarrass a few upstream departments. And expect the functions that measure novelty to pull noticeably ahead of those measuring volume.
Process Redesign Workshop — we rebuild the side door as the main entrance, with the recurrence threshold that stops it becoming permanent.