CapEx Approval Process: Steps, Owners, Controls

CapEx Approval Process: Steps, Owners, Controls

2026-09-29 · Tommaso Maria Ricci

Bent Flyvbjerg's database of 16,000 large projects found that only 8.5% came in on budget and on time, and only 0.5% did that while also delivering the benefits promised in the business case. Most of those projects were approved by someone, through some kind of capex approval process. The problem is rarely that nobody signed. The problem is that the signature certified a number nobody had tested. This guide lays out a capex approval process that actually filters decisions: the steps, who owns each one, the thresholds that decide who signs what, the controls that stop the usual failures, and a 90-day plan to put it in place.

I write this as a founder who has had to both ask for capital and decide where it goes. The mechanics of capex approval look like finance plumbing. In practice they are one of the few places where strategy turns into money, and where a company either learns from its bets or repeats the same mistakes on a bigger scale.

What a capex approval process is for

Capital expenditure is money spent to acquire, build or significantly improve long-lived assets: equipment, facilities, vehicles, major software platforms. It is recorded on the balance sheet and expensed over time through depreciation or amortization, instead of hitting the income statement all at once.

The scale is large. According to the U.S. Census Bureau's Annual Capital Expenditures Survey, U.S. nonfarm companies with employees invested $1,681.7 billion in new and used structures and equipment in 2022, the latest year in that release. At the company level, capex is often the largest discretionary decision a leadership team makes in a given year.

A capex approval process exists to do three things, and most companies only do the first:

  1. Authorize spending, so that nobody commits the company to a large, multi-year cost without the right person agreeing.
  2. Filter and rank requests, so that limited capital goes to the projects with the best risk-adjusted return and the tightest fit with strategy.
  3. Create accountability after the fact, so that the people who promised a return are asked, a year later, whether it arrived.

If your process stops at authorization, it is a signature workflow. Useful for audit, useless for capital allocation.

CapEx vs OpEx: where the process starts

Before any approval question, someone has to decide whether a request is capital at all. That decision has accounting, tax and behavioral consequences.

Accounting. Under U.S. GAAP, property, plant and equipment is capitalized and depreciated; under IFRS the equivalent standard is IAS 16. Internal-use software follows ASC 350-40, which the FASB overhauled with ASU 2025-06: the old three-stage model is gone, replaced by a threshold where capitalization starts once management with the relevant authority has authorized and committed to funding the project and it is probable the software will be completed and used as intended. The new rules are effective for annual periods beginning after December 15, 2027, with early adoption permitted.

Notice the first condition. Under the new standard, the capex approval itself becomes part of the accounting trigger. A sloppy approval trail for software projects is no longer just a governance issue; it muddies when capitalization begins.

Tax. In the U.S., the IRS de minimis safe harbor lets businesses deduct tangible property purchases up to $2,500 per invoice or item, or $5,000 for taxpayers with an applicable financial statement, as described on the IRS tangible property regulations page. Many companies align their internal capitalization threshold with these figures, which is sensible, but it is a tax threshold, not a governance threshold.

Behavior. Once people know that capex and opex are approved through different channels, they start routing requests through whichever channel is easier. A team blocked on a capex request leases the same equipment as opex. A team with spare opex budget buys three items at $4,900 instead of one at $14,700. Your process has to anticipate this, which is why the controls section below includes split-purchase detection and a rule for leases.

A practical rule: define capex in one written policy that covers the capitalization threshold, useful-life minimums, the treatment of leases and software, and who decides borderline cases. Put the controller, not the requester, in charge of classification.

CapEx approval process steps and thresholds

Here is the process I recommend for companies between roughly $20 million and $1 billion in revenue. Smaller companies can collapse steps; larger ones add layers. The sequence stays the same.

Step 1: Annual capital plan

Capex approval starts before any individual request. Once a year, usually alongside the operating budget, leadership sets a capital envelope: the total amount the company is willing to invest, broken down by category.

A useful split has four buckets:

  • Maintenance: keeping existing assets running (replacements, mandatory repairs);
  • Compliance and safety: spending required by regulation or to remove a material risk;
  • Growth: new capacity, new locations, new products;
  • Strategic or transformation: bets that change how the business operates, including major technology platforms.

Each bucket gets a target share and its own hurdle. Maintenance requests are judged on necessity and cost; growth requests on return; strategic requests on option value and fit. Treating them with the same financial yardstick is how companies starve maintenance for years and then face an emergency replacement at double the price.

Step 2: Request and intake

A project owner submits a request through a single channel. The request is short at this stage: problem, proposed solution, rough cost range, bucket, and the sponsor who will be accountable for results. The goal is to kill weak ideas cheaply, before anyone spends two weeks on a spreadsheet.

Finance screens for completeness and classification (is this really capex?) and routes it to the right tier based on estimated cost.

Step 3: Business case

Requests that pass intake get a full business case. The quality of the whole capex approval process depends on this document, so the next section covers it in detail. The short version: a clear baseline, costs including everything that follows the purchase, benefits tied to measurable operating metrics, a range instead of a point estimate, and the explicit assumptions that would make the project fail.

Step 4: Finance review

The FP&A or corporate finance team reviews the case independently. Their job is not to make the numbers look better. It is to check the math, challenge the assumptions against historical data, standardize the discount rate and the evaluation horizon, and flag any hidden operating costs: licenses, maintenance contracts, headcount, energy, training.

Step 5: Tiered approval

Approval authority follows a delegation of authority matrix. Here is a template to adapt:

| Tier | Project cost | Required approvals | Typical turnaround |

|---|---|---|---|

| 1 | Below capitalization threshold | Budget owner (treated as opex) | Same day |

| 2 | Threshold to $50K | Department head + controller | 5 business days |

| 3 | $50K to $250K | Business unit leader + CFO | 10 business days |

| 4 | $250K to $2M | CEO + CFO, capital committee review | Next committee meeting |

| 5 | Above $2M or strategic | Board or board committee | Next board cycle |

The numbers are illustrative; scale them to your company. Three principles matter more than the exact thresholds:

  • Total project cost, not invoice cost. Tiers apply to the whole project over its life, including installation, integration, internal labor and the first years of maintenance.
  • Budgeted vs unbudgeted. A request that is inside the annual capital plan can move one tier lower. An unbudgeted request moves one tier higher, because it competes with what was already promised.
  • Turnaround commitments. Approvers commit to response times. A process that takes three months to approve a $40,000 machine teaches managers to avoid it.

Step 6: Release and procurement

Approval does not mean the money is spent. Once approved, the request gets a project code and a budget ceiling in the ERP, and purchasing starts through the normal procurement flow. This is where capex approval meets your procure-to-pay controls: purchase orders reference the approved project code, and the system blocks POs that would push the project over its ceiling.

For large or strategic purchases, the sourcing work itself deserves structure. The same logic described in a strategic sourcing process applies: define requirements, understand the supplier market, and negotiate total cost of ownership rather than the sticker price.

Step 7: Execution and change control

Projects change. Costs rise, scope shifts, timelines slip. The process needs a change request rule: any increase above a defined tolerance, for example 10% of approved cost or a fixed amount, goes back for re-approval at the tier that matches the new total. Without this, a project approved at tier 3 can quietly become a tier 4 project without anyone at tier 4 ever seeing it.

Step 8: Capitalization and close

When the asset is placed in service, the controller moves costs from construction in progress to the fixed asset register, assigns a useful life and starts depreciation. This step belongs in the month-end close: projects that sit in construction in progress for months after go-live distort both the balance sheet and depreciation expense.

Step 9: Post-investment review

Twelve to eighteen months after completion, the sponsor presents actual results against the business case: cost, timeline, and above all the benefits. This is the step most companies skip, and it is the step that turns capex approval from a gate into a learning system. It gets its own section below.

Who owns each step

A capex approval process fails when ownership is diffuse. Everyone reviews, nobody is accountable. Here is a clear allocation.

| Step | Owner | Contributors |

|---|---|---|

| Annual capital plan | CFO | CEO, business unit leaders |

| Request and intake | Project sponsor | Finance (classification) |

| Business case | Project sponsor | FP&A, operations, IT |

| Finance review | FP&A lead | Controller, tax |

| Approval | Tiered approvers | Capital committee |

| Release and procurement | Procurement | Project owner, AP |

| Change control | Project sponsor | FP&A, approver of original tier |

| Capitalization | Controller | Fixed asset accountant |

| Post-investment review | Project sponsor | FP&A, internal audit |

The single most important name in that table is the project sponsor. The sponsor is a senior person who owns the promised benefits, not just the delivery. If the project was justified by a 15% productivity gain, the sponsor is the person who explains, eighteen months later, whether the gain showed up.

The capital committee deserves a note. For companies with more than a handful of large projects a year, a monthly committee with the CEO, CFO and two or three operating leaders is the most efficient way to rank requests against each other. Approving projects one at a time, in isolation, makes every request look reasonable. Seeing them side by side reveals which ones are not.

The business case that approvers should demand

Most business cases are written to be approved. The approvers' job is to make them useful. In the Kahneman, Lovallo and Sibony article Before You Make That Big Decision in Harvard Business Review, published in 2011 but still the clearest treatment of the topic, the authors argue that leaders should review not only the proposal but the process and biases of the team that produced it. That idea translates directly into a capex template.

A business case worth approving has eight parts:

  1. Problem and baseline. What happens if we do nothing? Current cost, current capacity, current failure rate. Without a baseline there is nothing to compare against in the post-investment review.
  2. Options considered. At least three: do nothing, a minimal option, and the proposal. For technology, include the build, buy and partner options; the reasoning in this build vs buy decision guide applies to most software capex.
  3. Total cost of ownership. Purchase price, installation, integration, internal labor, training, maintenance, licenses, energy, disposal. Over the full useful life, not the first year.
  4. Benefits tied to operating metrics. Not "improved efficiency" but "units per hour from 140 to 165 on line 2" or "manual invoice handling time from 12 to 4 minutes". Every benefit gets an owner.
  5. Financial summary. NPV at the company's standard discount rate, IRR, payback period. Use the same horizon and the same rate across all requests, set by finance, so that cases are comparable.
  6. Range, not a point. A base case, a downside and an upside, with the assumptions that drive each. If the downside destroys value, say so.
  7. Kill criteria. The specific conditions under which the project should be stopped or re-scoped, decided upfront.
  8. Reference class. How did similar projects, inside or outside the company, perform against their original estimates?

The last point is the one Flyvbjerg's work is built on. His recommended method, reference class forecasting, asks planners to adjust their estimate using the actual outcomes of a class of similar past projects, instead of building the forecast only from the details of the current one. You do not need a 16,000-project database to use it. You need a list of your own last ten capex projects with approved cost, actual cost, approved timeline and actual timeline. Most companies can build that list in a week, and the average overrun it reveals becomes the default contingency for the next wave of requests.

Controls that stop the usual failures

Capex approval has a predictable set of failure modes. Each one has a control that addresses it.

Split purchases. A request is divided into smaller pieces to stay under a threshold. Control: aggregate requests by project code, vendor and time window, and flag clusters just below each tier limit. Most ERP and spend analytics tools can run this report monthly.

Leases used to bypass capex. A team that cannot get a purchase approved signs a multi-year lease or a service contract that delivers the same asset. Control: any lease or multi-year commitment above the tier 2 threshold goes through the same approval, based on total contract value.

Scope creep without re-approval. Covered above: a change control tolerance and re-approval at the tier of the new total.

Hidden operating costs. The capex looks affordable; the maintenance, licenses and headcount that follow do not. Control: the business case template requires opex for the full useful life, and finance signs off on the opex impact separately.

Approvals without evidence. An approver signs off in the system without reading the case. Control: approval workflows capture the version of the business case approved, and the capital committee minutes record the discussion for tier 4 and above.

No link to procurement. Approved projects are spent through channels that do not reference the project code. Control: POs for capital items require a valid project code, and the ERP blocks spending above the approved ceiling.

New suppliers without checks. Large capital projects often bring in new vendors: contractors, integrators, equipment makers. Control: new suppliers pass through a standard vendor onboarding process with tax, bank and sanctions verification before the first payment.

No post-investment review. Benefits are never measured, so optimistic sponsors keep winning. Control: the post-investment review is scheduled at approval, with a date, and the capital committee tracks completion.

The post-investment review: where capex approval pays off

If you implement only one improvement from this guide, make it this one.

A post-investment review compares what was promised with what happened. It is not an audit and not a blame session. It answers four questions:

  1. Did the project cost what we approved, and if not, why?
  2. Did it finish when we planned, and if not, why?
  3. Did the benefits arrive, at the level and on the timeline promised?
  4. What should we change in how we estimate, approve or execute the next similar project?

The fourth question is the reason to do it. Over two or three years, post-investment reviews produce the reference class your business cases need. They also change incentives. When sponsors know they will present actual results to the same committee that approved their request, business cases become more honest almost immediately.

Practical rules for making reviews stick:

  • Schedule it at approval. The review date goes into the approval record.
  • Keep it short. A one-page template: approved vs actual cost, timeline and benefits, plus three lessons.
  • Review a sample, not everything. Every tier 4 and 5 project; a rotating sample of tier 3.
  • Publish the lessons. A short annual summary of what the company learned about its own estimates.

The method is the same one I use on operating projects, whether the goal was taking a hotel from 9 to 10 million in revenue or increasing a medical center's capacity by 20%: define the operating metric the investment is supposed to move before the money is spent, and look at it again after.

If you want an outside view on how your capital decisions are currently made, and where the process is filtering and where it is only signing, you can reach out through the consultation request page on this site. The conversation starts from your last ten capital projects, not from a template.

CapEx approval for technology and AI projects

Technology projects break traditional capex processes in three ways, and AI projects amplify all three.

The cost moves to opex. Cloud platforms, SaaS licenses and AI model usage are mostly operating costs. A process that only reviews capex will miss the largest technology commitments the company makes. The fix is to route any multi-year technology commitment above a threshold through the same governance, whatever its accounting treatment.

Benefits are uncertain and staged. A new machine has a known throughput. An AI system that promises to automate part of customer service has a range of possible outcomes that only narrows after a pilot. For these projects, stage-gated approval works better: approve a bounded pilot with clear success metrics, then approve the scale-up based on pilot results. Each stage is a separate approval at its own tier.

Capitalization rules are changing. With ASU 2025-06, capitalization of internal-use software begins when management has authorized and committed funding and completion is probable. For companies that adopt the new standard, the approval record for the build phase becomes evidence for when capitalization starts. Coordinate with your controller so that the stage gates in your approval process line up with the accounting judgment.

A final point on AI specifically. Every vendor pitch now includes a productivity number. Treat those numbers exactly like an internal sponsor's forecast: ask for the reference class. How did this tool perform at companies similar to yours, measured by someone other than the vendor? If nobody can answer, the pilot is the reference class, and the pilot should be sized accordingly.

Emergency and maintenance capex: the fast lane

Every capex approval process needs a way to spend money quickly when something breaks. A compressor fails in August, a roof leaks over the server room, a regulator gives you thirty days to fix a safety issue. If the only path is the standard business case and the next committee meeting, people will find another path, and it will be less controlled than the one you designed.

The answer is an emergency approval route with three features:

  • Narrow definition. Emergency means an immediate risk to safety, legal compliance or the ability to operate. "We need it before the trade show" is not an emergency.
  • Fast, limited authority. A named executive, usually the COO or CFO, can approve emergency spending up to a defined ceiling by phone or message, with a written record within 48 hours.
  • Retrospective review. Every emergency approval appears in the next capital committee pack, with the cost and the reason. If the same asset triggers emergencies twice, it goes on the maintenance plan.

Maintenance capex deserves its own logic too. Replacing a ten-year-old forklift with an equivalent one does not need an NPV analysis; it needs a condition assessment and a comparison of repair vs replace cost. Many companies keep a rolling asset renewal plan that forecasts replacements three to five years ahead, based on age, condition and failure history. Items on the plan get approved as a group during the annual capital plan, and individual requests only confirm timing and price.

Tracking the ratio between emergency and planned maintenance spending over time is one of the simplest health checks available. When emergency spend grows as a share of maintenance capex, the renewal plan is underfunded, and the bill will arrive at the worst moment.

How to rank competing capex requests

Approving projects one at a time makes every reasonable request look fundable. The real decision is comparative: with a fixed envelope, which projects go first?

A simple, defensible ranking method combines four factors:

  1. Strategic fit. Does the project support one of the company's stated priorities for the year? Score it 1 to 5, with the CEO owning the scale.
  2. Financial return. NPV per dollar invested, or IRR above the hurdle rate, calculated by finance on the standard assumptions.
  3. Risk. Execution risk, technology risk, dependence on a single supplier or a single person. A high-return project with high risk ranks below a moderate-return project the team knows how to deliver.
  4. Cost of delay. What does it cost to wait six months? For some projects the answer is nothing; for others, a lost contract or a regulatory deadline.

Weight the factors by bucket. For maintenance, cost of delay dominates. For growth, financial return dominates. For strategic projects, fit and learning value dominate, and they should be funded from a separate, explicitly limited envelope so they do not crowd out everything else.

The capital committee reviews the ranked list quarterly, not just the individual requests. That is where hard trade-offs happen: pausing a lower-ranked project to fund a higher-ranked one that appeared mid-year. Without a ranked list, these decisions go to whoever lobbies hardest, which is exactly what a capex approval process is supposed to prevent.

It is common for the first ranked list to surface at least one project that everyone had quietly assumed was going ahead and that, next to the others, nobody wants to defend. Cancelling it is the process working, not failing. The capital freed that way is often enough to fund the maintenance backlog that had been deferred for two or three years, which in turn reduces the emergency spending discussed above. A ranked list also makes the conversation with the board easier: instead of defending individual numbers, the CFO shows the full queue, the cut line, and what the company would fund with more capital.

The current capex climate

Capital decisions do not happen in a vacuum. The Q3 2026 CFO Survey run by the Richmond Fed, the Atlanta Fed and Duke's Fuqua School of Business, fielded between August 17 and September 4, 2026, found that firms' plans to invest in structures and equipment declined compared with the first quarter of 2026. The share planning equipment investment fell by roughly 8 percentage points and structures by roughly 2 points. Just under 20% of firms said access to or cost of financing constrained their investment or spending plans.

When capital gets scarcer, the quality of the approval process matters more, not less. In expansive years, a weak process approves too much and the market forgives it. In tighter years, a weak process approves the wrong things, and the good projects that were not approved do not come back.

Self-assessment: how mature is your capex approval process?

Score each statement 0 (no), 1 (partly) or 2 (yes).

Policy and structure

  1. We have a written capex policy that defines capitalization thresholds, leases and software treatment.
  2. We have a delegation of authority matrix with tiers based on total project cost.
  3. Budgeted and unbudgeted requests follow different rules.

Business cases

  1. Every request above tier 2 uses a standard business case template.
  2. Business cases include total cost of ownership over the full useful life.
  3. Benefits are tied to measurable operating metrics with named owners.
  4. Business cases show a range (downside, base, upside), not a single number.

Controls

  1. Approvers commit to turnaround times, and we track them.
  2. We run a split-purchase detection report at least quarterly.
  3. POs for capital items require a valid project code and cannot exceed the approved ceiling.
  4. Scope or cost changes above a defined tolerance require re-approval.

Learning

  1. Post-investment reviews are scheduled at approval for all large projects.
  2. We maintain a list of past projects with approved vs actual cost and timeline.
  3. Lessons from reviews change our templates, contingencies or thresholds.

Scoring

  • 24 to 28: a mature process. Focus on reference class data and stage-gating for technology projects.
  • 16 to 23: solid authorization, weak learning. Start post-investment reviews on your last year's largest projects.
  • 8 to 15: a signature workflow. Rebuild the business case template and the delegation matrix first.
  • 0 to 7: capital is allocated by negotiation. Start with a written policy and a capital committee.

A 90-day roadmap to rebuild your capex approval process

Days 1 to 30: diagnose and design

  • Week 1: collect the last 24 months of capital projects. For each: approved cost, actual cost, approved timeline, actual timeline, who approved, and whether benefits were ever measured.
  • Week 2: map the current process as it actually runs, including workarounds (leases, splits, emergency approvals). Interview three sponsors and two approvers.
  • Week 3: draft the capex policy: definitions, thresholds, lease and software treatment, classification ownership.
  • Week 4: draft the delegation of authority matrix and the business case template. Review with the CEO and CFO.

Days 31 to 60: build and pilot

  • Week 5: configure the workflow in your ERP or approval tool: intake form, routing by tier, project codes, PO blocking above ceilings.
  • Week 6: set up the capital committee: members, cadence, agenda template, minutes format.
  • Week 7: pilot with the next three to five requests that come in. Measure turnaround and collect feedback from sponsors and approvers.
  • Week 8: adjust thresholds, template and routing based on the pilot. Build the split-purchase detection report.

Days 61 to 90: roll out and close the loop

  • Week 9: train sponsors and approvers. Keep it practical: walk through a real business case, good and bad.
  • Week 10: go live for all new requests. Publish the policy and the template internally.
  • Week 11: run the first post-investment reviews on two or three completed projects from the last 18 months.
  • Week 12: present to leadership: the reference class from your historical data, the default contingency it implies, the first review results, and the calendar for next year's capital plan.

This roadmap works with existing tools. You do not need new software to start; most of the value comes from the policy, the template, the committee and the reviews. If a dedicated capex tool makes sense later, you will know exactly what you need it to do.

FAQ

What are the steps in a capex approval process?

A complete capex approval process has nine steps: set an annual capital plan with budgets by category, collect requests through a single intake, build a business case, run an independent finance review, route the request for tiered approval, release the budget and procure against a project code, control changes above a set tolerance, capitalize the asset when it is placed in service, and run a post-investment review twelve to eighteen months after completion. Most companies do the first five and skip the last.

Who approves capital expenditure requests?

Approval follows a delegation of authority matrix based on total project cost. Small projects are usually approved by a department head and the controller, mid-size projects by a business unit leader and the CFO, and large ones by the CEO and CFO after a capital committee review. Projects above a set amount, or with strategic impact, go to the board. Unbudgeted requests typically move one tier higher than budgeted ones of the same size.

How do you set capex approval thresholds?

Start from the capitalization threshold in your accounting policy, then set tiers so that approvers see a manageable number of requests at their level. Base tiers on total project cost over the asset's useful life, including installation, integration and maintenance, not on invoice value. Review thresholds annually, and move a request one tier higher when it was not in the annual capital plan. Scale the amounts to your company's size.

What should a capex business case include?

A useful capex business case includes the problem and a do-nothing baseline, at least three options, total cost of ownership over the full useful life, benefits tied to measurable operating metrics with named owners, NPV, IRR and payback on a standard discount rate, a downside and upside scenario, kill criteria decided in advance, and a comparison with how similar past projects performed against their original estimates.

What is the difference between capex and opex approval?

Capex approval covers spending on long-lived assets that are capitalized and depreciated, and usually requires a business case and tiered sign-off. Opex approval covers recurring operating costs managed within the annual budget. The risk is that teams route the same need through whichever channel is easier, for example leasing equipment as opex. Good practice applies capex-style governance to any large multi-year commitment, whatever its accounting treatment.

How long should a capex approval take?

It depends on the tier. Small requests should be approved within about a week, mid-size requests within two weeks, and large ones at the next capital committee meeting, typically monthly. What matters is that approvers commit to turnaround times and the company tracks them. When approvals take months, managers start splitting purchases or using leases to avoid the process, which weakens control.

What is a post-investment review?

A post-investment review compares a capital project's actual cost, timeline and benefits with what the approved business case promised, usually twelve to eighteen months after completion. It identifies why results differed and what should change in estimating, approving or executing similar projects. Over time, these reviews build the historical data that makes future business cases more accurate and sponsors more accountable.