Variations
A variation is a change to what was agreed: extra work, omitted work, a different specification, a delay somebody has to pay for. In Teralo it is a priced record on the contract that, once approved, becomes part of the contract sum and flows straight into the budget and into what can be claimed.
Variations live on a contract, under its Variations tab, and either party can raise one.
The register
Each row is a variation: its number, its title, its status, its value, and the approvers it is sitting with. Numbers run VAR-001, VAR-002 and so on, per contract, generated for you.
A variation has four statuses, and they are the same four a claim has: draft while it is being written, submitted once it is with the approvers, then approved or rejected.
Both parties see every variation on the contract, drafts included. That differs from progress claims, where a counterparty's draft is hidden from the host until it is submitted, and it is worth knowing before you use a draft as a private scratchpad. Use the description for a proposal you are still thinking about, not a draft nobody is meant to read yet.
Raising one
A variation carries a title, a description of the change, an external reference of your own, and a priced breakdown.
The breakdown is a schedule of values in the same editor used on the contract itself: sections and items, quantities, units, rates, budget codes and tax rates. Two things about it matter.
A line can point at an existing contract schedule item, which is how you say "this is a change to that", rather than adding a parallel line that has to be reconciled by hand later.
A line can be negative. An omission is a variation like any other, and pricing it as a negative is what keeps the contract sum correct rather than leaving a credit note floating outside the record.
Attachments and notes belong on the variation, and they are the part that ages well. A variation approved eighteen months ago is only defensible if the instruction, the sketch or the email that prompted it is still attached to it.
What approval changes
Approving a variation does four things at once, and they are the reason a variation is not just a document.
The contract value moves. An approved variation is part of the contract sum from that moment.
Committed costs move. The approved lines land against their budget codes in the budget as commitments, because you are now contractually on the hook for them.
On a head contract, the revised budget moves too. Where the contract's type is Head Contract, an approved variation also lands in the Approved HCV column and increases the money you have to spend, which is the correct treatment: a variation to the contract you are being paid under is more money in as well as more work.
It becomes claimable. Approved variations appear in the Variation Works block on the next progress claim, underneath the contract works and subtotalling separately.
While a variation is still submitted, it shows in the budget's Pending VARs column instead. That column is a warning about what is coming, not a commitment.
Claiming before approval
Some contracts want work claimed while a variation is still being argued about. There is a per-contract switch for it: allow claiming on unapproved variations. Turn it on and submitted variations join the approved ones in the claim's variation block, and the claim PDF separates them out under their own heading so nobody can mistake one for the other.
Leave it off unless you mean it. Claiming against a variation that is later rejected leaves you unwinding a certified figure.
Retention on variations
A variation can be retained differently from the base contract. The contract carries a second retention configuration, with its own basis, rate and cap, that applies to variation lines only.
That exists because the two are commercially different: retention on a two-year head contract and retention on a fifteen thousand dollar variation to it are not obviously the same question. Where they are, set both the same and forget about it. See Progress claims for how the bases work.
Rejection, and the one thing you cannot undo
Rejecting a variation sends it back with a reason. The default workflow routes it to a task to revise and resubmit under the same number rather than ending it, so a rejected variation is a round trip and not a dead end.
A submitted or rejected variation can be walked back to draft by the host, which cancels the approval run that was in flight.
An approved variation cannot be reopened. This is a deliberate difference from progress claims, where an approved claim can be reopened. A claim that is reopened has an accounting export to void and a figure to restate; an approved variation is a recorded change to the contract itself, and the way to change it back is another variation. That is also how it works on paper.
Deletion follows the same logic: a draft or submitted variation can be deleted by somebody with the permission, an approved or rejected one never can.
What a guest sees
A counterparty organisation can see and raise variations on its own contract, price them, attach the evidence and follow them to a decision. It cannot approve or reject them, including its own.
Where the host has turned cross-organisation access off on a contract, the counterparty can still read it but cannot submit variations against it, even holding the project permission. See Contracts.
SettingsHost only
Variation settings are on the contract's Settings tab: the variation retention configuration, whether unapproved variations may be claimed, and the variation approval workflow. All three are per contract, because they are commercial terms rather than company policy.
The budget codes and tax rates a variation line can use come from Organisation, then Tools, then Contracts and Tools, then Budget Codes, the same lists the contract's own schedule draws on. See Organisation level and project level.
PermissionsHost only
Three permissions, independent of one another with no cascade: submit a variation, approve or reject one, and delete one.
The independence is the point. Somebody who approves variations is not automatically able to raise them, which is the separation an auditor expects to find on the one record most open to argument. See How permissions work.
WorkflowsHost only
The variation workflow is bound on the contract rather than on the tool, so two contracts on the same project can require different approvals. Choose it when you create the contract, or change it later in the contract's Settings.
The run starts when the variation is submitted. A draft has no workflow behind it, which is why deleting one costs nothing.
There is no admin override: an approver has to be an assigned participant on the active step and hold the approve permission. See Assigning approvers and the workflow builder.