Who Owns an Exception After the Agent Finds It?

Faster Detection Leaves an Operating Question#

KTern.AI reports that its SAP agents surface 90% of exceptions across finance, controlling, sales, and materials workflows. The examples include unmatched invoices, blocked purchase orders, open credit memos, and billing exceptions.

The case study presents that detection as support for resolving issues before they affect the business. It does not say that exceptions were left unresolved, or that KTern.AI lacked an ownership structure.

It does raise a practical question for any team building a similar system: once detection becomes faster and more complete, who is expected to decide what happens next?

Detection and resolution are separate operations#

An agent can identify an unmatched invoice without having the authority or context to resolve it. The next decision may sit with accounting, procurement, the budget owner, or a vendor manager. Which one is correct depends on the exception and the business around it.

That distinction is easy to miss during implementation. Detection accuracy is measurable, so the team concentrates on whether the agent found the right cases. Resolution crosses roles and systems, which makes it less convenient to test.

The result does not have to be a queue of abandoned exceptions. A well-designed deployment may already have mature resolution workflows. The point is that those workflows need to be designed and tested independently of the agent's ability to detect a problem.

Map the receiving operation#

Before increasing detection volume, list the exception classes the system can produce. For each one, record:

• the person or role responsible for the first decision;
• the evidence that person needs;
• the action that counts as resolved;
• the time allowed before escalation; and
• the next owner when the first owner cannot decide.

Use a role only when someone is actually assigned to it. “Finance” is a destination, not an accountable owner.

This map also exposes exceptions that should not yet be automated. If the team cannot describe the decision path for a blocked purchase order, detecting it more quickly will not fix that ambiguity.

Measure more than exceptions found#

A detection metric answers whether the agent is doing its part. It does not show whether the operation is closing the work.

Add measures that cover the rest of the path: time to first review, time to resolution, reopen rate, volume by exception class, and the share that breach their escalation window. Those measures reveal whether the bottleneck has moved downstream.

If one class grows faster than the team can resolve it, there are several legitimate responses. The business can add capacity, automate a safe part of the resolution, narrow the detection scope, or explicitly accept the risk. Each is a management decision. None can be made cleanly while ownership remains vague.

Test the handoff before production#

A useful pre-production test is not only “did the agent find the exception?” It is also:

1. Did the right owner receive it?
2. Did the record include enough context to decide?
3. Could the owner record a resolution?
4. Did an overdue case escalate to the right person?

Run the test once for every materially different exception class. An invoice mismatch and a credit memo may share an interface while requiring different evidence, authority, and deadlines.

KTern.AI's case shows what becomes possible when agents can surface operational exceptions at scale. The implementation lesson for other teams is to build the receiving operation with the same care as the detection system.

Faster detection is useful. Faster detection connected to clear ownership and a tested resolution path is an operating capability.

---

Acrein Group designs agent workflows together with the human decisions, escalation paths, and evidence records around them.