Variation Claim Builder
Turns the scattered trail behind a variation — the email, the site diary note, the photo, the text, the sub's invoice — into a dated, evidence-linked claim with a costed build-up, ready for a person to check and approve.
It reads the documents you already have, lays out who instructed what and when, drafts the claim and cost build-up, and stops — a person approves before anything is sent.
Where this works well
The slow, invisible problem this makes visible is the trail. On most jobs the entitlement to a variation genuinely exists — the client did ask for power run to the shed, the trench was dug, the sparkie invoiced — but the proof is scattered across an email, a site diary, a phone photo, an SMS and a subcontractor invoice, each in a different system and none of them in order. Reconstructing that chronology weeks later, under time pressure, is the job nobody wants and the reason variations get written off or claimed thin.
This pattern earns its keep when you have the evidence but not the time to assemble it. It pulls the documents for one variation into a dated chronology, links every entry back to its source, drafts the claim (a reference like VAR-007, a scope description, a labour/materials/subcontractor/margin build-up) and rates how strong the instruction chain looks. The role that benefits most is the contract administrator or project manager on a mid-sized builder or head contractor — someone running several active jobs who is losing real money to unclaimed or under-evidenced variations because the assembly work keeps slipping.
Where it works badly
It is confidently useless when the evidence isn't there. If a variation was instructed verbally on site and nobody noted it, no tool can manufacture the instruction — it will build a clean-looking claim resting on a single ambiguous text, and a tidy layout can make a weak claim feel stronger than it is. The honest test: would this chronology survive the other side's contract administrator reading it line by line? If the answer depends on a "yeah go ahead 👍", the tool has surfaced your real problem, not solved it.
It is also the wrong tool where the dispute is contractual rather than evidentiary. Whether the work was genuinely outside the original scope, whether a notice deadline under your contract has already passed, whether to claim now or fold it into a final account — these are not assembly problems and the tool does not resolve them. Feed it a superseded contract scope or a variation order it hasn't seen and it will produce a stale draft with full confidence. If your jobs are small, your variations rare, or your paperwork already disciplined enough that assembly takes minutes, the effort to set this up won't pay back.
What it doesn't do — and shouldn't
It surfaces and drafts; it does not decide and does not issue. It assembles the chronology, links the sources, and proposes a cost build-up and a confidence rating. It does not judge whether the claim is contractually owed, whether you are inside the notice window, or how hard to press it commercially — and it never sends anything. The Approve / Edit / Reject step is a real gate: a person reads the draft, checks it against the actual contract, and decides.
That boundary is deliberate. A variation claim is a commercial and sometimes legal position you are taking against a client or principal — under regimes like the Building and Construction Industry Security of Payment Act, a claim has to properly identify the work and stand up to scrutiny. Getting it wrong erodes trust on the job at best and forfeits money or invites a dispute at worst. The drafting is mechanical; the decision to stand behind the claim is not, and it stays with the person whose name is on it.
What your data has to look like for this to work
The pattern needs three things tied to one variation: the original contract scope (so it can show the work was outside it), the instruction chain (the email, diary note, photo or SMS that shows it was asked for), and the cost evidence (subcontractor invoices, labour and material records). It needs to know which documents belong to which variation, and the cost build-up only holds if your labour, materials and subcontractor figures are real numbers, not estimates pencilled in later. The margin applied has to match what your contract actually allows — the 15% in the demo is illustrative, not a standard.
Most builders have all of this somewhere, and almost none have it linked. Emails sit in one inbox, site diaries in an app or a notebook, photos on a phone, invoices in the accounts package, and nothing connects "this invoice" to "that instruction" to "this variation". Closing that gap — agreeing how a variation gets tagged at the moment it happens, so the trail assembles itself rather than being reconstructed — is usually the real first job. It is a change to how information is captured on site, not a new tool to buy, and it is the work we help with. It is typically bigger and more valuable than the AI layer that sits on top of it.
Could it build a claim that's actually wrong — bill for work that was in scope, or one we have no right to claim?
It can draft a claim that looks tidy but isn't owed, so the draft is a starting point, not a verdict. Every line is linked back to the source document it came from — the contract scope, the instruction, the invoice — so the reviewer can see why it thinks the work was a variation and check that against the actual contract clause. The confidence rating ("Strong / clear instruction chain with written confirmation") is a prompt to look harder where the chain is thin, not a green light. The contract administrator decides whether the claim is sound before it leaves the building.
Our evidence is a mess — half of it is texts and verbal instructions noted in the site diary. Does that break it?
That is exactly the situation it is built for, and also where you must read carefully. It will happily assemble a chronology from an email, a diary note, a photo and an SMS, but a verbal instruction noted in a diary is weaker evidence than a signed variation order, and the tool can't make it stronger. It surfaces what you have and where the gaps are; it does not invent a written instruction that was never given. If a variation rests only on a "yeah go ahead" text, that is a fact about your claim, not a flaw in the draft.
Does this replace our contract administrator or QS?
No. It does the assembly — finding the documents, putting them in order, drafting the build-up — which is the slow part. It does not decide whether the claim is contractually sound, whether a notice deadline has been missed, or how hard to push it commercially. Those judgements stay with your contract administrator or quantity surveyor, who now spends their time on the call rather than on hunting through the inbox.
How current does the data need to be — what if the contract or a variation order changed after we fed it in?
It only knows what it has been given for that variation, so a superseded scope or a later signed variation order it hasn't seen will produce a stale draft. The build-up reflects the documents at the moment it runs, not the live state of the job. Before approving, the reviewer confirms they are working from the current contract scope and the latest instructions — the tool can't tell that the file in front of it has been overtaken.
Where does our project data go — the contracts, the client emails, the pricing?
That is a scoping decision we make with you before anything is built, not an afterthought. The documents and pricing are commercially sensitive, so the data path — what is processed, where it sits, what is retained — is agreed up front and kept inside arrangements you control. We do not need your data to leave that boundary for the pattern to work, and we would rather under-collect than over-collect.
Does it know the notice deadlines in our contract — will it stop us missing a time bar?
Treat it as an assistant, not a compliance check. Whether a claim is time-barred depends on your specific contract — a standard like AS 4000 may not impose a strict time bar, while many head contracts and bespoke contracts do, and missing the notice window can defeat an otherwise valid claim. The tool can flag dates and surface the instruction chain, but confirming the notice clause and the deadline is a judgement for your contract administrator. We can build the relevant clause rules in for your contracts, but the person still signs off.
Estimated build: 3–5 weeks. Most of it is template work we've already done.
Fixed scope, fixed price, fixed dates.
The cost band reflects the engagement shape, not a per-feature line item. We work on fixed scope, fixed price, fixed dates — see the services catalogue for what falls inside each band.
Considering this for your org?
The honest place to start is a bite-sized first piece — one contained change, low risk. Tell us where it hurts; we’ll play it back, scope it, and show you what’s possible.