Process exceptions: the path nobody logs
Your team adopted the system and the process still is not followed. The usual reason is an exception path: the shortcut built for the case the design never anticipated. It shows up in no report, because it happens outside the system, and it grows without anyone deciding that it should.
Why does a team build a parallel path after go-live?
Because the design covers the average case and the operation has cases that do not fit it. A client asks for different terms. A supplier delivers off spec, or the approver is traveling in the week of the close. When the only alternative is to stop, somebody handles it outside the system.
This is rarely indiscipline. The operation is patching a design gap with whatever is at hand, which tends to be a conversation, a spreadsheet, or a manual entry made afterwards. The person doing it usually believes they are protecting the process.
The problem shows up the second time. The first time was a deliberate decision by someone. By the tenth, it has become the normal way to handle that type of case, and nobody ever decided it would be. This is why measuring real system usage after go-live tells you more about adoption than asking the team whether they are using it.
Is the shortcut actually faster?
Almost never. It is faster at the moment of the decision and more expensive across everything that follows.
The clearest evidence is a conformance study by Negin Maddah, of Northeastern University, covering the first eight months of an ERP at a food manufacturer. It looked at 10,160 procurement cases across 41 business units. Only 55% followed the flow designed at implementation, though that count includes cases that were still open. Excluding incomplete cases, 1,130 violated the flow.
Those 1,130 cases took an average of 38.7 days longer to close than conforming ones, which closed in 13.4 days, and moved through 4.1 more steps. The shortcut added distance, not savings.
That number needs context. It is one company, one sector, and the work is a preprint with no peer review yet, produced with software access granted by a process mining vendor. It does not measure your operation. It shows the direction of the effect, and the direction contradicts the exact justification used to open the exception.
Why does the exception never appear in a report?
Because the record is a step on the official path. Leaving the path means leaving the record.
An order released over the phone exists in the operation and does not exist in the database. Six months later, the question "how many orders went out beyond the approval limit, and who authorized each one" has no answer, because the information was never captured anywhere.
Most of the exceptions in your operation have nothing to do with fraud. But the invisibility mechanism is the same, and in occupational fraud it has already been measured.
Occupational Fraud 2026, from the ACFE, analyzed 2,402 cases investigated across 143 countries: more than half involved either a lack of internal controls or an override of controls that already existed. The median scheme ran for 12 months before detection. When detection came within the first six months, the median loss was US$ 40,000. When it took more than five years, it passed US$ 1.1 million.
The loss scale there belongs to fraud, not to your exception list. What transfers is the time curve: the later the record appears, the bigger the total nobody can see.
The way the information comes back repeats too. In the ACFE sample, 43% of discoveries came from a tip, the most frequent detection method, and more than half of those tips came from employees. A meaningful share of what a company learns about its own process arrives because someone spoke up, not because the system showed it.
Look at where that weakness concentrates. KPMG's material weakness study, built on Audit Analytics and SEC filings, found that 238 of the 3,307 annual reports filed in FY'25 disclosed a material weakness. In 98% to 100% of them, at least one root cause was a lack of documentation, policy or procedure, a share that has held in four of the last five years. Weaknesses tied to IT, software, security and access climbed from 31% of cases in 2021 to 58% in 2025. Those are the layers an exception path leans on. The overlap is our reading, not the study's conclusion.
How do you measure a path that is not recorded?
You measure its edges. Four readings give you the size without asking anyone to start logging anything new.
The first reading is volume. Count the cases that reached the end without passing through a mandatory step. If the step is recorded, its absence is already a fact sitting in your database today.
The second is recurrence by type. Group exceptions by reason. A reason that shows up every week is not an exception; it is a missing rule.
Then comes authorship. Every exception had someone who authorized it. If that name is nowhere, the failure is in the design.
The last one is time. Compare how long cases that left the flow took against those that stayed in it. This tends to be the reading that surprises the board. To build the comparison without instrumenting anything new, the audit logs your system already writes are usually enough.
What this looks like in a real operation
The scenario below is hypothetical and exists to show the mechanism. Its numbers are not a measurement of any client.
A regional distributor has a credit limit per customer configured in the system. An order above the limit is blocked. The rule works well until the Friday a long-standing customer needs a delivery and sits US$ 4,000 over the limit. The sales rep calls the sales manager, the manager approves by message, and billing releases it manually in the back office.
Nothing wrong happened there. The manager has the authority for that decision and the decision was sound.
What went wrong is the trail. The system records a released order, with no field saying an exception occurred, no name of who authorized it, no reason. When that sequence repeats for a year, the company carries a volume of credit granted outside policy that nobody can total, and the memory of it lives in three phone conversations.
The board finds out the day one of those customers stops paying.
What to design when the exception is legitimate
The answer is not to close the door. Legitimate exceptions exist in any operation, and banning them only pushes the case further away from the system.
What changes is their status. The exception stops being the absence of the process and becomes a path within it, with its own screen, an approver field, a reason picked from a fixed list, and a deadline. Free-text reasons do not work, because free text cannot be counted.
From there the exception list becomes an input to decisions. A reason that repeats gets promoted to a rule, and the system starts handling that case on its own. A reason that shows up twice a year stays an exception, and that is fine. A reason that shows up every week, always with the same approver, is usually pointing at an approval bottleneck, not at a hard case.
It is the same logic behind the document management system at Repap On, where the process design determines how a document moves, instead of the document moving first and the process being discovered afterwards.
A quarterly review of the list is enough. Nobody needs to drive exceptions to zero. You just need to know how big the path is.
Frequently asked questions
My team resists change. Will formalizing the exception create more resistance?
It usually creates less. Resistance appears when a change removes the way out and offers nothing in its place. Formalizing the exception does the opposite: it acknowledges that the hard case exists and gives it a place inside the system. What teams reject is being forced to pretend every case is the same.
I cannot measure this. Where do I start?
With one process and one mandatory step. Count how many cases reached the end without it in the last ninety days. If the step is recorded, that number is already in your database and nobody had to fill in anything new for it to appear.
Designing the exception does not remove the bottleneck that created it. Am I right?
You are. Designing the exception does not solve the bottleneck; it makes it countable. The exception list grouped by reason is your operation's bottleneck queue ordered by frequency, which is a better basis for prioritization than the perception of whoever complains loudest.
The next step
If your operation lives with an exception path nobody can size, an Operational Architecture Diagnostic is a 30-minute conversation about where it started and what it costs you today. Book the diagnostic.
Related case studies
Did you recognize your operation in this article?
Book the Operational Architecture Diagnostic: 30 minutes to map where your operation's bottleneck is. No proposal in the first conversation.
Book a diagnostic