How Much Does One Process Exception Cost?

A process looks simple until the first “yes, but” appears in its description. An order arrives, the system checks it, and sends it for processing. Yes, but sometimes the project number is missing. Except when the customer is new. And occasionally a colleague handles it manually.

Those sentences often hide most of the cost of automation.

The Happy Path Is the Cheap Part #

The happy path is the ideal flow: all data is valid, every system responds, and each decision has an unambiguous outcome. It looks good on a presentation slide and is often relatively easy to implement.

Real operations, however, do not supply only ideal inputs. They produce incomplete data, duplicates, unknown formats, delayed responses, and cases that people decide using context. An automation must know what to do with them—or at least fail safely when it does not.

This is why two companies can automate what appears to be the same process and receive very different estimates. One has five clear rules. The other has five rules and thirty ways around them.

An Exception Is Not One ‘if’ Statement #

An exception may sound harmless in a requirement: “If the amount does not match, notify accounting.” The finished solution still has to answer several more questions:

• How does the system detect the mismatch?
• What difference is still acceptable?
• Who should be notified, and through which channel?
• What happens to the case while it is waiting?
• How does the process resume after a human decision?
• What happens if nobody responds?
• Where is the decision recorded for a future audit?

One condition has turned into a small process of its own, with states, permissions, notifications, history, and failure modes.

A useful mental model is therefore:

Cost of an exception = detection + decision + handling + recovery + oversight + testing + maintenance

This is not a formula for calculating a price in euros. It is a checklist of work that a rough estimate can easily miss.

Not All Exceptions Are Alike #

The distinction between technical and business exceptions matters.

A technical exception occurs when the process knows what it wants to do but cannot do it: an API does not respond, a database is unavailable, access has expired, or a file cannot be opened. Retrying may solve a temporary failure, but eventually the process must stop, log the error, and notify the responsible person.

A business exception occurs when the systems work but there is no unambiguous decision: a supplier has not been approved, an amount exceeds a limit, or an invoice has no matching purchase order. A retry will not help. The process needs a rule, more data, or a person with the authority to decide.

Microsoft’s official guidance on error handling in Power Automate likewise treats alternative paths, retries, logging, and notifications as separate concerns. Reliability does not come from adding one condition; it comes from designing the entire behavior after something goes wrong.

The Invoice That Stopped Being Simple #

Consider an automated incoming-invoice process:

Invoice arrives → supplier exists → purchase order exists → amount matches → post the invoice.

Now add three exceptions.

A Required Field Is Missing #

The system rejects the invoice and sends a prepared message. Detection is simple, the response is unambiguous, and the case does not need to wait in an internal state. This exception may be relatively inexpensive.

The Amount Does Not Match the Purchase Order #

A difference within a defined tolerance may be accepted; anything larger needs approval. The system must now compare data from two sources, track the approval state, identify the approver, send a notification, and process the decision.

The Amount Does Not Match, but Context Matters #

The outcome depends on the project type, framework agreement, supplier, and previous correspondence. What looked like one exception now requires access to more systems, new rules, and perhaps a user interface. Handling it may be larger than the original automated flow.

An exception therefore has no fixed unit price. It costs as much as the additional world the system must understand to resolve it safely.

Combinations Grow Fastest #

The number of exceptions alone does not tell the whole story. What matters is whether they can occur together and change one another’s outcome.

What should the system do if the supplier is unknown, the purchase order is missing, and the amount also exceeds a limit? Is one shared manual queue enough, or does each issue have a different priority and approver? Perhaps some checks should stop after the first failure. Perhaps the system should collect every problem and report them all at once.

Every decision branch adds paths that must be implemented and verified. Software engineering has a related concept called cyclomatic complexity. The NIST structured-testing methodology uses independent control-flow paths to guide testing. It is not a pricing formula for business processes, but it explains why another branch is more than another line of code: it is another scenario that can fail.

Good Automation Does Not Have to Cover Everything #

Trying to automate one hundred percent of cases is often expensive and sometimes unsafe. The last few unusual situations may require a disproportionate number of rules even though they occur only a few times a year.

A sensible design can be simpler:

The system handles routine cases. It safely stops ambiguous ones, collects the relevant information, and hands them to a person.

That is not an automation failure. It is a deliberate division of labor based on where machines and people are more economical and reliable.

There are three options for every exception:

1. Automate it when it is frequent, easy to detect, and governed by stable rules.
2. Remove its cause, for example with a required field, validation at entry, or standardized formats.
3. Hand it to a person when it is rare, ambiguous, or carries a high cost of a wrong decision.

The cheapest exception is often the one that no longer occurs after the process is improved.

What to Learn Before Estimating the Project #

Process analysis cannot stop at the ideal flow. At every step, ask: “What can happen differently here?” Then examine each answer through a few practical questions:

This list is more useful than saying a process has ten steps. Ten linear steps may be simpler than three steps that each begin with “it depends.”

The Most Expensive Phrase Is “Sometimes We Do It Differently” #

The cost of automation is not determined only by what the system does on an ordinary day. It is determined mainly by what it must do on an unusual day—and how safely it can return to normal.

Before automating a process, we should therefore ask not only “How does it work?” but, above all, “What can happen differently?” The answers reveal which exceptions are worth implementing, which should be eliminated by changing the process, and which are better left to a person.

In the end, an exception costs as much as the new decision-making, additional paths, and future care we create because of it.

Sources and Further Reading #

• Microsoft Power Automate: Employ robust error handling
• NIST: Structured Testing: A Testing Methodology Using the Cyclomatic Complexity Metric