Who knows what in capital project accounting, and where the gaps bite

Each role holds a piece the others lack. Project managers know when an asset is in use. Accountants know what the ledger holds, and buyers know what has been promised to suppliers. The gaps show up as late capitalization, spend checks that miss commitments, and return reviews built on guesswork.

Setting up the codes

The project accountant who creates a new project code knows the chart of accounts. That includes which segments drive capitalization, which cost types count as expense, and how the code will roll up for reporting. The engineer or sponsor requesting the code knows what is actually being built. They often describe it in a single line on an approval form.

That single line decides a lot. If a project mixes a new building with repairs to an old one, the accountant needs separate cost objects from day one. The sponsor rarely thinks to say so. Months later, someone has to split costs by hand, usually from invoices that were never coded with the split in mind.

Spend limits get set here too. Finance loads the approved budget against the code. The budget owner may know that part of the approval was conditional, or that a second phase needs its own sign-off. If that nuance stays in an email thread, the system treats the whole amount as available.

While money is being spent

Procurement sees purchase orders and contract commitments. Accounts payable sees invoices once they arrive. The project accountant sees whatever has been posted. Each one can report a different number for the same project, and each is correct about its own slice.

Overspending controls usually check posted actuals against the budget. They often ignore open commitments. A project can look comfortable in the ledger while procurement already knows the remaining budget is fully committed. The project manager sometimes knows more than either: a change order agreed verbally on site, a contractor claim that has not been submitted, a scope increase the sponsor approved in a meeting.

Indirect costs add another blind spot. Finance knows the allocation basis for overheads and internal labour. Project managers frequently do not, so they see charges appear that they cannot explain. Disputes follow, and some managers start keeping shadow spreadsheets. Once a shadow spreadsheet exists, the official report stops being trusted.

The in-service date nobody reports

Capitalization depends on when an asset is ready for use. Only the people on site really know that date. The fixed asset accountant needs it to start depreciation and move costs out of construction in progress. There is often no routine trigger that carries this fact from operations to finance.

So assets sit in construction in progress long after they are running. Depreciation starts late. At period end, the accountant chases project managers for status, and gets answers like "mostly done" that cannot be booked. Retentions and final invoices arrive after the asset is in service, and someone has to decide whether they belong to the original asset or need a separate adjustment.

Tax and fixed asset teams may also need component detail the project never captured. A plant asset recorded as one lump cannot easily be split into its parts for different useful lives.

After the project closes

The sponsor knows what benefits were promised in the business case. Finance knows the final cost. Operations knows whether the asset delivers what was claimed. These three rarely meet.

Measuring financial returns needs all of it. Without a named owner for the review, it becomes a cost comparison against budget and nothing more. Savings that were the whole reason for the project go untracked, partly because the operating budget absorbed them quietly and nobody tagged them back to the project.

Closing the code itself causes trouble when people outside finance do not know it has closed. Late invoices get rejected or posted to a general overhead account, and the true project cost drifts.

Questions to ask the people who run it

• When a new project code is requested, what information do you actually receive, and what do you have to go back and ask for?
• Where do you keep commitments that are not yet purchase orders, such as agreed change orders?
• Which number do you trust when the project report and your own records disagree, and why?
• How do you find out an asset is in use? Who tells you, and how late does that usually come?
• What happens to an invoice that arrives after the project code is closed?
• Do project managers understand the overhead and labour charges on their projects? Who explains them when they ask?
• Who reviews whether a finished project delivered its promised benefits, and has that review ever changed a later decision?
• Are there projects where costs were split by hand after the fact? What would have prevented it?
• Which approvals live outside the system, in emails or meeting notes, but still change how much can be spent?

The answers usually reveal a workaround that keeps the process running. Remove it without replacing what it does, and the gap it was covering opens again.

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.