Exception management

Exceptions rarely live in one place. Each source system has its own error queue, and the overflow ends up in shared inboxes and spreadsheets. Nobody sees total volume or total age. One exception can pass through three teams, each of which opens it, gathers the same context and passes it on.

The knowledge of how to fix each type sits with a few experienced people. When they are on leave, the queue ages. At period end the backlog becomes a crunch, and items get closed in bulk with write-offs or manual journals that nobody has time to explain. The causes that produced the exceptions are rarely recorded, so the same ones come back next month.

Queue software organizes the work. The investigation and the fix, which take most of the time, stay manual.

Take cash application as a hypothetical. A customer pays one lump sum and emails a PDF remittance listing three invoices; the bank file carries only a partial reference. Today the payment sits unapplied until someone opens the email. Rebuilt, the AI reads the remittance, matches two invoices exactly, finds the third short-paid, and applies the two. The short payment goes to a collector as a probable deduction, with the remittance, the invoice, the customer's history of deductions and the contract terms attached.

The pattern generalizes:

1. Triage. Each new exception is classified with a stated reason, linked to duplicates and prioritized.
2. Context. Related records from every system are pulled into one case.
3. Resolution. Exception types with a known, reversible fix are resolved within written limits.
4. Routing. The rest go to the right specialist with a brief and a recommendation.
5. Learning. Every case records its root cause, and the clusters go to whoever owns the upstream step.

Specialists keep write-offs, customer disputes and deductions, anything that touches a customer relationship, anything that may need regulatory reporting, and every exception type the system has not seen before. They also own the limits and the playbooks. The AI never approves its own write-off: segregation of duties applies to software the same way it applies to staff. This is human in the loop as a working queue design, and the principle behind it is the century-old idea of management by exception.

A Manthle engagement does not stop at go-live, and exception work is the clearest reason why. The months after launch are when an exception system decays if nobody owns it, because new exception types keep arriving and every playbook needs someone to update it.

Choose one exception family, such as unapplied cash, rejected orders or failed provisioning, and baseline it first. Measure average and oldest age, touches per exception, the share resolved without a person together with the share of those later reversed, time to resolution for routed cases, the period-end backlog, and how often the same root cause recurs.

• Volume is low and the types are stable. A shared queue in the ticketing tool you already have, with clear ownership, is enough.
• One upstream gap causes most exceptions. Fix the validation at the source; an exception that is never created needs no system to handle it.
• Your domain has mature packaged software, such as bank reconciliation in finance, and your process is standard. Buy it.
• The fix is always the same sequence of screens. That is a job for RPA, and it will be cheaper.

Exception queues sit at the center of most back-office automation work, and in billing they decide how quickly credits and adjustments reach the customer; see telecom billing for that case. For choosing which queue to rebuild first, start with the AI for business operations guide.