---
title: "Two for One: When Approvals Cost More Than They Protect"
description: "Why approval chains only grow — and two levers: put a price on every approval, and approve the pattern instead of the individual case."
image: https://blog.noreja.com/hubfs/blog/featured-images/.png-Aug-28-2026-07-39-57-5591-AM.png
---

[Skip to content](https://blog.noreja.com/en/when-approvals-cost-more-than-they-protect#main-content)

![](https://blog.noreja.com/hs-fs/hubfs/blog/featured-images/.png-Aug-28-2026-07-39-57-5591-AM.png?width=1820&height=1024&name=.png-Aug-28-2026-07-39-57-5591-AM.png)

Two-For-One GenAI BPM

# Two for One: When Approvals Cost More Than They Protect

![Lukas Pfahlsberger](https://app.hubspot.com/settings/avatar/6b6ceb34347ba3ac2667e67af4e9f63f)

 Lukas Pfahlsberger

October 6, 2026

Nobody ever got into trouble for adding an approval step. That asymmetry — invisible cost on one side, visible blame on the other — is why approval chains only ever grow. Every incident produces a new sign-off; no incident ever produces the removal of one.

## Why Approval Chains Grow but Never Shrink

An approval exists to prevent a specific kind of mistake, and most controls started as a sensible answer to something that actually went wrong. What makes them accumulate is that the decision to add one and the decision to keep one are made under completely different conditions.

Adding is cheap and defensible. Something went wrong, an additional pair of eyes is proposed, and nobody in the room can argue against caution without sounding careless. The cost of the new step — a day or two of waiting, multiplied by every case that will ever pass through it — is spread thinly across a future nobody is accountable for.

Removing is expensive and exposed. The saving is diffuse and hard to attribute, while the risk is concrete and personal: if anything goes wrong after you removed a control, it was your decision. So even approvals that have not caught a single error in three years stay in place, because keeping them costs the individual nothing.

The result is a control layer that reflects the organisation's accident history rather than its current risk profile. Approvals designed for a different volume, a different system landscape and a different set of failure modes are still applied to every case, including the majority that are entirely routine. Two levers change this without anyone having to gamble on removing a safeguard blind.

## When Waiting for Sign-Off Becomes the Process

There is a threshold past which the approval layer stops being an attribute of the process and becomes its dominant feature. It is recognisable in how people talk about their work: cases are described as "with the manager" or "waiting for finance" rather than by what is actually being done to them. Status means position in a queue of approvers.

The numbers show it too. In many administrative processes the work itself accounts for a small share of elapsed time and the waiting between steps for most of it. A purchase requisition that takes eleven days from request to order rarely contains eleven days of effort — it contains a couple of hours of work and a great deal of sitting in inboxes. The process is not slow because people are slow; it is slow because it consists mostly of pauses.

The organisational adaptations that follow are the real tell. People pre-warn approvers by chat so the formal request is not the first they hear of it. They batch requests to stay under one threshold, or split them to stay under another. They learn who approves quickly and route work accordingly. Urgent cases get escalated around the chain entirely — the pattern we examined in the edition on [when escalation becomes the default way to get things done](https://blog.noreja.com/en/when-escalation-becomes-default-way-to-get-things-done?hsLang=en). Each of these is a rational response, and each one quietly removes exactly the oversight the chain was built to provide.

## The Hidden Costs of Approval by Default

The obvious cost of an approval is the approver's time, and it is the smallest one. Reviewing a routine request takes minutes. The expensive effects are elsewhere.

The first is elapsed time, and it compounds. Each approval adds not a review but a queue, with its own arrival pattern, holidays and priority order. Three sequential approvals of one day each rarely cost three days — they cost a week, because the delays interact. Everything downstream inherits it: the supplier quotes later, the campaign launches later, the customer waits longer.

The second is the quality of the approval itself. An approver handling forty routine requests a week cannot examine each one meaningfully, and stops trying. Approval becomes acknowledgement. This is the paradox at the centre of the problem: the more cases a control covers, the less real scrutiny each case receives — so a chain built for safety ends up producing documentation of oversight rather than oversight.

The third cost is where it lands hardest: the decisions people quietly stop making. When a small purchase requires three signatures, teams find ways not to need one — using the tool they already have, deferring the fix, absorbing the workaround. That never appears in a report, and it is usually the largest cost of an over-approved process.

It is worth stating the diagnosis precisely, because it determines the remedy. Nobody in this system behaves unreasonably. The approver is diligent, the requester is compliant, the manager who added the control was responding to a real incident. The failure is structural: the organisation has no mechanism that prices approvals, so they are only ever added. Fix the mechanism and the same people produce a different chain.

## Two Practical Levers

The first lever makes the cost of each control visible, so that keeping it becomes as deliberate a decision as adding it. The second changes what gets approved — the pattern instead of the individual case — so that oversight survives while the waiting disappears.

### Lever 1: Put a Price on Every Approval

Most organisations know what their approvals cost in reviewer time and nothing else. The numbers that matter are different: how much elapsed time each approval adds, and how often it changes the outcome.

Both are available. The timestamps in your ERP, workflow or ticketing systems record when each case entered a step and when it left, so waiting time per approval can be measured rather than estimated. Process mining assembles that into a picture of the real chain — including the approvals that officially exist but are skipped in practice, and the ones nobody remembers introducing. Platforms such as [noreja](https://topai.tools/t/noreja) add the causal layer, which matters when an approval's delay depends on who happens to be in the loop.

The second number is the decisive one: the rejection or modification rate. For each step, how often does the approver actually change something? A control that alters two percent of cases is doing real work. One that has approved everything for two years is not a control; it is a queue with a signature at the end. That is not an argument to delete it blindly — some approvals exist for regulatory reasons and stay regardless — but it turns an emotional debate into a factual one.

Publishing both numbers changes behaviour before anything is removed. When a team can see that a particular sign-off adds two and a half days on average and has never once altered an outcome, the conversation about it becomes possible. Without those numbers, every proposal to remove a control is a matter of nerve rather than evidence — and nerve reliably loses.

### Lever 2: Approve the Pattern, Not the Case

The second lever dissolves the apparent choice between control and speed. Case-by-case approval is only one way to exercise oversight, and for routine work it is the most expensive one available.

The alternative is to approve the rule in advance and inspect afterwards. Define precisely what a standard case looks like — value below a threshold, known supplier, budget already allocated, no special conditions — and let those cases proceed without a signature. Oversight moves to a sample: a monthly review of a randomly drawn set, plus every case that falls outside the defined pattern. The approver's attention shifts from confirming the obvious to examining the unusual, which is the only place their judgement adds anything.

Two things make this honest rather than cosmetic. The boundary must be specific enough that nobody has to interpret it — a number, a supplier list, a budget line, not "low risk". And the sample review must actually happen, with a named owner and a fixed rhythm; otherwise you have not moved the control, you have removed it. When a sample turns up something wrong, the answer is to tighten the boundary, not to reinstate case-by-case approval for everything.

Start with one process and one threshold, measure the effect on elapsed time and on error rate for a quarter, and let the result decide whether to widen it. That evidence also protects the person who made the change — which matters, because the asymmetry described at the start is what keeps chains growing. What this does to a procurement process in numbers, we showed in the business case on [fixing slow procurement approvals](https://blog.noreja.com/en/fix-slow-procurement-approvals?hsLang=en).

The principle to test both levers against: an approval that has never changed an outcome is not protecting you from risk — it is protecting someone from responsibility.

## Food for Thought

For your most-used approval step: how many cases did it reject or alter in the last twelve months?

How much of your process's elapsed time is work and how much is waiting for a signature — do you know the split, or only suspect it?

Which approvals in your organisation were added after a specific incident that could not happen again today?

What would have to be true for a routine case to move through your process without any signature at all?

Who is allowed to remove a control, and what evidence would they need to feel safe doing it?

Which decisions are your teams quietly avoiding because getting them approved is not worth the effort?

## Conclusion: Make Removing a Control as Deliberate as Adding One

Approval chains do not grow because anyone wants bureaucracy. They grow because adding is cheap and visible while removing is expensive and exposed, and because nothing in the system prices what a control costs. The fix is not a purge — some approvals earn their delay many times over. It is to measure what each one costs in waiting time and how often it changes an outcome, then to move routine work from case-by-case sign-off to a defined pattern with sampled oversight. Do that, and you get the combination the trade-off seemed to forbid: less waiting and more actual scrutiny, because attention finally sits where the risk is.

[Contact us](https://outlook.office365.com/book/Kennenlernen@noreja.com/?ismsaljsauthenabled=true)

## FAQ

#### Why do approval processes keep growing?

Because adding and removing a control are decided under different incentives. Adding one is cheap, defensible and follows visibly from an incident. Removing one produces a diffuse saving but a concrete personal risk. With no mechanism that prices what an approval costs in elapsed time, the chain only ever accumulates.

#### How do you know whether an approval is still needed?

Two numbers answer it: the waiting time the step adds, measured from system timestamps, and how often the approver actually rejects or modifies something. A step that has altered nothing in two years and adds days of delay is a queue with a signature. Regulatory approvals stay regardless — but they should be identified as such, not assumed.

#### What does it mean to approve the pattern instead of the case?

Defining precisely what a standard case looks like — value threshold, known supplier, allocated budget, no special conditions — and letting those cases proceed without individual sign-off. Oversight moves to a random sample plus every case outside the pattern, so the approver's attention goes to the unusual rather than to confirming the obvious.

#### Doesn't removing approvals increase risk?

Not automatically, and keeping them does not automatically reduce it. An approver reviewing forty routine requests a week cannot scrutinise each one, so broad coverage often produces documentation of oversight rather than oversight. Concentrating attention on outliers and samples usually catches more, provided the sample review really happens and has a named owner.

#### How does process mining help with approval bottlenecks?

It reconstructs the actual approval chain from existing timestamps, showing how long each step waits, which approvals are skipped in practice, and which variants exist. That replaces assumptions about where the delay sits with measurements — including the approvals nobody remembers introducing and which appear in no documentation.

## Share this post

<https://www.facebook.com/sharer/sharer.php?u=https%3A%2F%2Fblog.noreja.com%2Fen%2Fwhen-approvals-cost-more-than-they-protect><https://twitter.com/intent/tweet?url=https%3A%2F%2Fblog.noreja.com%2Fen%2Fwhen-approvals-cost-more-than-they-protect><https://www.linkedin.com/shareArticle?mini=true&url=https%3A%2F%2Fblog.noreja.com%2Fen%2Fwhen-approvals-cost-more-than-they-protect><https://pinterest.com/pin/create/button/?url=https%3A%2F%2Fblog.noreja.com%2Fen%2Fwhen-approvals-cost-more-than-they-protect>[mailto:https%3A%2F%2Fblog.noreja.com%2Fen%2Fwhen-approvals-cost-more-than-they-protect](mailto:https%3A%2F%2Fblog.noreja.com%2Fen%2Fwhen-approvals-cost-more-than-they-protect)

## Keep reading

### [![](https://blog.noreja.com/hs-fs/hubfs/blog/featured-images/.png-4.png?width=1820&height=1024&name=.png-4.png) Quick Tips GenAI BPM Quick Tips: Turning Implicit Knowledge Into Process](https://blog.noreja.com/en/turn-implicit-knowledge-into-processes?hsLang=en)

### [![](https://blog.noreja.com/hs-fs/hubfs/blog/featured-images/.png-3.png?width=1820&height=1024&name=.png-3.png) GenAI BPM Process Intelligence Business Case: How to Cut Customer Onboarding Time](https://blog.noreja.com/en/cut-customer-onboarding-time-saas?hsLang=en)

[![noreja\_logo\_white](https://blog.noreja.com/hs-fs/hubfs/noreja_logo_white.png?width=300&height=78&name=noreja_logo_white.png "noreja_logo_white")](https://blog.noreja.com/?hsLang=en)

<https://www.linkedin.com/company/noreja/>

[Privacy Policy](https://noreja.com/en/privacy) · [Legal](https://noreja.com/en/imprint) · © 2026 Noreja. All rights reserved.

```json
{
  "@context" : "https://schema.org",
  "@type" : "BlogPosting",
  "author" : {
    "@type" : "Person",
    "name" : "Lukas Pfahlsberger",
    "url" : "https://blog.noreja.com/en/author/lukas-pfahlsberger"
  },
  "dateModified" : "2026-10-06T07:00:01.269Z",
  "datePublished" : "2026-10-06T07:00:00.000Z",
  "headline" : "Two for One: When Approvals Cost More Than They Protect",
  "image" : [ "https://blog.noreja.com/hubfs/blog/featured-images/.png-Aug-28-2026-07-39-57-5591-AM.png" ],
  "mainEntityOfPage" : {
    "@id" : "https://blog.noreja.com/en/when-approvals-cost-more-than-they-protect",
    "@type" : "WebPage"
  },
  "publisher" : {
    "@type" : "Organization",
    "logo" : {
      "@type" : "ImageObject",
      "url" : "https://blog.noreja.com/hubfs/noreja_logo_white-1.png"
    },
    "name" : "Noreja Intelligecne GmbH"
  }
}
```