What is a delegation of authority matrix?

A published table of approval thresholds showing which value bands require which approvers. A complete one also names the escalation path, the delegate for each approver and a target cycle time per band.

How long should CapEx approval take?

There is no universal figure, which is why the useful approach is setting your own target per authority band and measuring against it. Local decisions in a couple of days and material projects inside two weeks are reasonable starting points. Macmahon Holdings moved from five to six weeks down to under one week.

What is the difference between an approver and a reviewer?

An approver can reject the request and carries accountability for the decision. A reviewer provides input but cannot stop it. Reviewers sitting in the approval chain add queue time without adding control, so they are better served by a notification.

What happens when an approver is unavailable?

Without a named delegate, the request usually stops until they return. Every approver should have a delegate at the same authority band, with delegation activating automatically on absence and every delegated decision logged as delegated.

How do you set CapEx approval thresholds?

Sort the last twenty-four months of approved capital by value, find where the cumulative value concentrates, and set the top band there so the Investment Committee sees the projects carrying the money rather than the projects making up the count. Set the bottom band so routine capital clears locally, then check the item count in each band is small enough to be discussed properly.

CapEx Approval Workflow: How to Design One That Holds Up

Every capital project in your organization passes through the approval chain. It's the one control that touches all of them, the place where authority is actually exercised, and in most organizations it's the part nobody sat down and designed. It accumulated. Someone was added after an audit finding, a threshold was set in a policy nobody has reopened since, and a step that made sense at four sites is still running at forty.

The result is a process that people describe as slow while being unable to point at anyone who was slow. That's the tell. Approval delay is almost never a performance problem, and treating it as one produces reminder emails rather than results.

This guide covers how to design the chain itself: where to set thresholds, how to route, what to do about absent approvers and how to hold the whole thing to a cycle time you actually chose.

What is a CapEx approval workflow?

A CapEx approval workflow is the defined sequence a capital request moves through from submission to authorized spend. It sets who reviews, who approves, in what order and under what authority, and it records the decision in a form that survives an audit two years later.

The document moving through it is usually an Authorization for Expenditure, and what belongs inside one is a separate question with a settled answer. This guide is about the chain it travels, which is the part that tends to be improvised.

Three things separate a workflow from a routing rule. It carries authority, meaning an approval at each step says something specific about who is accountable. It's traceable, meaning you can reconstruct who decided what and when. And it's bounded in time, or at least it should be, which is where most of them fall down.

Why approval chains get slow without anyone being slow

Here's the arithmetic that explains most of it.

Take a request that needs five approvals. Each approver is reasonable, responds within four working days, and considers the request properly when they open it. Nobody is negligent. The chain takes twenty working days, which is a month of calendar time.

The actual work in an approval is often under half an hour. Read the case, check it against the budget, decide. Everything else is queue: the request sitting in an inbox waiting for someone to reach it. A sequential chain adds queue time at every handoff, and queue time compounds while work time does not.

That has two consequences worth sitting with. Adding one approver to a five-step chain doesn't add a decision, it adds four days. And chasing individual approvers, which is what most organizations do, attacks the smallest component of the delay.

The fix is structural. Shorten the chain, run in parallel what doesn't need to be sequential, and put a clock on each step.

How to set delegation of authority thresholds

Most guidance on approval workflows says thresholds should be defined in policy and stops there. Here's a method for deciding where they go.

Step 1. Pull the last twenty-four months of approved capital Sort it by value, highest first.

Step 2. Find where the money concentrates In most asset-intensive organizations a small share of projects carries most of the value. Note the point in the sorted list where the cumulative total reaches roughly eighty percent.

Step 3. Set the top band there The Investment Committee should see the projects carrying most of the money, not the projects making up most of the count. If your top band currently produces forty items a quarter, the committee is reviewing volume rather than exercising judgement.

Step 4. Set the bottom band so routine capital never reaches the centre Site-level replacements and small asset purchases should clear locally. Every one that travels to head office costs more in cycle time than the decision is worth, and it teaches people that the process is an obstacle.

Step 5. Check the count per band, not just the value A band is badly set if the number of items in it can't be discussed properly in the meeting that owns it.

A workable shape looks like this. The specific numbers depend on your capital base; the structure is what transfers.

Band	What it should catch	Who approves	Target cycle time
Local	Routine replacement and small asset purchases	Site or department head	2 working days
Divisional	Standard projects inside the approved plan	Divisional finance and operations lead	5 working days
Executive	Material projects, or anything outside the approved plan	CFO or executive sponsor	10 working days
Investment Committee	The projects carrying most of the capital, and anything strategically significant regardless of value	Investment Committee	Next scheduled sitting

Two rules keep the table honest. Anything outside the approved plan escalates a band regardless of value, because plan variance is a governance event rather than a money event. And the band is set by total project value, not by the current invoice, or people may split projects to stay under a line.

The approval latency budget

The column most delegation of authority matrices are missing is the last one.

An approval latency budget is a target number of working days for each band, published alongside the thresholds, measured on every request and reported when it's breached. It converts approval speed from an administrative complaint into a governance metric with an owner.

It works for the same reason variance reporting works. A number nobody reports is a number nobody manages, and days-in-queue is currently invisible in most organizations even though everyone can feel it.

Three things to get right when you set one up.

Measure queue time, not total elapsed time The clock should start when the request lands with an approver and stop when they act. Time spent with the requester answering a question is a different problem with a different fix.

Report breaches by step, not by project The point is to find the step that consistently runs long, which is usually a specific role rather than a specific person.

Set the target from your own data, then tighten it Take the current median for each band, set the target slightly below it and move it down as the structural fixes land. A target pulled from nowhere gets ignored.

Once the number is visible, the argument changes. An approval chain that takes six weeks stops being a shared frustration and becomes a measured six weeks of deferred return, which is a conversation an executive team can act on.

Weeks to days

Macmahon Holdings moved its AFE approval cycle from five to six weeks down to under one week. The case study covers what changed in the chain, not just the outcome.

Read the case study

Four design decisions that set your cycle time

Sequential or parallel

Sequential routing means each approver waits for the one before. It's correct where authority genuinely stacks, because a higher authority should be responding to a decision already made below.

Parallel routing means several people receive the request at once. It's correct for anything that is a check rather than an authorization: technical review, procurement input, compliance sign-off. These don't depend on each other, and running them in series buys nothing except delay.

Most chains are sequential by default rather than by design. Auditing which steps genuinely need to wait is usually the single largest cycle time reduction available, and it costs nothing to implement.

Approver or reviewer

A surprising number of people on approval chains have no authority to reject anything. They're there so they know what is happening.

Visibility is a legitimate need and it should be met with a notification rather than a signature. Every person in the chain who can't say no is pure queue time. Move them to informed, keep the record of who was notified, and the chain gets shorter without anyone losing sight of anything.

Delegation during absence

This is the failure mode nobody writes about and everybody experiences. One approver takes two weeks of leave, no delegate is named, and every request that reaches that step stops. The chain has no way to know the person is away, so nothing escalates. It just sits.

Four rules close it. Every approver has a named delegate at the same authority band. Delegation activates from a calendar absence rather than requiring the absent person to remember. Delegated authority is capped at the same band, never raised. And every delegated decision is logged as delegated, so the audit trail stays intact.

This is cheap to fix and it removes more delay than most process redesigns.

Exceptions and emergencies

Capital that can't wait exists. A failed asset, a safety issue, a regulatory deadline. If the workflow has no defined fast path, people don't wait patiently. They route around the process entirely, commit the spend and regularize it afterwards, which is considerably worse than a fast path would have been.

Design the exception deliberately: a named trigger, a shortened chain, a higher authority level rather than a lower one, and a mandatory review afterwards. An exception path with teeth protects the main process. The absence of one tends to guarantee the main process gets bypassed.

How to redesign your approval workflow

A practical sequence that doesn't require a transformation programme.

Step 1. Map the chain as it actually runs Not the policy version. Ask three requesters to walk you through their last submission, and count the steps.

Step 2. Measure the current median days per step This is the baseline for everything that follows, and gathering it usually settles the argument about where the problem is.

Step 3. Split approvers from reviewers Anyone who can't reject moves to notification.

Step 4. Parallelize every step that doesn't depend on the one before it Technical, procurement and compliance checks rarely need to wait for each other.

Step 5. Reset the thresholds Use the five-step method above, then check the resulting item counts per band.

Step 6. Name a delegate for every approver Make delegation automatic on absence rather than something the absent person has to remember.

Step 7. Publish the latency budget Report breaches by step in the same pack as capital variance.

Steps 3, 4 and 6 need no software and usually produce the largest single reduction. Step 7 is what stops the chain drifting back.

What a system has to enforce

Policy that depends on people remembering it degrades. If you're evaluating software to hold this together, the useful questions are about enforcement rather than features.

Does it enforce the delegation of authority, or just record it? Thresholds, escalation, delegation during absence and exception handling should be applied by the system. A configurable routing rule an administrator can bypass is documentation, not control.

Can it route in parallel and in series in the same workflow? Most real chains need both, and a tool that only does sequential routing locks in the delay you're trying to remove.

Does it timestamp every step? No latency budget is possible without per-step timing. Total elapsed time isn't enough.

Does the approval stay attached to the record afterwards? The authorization matters most eighteen months later, when somebody compares delivered outcomes to the case that was approved. An approval that lives in an email thread is an approval you may not be able to produce.

Does it hold the exception path? Emergency capital should follow a designed route inside the system rather than leaving it.

CapEx360 was built as a capital management system that carries the same record from request through authorization, commitment, forecast and post-investment review, which is the full capital lifecycle worth testing every vendor against.

Frequently asked questions

What is a CapEx approval workflow?: The defined sequence a capital request moves through from submission to authorized spend, setting who reviews, who approves, in what order and under what authority, with a record that survives audit.
What is a delegation of authority matrix?: A published table of approval thresholds showing which value bands require which approvers. A complete one also names the escalation path, the delegate for each approver and a target cycle time per band.
How long should CapEx approval take?: There is no universal figure, which is why the useful approach is setting your own target per authority band and measuring against it. Local decisions in a couple of days and material projects inside two weeks are reasonable starting points. Macmahon Holdings moved from five to six weeks down to under one week.
What is the difference between an approver and a reviewer?: An approver can reject the request and carries accountability for the decision. A reviewer provides input but can't stop it. Reviewers sitting in the approval chain add queue time without adding control, so they're better served by a notification.
What happens when an approver is unavailable?: Without a named delegate, the request usually stops until they return. Every approver should have a delegate at the same authority band, with delegation activating automatically on absence and every delegated decision logged as delegated.
How do you set CapEx approval thresholds?: Sort the last twenty-four months of approved capital by value, find where the cumulative value concentrates, and set the top band there so the Investment Committee sees the projects carrying the money rather than the projects making up the count. Set the bottom band so routine capital clears locally, then check the item count in each band is small enough to be discussed properly.

Where to go from here

The approval chain is the one control every capital project touches, which makes it the highest-leverage thing in capital governance to design deliberately. Most of the improvement available in it is structural rather than technological: shorter chains, parallel where parallel is safe, reviewers moved out of the critical path, delegates named, and a published number that makes delay visible.

If you don't currently know your median days-in-queue by approval step, that measurement is the place to start. It usually settles the question of what to fix first.

See how CapEx360 enforces delegation of authority, routing and approval cycle time across the full capital lifecycle.

Request a demo