Contracts
A contract in Teralo is the agreement plus everything that happens to it: the priced schedule it was signed on, the variations that changed it, the claims made against it, the money paid, the documents, and the trail of who changed what. It is the record you go to when somebody asks what was actually agreed.
Every contract has exactly two parties: the host organisation running the project, and the contracted organisation on the other side. That is not a permission setting, it is the shape of the record, and it decides who can open the contract at all.
The register
Contracts opens on a register split by classification, and the split is the first thing to get right.
A cost contract is money going out: a subcontract, a purchase order, a consultancy agreement. A revenue contract is money coming in, which for a builder is the head contract with the client. Same record, opposite direction, and the whole budget depends on knowing which is which. Because of it, the payments tab on a contract reads Payments Issued on a cost contract and Payments Received on a revenue one.
Two more tabs sit alongside, both permission-gated: Direct Costs, for spending that has no contract behind it, and Budget, which has its own article at The contract budget.
The register itself works like every other register screen.
Creating a contract
Contracts are created by the host. The quickest route is not this form at all: a package taken through Procurement and signed carries itself across with Copy to Contract Register, bringing the counterparty, the awarded amount, the commercial terms and the executed PDF with it.
Where you are creating one by hand, the form runs in sections.
Contract Overview is the title, the type, the status, the counterparty and the classification. The contract number is generated for you from the type's prefix, so a subcontract comes out as SC- and a purchase order as PO-. You can change it afterwards in Settings if your own numbering matters more.
Contract Dates are the start, the execution date, the estimated completion and, later, the actual completion. Payment terms and the warranty period sit here too.
Retention Configuration is covered in Progress claims, because retention is only ever felt on a claim. Set it now rather than later: it is much harder to change once claims have been certified against it.
Payment Claim Statement is the statutory wording printed on the front of every claim PDF. Teralo ships the security of payment wording for New South Wales, Victoria, Queensland and New Zealand, and defaults to inheriting whatever your project or organisation has set.
Compliance Requirements names the documents this contract's claims have to carry: insurances, monthly reports, statutory declarations, and anything else your organisation has defined. Once required, they gate claim approval.
Approval Workflows binds up to three graphs to this contract: one for progress claims, one for variations, and one for the contract's own approval. More on that below.
Schedule of Values is the priced breakdown the contract is worth. Sections and items, quantities, units, rates, budget codes and tax rates. The contract's value is the sum of this schedule, not a number you type. That is what keeps the value, the claims and the budget agreeing with each other.
Attachments takes the executed contract, insurances and anything else, and can be added to later.
Contract types and statuses
A type carries a prefix and answers what kind of agreement this is. Teralo starts you with Head Contract (HC), Subcontract (SC), Purchase Order (PO), Consultancy Agreement (CA) and Supply Contract (SP), all editable.
A status is where the contract has got to. The list is your organisation's rather than ours, so it can match the words your business actually uses. Every status change is recorded with who made it, when, and a note, so the history reads as a sequence of decisions rather than a single current value.
One type name is load-bearing: a variation approved on a contract whose type is called Head Contract flows into the budget's Approved HCV column and increases your revised budget, because more money coming in is more money available to spend. Rename that type and the behaviour follows the name. See The contract budget.
Inside a contract
Open a contract and it has up to five tabs.
Progress Claims and Variations are the two commercial workflows, each with its own article.
Payments records what has actually been paid against certified claims. It is host only, and it takes both manual entries and rows synced from your accounting system.
Contract Details is the contract itself: the schedule of values, the parties, the dates, the attachments and the activity history.
Settings is host only and is described below.
The contract's own approval
Separately from claims and variations, the contract itself can be put through an approval. Bind an execution workflow when you create the contract, or submit an existing one for approval, and the run drives the contract's status to Approved when it completes.
Because the status list is your organisation's, so is the vocabulary the workflow writes into it. If somebody renames the status the workflow targets, the approval still completes and simply does not move the status, rather than failing. That is deliberate, so a rename cannot break a live approval, but it does mean a renamed status is worth checking against your templates.
Do not confuse this with the e-sign step in Procurement, which is also called contract execution. That one is about getting signatures on a document before a contract exists here. This one is an internal approval of a contract record that already exists.
What a guest sees
A contracted organisation sees the contracts it is party to, and no others. This is not a permission somebody forgot to grant: contracts on the project that your organisation is not a party to are not in the data the page loads.
Within your own contract you can read the schedule of values, the documents and the history, submit progress claims and variations, and follow them to a decision. You cannot approve your own claims or variations, and you cannot see the Payments tab, which is the host's record of what they have paid.
If a contract you should be party to is not there, the contracted organisation on the record is wrong, and only the host can change it. See Hosts and guests.
SettingsHost only
Contract settings are per contract, on the contract's own Settings tab, and they are the same sections as the create form: overview, dates, retention, payment claim statement, variation settings, compliance requirements and approval workflows. Changing one here changes it for this contract only.
The templates those settings choose from live one level up, at Organisation, then Tools, then Contracts: contract types, contract statuses, tax rates, retention defaults, the payment claim statement default, compliance document types, direct cost types and statuses, and the accounting connection. Projects activate the organisation's entries and can add their own. See Organisation level and project level.
Email notifications can be turned off per contract, which stops the counterparty being mailed when claims are submitted or actioned. Use it on internal or dummy contracts rather than live ones.
Deleting a contract is here too, behind a confirmation. It takes the claims, variations and history with it.
PermissionsHost only
Four permissions govern contracts themselves: viewing, creating, editing and deleting. Claims, variations, payments, budget and direct costs each carry their own, which is what lets you give somebody the register without giving them the money.
For a counterparty organisation there is a second gate on top of the permission. Cross-organisation access is a switch on each contract, and turning it off stops that contract's counterparty submitting claims and variations even where they hold the project permission to do so. It does not hide the contract from them.
Note also that the party rule sits underneath all of this. Granting can_view_contracts to an organisation does not show them contracts they are not party to, because that filter is on the data rather than on the permission. See How permissions work.
WorkflowsHost only
Contracts bind workflows differently from the rest of Teralo, and it is worth knowing why.
Most tools bind one workflow at tool level, so every record of that type runs the same approval. A contract binds up to three graphs on the contract record itself: progress claims, variations, and the contract's own execution approval. Two subcontracts on the same job can therefore run different claim approvals, which is the point, because a two hundred thousand dollar package and a two million dollar one do not deserve the same sign-off.
The templates are built once in the workflow builder and activated per project; binding is choosing from that activated list when you create or edit the contract. See Binding a workflow to a tool for the general pattern.
There is no admin override on any of the three. An approver has to be an assigned participant on the active step, whatever else their account holds.