Most Variation Money Is Lost Before Anyone Argues About Price

A variation is a change to the scope, instructed under the contract. It becomes money by travelling a chain: something is instructed, you give notice, you keep records, the work is valued, the valuation is agreed, and the agreed amount reaches a payment certificate. Money exists only at the far end.

Every link in that chain has a time limit written into the contract, and a variation that fails any one of them can be worth nothing regardless of how correctly it was priced.

This is why the common framing — "we need to get better at pricing variations" — usually misdiagnoses the loss. Contractors rarely lose the argument about a rate. They lose because the instruction was verbal and never confirmed, or the notice period expired while the work was being done, or the records that would have proved the disruption were never made, or the variation was agreed months ago and has still not appeared on a certificate.

Two of those failures are commercial judgement. The other two are a tracking problem, and a tracking problem is a system problem.

That is the whole answer. The rest of this article is the chain, link by link, and what to make a system prove it can hold.

An instruction is not always called an instruction

The chain starts with a change. It does not always start with a document titled variation order.

A written instruction is the clean case: the engineer or consultant issues something in the contractual form, and the clock starts on a date nobody disputes.

A verbal instruction is the common case. Someone with authority tells the site to do something different. Most contract forms allow this but require the contractor to confirm it in writing within a stated period, after which it is treated as an instruction if not contradicted. That confirmation is a task with a deadline, produced by someone on site who is busy, and it is one of the two most common places money quietly disappears.

A constructive change is the difficult case: nobody instructed anything, but a revised drawing, a late approval or an answer to a query has changed what you must build. It is a variation in substance and not in name, and it becomes one only if the contractor identifies it and raises it as one. A system cannot detect these. It can, however, make the raising of one a cheap and ordinary act rather than a memo somebody drafts when they get a free hour.

The practical consequence for how this is stored: a variation must be able to exist in your system before anybody has approved it, and before it has a price. If the only way to record one is to create a priced, approved change order, then the entire early part of the chain — where the deadlines are — happens outside the system, on the site manager's phone.

Notice is a deadline, not a formality

Most contract forms require the contractor to give notice within a stated number of days of becoming aware of a change or of an event with time or cost consequences.

The number of days is a contract field. It varies by form, and the particular conditions amend it routinely, so a system that hard-codes any figure is describing a different contract than yours. What does not vary is the shape: there is a clock, it starts on an event, and it is short relative to how long the commercial consequences take to become clear.

That asymmetry is the whole difficulty. Notice is usually due long before anyone knows what the change is worth, which means the notice has to be given on incomplete information, by people whose job that week is delivery rather than contract administration.

The systems consequence is narrow and worth stating exactly: the date the event became known has to be captured at the moment it becomes known, by the person who knows it, and it has to raise the deadline as a visible obligation. A date entered retrospectively by the commercial team from a WhatsApp history is not a record. It is a reconstruction, and reconstructions are exactly what a disputed claim tests.

The valuation hierarchy, and why it depends on the bill

Once instructed and noticed, the work has to be valued. Contract forms generally set out an order of preference rather than leaving it open:

1. If the varied work is the same character and executed under similar conditions to work in the bill, the bill rates apply.
2. If it is similar but the conditions differ, the bill rates are used as the basis of an adjusted rate.
3. If neither applies, a fair valuation or newly agreed rate is made.
4. Where work cannot sensibly be measured, it is valued as dayworks against signed records of time and materials.

Read that list from a systems point of view and one thing stands out: three of the four rungs are references back to the bill of quantities. You cannot apply, adjust or argue away a bill rate that you cannot retrieve — and you cannot defend an adjusted rate without the build-up behind the original, which is the record that most commonly dies in the estimator's spreadsheet on the day the tender is won.

This is the concrete reason the bill and the variation register have to be the same data rather than two documents. A variation priced at "bill rate plus an adjustment" is only auditable if the bill rate it derives from is a stored figure with a version history, not a cell in a file that has been edited fourteen times since.

Approved is not certified, and the gap is the leak

Here is the failure that costs the most and is the easiest to fix.

A variation has states, and they are not two. At minimum it is: identified, notified, submitted, valued, agreed or rejected, included in a certificate, paid. A register with an Approved: Yes/No column collapses all of that into one bit and loses the only distinction that matters to cash — the difference between agreed and certified.

Agreed means the client accepts the amount. Certified means it has been included in a payment certificate. Between those two states sits real, earned, uncontested money that is not being paid, sometimes for months, usually because nobody produced the list.

The question that exposes it takes one line: what is the total value of variations that have been agreed and have not yet appeared on a certificate? In a business where that is a query, the number gets chased. In a business where it is an afternoon's work, it gets chased when cash is tight, which is the worst possible time to be asking a client for a favour.

Because the certificate revalues the whole job cumulatively rather than billing a month's work, an agreed variation flows in as an adjustment to the cumulative position — which is why the payment certificate is the document that has to absorb every variation rather than sitting beside it.

The same chain runs downwards

A main contractor is on both sides of this. Your client instructs variations to you; you instruct variations to subcontractors. The two are governed by different contracts, with different notice periods and different valuation rules.

The expensive pattern is a variation instructed downwards without the corresponding claim being made upwards. The subcontractor's account grows, the cost lands, and there is no matching entitlement recorded against the client — either because the upward notice was missed, or because nobody connected the two events.

Making that connection possible is a modelling decision, not a report. A downward variation that can carry a reference to the upward one it derives from turns "have we claimed for everything we have instructed" from an investigation into a filter. Without that link the reconciliation exists only in the head of whoever ran the package.

The hours spent every month rebuilding that picture by hand are the same category the cost of chaos calculator puts an annual figure against — worth sizing before anyone prices software to remove it.

What to make a vendor show you

On one contract, in front of you:

1. Raise a variation with no price and no approval, dated from a site event, and show it holding a notice deadline.
2. Show the deadline appearing as an obligation for a named person before it expires.
3. Value one variation from an existing bill rate, and show the rate it pulled and the version it pulled from.
4. Value another as an adjusted rate, and show the original build-up alongside.
5. Move a variation to agreed, then show the list of agreed-but-uncertified variations as a query with a total.
6. Include it in the next certificate and show the cumulative contract value change without any figure being retyped.
7. Instruct a variation to a subcontractor and link it to the client-side variation it belongs to.

Step 5 is the one worth insisting on. It is unglamorous, it takes ten seconds when the model is right, and it is impossible to produce honestly from a register that stores approval as a checkbox.

What the rest of the system has to do around this is set out in what a contractor's system has to do before it is worth buying.

The short version

Variations are lost at the beginning and at the end, rarely in the middle. At the beginning, through instructions never confirmed and notice periods that expired while everyone was building. At the end, through amounts agreed and never certified.

Both ends are tracking, and tracking is the thing software is actually good at — provided the model allows a variation to exist before it has a price, holds its states as more than a checkbox, and keeps it attached to the bill rate it was valued from.

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