Skip to content
CoreLabs AI
Insights

Controls / 6 min read / September 2026

Why your job-cost workbook is the legacy risk you keep deferring

It is not in the IT register. It has no backup plan and no owner other than the person who built it. It is also the number the board runs on. A hard look at the spreadsheet that quietly became your system of record, running on borrowed time.

CoreLabs AI

A site office at night: a laptop spreadsheet, printed cost reports and a hard hat on the plan table

Most mid-market contractors have a system of record for job cost. Very few of them know what it is. On the org chart it is the ERP or the accounting package. In practice it is a workbook, built years ago by someone who needed a number the system could not give them, and grown since then by everyone who needed one more column. It is legacy infrastructure in every sense that matters, unsupported, undocumented and one bad week from taking the board's only reliable number down with it, and it rarely gets named that way until it already has.

How a spreadsheet becomes a system running on borrowed time

Nobody decides it. The ERP holds the ledger but not the forecast. The scheduling tool holds dates but not commitments. Someone bridges the gap with a workbook that pulls from both and adds the judgement calls in between. It is faster than the system, more accurate than the system, and more trusted than the system, so leadership starts steering on it. Within a year it is the number in the board pack. Within three it is the only place the real margin position exists, and the business has quietly become dependent on infrastructure nobody would choose to build today.

At that point the business has a system of record that has never been through change control, has no audit trail, cannot be tested, and depends on one person for its logic, a single point of failure wearing a spreadsheet's clothes. If that sounds like an exaggeration, open the workbook and try to explain the formula in the total row to someone who has never seen it.

The five ways it fails

The owner leaves. This is the obvious one and it is still the most common. The knowledge of why the numbers are what they are goes with them, and the business discovers the difference between having a spreadsheet and having a process, usually in the same month a client is asking hard questions.

The source changes. A system update alters an export format, a branch adds a cost code, a subcontractor invoices differently. The workbook keeps producing a number. It is now the wrong number, and nothing flags it, because a legacy system on borrowed time does not announce the day it starts lying to you.

The silent error. A copied range, a hard-coded cell, a filter left on. Industry research puts the cost of bad data to construction at US$1.85 trillion a year and finds that 30% of firms believe more than half of their project data is bad. Very little of that is malicious. Most of it is a workbook doing exactly what it was told.

The timing gap. The workbook is refreshed weekly because it takes a person a day to refresh. Leadership reads Friday's position on the following Wednesday. Decisions on labour, procurement and claims are made on a number that is already history, on a business that has grown well past the point this process was built for.

The claim. A client or a regulator asks for the cost history behind a variation. The history exists as a chain of saved-as versions in a shared drive, with no record of who changed what or when. The position is right. It cannot be proven, and that gap is exactly where a contract dispute turns expensive.

What replacing it actually means

It does not mean a new ERP. Replacing an ERP to fix a workbook is how eighteen-month programmes start, and how deferred investment turns into a crisis rebuild instead of a planned one. It means treating the workbook as the requirements document it secretly is: it already describes the real workflow, the real exceptions and the real judgement calls, because it was built by the person who lives them. The job is to move that logic into a governed system with an audit trail, exception handling and a path to production, and to validate the new output side by side against the old one until both sides sign off.

Done that way the person who built the workbook stops being a single point of failure and becomes the most valuable reviewer in the room, because they are the only one who can say whether the new number is right. The board gets a position that is minutes old rather than a week old. And the next time someone asks for the history behind a number, it is a query, not a search.

The workbook was never the problem. It was the best answer available to a person who needed one. The problem is that the business built itself on it, kept deferring the fix, and never noticed how much risk it had quietly agreed to carry.