# Manage Order Exceptions with Rules, Escalation and Traceability

> How to design order exception management for price, stock, credit, product references and duplicates with explicit rules, owners and audit trails.

- Canonical: https://arkatai.com/en/manage-order-exceptions/
- Site: Arkatai (https://arkatai.com) — agentic operations as a service
- Language: en
- Published: 2026-09-01

---
Managing order exceptions is the centre of the operation, not a safety net added at the end. Registering a perfect order is a deterministic flow. Administrative cost appears when the price does not match, stock is short, the product reference is obsolete, the customer is blocked or the document contradicts the commercial agreement.

In many businesses those exceptions live inside the team's memory. One person knows that customer A accepts partial delivery, customer B needs the sales director's approval and customer C's old reference has a valid replacement. A system can operate only when that judgement becomes verifiable rules and when it knows how to stop outside its mandate.

This guide develops one part of the wider process to [automate B2B orders](/en/automate-b2b-orders/). The goal is not to eliminate every exception. It is to resolve known cases automatically and reduce the work required to decide the rest.

## What an order exception is

An exception is a condition that prevents an order from completing through the normal path. It should be expressible through four elements: observed fact, applicable rule, risk or impact, and next action.

“The order looks odd” is not operational. “Line four requests 120 units of a discontinued product and an approved replacement exists for this customer” is. The second statement can be resolved, escalated and measured.

Distinguish missing data, invalid data, conflicting sources, business restrictions and technical failures. Each class has a different owner and expected response time. An ERP outage should not land in the sales queue, and an unauthorised discount should not be treated as an integration error.

## A minimum taxonomy

| Class | Examples | Typical response |
|---|---|---|
| Identity | Ambiguous customer or legal entity | Request data or validate master record |
| Product | Unknown or superseded reference | Suggest an approved mapping |
| Commercial | Incorrect price, discount or minimum | Apply tolerance or request approval |
| Inventory | Insufficient stock or impossible date | Propose partial, replacement or new date |
| Risk | Blocked credit or amount over limit | Stop and escalate |
| Logistics | New address or special condition | Validate with the owner |
| Duplication | Existing order or possible amendment | Link, compare and decide version |
| Technical | ERP unavailable or uncertain write | Retry idempotently |

Start with a small taxonomy and grow it from evidence. Creating a hundred codes before observing real cases merely replaces a chaotic inbox with an impossible form. Initial classes come from a historical sample and are reviewed when unclassified exceptions appear.

## Rule, tolerance and prohibition

For every exception, define what the system may do. Three levels are useful.

An **automatic rule** resolves an unambiguous case, such as replacing an obsolete reference with its official successor or normalising units from an approved table. A **tolerance** permits action within a range, such as accepting a rounding difference or a date inside the agreed window. A **prohibition** always stops the case: blocked customer, price below floor or an action beyond the granted permission.

The model can help interpret a document but does not invent those limits. Rules are versioned and have an owner and effective date. Each execution records the version it used. When a price list changes, later orders use the new one while earlier cases retain evidence of what was valid at their time.

## Design human escalation

Escalation does not mean sending everything to one shared queue. The exception should reach the person able to resolve it: sales for terms, credit for blocks, operations for delivery and IT for technical failures.

An escalation card should include:

- affected order, customer and line;
- observed condition and source;
- rule preventing continuation;
- permitted options;
- impact on date, margin or risk;
- deadline for deciding;
- actions already taken;
- link to the original evidence.

It should also capture the decision structurally. “OK” in an email does not reveal whether a discount was authorised for one order or whether general policy changed. The interface must distinguish a one-off exception from a new rule. The broader split of authority is explained in [human in the loop](/en/human-in-the-loop/).

## Resolve more without hiding risk

A low escalation rate is not automatically good. It may mean the operation resolves more cases, but it may also mean cases pass that should have stopped. Autonomy and quality must therefore be measured together.

For each class, observe false positives—cases escalated that could have been resolved—and false negatives—cases resolved that required a decision. Their costs are not symmetric. Excess escalation consumes time; approving an order below margin or for a blocked customer can produce a much larger loss. Thresholds should represent that impact.

The system can initially operate in shadow mode, classifying and proposing while a person continues to decide. Compare both outcomes and widen autonomy one class at a time. Do not jump from reviewing everything to reviewing nothing through one confidence score.

## Trace an exception from evidence to action

Reconstructing a case requires the original input, extracted data, internal sources consulted, rules applied, generated proposal, human decision and final action. The trace should use stable identifiers and timestamps while avoiding unnecessary personal data.

Traceability serves three different jobs. It explains an error to the customer, evaluates whether the system retains quality and discovers operating rules still trapped in conversations. It should not be a warehouse of opaque model reasoning; it should preserve verifiable facts and decisions.

The wider architecture appears in [AI agent observability and traceability](/en/ai-agent-observability/), but in order management the audit unit should always be the complete case.

## Metrics by exception class

A total average hides the important information. The operating view should show for each class:

- volume and percentage of orders;
- time to resolution;
- percentage resolved automatically;
- human minutes used;
- recurrence by customer or format;
- later corrections;
- impact on date, margin or service;
- unclassified cases.

The final metric is particularly useful. If “other” exceptions increase, the taxonomy no longer represents reality. If one class rises suddenly, a price list, catalogue, template or integration may have changed.

## Turn repeated exceptions into improvement

Not every exception should be automated. Some reveal an upstream problem that should be removed: obsolete references in a customer's catalogue, commercial agreements not recorded or inconsistent master data. Resolving them faster may hide the cause.

Periodic review assigns one of three destinations. A stable, low-risk exception becomes an automatic rule. An exception caused by bad data produces a correction in the source system. An infrequent, high-judgement exception remains human but arrives with better context.

That improvement cycle is one reason to contract an operation rather than a one-off implementation. The system evolves with the process, and its metrics identify where the next effort belongs.

## Frequently Asked Questions

### Which order exceptions should be automated first?

Frequent, well-defined and low-risk ones: approved product mappings, unit normalisation or differences inside an explicit tolerance. Cases affecting credit, margin or major commitments usually require approval until sufficient evidence exists.

### Does an exception mean the agent failed?

No. It can mean the order lies outside the normal path and the system detected that correctly. Failure would mean hiding it, resolving it without authority or escalating without enough context.

### Who should own the rules?

The business owner of the process. Technology can implement them and Arkatai can maintain their execution, but prices, tolerances, credit and commitments remain business decisions.

### How do we stop every approval becoming a dangerous new rule?

Separate one-off authorisation from policy change. New rules require an owner, scope, review and effective date; they are never inferred automatically from an isolated reply.