Where capital project accounting breaks down

Capital project accounting usually breaks where work passes between project teams and finance. The common failures are codes opened late, spend charged to the wrong place, commitments that budget checks never see, and assets sitting in construction in progress after they enter service. Each one leaves traces in the ledger.

Codes that arrive after the spending starts

A project gets approved in a meeting. The account code gets requested later, often after the first purchase order has gone out. In the meantime, invoices land in a holding cost center, in general operating expense, or on another project that happens to be open.

The evidence sits in suspense and clearing accounts that grow early in a project's life. Look also for reclassification journals that move costs onto a new code, dated after the code went live. If the code setup form is routinely backdated, the request is coming too late.

Miscoding at the point of entry

The person keying an invoice or approving a timesheet rarely knows whether a cost is capital or expense. They pick the code that looks closest. Repairs end up capitalized. Genuine build costs end up in operating budgets, where managers notice them and ask for a fix.

Watch for disputes that surface only when a cost center owner reviews a variance. Heavy manual reclassification at period end is another tell, especially when the same vendors keep turning up in those entries.

Commitments the budget check never sees

Spend controls tend to check actuals posted against budget. Open purchase orders, signed contracts and verbal approvals to contractors are invisible to that check. A project can look comfortably under budget while the obligations already exceed it.

Project managers who keep their own commitment trackers outside the ledger are the clearest sign. So is a sudden jump in spend when a large contract invoice finally posts.

Change orders and overspend workarounds

When a hard limit blocks an invoice, people find a way around it. Costs get split across sibling projects. A new phase code is created to absorb the excess. Sometimes the invoice is simply held until a budget transfer clears, which delays payment and annoys suppliers.

These habits show up as projects with oddly similar names, small budget transfers approved in bulk, and supplier complaints about late payment that trace back to blocked project lines. Change orders approved by engineering but never reflected in the financial budget belong in the same category.

Labour, overhead and work not yet billed

Internal labour depends on timesheets coded to project tasks, and those are often filled in from memory. Overhead allocation depends on a rate or basis that someone set once and nobody revisits. Contractor work completed before an invoice arrives needs an accrual, and that accrual depends on the project manager telling finance the work is done.

When this goes wrong, project costs swing sharply between periods with no matching change in activity. Allocated overhead no longer resembles the effort actually spent, and accruals reverse in full the following period because the estimate was a guess.

The gap between in service and capitalized

An asset starts being used. Operations knows. The fixed asset team often does not, because no one sends a completion notice. The balance stays in construction in progress, depreciation starts late, and catch-up entries follow.

Ageing balances in construction in progress for projects that operations describes as finished is the obvious marker. Large depreciation catch-ups and auditor questions about long-open projects point the same way.

Codes left open after close

Once a project is capitalized, its code should stop accepting charges. Frequently it does not. Late invoices, warranty work and stray timesheet entries keep posting, and each one needs a decision about whether to adjust the asset or expense the charge.

Check for postings to projects already marked complete, and for small residual balances that sit on closed projects indefinitely.

Returns nobody can measure

Measuring the return on a finished project needs a baseline from the original business case and a way to isolate the benefits. Both tend to be missing. The case lives in a slide deck, and the benefits blend into departmental results.

If post completion reviews are scheduled but quietly skipped, or are written up in qualitative terms only, the baseline was never captured in a usable form.

Questions to ask the people who run it

What happens in practice often departs from the procedure document. These questions tend to surface the real version:

• When a project is approved, who asks for the account code, and what gets charged before it exists?
• When an invoice is unclear between capital and expense, who decides, and how?
• Where do project managers track committed spend, and does finance ever see that file?
• What do people do when a budget limit blocks a payment?
• How does the fixed asset team learn that something has gone into service?
• Who closes a project code, and what triggers it?
• Which reclassification entries recur every period, and why have they never been fixed at the source?
• Has anyone pulled the original business case when reviewing a finished project?

Ask these of the clerks, the project controllers and the site managers separately. Their answers rarely match, and the differences mark the handoffs that need redesign.

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.