Why construction projects always have two sets of numbers

The PM has a forecast in the project management tool. The site manager has different actuals from the ground. Finance has a third version in the accounting system. Every week someone reconciles them manually, and every month the overrun is a surprise anyway. This is the most expensive data problem in construction, not that the data does not exist, but that it lives in three places and nobody has the same number at the same time. Here is what causes it, what it costs, and what a single project board actually requires to solve it.

It usually surfaces on a Wednesday evening. The project manager has spent the afternoon updating the programme and the cost forecast in the project management tool. The site manager calls, asks why the system is showing thirty percent complete on groundworks when the team finished sixty percent today. The PM explains that the system only gets updated when someone logs progress. The site manager points out that he sent a WhatsApp with photos on Monday. The argument about whose number is right runs until nine.

This call, or something very like it, happens on most live construction sites every week. The specific tools and the specific numbers vary. The structure does not.

Why there are always two sets of numbers

A construction project generates data in at least three separate systems, and none of those systems were designed to talk to each other.

The project management tool, Buildertrend, CoConstruct, MS Project, Asta Powerproject, or a variant, holds the programme, the task breakdown, and the cost forecast. It is updated by the PM, usually once or twice a week, from a combination of direct entry and whatever the site manager has reported in. It is the PM’s view of the project.

The accounting system, Sage 200, Xero, QuickBooks, or a construction-specific tool like Causeway, holds purchase orders, subcontractor applications for payment, invoices posted, and the actual cost codes. It is updated by finance when documents arrive. It is the finance team’s view of the project, which lags the work on site by two to four weeks because that is how long it takes invoices to arrive and get processed.

The site, daily logs, weekly progress photographs, RFI responses, delivery records, labour timesheets, generates a third dataset that captures what actually happened. Most of it lives in WhatsApp group messages, email threads, shared Dropbox folders, and site diary entries that do not automatically connect to anything else.

When a PM asks “where are we against budget?” the answer requires pulling from all three. The PM tool shows forecast vs committed cost, but the committed cost only includes what finance has entered. The accounting system shows actual spend but nothing about programme progress. The site data shows physical progress but nothing about cost. Someone has to reconcile them. That reconciliation, done monthly at best, is where the overrun is always a surprise.

What the lag actually costs

The standard defence of monthly reconciliation is that the work is moving too fast for daily reporting to be practical. This is true. What it misses is that the cost of discovering an overrun in month three is not the same as discovering it in week three.

On a typical project we see, the monthly reconciliation produces a cost report that finance sends to the PM and the commercial manager. The PM reviews it and finds that the groundworks package is running twelve percent over the cost plan. The question is immediately: when did this start? If the overspend began in week four, the project has been absorbing it for six weeks before anyone noticed. At that point, the options are limited: value engineer something elsewhere, have a difficult conversation with the employer, or carry the overrun. All of them are harder and more expensive than they would have been at week four.

RFI cycle time is a second cost that reconciliation cannot catch. An RFI sent to an architect in week two and not responded to by week five is blocking work. The PM knows this, they have a list of open RFIs, but the list is usually a spreadsheet, and whether a given RFI is blocking a critical path item or a non-critical task requires cross-referencing the programme. That cross-reference almost never happens in real time. The blocker sits open for two weeks before anyone escalates it.

What the board looks like

For a contractor running six live projects simultaneously, the brief we received was specific: the commercial director needs to see the financial health of every project in one view, updated weekly, without having to chase individual PMs for reports. The weekly PM reports were taking two days to compile and were still out of date by the time they reached her.

The data sources we connected were the project management tool (Asta Powerproject, via a weekly data export into a structured format, live API was not available), the accounting system (Sage 200, via an existing data feed), and a simple form the site managers filled in each Friday afternoon covering physical progress percentages and any open blockers. Three sources. The form took the site managers four minutes.

The board has six tiles per project, displayed in a portfolio grid. Cash burn: actual spend this week against the forecast at this stage of programme, with a colour flag for any project where actuals are tracking more than eight percent above plan. Cost-to-complete: remaining budget versus the PM’s current estimate to complete, updated when the form is submitted. Programme progress: reported physical completion this week versus planned completion at this date. RFI age: the oldest open RFI on each project, with a flag if any item is over ten working days without response. Subcontractor application status: how many applications for payment are currently under assessment and whether any are overdue for response. And a single free-text cell for the commercial director to note anything the data cannot capture.

The board does not require the PM to update the project management tool more frequently than before. It does not require finance to change how invoices are processed. The only new input is the four-minute Friday form from site. Everything else is read from systems that already existed.

What changed

The two-day weekly report was replaced by the board in the fourth week. The commercial director’s view of the six projects went from a document that was already a week old when she received it, to a board that was current as of Friday afternoon when she looked at it Monday morning.

The cash burn flag caught an overrun on a fit-out project in week seven, the groundworks subcontractor had submitted two invoices that pushed the package to nine percent over plan. It was caught on Monday. The previous reconciliation process would have surfaced it in the monthly report, four weeks later. The commercial director opened a variation discussion with the employer in week eight. The outcome was the same; the timing was not.

The RFI age tile surfaced a structural design query that had been open for eleven days without response, sitting on a critical path item for a ground-floor slab pour. The PM had it on her list but had not escalated because she did not know it was critical path. The board made the connection visible. The architect responded within 24 hours of the escalation. The pour was not delayed.

The commercial director told us, at the eight-week review, that she had stopped having the nine-pm argument with site managers. Not because the data problems had gone away, but because the Friday form and the Monday board meant that by the time any discrepancy surfaced, everyone was already looking at the same number.

If your weekly cost report is a spreadsheet that takes two days to compile and is out of date when it arrives, book a call. Bring the names of the tools your PMs and your finance team currently work in. That is usually enough to scope the board on the first call.