Why your construction project cost position doesn’t match Finance

Every commercial manager has had this conversation. The project cost report says one thing, the ledger says another, and somewhere between the two a number has to be agreed before the monthly review. The instinct is to treat the gap as an error. Usually it isn’t.

A difference between your project cost position and Finance actuals is normal. The two views are built for different purposes, on different timings, from different source records. The problem is not that they differ. The problem is when nobody can say why.

Two legitimate views of the same project

Finance actuals are the accounting truth for what has been posted in the accounting period. They are governed by policy, cut-off and audit. They are deliberately conservative: a cost exists when it has been recognised and posted, not when it happened on site.

The project controls view is an operational and commercial view. To be useful for decisions it has to account for what has already happened on site, and what is reasonably expected, even where none of it has reached the ledger yet. A project manager cannot wait three weeks for a subcontractor application to be processed before knowing that the frame package is running hot.

Both views are correct. Neither replaces the other. Finance stays authoritative for reported cost; project controls stays authoritative for operational awareness. Reconciliation is the discipline of holding both, visibly, and explaining the space between them.

Six reasons the two numbers diverge

1. Timing and posting period

The most common cause and the least alarming. An invoice received on the 28th may post in the following period. Plant hire, materials and subcontract valuations frequently sit in an approval queue at month end. The cost is real, it is simply not posted yet.

2. Site cost captured before Finance posting

Labour hours, plant on hire, materials taken to work and subcontract progress are recorded on site days or weeks before any commercial document exists. That captured evidence is exactly what makes the project view timely — and exactly what makes it differ from the ledger.

3. Accruals, expected costs and commitments

Where accruals are used, the accounting treatment is Finance’s call and follows policy. The project view may separately carry expected costs and committed spend that have not been accrued at all. These are useful for control but they are not posted actuals, and they should never be presented as if they were. Keep the categories distinct and the difference stays explainable.

4. Allocation and cost-code or WBS mismatch

The project total can be right while every line is wrong. A delivery coded to groundworks that belongs to drainage, or a package split across a WBS in a way the purchase ledger never sees, produces offsetting variances that cancel at project level and mislead at package level. This is the difference that most often hides a genuine problem.

5. Corrections, reclassifications and late postings

Credits, journal corrections and recoded transactions land after the fact and change a prior position. If last month’s reconciliation was agreed verbally and never written down, this month’s variance looks new when it is actually the correction of something already understood.

6. Different cut-off dates

Site reporting often runs to a Sunday; the accounting period runs to a calendar month end. A few days of labour and plant sit permanently between the two. Once you know the cut-off rule, this difference is predictable and should be stated rather than rediscovered every month.

What bad reconciliation looks like

Bad reconciliation is not usually careless. It is the result of pressure to produce one agreed number quickly. The symptoms are consistent:

• Overwriting the project position with the ledger, which destroys the site evidence that made it timely.
• Forcing the two sides to agree with a balancing adjustment that has no stated reason.
• Spreadsheet plugs that survive several months and are eventually owned by nobody.
• Reconciliations agreed in a meeting and never recorded, so the reasoning leaves with the person.

In each case the arithmetic is tidy and the understanding is gone. The next unexplained movement then has no baseline to be measured against.

A better reconciliation model

1. 1.Keep Finance actuals authoritative. Never edit posted values to make a project report agree.
2. 2.Keep captured project evidence separately visible alongside them, at the same level of detail.
3. 3.Identify the difference explicitly, per cost code, rather than only at project total.
4. 4.Record a reconciliation decision and reason for each material difference — timing, allocation, correction, or something that needs investigating.
5. 5.Carry legitimate timing differences forward until Finance catches up, then confirm they cleared.
6. 6.Keep an audit trail so the position can be re-explained months later to a project director, auditor or client.

A worked example

The figures below are illustrative demo data, not customer data. Take a single package at month end.

• Captured project cost: £1,250,000
• Finance actuals posted: £1,180,000
• Difference: £70,000

Presented on its own, £70,000 looks like a control failure. Broken down, it is three different conversations:

• £45,000 timing — a subcontract valuation and two material deliveries received before cut-off but posting next period. Expected to clear; no action beyond carrying it forward.
• £20,000 allocation — plant coded to the wrong cost code. The project total was never wrong, but two packages were. Recode and the package view becomes usable again.
• £5,000 correction — a credit note applied after last month’s report. Explains a movement that would otherwise look like new cost.

Same £70,000, completely different management response. One item needs nothing, one needs a coding fix, one closes out a prior-month question. Only the second affects how you read package performance — and it is invisible if you reconcile at project level.

A monthly review checklist

• Are captured cost and Finance actuals shown side by side at cost-code level?
• Is every material difference categorised as timing, allocation, correction or unexplained?
• Did last month’s timing differences actually clear this month?
• Does any adjustment exist without a recorded reason and owner?
• Are commitments and expected costs clearly separated from posted actuals?
• Could you re-explain this position in six months from the record alone?

If the answer to the last question is no, the position is agreed rather than understood.

Where Foras fits

Foras is built on the assumption that the two views should stay separate and stay visible. Captured site evidence sits alongside imported Finance actuals at cost-code level, the difference is shown rather than resolved automatically, and each reconciliation decision is recorded against the code it belongs to. Finance remains authoritative; Foras does not change accounting treatment or replace your ERP.

The aim is modest and practical: when the project position and the ledger differ, you should be able to say why in a sentence, and show the evidence behind it.