Capital project accounting: what to automate, what to keep human, and the data it depends on

Software can already open project codes, apply account coding to most project transactions and stop commitments that would breach an approved budget. A person still has to judge what is capital and what is expense, and decide when an asset is ready for use. Clean project and asset master data has to come first.

Steps a system can carry today

Opening a project code is the easiest step to hand over. Once a capital request is approved, a workflow can build the project, its tasks and its cost objects from a template. It can attach the approved budget and spend limits, then link each task to the asset class it will eventually settle into. Nobody needs to retype anything.

Recording transactions follows the same logic. Purchase orders, supplier invoices, timesheets and internal labour charges can carry the project and task code from the moment they are raised. Matching engines handle the routine invoices. Overhead and indirect costs can be spread by a rule the system applies every period, provided the allocation basis is captured somewhere reliable.

Funds control is where automation earns its keep. A system can check every requisition against remaining budget at the project or task level and either warn or block. It can also compare commitments and actuals against plan and flag variances before month end, which turns monitoring from a monthly scramble into a standing report.

At period end, the system can post accruals for work done but not yet invoiced, calculate interest to be capitalised where policy allows, and settle completed tasks to assets under construction. Depreciation can start automatically once an in-service date is entered.

AI tools are useful at the edges. They can suggest a project code for an uncoded invoice by reading its description, spot charges that look like operating costs sitting in a capital project, and draft variance commentary for a reviewer to edit. Treat each of these as a suggestion queue. None should post without review.

Decisions that stay with a person

The capital versus expense call is a judgment. Feasibility work, training, repairs and abandoned design options all sit near the line, and accounting policy rarely settles every case. An experienced accountant should own that call, with an engineer or project manager providing facts.

The in-service date is another. A building can be occupied while snagging continues. Software can be live in one region and still in testing elsewhere. Someone has to decide when the asset is substantially ready for its intended use, because that date drives depreciation and stops capitalisation.

Projects that stall or get cancelled need a human too. Writing off sunk costs, assessing impairment and agreeing with the business that a project is truly dead are conversations, not calculations.

Measuring returns on finished projects can be partly automated, since actual cost and some benefit data can be pulled together. Interpreting why a project missed its case, and whether the original assumptions were reasonable, belongs with finance and the sponsor together.

What the data must look like before automating

Every project needs a single owner, an approved budget loaded in the system and a clear structure of tasks. If budgets live in a spreadsheet and the ledger only holds actuals, budget checks will run against nothing.

Coding has to happen at the source. When requisitioners leave the project field blank and accounts payable fixes it later, automation simply moves the error downstream faster.

Each task should map to an asset class and a useful life before work starts. Settlement rules defined at the end of a project are where most manual rework comes from.

The allocation basis for overheads, whether labour hours, headcount or floor space, must be captured consistently each period. An allocation rule fed with stale drivers produces confident nonsense.

Evidence of completion needs a home. A handover certificate, a go-live sign-off or a commissioning note should be stored against the project so the in-service date can be traced.

Finally, the project subledger must reconcile to the general ledger every period. If it does not, fix that before adding anything new.

Questions for the people who run it

Documented procedures often describe the intended process. These questions surface the real one.

• When an invoice arrives without a project code, who decides where it goes, and how do they decide?
• Which projects get closed late, and what usually holds them up?
• Are there costs that routinely move from capital to expense after review, or the other way?
• Who tells finance that an asset is in use, and does that message ever arrive after depreciation should have started?
• Do project managers keep their own tracking outside the system, and which figures do they trust more?
• How are budget changes approved in practice, and do revised budgets always reach the system?
• When a budget check blocks a purchase, what happens next? Is there a workaround everyone knows?
• Has anyone ever compared a finished project's actual return to its original case, and what happened to that analysis?
• Which manual journals are posted to projects every month, and why do they exist?

The answers to the last two questions tend to show where automation will help most and where the process itself needs redesign before any tool is switched on.

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.