How capital planning and project approval is set up in finance and ERP systems

Most organisations run capital planning partly inside the ERP and partly outside it. The annual capital plan and project business cases often sit in spreadsheets or a planning tool. Once approved, a project code and budget are created in the ERP, and spending is checked against it.

Where the work actually sits

The split matters. Planning and justification tend to happen in a world of versions, scenarios and email threads. Execution happens in a ledger with hard rules. The handover between the two is where most problems start.

A typical landscape has a planning or budgeting tool holding the capital plan by business unit and year. A request system, sometimes a workflow module in the ERP and sometimes a separate form, carries individual project proposals through review. The ERP holds the project structure, the approved budget, purchase commitments, actual costs and, eventually, the fixed asset record.

Some organisations push everything into the ERP's project module. Others keep the ERP thin and treat it purely as a book of record. Neither is wrong. What breaks is a setup where nobody is sure which system holds the approved number.

Policy turned into configuration

Capital investment policy usually defines what counts as capital, who can approve what and how much evidence a request needs. In the system, those rules show up in less obvious places.

The capitalisation threshold lives in asset class settings and in coding guidance for buyers. Approval authority lives in workflow rules keyed to cost centre, project type and value bands. Required justification lives in mandatory fields on the request form, or in a checklist that a finance analyst enforces by hand.

When policy changes, the document gets updated. The workflow tables often do not. Checking both is worth the effort.

The capital plan and its budget

The plan is normally built bottom up from departmental wish lists, then cut to fit an envelope set by the finance team or the board. In the planning tool, items may be named projects or simply placeholder lines.

Only approved items should reach the ERP as budgets. Many setups load the plan at a summary level, by programme or business unit, and release money to individual projects as each one clears approval. This creates a funds control hierarchy: an organisation level, a programme level and a project level beneath it. Spend limits can be enforced at any of these.

Approving individual projects

A project request usually moves from a sponsor to a finance reviewer, then up an approval chain that lengthens as value rises. Large or strategic items go to a capital committee outside the system, and someone records the decision afterwards.

That manual recording step deserves attention. If the committee approves a revised figure and the workflow still holds the original, the ERP budget will be wrong from day one.

On approval, the ERP project or internal order is opened, linked to a cost centre and an asset class, and given its budget. Settlement rules that move costs into assets under construction are usually defined here too.

Financial justification

Business cases are almost always prepared in spreadsheet models. Common measures include net present value, payback and internal rate of return, plus a qualitative case for safety, compliance or strategic items that cannot earn a return.

The ERP rarely holds the model itself. Good practice attaches the final approved version to the project record so that post-implementation reviews can compare forecast benefit with outcome.

Controlling spend once a project is live

Funds control checks each requisition, purchase order and invoice against the remaining budget. Settings decide whether an overrun produces a warning or a hard stop, and whether tolerances apply between commitment and order value or between order value and invoice.

Commitments matter as much as actuals. A project can look underspent in the ledger while its open purchase orders already exhaust the budget. Reports that show budget, commitments and actuals side by side are the ones project managers trust.

In public bodies, legal limits on spending add another layer: obligations cannot exceed amounts authorised, and breaches must be reported.

Costs, capitalisation and close-out

Direct costs post to the project as they arrive. Internal labour and overhead may be allocated on a defined basis. Periodic settlement moves accumulated cost into assets under construction, then into final asset records when the item goes into service.

Closing projects is the step most often neglected. Open projects with stray budgets invite misposting and blur capital reporting.

Questions to ask the people who run it

• Which system holds the approved budget figure, and who updates it when a committee changes a decision?
• Are overrun checks set as warnings or hard stops, and how often do people ask for them to be overridden?
• How are urgent or emergency purchases handled before formal approval exists?
• Who checks that the capitalisation policy matches asset class and coding settings?
• When a project is split, merged or descoped, what happens to its budget and commitments?
• Is the approved business case stored anywhere a later reviewer can find it?
• Who decides a project is finished, and what prompts the close-out?
• Do project managers use the ERP reports, or do they keep their own trackers, and why?

The answers to the last question often reveal more about the real process than any configuration document.

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.