A 60-person contractor running eight projects. Procore for programme, Sage for actuals, a site spreadsheet for cost-to-complete, and a 90-minute Wednesday cost review that spent the first 20 minutes reconciling three different numbers. Here is what we connected, the six tiles we built, and the three outcomes, including a 9% package overrun caught in week seven instead of month three.

This is a case study from a build we completed in early 2026. The client is a mid-size construction contractor, 60 people, running eight active projects simultaneously across commercial fit-out and residential development. We have anonymised the company name and kept the numbers as close to real as we are able to share.

Before: the Wednesday cost review

Every Wednesday afternoon, the project manager and commercial manager sat down for the weekly cost review. It took 90 minutes. Roughly 20 of those minutes were spent reconciling three different cost figures before they could start the actual conversation.

The PM tool (Procore) had the programme, what was planned, what was complete, what was behind. The accounting system (Sage) had the financial actuals, what had been invoiced, what had been paid, what was committed. The site manager maintained a spreadsheet updated from memory after the Friday site walk, with a manual cost-to-complete estimate that nobody in the office fully trusted but everyone used as a sanity check.

Each of the three sources was accurate in its own domain. None of them agreed with the others. The reconciliation exercise, matching Procore activities to Sage cost codes, then checking both against the site spreadsheet, was not optional. If they skipped it, the review was meaningless. If they did it, 20 minutes of the meeting was housekeeping before the work started.

The things this process missed regularly:

Package overruns that were visible in the cost trajectory by week four or five but only surfaced at the month-end when Sage and Procore were formally reconciled. RFIs sitting on the critical path for days without anyone having a clear view of which ones were blocking programme progress. Subcontractor payment status that the PM had to check separately in Sage to understand whether a delay was a performance problem or a cash flow dispute. Cash burn against forecast that required manually dividing Sage actuals by Procore programme percentage to get a meaningful number.

The commercial manager described it plainly: the data existed to catch a package overrun in week five instead of month three. It just lived in three places, and getting it into one place took longer than the meeting was designed to allow.

What we built

The brief from the discovery call was direct: the PM and commercial manager needed to walk into the Wednesday review already knowing what was overspent, what was behind, and what was at risk, without spending the first 20 minutes assembling that picture from three exports.

We connected three sources: Procore (via API, programme activities, completion percentages, RFIs, and subcontractor submissions), Sage (via a scheduled daily export, cost codes, committed costs, invoiced amounts, and subcontractor payment status), and the site manager's spreadsheet (migrated to a shared Google Sheet with a structured update template, refreshed after each Friday site walk). The board has six tiles, covering eight active projects simultaneously:

Cash burn vs forecast. Actual spend to date against the Procore programme completion percentage, by project. The number the PM and commercial manager previously calculated manually by dividing Sage actuals by Procore percentages. Updated daily from both sources. A project burning faster than its programme is completing shows as an amber flag; a project burning significantly faster shows as red.

Cost-to-complete. Committed costs from Sage plus the site manager's estimate of remaining work, broken out by trade package. The first time the site manager's estimate has ever been formally combined with the committed cost picture, instead of living in a separate spreadsheet nobody fully believed.

Programme progress by project. Procore activity completion, overall and by phase, against the baseline programme. Tasks more than five days behind show amber; more than ten days show red. Replaces the PM's manual extraction of Procore activity data into a summary slide before each meeting.

RFI age and status. All open RFIs, sorted by age, flagged if they are on the critical path. Pulls from Procore's RFI module. An RFI that has been sitting open for more than five working days on a critical activity gets an escalation flag, visible to both the PM and the director without anyone having to check Procore manually.

Subcontractor payment status. Outstanding payments by subcontractor, by project, from Sage. The tile that makes it possible to distinguish between a subcontractor who is performing poorly and one whose performance is suffering because they have not been paid. The PM previously had to cross-reference Sage manually to make this call during site review conversations.

Package variance. Actual and committed spend by trade package against the contract budget, by project. The overrun indicator the commercial manager checks first every Wednesday. Flags a package that is tracking more than five percent over budget so the commercial manager can investigate before it becomes a variation order conversation.

Build time was seven days. Day one: discovery, mapping the Procore activities to the cost codes in Sage, understanding the site spreadsheet structure, agreeing which eight projects to include. Days two and three: Procore API integration, programme and RFI tiles. Days four and five: Sage export pipeline, cash burn and cost-to-complete tiles. Day six: Google Sheet integration, package variance tile, review session with the PM and commercial manager. The board went live on day seven with a two-hour handover session for the PM, commercial manager, and director.

After: three months in

The Wednesday cost review now starts with the board already open. The reconciliation exercise is gone. The meeting runs 40 minutes instead of 90, not because they are covering less ground, but because they arrive knowing what the ground looks like.

Three specific outcomes that were measurable within the first quarter:

A 9% package overrun caught in week seven. On the largest active project, a commercial fit-out, the package variance tile showed groundworks tracking 9% over the contract budget in week seven. The commercial manager raised it with the groundworks contractor in the week eight site meeting, agreed a revised scope, and the overrun was contained before it became a formal variation. Under the previous process, the first formal signal would have been the month-three cost review, at which point the variation would already have been inevitable. The commercial manager's estimate: catching it in week seven rather than month three saved between £18,000 and £25,000 in commercial exposure on that package.

An RFI blocker resolved before the slab pour. On a residential development, an RFI concerning the reinforcement specification had been open for nine days. It appeared on the RFI tile with a critical- path flag on a Thursday morning, the PM had not registered it as critical-path when it was submitted, because at submission time the slab pour was two weeks out. By Thursday it was four days out. The PM escalated the same afternoon, the engineer responded the following morning, and the pour proceeded without delay. Under the previous process, the RFI would have appeared in the Procore inbox without a flag and might not have surfaced until the foreman arrived on pour day.

The site spreadsheet stopped being a problem. Moving the site manager's cost-to-complete estimate from a personal spreadsheet to a structured Google Sheet template, with the same cost-code structure as Sage, did not change how long it took to update. What changed was that the update was now visible to the office the same day it was made, rather than being emailed on request. The commercial manager noted at the three-month check-in that she had stopped asking for the spreadsheet to be sent, because it was already in front of her.

What made it work

The data was not the problem. Procore, Sage, and the site spreadsheet each had accurate information in their domain. The problem was the join, making the commercial question ("are we overspending?") answerable from a single view rather than requiring a manual reconciliation of three sources.

The discovery call spent most of its time on the cost code structure. Procore's activity list and Sage's cost codes do not share a common key by default, the mapping had to be built manually with the commercial manager, who knew which Procore activities mapped to which Sage codes. That mapping is the foundation of the cash burn tile. Without it, the tile would show a number, but it would not be the right number.

The package variance tile is the one the commercial manager checks first every Wednesday. Not because we designed it that way, because it answers the question she was spending 20 minutes of every meeting trying to get to.