Progress claims

A progress claim is the monthly conversation about money, written down. The contractor says what they have completed, the party paying assesses it, somebody approves a figure, retention comes off, and a payment eventually follows. Teralo holds all four steps against the contract, so the claim, the assessment, the reasons and the certificate are one record rather than four emails and a spreadsheet.

Claims live on a contract, under its Progress Claims tab. Either party can raise one: a subcontractor claiming their own work, or a head contractor raising a claim on behalf of a counterparty who does not use Teralo.

The register

Each row is one claim: its number, the period it covers, an external reference of your own, the due date, its status, whether it has been paid, how far through the contract it takes you, the workflow it is sitting in, the amount this claim, the amount to date and the retention held.

The workflow column shows the approvers as avatars with a coloured ring each, so you can see at a glance whose desk it is on.

One claim at a time

This is the rule that surprises people, and it exists to keep the arithmetic honest.

Every "previously approved" figure on a claim is the sum of approved claims with a lower number. That sum is only correct if claims land in order, so Teralo enforces order in three ways:

• A new claim cannot be started while an earlier one is still open. Open means draft or submitted. Submit the outstanding claim or delete it first.
• A claim cannot be submitted while a lower-numbered one is still open, which catches the case where two claims end up open at once.
• A claim cannot be amended once a later claim has moved past draft. Later drafts never block, because a draft's figures are worked out fresh every time it is opened.

Approved and rejected are both terminal. A rejected claim is not reopened and reworked, because it is a record of a decision under security of payment legislation. The remedy is a fresh claim.

Claim periods

The contract's claim frequency, weekly, fortnightly or monthly, decides which periods you are offered. Three rules apply:

A period may repeat the last one, which is the catch-up case: June was claimed and approved on the 15th, and on the 16th you claim the rest of June. A period may never go backwards. Otherwise the new period must sit inside the next one for the contract's frequency, so the next period is always available and a skipped period never is.

The due date is worked out from the end of the period plus the contract's payment terms.

Filling in a claim

The claim opens on the whole schedule of values, sections and all, with the approved variations underneath it in their own Variation Works block. Only variations that existed when the claim was created appear, so a variation approved mid-claim does not silently change what you are looking at.

Each line takes progress in whichever of three ways suits you, and the other two follow: a percentage complete, a claimed to date amount, or a this claim amount. Enter one and the other two recalculate.

Column groups collapse and expand, so you can work with just the numbers you need on screen: When Complete, Prev. Approved, Claimed, Assessed and Retention. Claimed and Assessed each flip between this period and cumulative.

Sections subtotal, Contract Works and Variation Works subtotal separately, and a grand total sits at the foot.

Three things make a long schedule bearable. Bulk Update applies one percentage or amount to everything you have selected, with a preview before it commits. Reset to Zero clears a claim you would rather start again. And any line takes a note with attachments, which is where a photograph or a delivery docket belongs, on the line it is about rather than in a covering email.

Claims save when you press Save Draft, not as you type. That is deliberate: a table this wide with three interdependent fields per row is exactly where an autosave races itself.

Teralo warns rather than blocks on a percentage over 100, a negative amount or a line claimed over its contract value. Sometimes they are right.

Retention

Retention is configured on the contract, and there are four bases.

Percentage holds a rate off each claim, optionally capped at a percentage of the contract value. Max value does the same with the cap expressed in dollars. Bank guarantee holds nothing, because security is provided another way. Tiered bands the retention rate against the cumulative value certified across the whole contract.

The tiered basis is worth understanding if you use it. It is banded on the total certified to date rather than on the claim in front of you, so slicing the same work into ten claims retains exactly what one big claim would have. The tier schedule is its own cap, so a top band of zero per cent is how you stop it.

Variations can carry a different retention basis from the base contract, which is set separately.

The Retention tab on a claim shows what is held, and progress towards release. Release is triggered when the approved value reaches a set percentage of the contract, releasing a set percentage of what is held. Teralo starts you at 90 per cent approved releasing 50 per cent of retention, both editable per contract.

Compliance documents

A contract can require documents with its claims: insurances, monthly reports, statutory declarations, whatever your organisation has defined. Each type is required once, monthly, or on every claim.

Insurances, reports and statutory declarations

Attach them on the claim's Compliance tab, either by uploading, by picking a project document, or by choosing from your organisation's own Insurances and Licences pool so a current insurance certificate is not re-uploaded twelve times a year. A statutory declaration is usually the per-claim one; an insurance certificate is usually the annual one.

Somebody on the approval then verifies each one, which is a separate act from it being uploaded. The tab carries a dot that tells you where you stand: red for a required document missing, orange for uploaded but unverified, green for all clear.

A claim cannot be approved until every required document is uploaded and verified. That is enforced on the server rather than by greying out a button, so it holds however the approval is reached.

Assessing a claim

Assessment is the paying party's answer to the claim, line by line, and it is what turns "we do not agree" into a record.

Open the assessment and you get claimed against assessed side by side. Adjust the quantity or the rate on any line and the assessed amount recalculates. Every line assessed downwards has to carry an explanation, and the submit is refused until they all do. Assessed lines are highlighted in the schedule afterwards, with the assessor's name and their reason on hover.

What an assessed value changes

An assessed value is what everything downstream uses: the certified total, the retention calculation, the ceiling on what can be paid, and the actual costs to date in the budget. A line nobody assessed is simply certified at what was claimed.

Approval, and what it sets off

Claims are approved through a workflow rather than by a single button, so the approval is a sequence of named people rather than whoever got there first. See Approving and rejecting.

Three checks run before an approval is accepted, all server-side:

1. Every required compliance document is uploaded.
2. Every required compliance document is verified.
3. Every downward-assessed line carries its explanation.

When the last approval lands, the claim is certified, retention is recalculated and stamped onto the claim, and where your organisation has an accounting connection the invoice or bill is exported automatically. A failed export does not undo the approval; it is reported on the claim with a retry.

Rejecting sends the claim back with a reason, and the default workflow routes it to a task to revise and resubmit under the same claim number rather than ending it.

Reopening is the host's escape hatch: a submitted, approved or rejected claim can be walked back to draft. Doing so cancels the workflow run that was in flight, so it stops the reminders too. Reopening an approved claim also voids the accounting export.

Payments

Approval certifies an amount; it does not pay it. Payments is a host-only tab on the contract recording what actually left the bank: amount, date, reference and method, entered by hand or synced from your accounting system.

Teralo will not let recorded payments exceed the claim's certified total, and derives the claim's payment state from the sum of the rows, so a claim reads as partly paid or paid without anybody maintaining a status.

The two PDFs

The progress claim, and its security of payment statement

The progress claim PDF is the claim itself, and it can be previewed or downloaded at any stage. Its cover page carries the statutory payment claim statement, and Teralo ships the security of payment wording for New South Wales, Victoria, Queensland and New Zealand.

The statement is frozen at submission. Whatever the organisation, project and contract settings resolved to at the moment the claim was submitted is what every later export of that claim prints, so changing your organisation's default next year cannot rewrite what you served last year.

The payment schedule

The payment schedule is the respondent's document and is only available once a claim is approved. It sets out what is being paid and, where it differs from what was claimed, why, which is exactly the assessment explanations doing their second job.

Comments

Every claim has one threaded discussion, shared by both organisations, with replies at any depth and file attachments. Comments are attributed to the person and their organisation, and the two sides are styled differently so a thread is readable at a glance.

Use it. A disagreement argued in the comments is on the claim; the same disagreement by email is on nothing.

What a guest sees

A counterparty organisation sees every claim on its own contract, including a claim the host raised on its behalf.

Your draft is not visible to the host until you submit it. They see their own drafts and everything of yours from submission onwards, so a claim you are still working on is genuinely yours.

You cannot approve, assess or reject your own claim, and the Payments tab is not shown to you. What you can do is see the assessment and its reasons the moment it lands, which is more than most systems give you.

SettingsHost only

Claim settings live on the contract, on its Settings tab: the claim frequency, payment terms, the retention configuration, the payment claim statement, the compliance requirements and the claim approval workflow. Setting them per contract is the point, because a supply order and a major trade package do not claim the same way.

The templates those settings choose from are at Organisation, then Tools, then Contracts: retention defaults, tax rates, the payment claim statement default, compliance document types and the accounting connection. See Organisation level and project level.

PermissionsHost only

Three permissions, and they are deliberately independent of each other with no cascade between them: submit a claim, approve or reject a claim, and delete a claim.

That is segregation of duties made explicit. Granting somebody the ability to approve does not quietly grant them the ability to submit, which is the arrangement any auditor will ask about.

Deletion is bounded by status regardless of permission: a draft or submitted claim can be deleted, an approved or rejected one never can, because both are financial records. See How permissions work.

WorkflowsHost only

The claim workflow is bound on the contract, not on the tool, so different contracts on the same project can run different approvals. Pick it when you create the contract or change it in the contract's Settings.

The run starts when a claim is submitted, not when it is created, so a draft claim has no workflow behind it and nothing to cancel if you delete it.

There is no admin or superuser override. An approver has to be an assigned participant on the active step and hold the approve permission, both. See Assigning approvers.