The Bill You Priced Is Not the Bill You Are Building

A bill of quantities is a priced list of the work. Every item carries a description, a unit, a measured quantity and a rate. Multiply, total, and you have the contract sum. That is the entire document, which is why estimating looks straightforward from the outside.

The difficulty is that three different bills exist on every job, and only one of them is in the contract.

The estimator's bill carries a build-up behind every rate — labour, material, plant, subcontract, overhead, margin. The contract bill keeps the rates and discards the build-up; the client agreed a number, not your reasoning. The bill being built carries quantities that match neither, because quantities get remeasured, provisional sums get instructed, and variations introduce items nobody priced at tender.

Margin lives in the differences between those three. Most contractors cannot see the differences, and the reason is structural rather than careless: the build-up stayed in the estimator's spreadsheet, the contract lives as a PDF, and the cost ledger is coded by supplier and cost type rather than by bill item. Nothing joins them.

That is the whole answer. The rest of this article is where each drift happens, and what to make a system prove before you trust it with a tender.

A rate is a build-up, and the contract keeps only the answer

The number in the rate column is a conclusion. Behind it sits a calculation: quantities of labour hours, material with waste allowance, plant time, any packages priced by a subcontractor, then an addition for site overhead, head office overhead and profit.

That calculation is the only place your margin is stated explicitly. Once the tender is submitted, the client has the conclusion and nothing else — correctly, because they contracted for a price, not for your cost base.

The problem is that the contractor usually loses it too.

The build-up lives in the estimating spreadsheet. The job is won, the contract is signed, and the operational system is loaded with the contract bill: item, unit, quantity, rate. The resource detail behind each rate is not carried across, because the system has nowhere to put it. From that day the business knows what it is charging and has no structured record of what it assumed the work would cost.

The consequence shows up months later as a question nobody can answer quickly: is this item making money? Answering it requires the rate build-up, the actual cost incurred against that item, and both in the same units. Most contractors have the first in a file, the second in a general ledger organised on a different logic, and no bridge.

This is not a reporting gap. It is the absence of the record that reporting would read.

Quantities are not facts

The second drift is the one that surprises people who have not worked on a measured contract: the quantities in the bill are an estimate, and on many contracts they are explicitly provisional.

Where the contract is a remeasurement contract, the bill quantities are the surveyor's forecast of what the drawings imply. The work is then measured as it is actually built, and the measured quantity is what gets paid — up or down. An item billed at one quantity and built at another is not a variation and not an error. It is the contract working as written.

Where the contract is lump sum, the quantities are fixed and the risk of getting them wrong sits with whoever prepared them. But even there, variations change the scope, and each variation adds items or adjusts quantities against the original bill.

Either way, the bill is a living quantity set rather than a fixed one, and this has a direct consequence for how a system must store it. A bill held as a static list — imported once, never versioned — cannot answer what changed, when, or why. A bill held as a base plus a sequence of adjustments can, and the sequence is the audit trail a claim is built from.

The same cumulative logic governs the certificate that pays for it all, which is why the payment certificate revalues the whole job every month rather than billing the month's work. The bill and the certificate are two views of one measured position. Systems that treat them as unrelated documents make the contractor the integration layer.

The three priced unknowns

Every bill contains items that are deliberately not fully priced at tender, and each behaves differently:

Item	What it is	How it resolves
Provisional sum	An allowance for work described but not yet defined	Instructed and valued when the scope is issued; the allowance is omitted
Prime cost sum	An allowance for goods or a package to be supplied by a nominated party	Replaced by the actual cost, with your attendance and profit added separately
Dayworks	Work with no applicable rate, valued on recorded resources	Paid against signed time and material sheets

These are ordinary contract mechanics, and they are where a general ERP tends to fail quietly rather than loudly. The allowance sits in the contract sum as a line with a value, so the totals look right. When the work is instructed, the allowance has to be removed and the valued work added — a substitution, not an addition. Systems that cannot express that substitution end up double-counting the allowance, and the contract sum reads high until somebody reconciles by hand.

Dayworks have a different failure. The valuation depends on records made on site, signed at the time, by someone who was there. A daywork sheet that is not signed within days is not evidence, and no amount of accounting rigour later recovers it. This is a workflow requirement before it is a software one, but it is exactly the kind of requirement software either supports on a phone at the workface or does not support at all.

Why actual cost never lands next to the rate

Here is the drift that costs the most and gets discussed the least.

A bill is structured by work — trades, sections, elements, items. A cost ledger is structured by accounting — supplier invoices, payroll runs, plant hire, materials by account code. These are different taxonomies of the same money, and neither converts to the other without a deliberate link.

That link is a cost coding structure, decided before the job starts, that maps every incurred cost to the bill item or work package it belongs to. Where it exists, the question "what did this item actually cost against what we priced it at" is a query. Where it does not, the same question is a week of somebody's life, produced once at the end of the job, too late to change anything on that job and usually too late to inform the next tender either.

The recurring version of this is a contractor who knows the project margin and cannot decompose it. The job made or lost money and nobody can say which items did it, so the next estimate repeats the same assumptions — including the wrong ones. The cost of that is not a line item; it is the reason a contractor can run profitably for years and never improve their rates.

It is also a measurable cost in its own right. The hours spent every month reassembling this by hand are the same category the cost of chaos calculator converts into an annual figure — worth putting an order of magnitude on before anyone prices software against it.

What to make a vendor show you

The bill is a good demonstration test because it looks like a spreadsheet and is not one. Ask for these in front of you, on one contract:

1. Load a bill with sections and items, then show the rate build-up stored behind one rate — not attached as a file.
2. Remeasure one item downwards and show the contract value adjust without a credit note.
3. Instruct a provisional sum and show the allowance removed and the valued work added as one movement.
4. Enter a daywork sheet and show it reaching a valuation.
5. Show actual cost to date against one bill item, next to the rate it was priced at.
6. Add a variation and show it appear as a new item in the bill, carrying its own rate.

Item 5 is the one that separates products. Most systems can hold a bill; far fewer can put incurred cost beside the priced rate at item level, because that requires the cost coding structure to have existed since day one.

What should be true of the whole system, of which the bill is one part, is set out in what a contractor's system has to do before it is worth buying. And the deduction that sits on top of every valuation the bill produces — retention, its cap and its two release dates — is a separate mechanism with its own failure mode.

The short version

There are three bills. The estimator's has the build-up and usually dies in a spreadsheet. The contract's has the rates and is legally binding. The one being built has the real quantities and only exists properly if the system versions it.

A system worth buying holds all three and can put them side by side at item level. A system that holds one of them — the contract bill, as a static import — will produce correct-looking totals for the whole job and answer no useful question about where the money went.

What that looks like built, with the certificate, the retention and the variation chain around it, is on the contracting page.