Executive Summary
Automation initiatives are frequently evaluated using the wrong financial framework. Because automation is typically procured like software, it defaults into IT budgets and is judged against efficiency metrics (hours saved, headcount avoided) rather than capital-investment metrics (payback period, risk-adjusted return, opportunity cost of delay). This causes viable automation business cases — even ones with strong ROI — to stall, get re-scoped, or die in committee, not because the technology fails, but because the wrong people evaluate it against the wrong benchmark.
Why Automation Should Be Evaluated as a Business Asset
Here is a case study: eighteen months ago, a mid-market logistics company built a business case for automating its exception-handling process in accounting. The manual process it aimed to replace was expensive to keep running. It consumed the equivalent of eleven full-time roles that were actually hired to do other work in Finance transformation that had since stalled. Despite best efforts, the process generated duplicate payments and late-fee penalties, and carried error rates that a controls audit had flagged twice. All in all a fully loaded cost of just over $1.1 million a year. The automation vendor’s pilot promised to eliminate most of that cost, and it ran spotlessly. The finance team that would eventually own the process liked what they saw. Yet the case sat, unapproved, for a year.
It stalled for reasons to do with how it was framed and with who was asked to judge it, and remarkably little to do with whether the technology worked, which it did. It arrived in the IT budget as a request for licenses and integration hours, competing against a server refresh and a CRM upgrade, all which were fighting for a spot in the same capped budget. The automation was pitched using the language of efficiency (hours saved, headcount avoided) to an operations budget committee that lacked the authority to allocate capital and lacked the mandate to weigh opportunity cost. What a year of delay had actually cost the business went unasked, because that question belonged to nobody in the room. The project that deserved comparison to a plant upgrade or a bolt-on acquisition instead drew comparison to a laptop refresh cycle, and it lost.
This pattern happens to many companies and is common enough to be structural rather than accidental. Automation inherited its budget category from the technology it most resembles on the surface: software. And software has historically been evaluated as a cost of doing business rather than a source of return. IT budgets are built around keeping the lights on, through licensing, infrastructure, security, support. They are sized against last year’s spend, adjusted incrementally, and owned by a function whose mandate is operational continuity rather than capital productivity.
Automation fits that budget line by default, because that is where the request originates and where the approval authority sits, even though it fits that mandate poorly. The result is a systematic mismatch between how the investment is evaluated and what the investment actually is.
By contrast, a plant upgrade or an acquisition is judged against a hurdle rate: does the risk-adjusted return clear the cost of capital, and does it clear it faster or more certainly than the alternative uses of that capital? An automation case, by contrast, is typically judged against a wish list, a ranked set of nice-to-haves competing for whatever residual budget IT has left after infrastructure and maintenance are funded. One of these is a resource allocation decision, whereas the other is a queue.
Because of this, automation programmes get stalled, re-scoped, or quietly deprioritized by committees given neither the tools nor the incentive to weigh them properly. A hurdle rate forces a decision, but a wish list tends to defer these decisions indefinitely.
This unfortunately can cause bigger issues. A single delayed automation case is a rounding error. A hundred of them, sitting in an enterprise’s IT queue, add up to an opportunity cost the finance function has effectively chosen to carry without ever underwriting the decision. If we look back at the example, considering the annual cost that could have been saved, and the number stops looking like an IT backlog and starts looking like a capital allocation failure wearing a technology label. Because the business case for automating was judged by the wrong decision-making process.
Like any asset investment, payback period is the first and most familiar influencer: how many months until the automated process returns the capital deployed to build it, inclusive of implementation, change management, and the maintenance that the case likely understates.
Risk-adjusted return is the second: what is the expected value of the investment once the probability of implementation slippage, adoption failure, and process drift gets priced in, rather than assumed away.
Opportunity cost of delay is the third, and the one operations pitches almost always omit: what does another quarter of the status quo actually cost (in error rates, in rework, in the headcount that could be redeployed to higher-value work) and how does that compare to the cost of capital tied up elsewhere.
This is the same standard toolkit finance uses to evaluate a plant expansion, a fleet replacement, or a bolt-on acquisition. However now, object being evaluated is changed. Automation cases that adopt this language stop competing against other IT tickets and start competing, on equal footing, against every other claim on the company’s capital. Some will still lose that competition, and rightly so, when the return fails to clear the bar. But when that happens, they will lose because the numbers genuinely didn’t hold up and not because the request was filed under the wrong budget line and judged by a committee that wasn’t equipped to weigh it.
Part of why automation defaults to the wrong ledger is structural in a way that has nothing to do with how anyone frames the pitch: it often gets bought as a subscription. RPA licenses, workflow platforms, and orchestration tools are typically priced and procured as software-as-a-service, which lands on the income statement as an operating expense rather than a capital expenditure. A plant upgrade or a piece of equipment is capitalized by default, which routes it through a capital approval process as a matter of accounting convention, independent of who happens to be pitching it. An automation subscription is opex by default, which instead routes it through the same approval chain as a project management tool or a design license, meaning it is reviewed for budget fit, rather than for return.
However, neither decision is inherently the wrong choice. Opex gives a company real flexibility to adapt as the automation landscape keeps shifting; this makes it easier when the company is swapping vendors, scaling a tool up or down, or walking away from a platform that underdelivers, without the sunk-cost weight a multi-year capitalized asset carries. And capital treatment carries its own advantage: the discipline of planning a multi-year investment forces a company to size the return properly and spread the cost over the asset’s real useful life, rather than re-litigating a foundational system every budget cycle. Which treatment fits best depends entirely on what a given company needs; this depends on how quickly its process landscape is changing, how long the investment is expected to hold its value, and how much it values flexibility over commitment.
What stays constant across both treatments is who makes the call, in the end. Whether an automation investment gets structured as opex or capex, the decision belongs to an investment committee that includes, finance, the process owner, and the IT experts, who should jointly own the return and can weigh that trade-off properly.
This reframing carries a direct implication for ownership. If automation is an asset investment decision, IT alone can hardly build and defend it, because accountability for the return, and authority over the hurdle rate, sit elsewhere. The business case belongs jointly to finance and the process owner: finance, because it holds the discipline for translating an operational proposal into payback period, risk-adjusted return, and opportunity cost; and the process owner, because they hold the baseline data; the volumes, error rates, cycle times, the true fully loaded cost of the current-state process. IT, of course, still retains a vital role: technical feasibility, integration risk, security and control implications.
This division of labour also solves a credibility problem that hurts many automation pitches. A technologist arguing for a hurdle rate invites scepticism about whose interests the number serves. A finance leader and a process owner arguing for the same hurdle rate, using the same methodology applied to every other capital request, invite scrutiny of the number itself, which is exactly where the scrutiny belongs.
There is also a governance benefit of doing this. A capital allocation styled investment decision process leaves an audit trail: who proposed the hurdle rate, what assumptions fed the payback calculation, who signed off and on what basis. An IT budget line doesn’t often leave a trail like this, because it wasn’t built to. When a board or an audit committee eventually asks why a process ran manually for three extra years despite a viable automation case sitting somewhere in a backlog, a capital allocation styled process produces an answer.
Sceptics will point out, fairly, that subjecting every automation request to a full capital allocation review risks burying small, low-cost improvements in a process designed for eight-figure decisions. A three-week workflow tweak saving a single analyst a few hours hardly needs a hurdle rate calculation and a finance sign-off chain built for a plant expansion.
This is true, and companies that handle capital expenditure this way already set materiality thresholds for equipment purchases and facility investments; automation deserves the same treatment. Below a defined size or risk level, a lightweight version of the same discipline (a one-page payback estimate, signed by finance and the process owner) keeps small projects moving quickly. Above that threshold, the full capital allocation process applies, exactly as it would for any other investment of comparable size. What changes is the weight of the process, because the underlying question (does this investment clear a return hurdle) always gets asked.
Every board and finance function already has a reflex for capital decisions that carry this shape: define the return, price the risk, set a hurdle rate, and require the case to clear it before capital moves. A plant upgrade would struggle to win approval on the strength of a slide about efficiency gains alone, and a pending one would draw scrutiny long before a year passed without anyone asking what the delay was costing.
Automation spend deserves the same discipline, in both directions. A vendor demo alone should never wave a project through, and a queue should never let one stall for want of a framed decision with a return, a risk profile, and a cost of delay attached. The questions should be the same for an investment like automation: what is the hurdle rate and does this clear it. Boards and finance leaders equipped to answer that question for their automation pipeline are exercising real capital discipline. Those left guessing are simply leaving the decision unmade and calling it caution.
Automation is usually procured like software, so it lands in the IT budget and gets judged on efficiency metrics (hours saved, headcount avoided) instead of capital-investment metrics like payback period and risk-adjusted return. It ends up competing against unrelated IT tickets — like server refreshes — in front of a committee that has neither the authority nor the mandate to weigh capital allocation decisions properly.
Three, mirroring how any capital asset is judged: payback period (how long until the investment returns its cost, including implementation and change management), risk-adjusted return (expected value once implementation slippage, adoption failure, and process drift are priced in), and opportunity cost of delay (what continuing the manual status quo actually costs in errors, rework, and underused headcount).
Yes, though neither is inherently wrong. Opex (typical for SaaS-based RPA/orchestration tools) offers flexibility to swap vendors or scale without sunk-cost pressure, while capex forces multi-year return discipline and spreads cost over the asset’s useful life. What should stay consistent regardless of treatment is that an investment committee — finance, the process owner, and IT — jointly owns the decision.
It should be a joint effort between finance and the process owner, not IT alone. Finance brings the discipline to translate the proposal into payback period, risk-adjusted return, and opportunity cost; the process owner supplies the baseline data (volumes, error rates, cycle times, fully loaded current-state costs); IT contributes technical feasibility, integration risk, and security considerations.
No — the article recommends materiality thresholds, similar to those already used for equipment or facility purchases. Small, low-cost projects can use a lightweight version (a one-page payback estimate signed off by finance and the process owner), while larger investments go through the full capital allocation process. The rigor scales with size, but the core question — does this clear a return hurdle — always applies.