← Back to News
Insight8 Oct 2026

What An Extension Of Time Claim Needs From Your Site Records

Most extension of time claims fail on process rather than on merit. Three of the four usual process failures are decided by what somebody wrote down on the day, long before anybody knew a claim was coming.

Illustration of a dated site record sheet beside a programme bar chart with one activity isolated, in the site's blueprint style

An extension of time claim has to show that an event delayed work on the critical path to completion, that the event is one the other party carries the risk for and that notice was given the way the contract asked for. The contractor has to prove all three of those.

None of them get settled when the claim gets written. They were settled weeks earlier on the afternoon the thing happened, by somebody who had no idea any of it would ever be read.

Claims fail on process more often than on merit

The usual reasons a delay claim comes apart are well known in the industry. A notice that arrived late, no evidence tying the delay to the critical path, a global claim that never links a particular cost to a particular cause, or reliance on a verbal direction with nothing in writing behind it.

Only the first of those is a diary date in an office. The other three are decided on site at the time, by whatever somebody wrote down.

So a claim can be right on the facts and still fail. The delay happened, it really was somebody else's risk and the record of it won't carry the weight.

The clock is already running

Notice periods run from the event itself, or from the point the contractor should reasonably have become aware of it. That's a different date from the day anybody works out that a claim exists.

AS 2124 and AS 4000 commonly allow 28 days, FIDIC runs 28 days from awareness with a further window for the detailed claim and NEC4 allows eight weeks for a compensation event. Amended contracts often shorten whatever the standard form says, so the only number that matters is the one in your own contract.

These deadlines generally get enforced as written, which CMA Assets Pty Ltd v John Holland Pty Ltd [No 6] [2015] WASC 217 shows plainly. A subcontractor on a wharf upgrade lost its extension of time entitlement because its notices of delay were late or incomplete, in circumstances where the main contractor had caused both delays and knew about them. The court said strict application of the clause was harsh, then applied it strictly, since the contract had made compliance a precondition to any entitlement.

Getting the notice in on time isn't the end of it either, since a notice can also fail for not carrying the detail the contract asks for. That detail comes from the site record.

What the record has to carry

An event needs enough written down at the time to answer the questions a claim will ask of it months later, which in practice comes to five things.

When it happened. The date, plus the time where it matters, since an event at seven in the morning and the same event at three in the afternoon have very different consequences for the rest of the day.

What it stopped. The activity, not just the area. A note saying work was held up in Zone B establishes very little, while a note naming the activity can be matched against the programme and tested for whether it sat on the critical path.

How long it lasted. Written down at the time, not worked out later from the fact that something didn't finish. A half day you recorded on the day is a fact, while a half day worked out afterwards is an opinion.

The cause, described the same way every time. A fixed reason picked at the point of the event, instead of a sentence typed hours later. This is what decides whether a pattern can be shown across a month or a project, since four descriptions of the same cause can't be counted together.

Who was standing there. A record made by that person counts for more than a summary written up later by somebody who wasn't.

Why it can't be put back together afterwards

When a claim starts to take shape the usual move is to go back through the diaries, the photos and the message threads and build the picture from whatever survives. That gets you roughly what happened without getting you the link between the event and the programme, since nobody wrote down which activity stopped or for how long. A link worked out in hindsight by somebody who was elsewhere counts for a lot less than one recorded on the day.

It also tends to produce a global claim, since once the individual links were never captured the only claim left is a general one saying a group of events caused a group of consequences. Those are the ones that get rejected.

The programme is the other half

None of this works without a programme that was being kept up to date. A delay can only be shown to have hit the critical path if there's a baseline and a sequence of updates to compare it against.

The records and the programme are two halves of the same evidence, with the records establishing what happened and when while the programme establishes what that meant for completion.

Projects with good records and a stale programme end up roughly where projects with neither end up. The events are documented and nothing can be proven about their effect.

What to do about it on Monday

Pick the causes that cost you time on your own jobs and agree a short list of them. Have every one of those events recorded on the day with the activity, the duration and the reason taken from that list, then keep the programme updated often enough that the comparison means something.

None of that needs anybody to know in advance which event will turn into a claim, which is the whole point of doing it that way.

The alternative is where most projects sit, with the entitlement real and the record of it thin, so an argument that should have been straightforward turns into a negotiation about what everybody remembers.

Explore SiteVector

See how Flow, Commit and Vector capture site data in real time.