An AI business case usually begins with a stopwatch.
A task took six hours. With a model, it takes one. Multiply the five hours saved by the number of employees and frequency of the task. Apply a wage rate. Compare the result with software and implementation cost. The return appears.
The arithmetic may be correct and the business case still wrong.
It has collapsed three different clocks into one.
The capability clock governs how quickly models and tools improve, change price or disappear.
The operating clock governs how quickly the enterprise can redesign work, integrate systems, validate output, change roles and handle exceptions.
The economic clock governs when recovered time becomes lower cost, additional revenue, better asset utilization or another measurable financial outcome.
These clocks interact. They do not synchronize automatically.
Clock one: capability moves first
Model performance can improve sharply between procurement cycles. Costs can fall. New modalities appear. A provider can deprecate a model before the enterprise has finished standardising the last one.
This creates a strange investment problem. The technical component with the shortest useful life may sit inside a programme whose approval, integration and adoption take years.
A pilot can therefore prove that a capability exists without proving that the chosen component will still be the right—or available—component when the workflow reaches scale.
The obvious response is to preserve flexibility. But flexibility is not free. Multi-model routing, abstraction, evaluation suites, observability and replacement testing are additional operating assets. They belong in the cost of the solution rather than being treated as optional technical hygiene.
The capability clock also creates recurrent cost. The model that made the original business case work may need to be replaced, re-evaluated or repriced before the investment has paid back.
Clock two: the enterprise absorbs change slowly
The operating clock begins where demonstrations end.
The enterprise must connect data, permissions and systems; define exceptions; decide who approves output; create monitoring; redesign roles; train users; change policy; and determine what happens when the model is unavailable or wrong.
In consequential workflows, it must also establish provenance, independent review, testing and evidence.
This work is not a temporary nuisance around the “real” AI. It is the mechanism through which capability becomes a reliable operating process.
The operating clock is constrained by dependencies the model does not remove:
- Sales cannot book revenue from a proposal the delivery organisation cannot fulfil.
- Finance cannot close faster if upstream data remains unreconciled.
- A bank cannot remove review simply because a memo was generated faster.
- A healthcare workflow cannot transfer clinical responsibility to a language model.
- Engineering cannot apply one productivity gain across code with radically different integrity requirements.
The bottleneck therefore moves. When generation becomes nearly instantaneous, integration, acceptance and organizational conversion become the long pole.
Clock three: saved time is not yet economic value
Time saved is an operational fact. Value realised is a management decision.
A worker who saves five hours does not hand five hours of cash back to the company. The capacity is fragmented across people and weeks. It may be consumed by more work, waiting, meetings or quality improvements. Some of those are valuable; none should be labelled cost reduction without a mechanism.
There are only a few ways recovered capacity becomes financial value:
Cost removed. Roles, contractors, overtime or future hiring are actually reduced.
Throughput increased. The same resources process more demand and demand exists to absorb it.
Revenue improved. Faster response, better conversion, greater retention or a new product changes cash inflow.
Risk or loss reduced. Fewer errors, claims, write-offs or control failures produce a measurable avoided cost.
Capital efficiency improved. Assets, inventory or working capital turn faster.
Everything else may still be worthwhile, but it is not the cash return commonly presented to an investment committee.
The conversion mechanism must identify an owner. “Employees will use the time for higher-value work” is not a mechanism. Which work? What constraint prevented it before? How will the capacity be aggregated? Which metric will show that it occurred?
Replacement and verification belong in the original case
Many AI investment models price initial software, implementation and change management. They omit the obligation to replace the component and re-establish evidence when its lifecycle is shorter than the surrounding system.
The omission matters because replacement is not merely another licence purchase. It may require regression testing, policy review, prompt or workflow changes, new failure analysis, user retraining and renewed validation.
Verification creates a similar distortion. If AI reduces generation time but adds review, traceability and exception handling, the gross saving is not the correct input to the financial model. The model should use accepted-output time from the verification analysis, not demonstration time.
These are not pessimistic contingencies. They are recurring operating characteristics of a system whose probabilistic component and supplier ecosystem continue to change.
The accounting clock adds another judgment
Software development costs may be capitalised and amortised over an estimated useful life. In September 2025, the Financial Accounting Standards Board issued ASU 2025-06, which removes references to sequential development stages in the internal-use software guidance. Under the amended model, capitalization begins when management has authorised and committed funding and it is probable that the project will be completed and used as intended. The amendments are effective for annual periods beginning after December 15, 2027, with early adoption permitted.
That accounting change is not an AI rule. But it arrives while generative tooling is changing both how software is produced and how quickly some of it may be replaced.
A modern development portfolio can contain two very different populations:
Software inside long-lived products and platforms. The enterprise expects to support it for many years, even when components beneath it need replacement.
Software regenerated at the pace of the tooling. Falling production cost may make replacement rational well inside the conventional useful-life estimate.
Treating both populations with one inherited useful life may cease to describe the economics. Finance needs a documented rationale, not because one universal answer exists, but because the portfolio no longer has one obvious answer.
Provenance also matters. If generated work is capitalised, reviewed or later challenged, the organisation should be able to show which tool and model were used, under what policy and with which controls. Capturing that prospectively is a configuration choice. Reconstructing it after a year of commits is a forensic exercise.
Build the business case as three linked schedules
A more defensible investment case has three explicit schedules.
1. Capability schedule
- Expected model and vendor lifecycle
- Pricing sensitivity
- Replacement triggers
- Evaluation and portability assets required
- Expected refresh or migration cost
2. Operating schedule
- Integration and data readiness
- Verification and acceptance design
- Exception rates and fallback process
- Role and policy changes
- Time to scale by workflow population
- Replacement and revalidation procedure
3. Economic schedule
- Gross time or quality improvement
- Net accepted-output improvement
- Specific conversion mechanism
- Owner of the conversion
- Cash, revenue, risk or capital metric
- Recognition timing and useful-life assumption
The schedules should connect. A capability change should show where it creates operating work. Operating adoption should show when and how it produces economic realization. The financial model should include a revalidation or replacement event if one is likely inside the payback period.
Four questions for the investment committee
What exactly is being counted? Generated output, accepted output, capacity recovered or value realized are different measures.
Who converts the capacity? The owner should be able to state which budget, headcount plan, throughput target or revenue metric changes.
What happens when the component changes? The business case should contain the cost and elapsed time of replacement, not simply a statement that the architecture is model-agnostic.
Which useful life is being assumed? The answer should reflect the actual refresh and support strategy for the software population, not an inherited convention.
The central mistake is not optimism. It is temporal compression.
The model can improve in a quarter. The workflow can take two years to redesign. The cost saving may not appear until a hiring plan changes—and the original model may need replacement before then.
A serious AI business case makes those clocks visible. Only then can the organisation decide whether capability will become consequence on terms worth funding.