Change Order & Variation Register
Track every change order and variation on a contract: value submitted against value approved, days waiting for a decision, and the work you have already started without written approval. Runs entirely in your browser — nothing is uploaded.
Version 1.0.0 · Updated Aug 5, 2026
Overview
How to use Change Order & Variation Register
The complete in-tool guidance, reproduced here so you can read it before you download.
What this tool does
CM8-72 is a register of changes to one contract. You record each variation from the day it is first identified, follow it through submission and decision, and the tool works out what the contract sum has become, what is still hanging, how long decisions are taking, and — the figure most registers hide — how much work has already been done on site without a written approval behind it.
The point of a register is not administration. It is that at the end of the job somebody will ask how the contract sum went from the original figure to the final one, and you need to be able to answer that line by line, with a date and a decision against each step. This tool keeps that answer in one place.
Everything runs inside this single file. There is no account, no upload and no network request of any kind, so commercially sensitive values never leave the computer you are using.
What belongs on the register
Everything that could change the price or the programme, from the moment somebody first says it out loud. A change that is only in an email, only in a meeting minute or only in somebody's head is exactly the change that gets forgotten and then paid for out of your own margin.
- Instructed changes — a written instruction has been issued and there is no argument that it is a variation.
- Changes you believe are variations — you have been told to do something you say is outside the contract, and the other side may not agree. Record it, submit it, and let the status say "disputed" rather than leaving it off.
- Site conditions — something found that the documents did not describe.
- Errors and omissions — in either direction. Some will be rejected; that is a result, not a reason to leave them off.
- Savings and omissions — value engineering, work taken out, specification substitutions. Enter these as negative values so the contract sum moves the right way.
Keep one register per contract. The original contract sum is a single setting, so a register covering two contracts will produce a revised sum that belongs to neither. Use the project field for the package or section within one contract.
The fields, and why each one matters
Reference is what everyone will quote in correspondence, so use the numbering the contract administrator uses, not your own. Date raised is when the change was first identified, which is usually earlier than the day you priced it — and it is the date the monthly chart and the date filters use. Date submitted starts the response clock. Date of decision stops it.
Originator is who or what caused the change, not who wrote the paperwork. It is the field that decides who is likely to pay, and it is worth being honest in it: a register in which nothing is ever originated by the contractor will not be believed.
Instruction reference is the written authority for the work. An approved value with no instruction reference against it is the weakest line on any register; the tool cannot check whether the instruction exists, but leaving the field empty is a useful reminder that it does not.
Status and what it means for the money
- Status — Meaning — Effect on the contract sum
- Identified — Known about, not yet submitted — None — forecast only
- Submitted — With the other side, clock running — None — forecast only
- Under review — Being assessed — None — forecast only
- Approved — Decided and instructed — Approved value is added
- Rejected — Decided against — Nothing is added, ever
- Withdrawn — Taken back before a decision — None, and excluded from approval rates
- Disputed — Not agreed, still live — None until it is resolved
Only variations marked approved move the contract sum, and they move it by the approved value, never by the submitted one. The tool will not let you record an approved value against a rejected or withdrawn line, and will not let you leave the approved value empty on a line marked approved — enter 0 if the change was approved at no cost. These two rules are what stop a register quietly inflating itself.
The response clock
Set the response period in the settings to whatever the contract allows for a decision after a variation is submitted. Every open variation is then aged against it.
Days waiting = today − date submitted Overdue when days waiting > response period Overdue by = days waiting − response period
The clock only runs on variations that have actually been submitted. One that is still only "identified" is waiting on you, not on anybody else, and is shown as "not submitted" rather than being aged. For decided variations the tool shows how long the decision took, so you can see whether the response period is being kept to in practice.
The Awaiting a decision table lists everything undecided, oldest first, with the value at stake beside it. That table, printed and attached to a letter, is usually more effective than the letter.
Work started before approval
This is the single most valuable figure the register produces, and it is the reason to keep one.
Unapproved work exposure = Σ value submitted, for every variation where work has started and the status is not "approved"
Tick "work on this variation has already started" whenever anything has been ordered, fabricated, dug or built. If the status is anything other than approved, the whole submitted value appears in the Started, not approved tile and in the register's own column, in red.
Every currency unit in that figure is money you have spent that nobody has yet agreed to pay you. It is not a forecast and it is not a risk allowance — the cost has been incurred. Some of it will be approved later, some will be negotiated down, and some will never be recovered at all, because the argument about whether it was ever a variation is much harder to win once the work is finished and invisible.
There are good reasons to start before approval: a delivery slot, an inspection that cannot be re-booked, a sequence that cannot wait. The point is not that it never happens. The point is that somebody senior should be looking at the total, in money, once a month, and deciding whether it is still acceptable.
Reconciling the contract sum
Enter the original contract sum in the settings. Everything else follows from the register.
Revised contract sum = original contract sum + Σ approved values (status "approved" only) Forecast final sum = revised contract sum + Σ submitted values of undecided variations Variance on a line = approved value − submitted value
The Contract sum after column shows the revised sum as it stood after each variation, taken in date-raised order. It gives you a running reconciliation you can read straight down the page: original sum at the top, revised sum on the last line. It is deliberately calculated from every record, not from the filtered view, because the contract sum does not change when you change a filter.
The forecast is a forecast. It assumes every open variation is approved in full, which will not happen. Use it as an upper bound and the revised sum as the defensible figure; the gap between them is what is still to be argued about.
Approval rate by value and by count
Two ways of measuring the same thing, and they usually disagree — which is the point of showing both.
Approval rate by value = approved value ÷ submitted value of decided variations × 100 Approval rate by count = approved variations ÷ decided variations × 100
"Decided" means approved or rejected. Variations that are still open have not been decided, and including them would drag both rates towards zero for no reason other than the passage of time. Withdrawn variations are excluded from both: you took them back, nobody refused them.
The two rates come apart as soon as the value is unevenly spread, which it always is. Ten small approvals and one large rejection give a high rate by count and a poor one by value. That is the situation worth spotting, because the money follows the value rate and your sense of how things are going follows the count. Quote both, or quote the one by value.
Where a reason category contains only savings, the rate by value is left as "—". Dividing one negative figure by another produces a percentage that looks like a result and means nothing, so the tool declines to print it.
Time effect
Record the effect on the programme in days against each variation, negative where the change saves time. Days are totalled separately from money and are never mixed with it.
Two cautions. First, the days on approved variations are days that have been agreed as an effect on the programme; they are not automatically an extension of time, which usually requires its own notice and its own assessment under the contract. Second, the days do not simply add up: two variations that delay the same activity, or that run in parallel, do not delay completion by the sum of their durations. The total in the tile is the arithmetic sum of what you entered, and it is an indicator, not a delay analysis. If time is genuinely in dispute, the register tells you where to look; it does not tell you the answer.
Settings
- Original contract sum — the figure before any variation. Every percentage on the tiles is measured against it.
- Response period — the days allowed for a decision after submission. It drives every overdue flag.
- Extra-scrutiny threshold — the value at or above which a variation is marked for closer checking, usually where a second signature or a client approval is needed. It is a prompt, not a rule; the tool does not stop anything.
All three are settings rather than fixed values because contracts differ. Change them to match yours, and state on any report you issue what they were set to.
Printing and sharing
Print Report produces a report from whatever the current filter shows: header, the headline figures, the four charts, the awaiting-decision and reason tables, the full register and your closing notes. Print to PDF to circulate it.
The scope line under the title states the filter in force. Clear the filters before issuing anything described as the full register — a report filtered to one reason or one status, issued without saying so, is the fastest way to lose the argument you are trying to win.
Saving your work
Variations, settings and the report header are written to this browser's local storage as you type, and the toolbar shows the time of the last save. That storage belongs to one browser on one computer: another browser, a private window, a second machine or a clean-up tool that clears site data will not have it.
Treat Export .json as the real save — one file containing everything, which Import .json restores anywhere. Export CSV gives you the register for spreadsheet work and includes every filtered record, not only those drawn on screen. Reset asks twice, then erases everything this tool has stored. There is no undo.
Accuracy & disclaimer
This tool records what you enter and calculates from it. It cannot tell whether a change is a variation under your contract, whether the notice you gave was valid, whether an instruction actually exists, or whether a value is reasonable. It does not issue anything, notify anybody, or preserve any entitlement.
What counts as a variation, what notice is required and in what time, how valuations are made, and what happens when a decision is not given within the response period are all matters for the contract and for the law that governs it, and they differ from one contract and one country to the next. This is an internal record-keeping and calculation aid, not legal or contractual advice, and not a substitute for reading the contract you signed.