How Do You Evaluate Strategic Projects That Don’t Meet Your Capitalization Threshold?

Some of your most consequential spending never gets a serious look, because it does not meet your capitalization threshold. Simply because some costs are classified as operating expenditure, they don’t the same rigorous evaluation applied to CapEx.

This is increasingly a problem for IT. Subscription software, multi-year service agreements, cloud platforms and AI initiatives create large financial commitments and shape operations for years without ever qualifying as capital. The capitalization threshold ends up deciding how much scrutiny a decision receives, even though this expenditure will have far reaching implications for the organization.

Five characteristics of expenditure give you a more useful test: the total value of the commitment, its duration, the breadth of its impact, the risk and uncertainty involved, and your confidence in the estimate. Any one of these is enough. They also explain why a small software decision can deserve more scrutiny than a much larger capital purchase.

Why Doesn’t a Capitalization Threshold Tell You How Much Scrutiny a Project Needs?

A capitalization threshold answers an accounting question: is this a high value asset the business will capitalize and depreciate over time? It says nothing about how carefully to think before committing the money. Whether a cost is a capital or operating expense is an important accounting classification, and with combined subscription and implementation costs, not a trivial one, but it remains a finance question and should not be the basis for formalized evaluation and prioritization.

Large commitments do get seen. The purchase order approval process will typically ensure appropriate sing-off. But that is an approval, not an evaluation. The approver is asked to verify the legitimacy of the spend, not whether the case for it holds, or is the most valuable application of funds.

For many organizations, the formal evaluation of business cases only occurs when expenditure is classified as ‘CapEx’ and meets a certain materiality threshold. Given that only high-value CapEx is subject to business case scrutiny, it is easy for low value initial OpEx spend to slip through.  Before you realize, the pilot AI initiative waved through in March is in production across four business units by November. The subscription approved at $40,000 for one team is renewed at $400,000 across ten teams. The commitment grows. The analysis and justification is nowhere to be found.

This article is about the depth of that evaluation. Not whether the expenditure is permitted, and not who sets the rules.

Why Do Multi-Year OpEx Commitments Squeeze Out New Investment?

A three-year agreement signed this quarter is cash already spoken for in the two years after it, competing with the capital plan for the same money.

Budgets get consumed in order. Contractual commitments first. Then the stay-in-business sustenance requirements: renewals, compliance, the platforms that must stay up. New investment draws on what is left, and that remainder is the only part anyone deliberates over.

Traditionally the committed base was also invisible at the point of decision, because a capital plan showed this year’s choices and not the agreements signed in previous years. Finance teams have closed much of that gap with better forecasting and faster reporting cycles. But visibility and evaluation are different things. Knowing what a renewal will cost is not the same as asking whether it should proceed, and the commitment was made years earlier by someone without assessing if this is the optimal use of funds.

So, the committed share grows every year, the discretionary share shrinks, and the spending that gets the least scrutiny keeps the first claim on the budget. That is the cost of using an accounting classification test to decide what gets examined, and as a result strategic operational expenditure keeps growing as a share of the total IT budget.

5 Signals That Your Project Needs a Closer Look

Five signals that tell you a project-related decision deserves more than a rubber stamp, and none of them are related to where cost sits in the ledger, see here:

Five signals that determine how much scrutiny an investment decision needs.

1. Value

Ask what the decision commits the business to over its life, not what the first payment is. A subscription at $400,000 a year for three years is a $1.2m commitment presented as an annual cost. It will never be capitalized, and it is larger than most capital projects that get a full appraisal.

Value is the signal everyone already uses. It is also the one that misleads most often, because a large familiar purchase can need far less examination than a small unfamiliar one.

2. Duration

A multi-year agreement removes a decision from future years. Whoever holds the budget in year three inherits a commitment they had no part in making and cannot easily undo.

Duration and value answer different questions. A five-year $30,000 contract and a $2m one-off purchase are not comparable on size, but it is the five-year contract that constrains future expenditure decisions.

3. Breadth of Impact

Some decisions are contained. Others change how a large population works, take systems down during transition, or require several functions to be scheduled together.

A moderate-cost application replacement that interrupts everyone for two days has a bigger operational footprint than a larger purchase nobody notices. Cost tells you nothing about that.

4. Risk and Uncertainty

There are two questions here. Does the decision change the organization’s exposure, whether that is security, regulatory, continuity or dependence on a single supplier? And has this been done before, or is it unfamiliar work?

Risk is the signal a value test can never see, because the cheapest item on the list can be the one that enables everything else. Or the one that brings it all crashing down.

5. Estimate Confidence

A point estimate hides its own uncertainty. The question is not what the number is but how much weight it will bear: has this team estimated this kind of work accurately before, and what happens if the number is wrong?

The fallback matters because reversibility is cheapest before you start. Once the money is spent, going back to the beginning is rarely available.

Any 1 of the 5 Signals Is Enough

None of these signals needs a companion. A small tool can trigger evaluation on risk alone. If a request triggers none of them, standard purchase order approval limits will suffice.

Why Software Purchases Can Need More Scrutiny Than Hardware

On IT spending, size and required attention often run in opposite directions. The capitalization threshold and the accounting limit both test money, so the biggest number gets the most process. In IT that is frequently the wrong way round.

Take a server you buy every three months. Same vendor, same specification, and you know what it costs to install and what throughput it delivers. It is the largest number on the page, and it needs the least attention, because everything about it is known. It triggers evaluation on value and nothing else.

Now take a piece of software three people use. It is small enough to go unnoticed, but it may hold regulated data, connect two critical systems, or open a security exposure across the whole operation. It triggers on risk and nothing else, and risk is the signal a capitalization threshold cannot see.

Both decisions trigger one signal. One needs a purchase order and the other needs a review. What determines the answer is which signal triggered, not how many.

What Does a “Closer Look” Actually Mean?

More scrutiny does not mean a different or more complex process. It means more rigorous questions, asked before the commitment exists rather than after. The purpose is to surface what the requester has not thought about yet: what this will cost over its life, who else it affects, what it changes about the organization’s exposure, and what happens if the estimate is wrong. Those questions get answered eventually. The choice is whether they are answered before the money is committed or discovered afterwards.

In practice it is 4 things:

1. More information: the fields a requester has to complete, and the detail expected in them.
2. More supporting documentation: the quote, the alternatives considered, the estimate history.
3. More expert review: security, legal, architecture or finance looking at it because something in the request concerns them.
4. More endorsement: sign-off from the functions that will carry the consequence.

Proportionality has to work in both directions or the argument fails. A low value, low risk, low impact request should be submitted in minutes and approved quickly, and if it is not, the sanctioned route becomes the slow one and people stop using it. A complex initiative gets the analysis it warrants. Nothing here argues for more process across the board.

The teams that solved this did not build a second workflow for non-capital spend. They widened what the existing one accepts and let the request itself determine the depth of review. Stratex Online applies that principle: an upfront assessment of the request determines what information, documentation and endorsements it needs, so the depth of evaluation follows the decision rather than its accounting treatment.

Once a decision is in evaluation, how it is compared against everything else competing for the same budget is a separate discipline. Prioritizing capital projects covers the method.

Would This Mean Scrutinizing Every Request?

No. Applied to a real portfolio, the five signals leave routine spending exactly where it is and send only the decisions that warrant it for proper evaluation. Keeping scrutiny proportionate is also central to strategic OpEx governance once a commitment has been flagged.

The eight cases below are the kind of thing that crosses an IT budget in a year. Each is tested against the five signals, proposing the appropriate evaluation that decision should get.

Four of these cases fire a single signal and get four different answers. What a single signal warrants depends on which signal was triggered, not on how many.

The application upgrade is the same activity twice. The first time, breadth and unfamiliarity both trigger and it needs a full evaluation. By the tenth, the work is known and only breadth remains, so it gets recorded and waved through.

The AI pilot also appears twice. Contained, with a defined token budget, it needs one question about what happens if it does not work. In production across the business it fires four signals and is a different decision, but no process reassesses it. The original approval was correct when it was given, and it is the one still in force.

The laptop refresh and the small tool are the inversion. The laptop refresh is the largest number in the table and needs the least attention. The small tool is the smallest and needs a security review.

The capitalization threshold is not wrong. It answers an accounting question accurately, five signals answer the question that should be asked, and they scale in both directions: more examination where the commitment warrants it, and less where it does not.

That leaves one question open. Who decides what the signals are, and who has the authority to change them?