Capital planning and project approval: what to automate and what to keep human

Software can take over the mechanical parts of capital planning: assembling requests, running return calculations, checking spend against approved limits and flagging overruns. People still have to set policy, weigh competing projects and decide which risks are worth taking. None of it works until project and asset data is consistent.

Where software already does the work

Request intake is the easiest place to start. A structured form collects the sponsor, the asset type, the estimated cost and the expected benefit. The system then routes each request by approval threshold. That alone removes most of the email chasing that slows a capital cycle.

The justification arithmetic is also safe to hand over. Net present value, internal rate of return and payback follow fixed formulas once the inputs exist. A tool can apply the hurdle rate set by treasury, run sensitivity cases and produce a standard appraisal pack. AI adds something here. It can draft the narrative, compare a new request with similar past projects and point out an assumption that looks far more optimistic than history supports. It should flag. It should not approve.

After approval, control belongs in the system. Each approved project gets a code tied to a cost center and to the general ledger. Spend limits sit on that code. Purchase commitments are checked against the approved amount, and invoices against commitments, within agreed tolerances. The system can warn at one level and block at another. Budget against actual reporting then traces straight back to ledger balances, with no rebuilding in spreadsheets.

Closeout is often forgotten. Software can prompt it when spending stops, move costs from construction in progress to the asset register and shut the project code so nothing new lands there.

Where a person has to decide

Policy is a human job. Someone has to decide the capitalization threshold, the hurdle rate, who can approve at which level and what counts as maintenance versus improvement. A tool can model the effect of changing a threshold. The accountability for choosing it stays with finance leadership.

Ranking projects against each other is where judgment matters most. Financial returns are only part of the case. Safety work, regulatory obligations and strategic bets often show weak or no return on paper. A committee has to trade these off, knowing the capital pool will not stretch to cover everything.

Sponsors tend to overstate benefits and understate cost. A reviewer who knows the business can tell when a volume forecast ignores a market change or a contractor quote leaves out installation. AI can raise the question. A person has to press it in the room.

Exceptions also need an owner. When a project runs over its approved amount or changes scope, someone must decide whether to fund the overrun, cut scope or stop. Systems detect the breach well. They cannot weigh the cost of abandoning half a building.

Some accounting calls stay manual too. Whether a software build meets the criteria for capitalization, or when an asset is ready for use, depends on facts that rarely sit in any field.

What has to be true about the data first

There must be a single project register. Every request, approved project and asset needs a stable identifier that links the plan, the commitments, the ledger postings and eventually the fixed asset record. If the same project carries different names in the budget file and the purchasing system, automation will produce confident nonsense.

Capital and operating spend must be classified the same way across sites. Otherwise spend controls fire on the wrong codes and reports mix maintenance into the capital line.

Approved amounts have to live in the system that enforces them. A figure that exists only in committee minutes cannot stop an overspend.

Assumptions behind each appraisal should be stored as data fields, not buried in slide decks. Discount rate, useful life, volume and price inputs all need recording. Without them, nobody can run a post-implementation review, and any AI comparison with past projects has nothing to learn from.

Commitments need to be raised when orders are placed, not when invoices arrive. Late commitments make every available balance look healthier than it is.

Questions to ask the people who run it

• When a request arrives, where does it actually go first, and who touches it before it reaches a committee?
• Which approvals happen informally before the formal one, and who gives them?
• How often do sponsors split a project to stay under an approval limit?
• Where do the cost estimates come from, and does anyone check them against what similar projects really cost?
• When a project overspends, who finds out first, and how?
• Which spreadsheets are kept alongside the system, and what do they hold that the system does not?
• How is the decision made to move costs from construction in progress to a finished asset?
• Has any approved project ever been compared with its original business case after completion? What happened to the findings?
• Which projects get approved regardless of return, and who decides that they qualify?
• What would break if the approval routing changed tomorrow?

APQC's Process Classification Framework® (PCF) is an open standard developed by APQC, a nonprofit that promotes benchmarking and best practices worldwide. To download the full PCF or to view definitions and measures, please visit www.apqc.org/pcf.