Variations Register for Construction Projects (UK QS Guide)

A variations register is the live QS control record for instructed change on a construction project. A useful register captures each Architect's Instruction, Project Manager's Instruction or NEC compensation event with its reference, date, description, pricing basis, status, addition or omission value, agreed value and evidence link. Those rows then roll into the application for payment, CVR and final account without losing the trail back to the instruction.

For a UK QS, the register has to separate the mechanism, status and certainty of every change: JCT variation, NEC compensation event, AI, PMI, quotation, dayworks or fair valuation. It should keep additions, omissions, submitted values, assessed values and agreed values distinct so AfP, CVR and final account figures do not inherit the same uncertainty.

This matters because the same change can appear in several places. A late instruction might be priced in the variations log, included provisionally in the CVR, held back from the AfP because it is not agreed, and later become part of the additions and omissions schedule for final account. If the register does not carry status, evidence and certainty level clearly, the commercial picture starts to look cleaner than it really is.

The strongest variation registers are built from the source documents. Each row starts with the instruction, notice or event that created the change, then accumulates the pricing basis, supporting build-up, submitted quotation, response, agreement evidence and reporting treatment. That row-level trail is what makes the register useful in a monthly commercial meeting and defensible when the final account is challenged.

Build each row from the instruction stream

The register should be designed around the documents that create and support the change, not around a tidy summary you want at the end. Start with row fields that let a QS trace each item back to its source:

Register field	Why it matters	Feeds into
Contract mechanism and AI, PMI or CE reference	Shows what created the change and which contractual process applies	Entitlement review, deadlines
Date issued and date notified	Keeps notice timing visible where the contract requires it	NEC response control, audit trail
Work package, cost code and description	Ties the change to the affected scope and budget owner	AfP, CVR, package reports
Pricing basis and value columns	Separates additions, omissions, quoted value, assessed value and agreed value	Valuation review, final account
Status, evidence link and reporting treatment	Shows whether the value is instructed, priced, agreed, disputed or pending	AfP, CVR, final account

A variation register from architect instructions should not stop at the AI reference and a short description. The row needs enough structure to show what the instruction changed, which package it affects, how the value is being built up, and where the supporting documents sit. The same logic applies when the source document is a PMI, CE notice, contractor notification, quotation, dayworks sheet or email confirming agreement.

One register can handle JCT and NEC work if the mechanism is explicit. The JCT row may need to show a retrospective valuation route and whether a clause 5.3.1 quotation has been accepted. The NEC row needs notification and response controls because the compensation event process is live before it becomes a settled value. The mistake is trying to hide both mechanisms behind one generic "variation value" column.

The value columns should be kept apart. A submitted quotation is not the same as an assessed value. An assessed value is not the same as an agreed value. An omission should not disappear inside a net addition. If the register rolls those into one number too early, the AfP, CVR and final-account positions all inherit the same confusion.

For projects with a heavy document stream, the first pass can be a document-to-row exercise. A team might extract the reference, date, issuer, package, description, claimed value and source-page reference from a set of PDFs, then review the rows before importing them into the live workbook. That is the narrow place where invoice data extraction for construction documents can help: Invoice Data Extraction takes uploaded PDF, JPG or PNG files, follows a prompt describing the fields needed, and returns Excel, CSV or JSON output with source-file and page references. It can help prepare reviewable rows from repeated document sets, but it does not decide entitlement, value the change or administer the contract.

Show the contract mechanism, valuation route and live deadlines

On a JCT project, the register line usually starts with an Architect's Instruction or Contract Administrator's instruction. The row should then show the valuation route: retrospective valuation under the Valuation Rules, with measured build-up and rate source, or a clause 5.3.1 quotation route with submitted value, assumptions, acceptance status and agreed value. Additions and omissions should stay separate because netting them inside one cell removes the audit trail a QS needs when the final account is reviewed.

An NEC compensation event row needs more live-process fields because notification, quotation, response and implementation are managed before the value becomes history. The row can start from a Project Manager's instruction, a PM notification of a compensation event, or a contractor notification. It should show the date notified, any notification timing risk, response deadline, quotation submitted date, PM response, assessed value, time impact, implementation status and evidence link.

RICS Valuing change practice information explains how construction change is valued under JCT, NEC and FIDIC forms, and identifies change terms such as Variation, Change of Employer's Requirements and Compensation Event. For the register, the practical point is that the contract language should be visible enough to guide the row structure, without turning the workbook into a clause commentary.

The row should expose commercial state as well as contract form. A change may be instructed but unpriced, priced but not assessed, assessed but disputed, or agreed and ready to affect the contract-sum projection. Time-related and cost-related impacts should also stay visible in the same row so the CVR does not lose programme risk while tracking value.

Tag the pricing basis before the value is argued

The pricing-basis column is one of the most useful fields in the register because it tells the reviewer how the number was built. A variation priced from contract rates needs a different check from a dayworks item, a lump-sum quotation or a fair valuation. If the register only carries the amount, the commercial team has to reopen the file every time the value is challenged.

For BOQ rates, the row should point to the relevant bill item, varied quantity and rate source. That matters where the contract permits existing rates to be applied to changed quantities. If the source bill has been extracted into a usable spreadsheet, it is easier to compare the varied quantity back to the original item, which is where a workflow to convert a bill of quantities PDF to Excel supports the valuation trail.

For Schedule of Rates work, the same principle applies, but the rate source is usually a standing schedule rather than a project-specific bill item. The register should still show the schedule reference, measured quantity and any adjustment made because the instructed work does not fit the rate cleanly.

A quotation tag should be used where the change is treated as a discrete piece of work. The row should link to the submitted quotation, assumptions, exclusions, supporting build-up and acceptance evidence. A quotation without its assumptions is weak evidence, especially when scope changed after submission.

Dayworks need a different control. The main variations register can carry the dayworks total, but the signed sheets, labour hours, plant, materials, supervision notes and reconciliation detail belong in a dayworks sub-register. The main row should link to that sub-register rather than trying to hold every sheet-level detail in one cell.

Fair valuation is the exposed category. It may be the right route where neither contract rates nor a clean quotation basis fits, but it needs more explanation because the judgement is less mechanically traceable. The register should name the basis of assessment, the supporting records used, and the reason a more direct pricing route was not available.

Status and evidence columns are what make the register defensible

A variations log construction QSs can defend needs status definitions that everyone on the commercial team uses the same way. "Open" and "closed" are too blunt. They hide whether the change has been instructed, priced, quoted, assessed, agreed, disputed or left pending information.

Those statuses should control how the value is reported. An instructed item may have no reliable value yet. A priced item may be the QS's internal assessment only. A quoted item may have been submitted but not accepted. An assessed item may reflect the other side's position. An agreed item can support the contract-sum movement. A disputed item needs to stay visible instead of being absorbed into a net forecast. A pending-information item should name the missing record, the owner and the next action date.

Every row should then link to the evidence that supports its current status. At minimum, that means the source instruction or notice, the quotation or valuation build-up, substantiation, dayworks sheets where relevant, correspondence about disagreement, meeting minutes if agreement was recorded there, and any signed acceptance or formal confirmation.

This is where many registers fail. The summary tab may show a professional-looking total, but the individual lines do not prove how the total was created. If a disputed variation later goes to senior review, adjudication preparation or final-account negotiation, the row-level trail matters more than the dashboard.

The evidence link should point as close as possible to the supporting record. A folder full of project correspondence is not the same as a direct link to the instruction PDF, quotation, signed daywork sheet or agreement email. If the team uses a common data environment, the register should link to the controlled document location rather than to a local copy sitting on one QS's machine.

Status reporting should be built from those row-level fields. A monthly dashboard can show the count and value of instructed, quoted, assessed, agreed, disputed and pending-information items. That gives the commercial manager a better risk view than a single "variations total", because it shows which part of the number is bankable and which part still needs work.

Roll the register into AfP, CVR and final account without mixing certainty levels

The variations register should feed the monthly payment and forecasting process, but it should not pretend every value has the same certainty. Agreed variations can be included in the next application for payment in the normal way. Submitted, assessed, disputed and pending-information values need different treatment.

For payment, the QS should be able to filter the register to agreed items and any other items the contract allows to be applied for. That is where the register connects to the discipline needed to assess subcontractor applications for payment: the value in the AfP should be traceable to a status, a pricing basis and supporting evidence, not just copied from a forecast total.

For CVR, the register has a broader role. Submitted or assessed values may be useful commercial intelligence even before agreement, provided they are marked as provisional. A contractor's forecast may need to recognise likely recovery, exposure on disputed omissions, or risk on pending compensation events. The register should support that judgement while keeping agreed value separate from forecast value. The same separation is essential when teams build a construction CVR spreadsheet, because the CVR needs to show commercial expectation without disguising unresolved entitlement.

For final account, the register becomes the additions and omissions schedule only after reconciliation. The QS should be able to show the source instruction, pricing basis, agreed value and evidence for each line that survives into close-out. Items still disputed or pending information should not be swept into the agreed total simply because the project is ending. A separate workflow to prepare a construction final account workbook can then use the reconciled register as the change-control source rather than rebuilding the history from scattered files.

The monthly roll-up should therefore separate additions, omissions, net movement, agreed value, submitted value, assessed value, disputed value and pending-information value. That layout gives the project team a truthful contract-sum projection: what has changed, what is claimed, what is agreed, and what still carries risk.

The discipline is simple: keep one live register, define statuses tightly, preserve row-level evidence, reconcile monthly to AfP and CVR, and stop the same change appearing twice across the variations log, package records and final-account schedules.