If you work in Australian construction, you'll hear "payment claim" and "payment schedule" used so often they start to blur together. They sound similar. They're not. Mixing them up — or skipping the schedule entirely — is one of the most expensive mistakes a builder or principal can make under the Security of Payment Act.
Here's the short version, then the detail.
The short version
- A payment claim is the document the contractor (or subcontractor) issues to ask for money — typically once per month, covering work completed in that period.
- A payment schedule is the response from the party paying. It's a line-by-line assessment of what they agree to pay, what they don't, and why.
- The schedule has to come back inside a strict statutory window. Miss the window and the full claimed amount becomes payable.
- Both documents are part of the Security of Payment Act (SOPA) regime that applies — with state-by-state variations — across Australia.
What's in a payment claim?
A payment claim sets out everything the claimant believes they're owed for the period. On a typical head-contract claim, that includes:
- Contract works — progress against the original lump-sum or schedule of rates, usually expressed as a percentage complete per breakdown line.
- Variations — approved (or pending) changes to the contract scope.
- Less previously claimed — so the claim only requests the delta since the last claim.
- GST, retention deductions, and any contractual offsets.
- The total amount due this claim — in plain numbers, with the contract reference, claim period, and a statement that it's made under the relevant SOPA.
The format isn't sacred. It can be a one-page invoice or a 200-line breakdown. What matters is that it's clearly identifiable as a payment claim and reaches the right party at the right time.
What's in a payment schedule?
A payment schedule answers the claim. It either:
- Agrees with the full amount claimed — usually rare on anything more complex than a small subcontract — or
- Assesses the claim line by line, sets out which amounts are accepted and which aren't, and gives reasons.
If you're going to withhold any portion of a claim, the reasons go in the schedule. They have to be specific. "We disagree" is not a reason. "Variation 14 has not been formally approved by the Superintendent and is rejected pending further submission" is.
The schedule also restates the totals: total claimed, total assessed, total to be paid, GST, retention movements, and the date payment will be made.
The statutory window — why timing is non-negotiable
This is where most people get caught.
When a payment claim is served, the recipient has a fixed period — typically 10 to 15 business days, depending on which state's SOPA applies — to issue a payment schedule. If they don't:
- The full amount of the payment claim becomes payable. Not the amount the recipient thinks is fair. The claimed amount.
- The claimant can pursue recovery through the courts as a debt, or go to adjudication for a fast-track determination.
There's no "we were busy" defence. The clock runs from the date the claim is properly served. Builders and principals who rely on email-trails to manage this miss the deadline more often than they admit.
Why the relationship matters
A payment claim and its corresponding payment schedule are the paired record of one payment cycle. Together they show:
- What was claimed
- What was agreed
- What was disputed and why
- What was actually paid
When something goes wrong months later — a final account dispute, an adjudication, a defect claim, or a contract termination — these paired records are the evidence. Sloppy claims and missing schedules make every downstream dispute harder.
This is why the better way to handle them is in a system that locks both sides down at the moment they're issued: claim values frozen the second the claim is submitted; schedule values frozen the second the schedule is issued; both rendered identically in the UI, in PDFs, and in audit logs. No retro-edits. No "the spreadsheet's been updated." Just a clean, immutable history of what was claimed, what was assessed, and when.
How ClaimStack handles it
ClaimStack runs payment claims and payment schedules as paired immutable records:
- A claim is composed against the contract breakdown, line by line, with previously claimed amounts auto-populated from prior claims so the totals always reconcile.
- Once submitted, the claimed values are read-only — for everyone, on every screen and PDF.
- The recipient sees the claim in their portal, can issue a schedule (with line-by-line accept/reduce/reject and reasons), and submitting it freezes those assessed values just as immutably.
- The statutory clock is tracked automatically from the date the claim is served, so the schedule deadline doesn't slip.
- Variations that have been approved or are still pending are surfaced inline so neither party loses track of what's in scope.
It's the same workflow you've always run — just without the spreadsheet drift, the missed deadlines, and the disputes that come from two parties looking at slightly different numbers.
Want to be invited as a free collaborator on a project that already runs on ClaimStack? Anyone in the contract chain can join free — submit claims, respond to variations, upload documents, no subscription required. The party issuing contracts upstream is the only one who needs a paid plan. Read about pricing →