When approved capital spend drifts past its authorisation

The most common failure is spend drifting past what was approved. A project is authorised at one amount, but that decision never becomes a control on the project code. Commitments build up unchecked, and the overrun surfaces late, usually when the asset is capitalised or the capital budget is reported.

How it starts

Capital approval and capital spending usually live in different places. The investment committee signs a business case. Finance records the decision in minutes or a tracker. Separately, someone in accounting opens a project code so costs have somewhere to land.

The gap sits between those two acts. If the authorised figure is never loaded against the code as a spend limit, the ledger has no idea what was approved. Purchase orders and contractor invoices post freely. Each one looks reasonable on its own.

Then scope moves. A site survey finds extra groundwork. An equipment supplier changes the specification. The project manager treats these as part of the original approval, because nobody said otherwise. The capital investment policy may require supplementary sign-off for changes, but the trigger is vague, so it is rarely pulled.

A quieter version also appears. A large purchase is broken into several smaller requests, each under the delegated authority threshold. Every request passes. The combined total would have needed board sign-off.

How it is spotted

Late, in most cases. The usual first signal comes from the fixed-asset accountant trying to capitalise a finished project and finding the cost well above the business case. By then the money is gone.

Earlier warnings exist for anyone who looks. Open commitments on a project creep toward the authorised figure while the work is far from done. A project manager forecasts completion cost, and nobody holds that forecast up against the original authorisation. Budget execution reports show the capital line healthy in total, which hides individual projects running over while others underspend.

Split requests show up as clusters: several approvals for the same vendor or asset type, raised close together by one requester. These patterns rarely trigger alarms, because each approval is reviewed in isolation.

Another clue lies in coding. When a project nears its ceiling, charges sometimes migrate to expense accounts. A repairs and maintenance line that rises unexpectedly at one site deserves a closer look.

How it is fixed

Tie the approval to the control. When a project is authorised, set the approved amount up as a spend limit on the project code in the same step. Whoever opens the code needs the signed approval in hand, and the limit should match it exactly.

Decide in policy what happens near that ceiling. A tolerance between authorised and committed amounts lets small variances through while forcing a stop beyond it. Past the tolerance, the system should block new commitments or route them back to the original approver. Supplementary requests deserve the same financial justification as the first one. The revised cost and the restated benefits both belong in the case, not just a request for extra money.

Reporting has to trace to the ledger. Capital budget reports built in spreadsheets drift from the general ledger, and a project can look fine in one while over in the other. Reconcile the report to project-level ledger balances before it reaches the committee.

Splitting is caught by reviewing approvals in aggregate, by vendor and by requester. Write the policy so related purchases count as one project for threshold purposes.

Close project codes once the asset is capitalised. Codes left open attract stray costs from unrelated work, and those costs quietly inflate the next overrun.

Questions to ask the people who run it

Documented procedure and daily practice often part ways here. These conversations tend to show where.

• When a project is approved, who opens the code, and do they ever see the approval document?
• Is the authorised figure entered as a limit in the system, or only noted in a tracker?
• What actually happens when commitments exceed that figure? Has anyone tested it?
• How does a project manager know when a scope change needs fresh approval?
• Who compares forecast completion cost with the original authorisation, and does that comparison really happen?
• Have requests ever been split to stay under a threshold? Ask the requesters directly, not only their managers.
• When a project runs out of capital headroom, where do the remaining costs get coded?
• Who decides when a project code is closed, and what prompts them?

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.