When finished capital projects never get capitalized

The most common failure is a project that finishes in the field but never closes in the books. The asset goes into service while its cost sits in construction in progress. Depreciation starts late, and stray charges keep landing on a project code that should have been shut.

How it starts

Nobody decides to leave a project open. The problem grows from a gap between two groups. Engineering or operations knows when a plant, building or system goes live. Finance only knows what the ledger tells it. Unless something carries that news across, the project account stays active by default.

Several ordinary habits feed the gap. Project managers keep a code open because a final invoice is still expected. Retention payments hang on. A small snagging list gives everyone a reason to call the job unfinished. Meanwhile the asset is earning its keep on the shop floor.

Open codes also attract spending that does not belong there. Once a code is known to work, people reuse it for maintenance, for the next phase, or for something only loosely related. Every one of those postings makes the eventual settlement harder, because the balance no longer describes one asset.

Where it hides

Construction in progress is a balance sheet account, so it does not shout. It carries no depreciation and rarely draws attention in a profit review. A growing balance can look like healthy investment activity. Budget reports compare spend to approval, and a finished project that came in under budget looks fine on that view.

The damage is quieter. Profit is overstated while depreciation is missing. The fixed asset register understates what the business owns. Insurance schedules, tax claims and return calculations all draw on incomplete data.

How it gets spotted

Auditors often find it first, which is the worst way to learn. Better signals sit inside the process if someone looks for them.

An aging view of construction in progress by project is the most useful single report. Projects with an old start date and no recent cost movement deserve a call. So do projects whose spend has crept past the approved amount without a change request, since that often means unrelated costs have drifted in.

A walk around the site helps too. Equipment that is plainly running but has no tag on the register is a strong clue. Maintenance work orders raised against an asset that finance has never capitalized point the same way.

A third check compares project status in the engineering or project tool against status in the ledger. Where one says complete and the other says active, the mismatch is the finding.

Fixing the backlog

Start by sorting the stuck projects. Some are genuinely still underway. Others are done and simply need settlement. A few are mixed, with costs from several assets or from expense work tangled together.

For the finished ones, agree an in service date with the people who ran the work, and record the evidence. Settle the cost to the right asset classes. Post catch up depreciation from that date, and treat any material prior period effect according to the accounting policy and with the controller's sign off.

The tangled projects take patience. Pull the transaction detail and separate what built the asset from what maintained something else. Reclassify the expense items. Where indirect costs were allocated, check the basis still makes sense for what the asset turned out to be.

Once a project is settled, block further postings to its code. A closed code that still accepts charges is not closed.

Stopping it coming back

The lasting fix is a trigger. Completion should create a notice to finance as part of handover, not as a courtesy. Many teams tie it to the commissioning certificate or the acceptance sign off, so the event already exists and only needs routing.

Give each project an expected completion date when the code is created. At period end, review any project past that date as a standing item on the close checklist. Spend limits on project codes help, because they force a conversation when costs overrun.

Treat final invoices and retention as accruals against a settled asset. Waiting for the last bill is the single most common excuse for leaving a code open, and it is rarely a good one.

Finally, close the loop on returns. A post completion review that compares actual cost and benefit to the original case only works if the project was cleanly settled. Messy settlement makes the review meaningless, which removes one more reason for anyone to care.

Questions to ask the people who run it

• How does finance actually learn that a project has gone live? Who tells them, and in what form?
• Which projects are complete on site but still active in the ledger today?
• Do people ever charge costs to an old project code because it is convenient or already approved?
• What usually holds a project open after handover? Is it invoices, retention, snagging or something else?
• Who agrees the in service date, and what evidence do they keep?
• When a project mixes capital and repair work, who decides the split, and when?
• Can a closed project code still accept postings in the system?
• Has anyone ever compared the engineering project list to the construction in progress listing?
• Does anyone review returns on finished projects, and do they trust the cost figures they get?

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.