How capital project accounting is usually set up in finance and ERP systems

In most ERP systems, a capital project is a cost collector with a budget attached. Spending lands on it through purchase orders and journals, sits in an assets under construction balance, and is settled to fixed assets when the work is finished. Returns are measured afterwards, often outside the ERP.

Project codes and the structure behind them

A project is usually created as its own object in the system, separate from the cost center that owns it. It carries a code, a responsible manager, a legal entity and the asset class it will eventually become. Larger projects break down into a hierarchy of phases or work elements, so costs can be captured at the level where decisions get made.

The code itself matters less than the attributes behind it. These include a flag marking the project as capital, a settlement rule pointing to the target asset, and a status that controls whether postings are allowed. Getting these right at creation saves a great deal of cleanup later.

Some organizations create the project code only after a capital request is approved. Others open it early so design costs have somewhere to go. Both approaches work, provided the treatment of pre-approval spending is agreed.

Recording costs against the project

Transactions reach the project through the normal subledgers. A purchase order line carries the project code, so the supplier invoice posts there automatically. Timesheets assign internal labor. Manual journals handle anything else, such as accrued contractor work or reclassifications out of operating expense.

Indirect costs are the harder part. Where policy allows overhead or interest to be capitalized, the system applies an allocation rule at period end, using a base such as labor hours or direct spend. These rules tend to be configured once and forgotten, which is why they deserve a periodic look.

Everything posted to an open capital project typically sits in an assets under construction account on the balance sheet. Nothing depreciates yet.

Budgets and spending control

The approved budget is loaded against the project, sometimes split by fiscal year or by work element. Availability control then compares commitments and actuals with that budget. Purchase orders count as commitments the moment they are released, which is the whole point of the check.

Controls come in two strengths. A warning lets the user carry on. A hard stop blocks the document until someone raises the budget or approves an overrun. Many teams start strict and loosen the settings once the stops get in the way of urgent work, so it pays to confirm what the configuration really does today.

Tracking reports show budget, open commitments, actual spend and remaining funds side by side. Project managers often keep their own forecast of cost to complete in a spreadsheet, because the system only knows what has been ordered or invoiced.

Period close and capitalization

At each close, finance runs the allocations, reviews accruals and settles any part of the project that is already in use. A building wing that opens before the whole site is finished should begin depreciating independently.

When the project is technically complete, a final settlement moves the remaining construction balance to one or more fixed asset records. The in-service date drives depreciation. It needs to reflect when the asset was ready for use, not the day someone remembered to close the project. After settlement, the status changes to closed so nothing further can post.

Costs that do not qualify for capitalization, such as training or abandoned design options, are written off to expense at this point.

Measuring returns after completion

Post-completion review is the step most likely to live outside the ERP. The original business case sits in a capital request document. Actual benefits come from operational data or a different ledger entirely. Someone has to bring those sources together and compare realized savings or revenue with what was promised.

Where this works, the project code stays visible on the related cost centers or revenue lines, so benefits can be traced. Where it does not, the review becomes an opinion piece.

Questions to ask the people who run it

• Who actually creates project codes, and what do they need before they will do it?
• What happens to costs incurred before a project is approved?
• Does the budget check stop documents, or only warn? Who can override it?
• How are overhead and internal labor allocated, and when was the basis last reviewed?
• How does finance find out that an asset has gone into service?
• Which projects are technically complete but still open to postings?
• Where do cost overruns get approved, and is that approval recorded somewhere auditors can see?
• Does anyone compare actual returns with the business case, and does the result influence future approvals?
• Which spreadsheets run alongside the system, and who trusts them more than the ledger?

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.