Ask a project tool what a job has cost so far and most will give you a number. Spent, remaining, percentage consumed. It is a clear answer and it is usually correct.

Then ask the harder question — why is the number what it is — and the same tool will have nothing to say. Not because the data is missing, but because the shape it was stored in cannot answer that class of question. A budget line holds a current figure. It does not hold the sequence of events that produced the figure, and once you need to explain an overrun to a client or a board, the sequence is the only thing that helps.

The discipline that solves this is old, well understood, and almost entirely absent from software-first project tools. It comes from construction, where it is called a bill of quantities, and the four properties that make it work are worth understanding whether or not you pour concrete.

Property one: increments, not running totals

The natural way to build this in software is to store a "completed" figure per line and update it as work progresses. Two hundred metres done, then four hundred, then six-fifty. Simple, and it gives you the current state instantly.

It also destroys the history. When the figure moves from 400 to 650, the record does not say whether that was one booking of 250 or five bookings across three weeks, or a booking of 300 followed by a correction of 50. All of those produce the same current number and mean very different things.

A bill of quantities stores the increments. Each entry is an event: this much work, on this date, by this person. The current total is derived by adding them up, never stored as an authoritative figure in its own right. That inversion is the foundation — everything else depends on the total being a consequence of the record rather than a field in it.

Property two: the rate is snapshotted at booking

Rates change. Materials move, a supplier renegotiates, a contract has an escalation clause. If the rate lives only on the bill line and the value of past work is calculated against the current rate, then changing a rate silently rewrites what everything before it cost.

This is not a hypothetical failure. It is the standard behaviour of a spreadsheet with a rate column and a formula, and it means that the moment a rate is updated, every historical figure in the project quietly becomes wrong — in a way that produces no error, no warning, and no visible change to anything except the totals.

The fix is that each booking carries the rate it was made at. Work booked in March is valued at March's rate forever, regardless of what happens to the rate afterwards. The line's future work uses the new rate. Both facts are true and both are preserved.

Property three: corrections are reversals, not edits

Somebody books 300 when they meant 30. This will happen, and how the system handles it is the clearest test of whether you have a ledger or a spreadsheet with ambitions.

The intuitive fix is to edit the entry. Change 300 to 30, move on. The total corrects itself, the screen looks right, and the mistake is gone — which is exactly the problem. The mistake happening is itself a fact, and it is often the most useful fact in the record. Somebody booked ten times the actual quantity and it took two weeks to notice: that tells you something about your process that the corrected number never will.

In a ledger, a correction is a new entry that reverses the original and points at it. The original booking stays. The reversal stays. The total is right, and the history of how it got right is intact. Auditors ask for this, but the deeper reason to want it is that a record you can edit in place is not a record — it is a current opinion with a timestamp.

Property four: variations stay separate from the bill

This is the one that costs the most money when it is done wrong, and it is done wrong almost universally.

A project is agreed at a certain scope. Partway through, the client asks for something additional, it is priced, approved, and executed. The question is where that approved change lives.

The convenient answer is to add the quantity to the relevant bill line. The line grows, the total grows, everything reconciles. The project reports as being on budget against its updated bill, and everyone is satisfied.

What has just happened is that the reason the project grew has been erased. The original bill no longer says what was agreed. There is no longer a difference between planned and actual, because the plan has been rewritten to match the actual. Six months later, when someone asks why this job cost forty per cent more than the comparable one, the record has no answer — it says the job always cost that.

Kept separate, both facts survive. The original bill shows what was agreed and what was delivered against it. The variations show what changed, when, who approved it, and what it cost. The overrun becomes explainable, which is the difference between a difficult client conversation and an impossible one.

Why this matters outside construction

The vocabulary is construction's, but nothing about the four properties is specific to building things. They apply wherever money is committed against measured work: fabrication, interiors and fit-outs, engineering services, plant maintenance, and fixed-scope professional engagements where the deliverable is itemised.

The test for whether you need this is not your industry. It is whether the following question has an answer in your current system:

"This project overran by twenty per cent. Show me where."

If the answer requires someone to reconstruct it from emails, invoices and memory, then what you have is a budget rather than a ledger. That is fine right up until the moment it isn't, and the moment it isn't is always a moment when the stakes are already high.

The shape of the fix

None of this requires sophisticated software. It requires a data model that refuses to overwrite: entries are added, never changed; totals are derived, never stored; the rate travels with the booking; and change to scope is recorded as change rather than absorbed into the original.

Most project tools cannot do this, not because it is difficult but because they were designed by people whose projects did not have bills. The result is a category of software that handles schedule well and money badly, which is an odd place to end up given that money is usually the reason the schedule matters.

GoWarm Work treats the bill of quantities as a first-class part of the project rather than an export. Increments, rate snapshots, corrections as reversals, and approved variations kept apart from the original bill — with a negative figure in Left meaning that line has overrun what was sanctioned for it, visibly, on the day it happens.