Where capital planning and project approval breaks

Capital planning usually breaks at the joins. These include the move from an approved budget to an approved project, from approval to a live project code in the ledger, and from spend to close-out. Exceptions such as emergencies and split requests bypass the rules, and the evidence shows up in journals and reports.

Policy says one thing, requesters do another

Most capital policies set approval thresholds by amount. Requesters learn these quickly. A project that would need board sign-off gets broken into smaller requests that a plant manager or department head can approve alone.

The tell is in the request log. Look for several requests just under a threshold, raised close together, for the same site, asset or vendor. Another clue is a project description that only makes sense when read alongside another request.

Policies also go stale. Capitalisation rules written before cloud software, leases and configuration work became common leave people guessing. When finance staff answer the same classification question by email again and again, the policy has a gap.

The budget is approved, but the project is not

The annual capital plan is often approved as an envelope by division or category. Sponsors then treat inclusion in the plan as permission to spend. Finance treats it as permission to submit a business case. That misunderstanding is one of the most common sources of friction.

Watch for purchase orders against a capital category where no individual project approval exists. Watch also for approvers complaining that they are being asked to sign off on spend already committed.

The business case gets rebuilt more than once

Sponsors build financial justification in their own spreadsheets. Assumptions about volumes, savings and useful life are rarely checked against anything. Finance then rebuilds the model in a standard template. Approvers ask questions, the sponsor revises, and the versions multiply.

The signal is version confusion. Approval packs that cite a different return from the model on file mean the case has drifted. So does a committee that asks the same question about discount rate or residual value at every meeting. Benefits that are approved and then never measured are a quieter failure. Nobody learns which assumptions were optimistic.

Approval does not reach the ledger

Once a project is approved, someone has to create the project or cost object, set its spend limit and link it to the right asset class. This handoff usually sits between the approval body and a ledger team that was not in the room.

When it lags, costs land somewhere else. Invoices post to operating expense or to a holding account, and someone reclassifies them later. The evidence is a pattern of manual journal vouchers at period end that move costs into capital projects. Auditors notice these. So should anyone redesigning the process.

Spend control is set up loosely or not at all

A project code without a spend limit cannot stop an overrun. Tolerance checks between commitment and order amounts are often set wide or switched off to avoid blocking urgent purchases. Overspend is then discovered in a cost report long after the money has gone.

Compare actuals plus open commitments against approved amounts. Projects above their approval with no supplementary request on file show that change control is happening informally, if at all. Scope changes agreed in a site meeting and never written down are the usual cause.

Exceptions become the normal route

Emergency replacements, safety work and regulatory deadlines justify fast approval. That is reasonable. The trouble starts when the emergency path is easier than the standard one and people learn to use it.

Retrospective approvals are the giveaway. So are emergency requests with vague descriptions, or a rising share of capital spend that skipped the committee. Mixed projects with both capital and operating elements create a related problem. Costs get split by judgement after the fact, and the split is hard to defend.

Projects never close

Closing a project means confirming the asset is in service, settling final costs, transferring the balance to fixed assets and shutting the code. Nobody owns this step strongly. Sponsors have moved on and the ledger team waits for confirmation that never comes.

Open projects with no recent postings are the clearest sign. Depreciation that starts late follows from this, along with assets sitting in construction in progress after they are visibly running. A code left open also invites unrelated costs to be charged against leftover budget.

Questions to ask the people who run it

The documented process and the lived one rarely match. These questions tend to surface the difference.

• What happens when a project is in the annual plan but the business case is not ready? Does work start anyway?
• Who creates the project code after approval, and how do they find out a project was approved?
• Where do invoices go when they arrive before the project exists in the system?
• Which requests were split to fit an approval limit, and who suggested splitting them?
• How is a cost overrun handled today? Who decides whether it needs to go back to committee?
• What counts as an emergency, and who can declare one?
• Which classification questions come up so often that someone keeps a private note of the answers?
• When was a business case last checked against what the project actually delivered?
• Who tells finance that an asset is in service, and what prompts them to do it?
• Which spreadsheets sit outside the official system but are relied on to track capital spend?

The answers to the last question often reveal where the real controls live. Any redesign that removes those spreadsheets without replacing what they do will reopen the gap they were quietly filling.

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.