NEC Clause 31 Programme Acceptance: The Complete Guide For Contractors
- 5 hours ago
- 15 min read
There is a version of NEC project management where clause 31 is a procedural hurdle to clear at the start of the job and then file away. Submit the programme, wait for acceptance, move on. The programme is accepted. The project continues. Nobody thinks about it much until something goes wrong.
There is also a version where clause 31 is the foundation on which everything commercially important rests: every compensation event assessment, every delay argument, every entitlement to time and money. That version is what the contract actually describes. And the gap between those two versions is where the margin tends to go.
Clause 31 of the NEC4 Engineering and Construction Contract governs programme submission and acceptance. It is, as NEC's own guidance describes, the keystone of the contract. This article explains what that means in practice, not as a clause walkthrough, but as a commercial mechanism that works for the contractor when understood properly and against the contractor when it is not.
Why the programme is not like other NEC documents
Before working through clause 31 itself, it is worth understanding why NEC treats the programme differently from almost every other contract document.
Most construction contracts treat the programme as evidence. It shows what the contractor planned to do. If something changes, the contractor refers to the baseline to demonstrate the effect. The programme is a record, consulted after the event.
NEC treats the programme as a live management tool that carries contractual weight throughout the project. The accepted programme is not just a record of intent at contract award. It is, at any given moment, the agreed picture of how the remaining works will be delivered. Compensation events are assessed against it. Time entitlement flows from it. The project manager's ability to dispute a quotation is shaped by whether a credible accepted programme exists. When things change, NEC's mechanism for dealing with change requires both parties to work from a shared, current baseline.
That design choice has a specific commercial consequence. On a traditional contract, a stale programme is inconvenient. On NEC, a stale or non-existent accepted programme fundamentally changes the commercial position of the contractor, almost always for the worse.
What clause 31.1 actually establishes
Clause 31.1 sets out two possible starting points. Either the programme is identified in the contract data, in which case that programme becomes the first accepted programme without going through the acceptance process, or the contractor must submit a first programme within the period stated in the contract data.
In practice, the second route is the norm. Contractors submit a tender programme, win the job, and then produce a more detailed contract programme for submission after award. This is where the first trap lies.
A tender programme is not an accepted programme. It does not carry the contractual weight that an accepted programme carries. If the contractor starts work using the tender programme as a de facto baseline without obtaining formal acceptance under clause 31, there is no accepted programme in place. The compensation event clock, the delay assessment mechanism, and the entitlement architecture all require an accepted programme to function in the contractor's favour. Starting without one is starting without a commercial anchor.
The period for first submission is stated in the contract data. If the contract data is silent on this point, clause 31.1 requires submission within the period for reply after the starting date. Contractors should verify this period at contract award and treat the first programme submission as a commercial priority, not a box-ticking exercise.
What clause 31.2 demands, and why it is more than a checklist
Clause 31.2 is the longest clause in section 3 of the NEC4 ECC. It sets out what every programme submitted for acceptance must show. Most guidance treats this as a checklist. That misses the point.
The list in clause 31.2 is structured around a specific commercial purpose: giving the project manager a complete, internally consistent picture of how the contractor plans to deliver the remaining works, so that the effect of any change can be assessed against that picture. Every element of the list serves that purpose.
The programme must show the starting date, access dates, key dates and the completion date alongside the contractor's planned completion. The distinction between planned completion and the completion date matters commercially. Planned completion is the contractor's forecast of when the works will actually finish. The completion date is the contractual obligation. The gap between them is terminal float, which belongs to the contractor under NEC4 clause 63.5. A programme that places planned completion exactly on the completion date with no terminal float is either a programme with no risk margin at all, which is unlikely to be realistic, or a programme that will fail to demonstrate time entitlement properly when change arrives. The article on time risk allowance and terminal float in NEC covers that distinction in detail.
The programme must show the order and timing of the contractor's operations. This is not a high-level bar chart. NEC expects logic links: predecessor and successor relationships that show how the sequence was constructed and how disruption to one activity flows through to others. A programme with no logic links is a programme that cannot demonstrate the time effect of a compensation event, because there is no mechanical chain connecting cause to effect.
The programme must show time risk allowances. These are the contractor's own risk periods within activities, distinct from float. NEC4 requires them to be visible, not buried in activity durations. A programme where all risk is hidden inside duration estimates cannot be properly evaluated and cannot honestly demonstrate whether the contractor is carrying realistic contingency.
The programme must show the dates when the contractor will need access to parts of the site, acceptances from the project manager, plant and materials from the employer, and information from others. This requirement is commercially critical and routinely missed. If the programme does not show when the employer is required to provide something, clause 60.1(3), the compensation event for the employer failing to provide something by the date shown in the accepted programme, simply cannot be triggered. The contractor has removed its own entitlement by failing to model the dependency.
NEC4 added two requirements not present in NEC3. First, the programme must be in the form stated in the scope. This allows clients to specify software, format and level of detail in the scope document, making those requirements contractually enforceable rather than advisory. Second, NEC4 requires the programme to show health and safety requirements. Contractors should check the scope carefully for any additional programme requirements particular to the project, since failure to include scope-required information is a valid ground for non-acceptance under clause 31.3.
The four grounds for non-acceptance, and what they mean in practice
Clause 31.3 states that the project manager accepts the programme or notifies the contractor of its reasons for not accepting it. There are four stated grounds for non-acceptance.
The contractor's plans are not practicable. The programme is not practical on its face: durations that cannot be achieved with the resources shown, logic that does not reflect physical constraints, a sequence that contradicts site conditions or the scope of work.
The programme does not show the information the contract requires. This is a direct reference to clause 31.2. Any of the required elements that are missing or inadequately shown can ground a non-acceptance.
The programme does not represent the contractor's plans realistically. Even if the programme shows all the required information and looks internally consistent, the project manager can decline to accept it if it does not reflect what the contractor is actually planning to do. A programme that shows three shifts per day when the contractor has no intention of working three shifts is unrealistic. A programme that shows an activity starting before its prerequisite is complete is unrealistic.
The programme does not comply with the scope. Client-specified requirements in the scope, such as software format, level of detail, naming conventions, interface modelling and reporting structure, must be met.
Two things follow from this list. First, it is an exhaustive list. The project manager cannot invent additional grounds for non-acceptance beyond these four. If a programme is rejected for a reason outside these four categories, clause 60.1(9) provides the contractor with a compensation event, as the project manager has withheld acceptance for a reason not stated in the contract. Second, when the project manager notifies non-acceptance, they must give reasons under clause 13.7. Vague or general reasons that do not connect to one of the four grounds are insufficient and potentially give rise to a compensation event in themselves.
In practice, contractors should read non-acceptance notifications carefully against each of the four grounds. A notification that says "the programme is not sufficiently detailed" might be legitimate under ground two, but only if specific missing information is identified. A notification that says "we do not agree with your methodology" is not a valid ground for non-acceptance at all, as the contract does not require the project manager to agree with the contractor's chosen method.
NEC Clause 31 programme acceptance: the two-week timeline and deemed acceptance
Clause 31.3 gives the project manager two weeks from receipt of the programme to either accept it or notify non-acceptance with reasons. This two-week period is a hard contractual obligation on the project manager, not a target.
In NEC3, if the project manager failed to respond within two weeks, the only remedy was a compensation event under clause 60.1(1), covering a failure by the project manager to give a decision or reply within the required time. That compensation event could produce time entitlement and, in theory, cost, but in practice it did not give the contractor an accepted programme. The project manager could remain silent indefinitely without the programme ever becoming accepted.
NEC4 introduced a more meaningful remedy. If the project manager does not respond within two weeks, the contractor may notify the project manager of that failure. If the project manager then fails to respond within a further one week, the programme is deemed accepted. The total window is three weeks from submission: two weeks for the project manager to respond, then one additional week after the contractor's chase notification.
This is the only deemed acceptance provision in the NEC4 ECC, and it does not operate automatically. The contractor must issue the notification of failure after the two-week period has passed. Without that notification, the programme does not become deemed accepted regardless of how long the project manager takes to respond.
The practical consequence for contractors is this. Track programme submissions precisely. Note the two-week deadline. If the project manager has not responded by that date, send a formal notification of failure to respond immediately. Then track the one-week window. If no response comes within that further week, confirm the deemed acceptance in writing. A programme that is deemed accepted is contractually an accepted programme with all the commercial weight that carries.
Project managers who understand the NEC4 machinery will not let programmes sit unresponded. Those who do not understand it, or those who treat programme acceptance as administrative routine, may leave programmes in limbo for months. The deemed acceptance provision was introduced precisely to prevent that, and contractors should use it.
The 25 percent withholding sanction
Clause 50.5 of NEC4 (clause 50.3 in NEC3) allows the project manager to withhold one quarter of the price for work done to date if the contractor has not submitted a first programme showing the information this contract requires. This is the only provision in the entire NEC4 ECC allowing the project manager to withhold payment from the contractor.
Several points about this sanction deserve attention. It applies only to the absence of a first programme that shows the required information. Once the first accepted programme is in place, clause 50.5 does not apply to later revisions. The contractor cannot be withheld from for failing to update the programme promptly under clause 32, however commercially damaging that failure may be in other ways.
The sanction applies if the contractor has not submitted a programme showing the required information, not if the programme has not yet been accepted. This distinction matters. If the contractor has submitted a compliant programme but the project manager has not yet accepted it, clause 50.5 does not apply. The sanction is for failure to submit, not for the project manager's failure to accept.
In practice, contractors should submit a first programme as early as possible after contract award, ensure it contains all the information required by clause 31.2, and retain evidence of submission. A compliant submission eliminates the 50.5 risk immediately, regardless of how slowly the project manager moves through the acceptance process.
The misconception that prevents timely acceptance
There is a well-documented reluctance on the part of project managers to accept programmes, rooted in a misunderstanding of what acceptance means under NEC.
Clause 14.1 is clear: acceptance of a communication, including a programme, does not change the contractor's obligation to provide the works. Accepting the programme does not mean the project manager has endorsed the contractor's methodology, agreed that the programme is achievable, taken responsibility for any risk the contractor has carried, or in any way transferred liability from contractor to employer.
What acceptance means is that, to the best of both parties' knowledge at that moment, the programme meets the requirements of clause 31.2 and represents the contractor's realistic plans. It is a shared reference point, not a guarantee or a liability transfer.
Project managers who treat acceptance as "signing their life away," and there are many, create a more commercially dangerous situation than the one they are trying to avoid. An absence of an accepted programme does not protect the employer's position. It destroys the mechanism that allows both parties to assess change quickly, fairly and from a shared baseline. Without an accepted programme, compensation events are harder to value, delay is harder to attribute, and disputes are more likely. The project manager who refuses to accept a broadly compliant programme thinking it gives them commercial protection has misread the contract.
This point is worth making directly to project managers when it arises. The accepted programme does not give the contractor a weapon. It gives both parties a tool.
Acceptance and the compensation event machinery
The connection between clause 31 and the compensation event mechanism is where the real commercial significance of programme acceptance lies.
Clause 62.2 requires that a compensation event quotation includes any changes to the accepted programme that the compensation event requires. The key phrase is "the accepted programme." If there is no accepted programme, or if the accepted programme is months out of date, the starting point for compensation event assessment is already compromised.
Clause 63.1 determines what counts as actual Defined Cost and what counts as forecast. The dividing date, being the date when the compensation event occurs, fixes the accepted programme snapshot that is used to assess time and cost. If the accepted programme at the dividing date does not show the activity affected by the compensation event, the programme cannot demonstrate the time effect of the change. The contractor is left arguing from first principles rather than from a contractual baseline.
This is the mechanism the article on NEC4 compensation event quotations covers in detail. The short version is this: a contractor with no current accepted programme at the moment a compensation event arises has lost the most important tool for demonstrating time entitlement. The project manager can assess the event using actual records rather than the contractor's forecast, and that assessment almost always produces a lower entitlement than the contractor expected.
Every accepted programme that is in place, current and compliant with clause 31.2 is protecting a specific future compensation event assessment. Every gap, every period where the programme has not been updated or where acceptance has lapsed, is a window of commercial exposure.
The drift problem: why a once-accepted programme is not enough
Clause 32 requires the contractor to revise the accepted programme and resubmit it for acceptance whenever the project manager instructs a revision, when the contractor chooses to revise it, and in any case at intervals no longer than those stated in the contract data (usually four weeks). Revisions must show the effects of implemented compensation events and may show the effects of others.
This is where clause 31 and clause 32 work together, and where the combination is most often undermined in practice.
A programme that was accepted at mobilisation and has not been revised in six months is an accepted programme in a narrow technical sense. It was accepted once. But it no longer represents the contractor's realistic plans. It does not show implemented compensation events. It does not show progress. It does not show how the remaining works will actually be delivered.
For the purposes of compensation event assessment, the relevant accepted programme is the latest one. A six-month-old programme accepted at mobilisation is the baseline for nothing useful when a compensation event occurs in month eight. The contractor needs a current accepted programme, one that was revised to incorporate everything that has happened since mobilisation, to demonstrate the time effect of new change.
The contractors who maintain their commercial position throughout an NEC project are the ones who treat programme revision and resubmission as a monthly discipline rather than an occasional task. Specialist contractor planning support is specifically designed to maintain this discipline for contractors who do not have a full-time planning function.
The article on when an accepted programme stops protecting a specialist contractor covers the specific failure pattern, programme accepted at mobilisation, quietly ageing, then proving inadequate when a dispute arrives, in more detail.
What good clause 31 practice looks like
Understanding the clause is one thing. Building a project rhythm around it is another.
First programme submission should be treated as a commercial priority, not an administrative task. The programme should be resourced, logic-linked and contain all the information clause 31.2 requires before submission. It should be submitted within the contract data period and the submission date recorded.
After submission, the acceptance clock should be tracked actively. Two weeks is the project manager's window. If no response has arrived by day fourteen, the contractor's notification of failure should go the same day.
Once accepted, revisions should be issued at least at the frequency the contract data requires, and more often if compensation events have been implemented or if the sequence has changed materially. Each revision should be dated, submitted formally and tracked for acceptance. Non-acceptance notifications should be read against the four grounds in clause 31.3 and any grounds outside those four should be challenged.
The programme narrative, meaning the written statement that accompanies the programme and explains what has changed and why, should be part of every revision. The project manager's acceptance of the programme is easier to obtain when the reasoning behind any changes is clearly articulated. And the narrative forms part of the contemporaneous record that supports compensation event submissions later in the project.
At every stage, the question is the same. If a compensation event arose today, would the current accepted programme provide a credible baseline for assessing its time effect? If the answer is no, the programme needs attention.
The argument in short
Clause 31 of the NEC4 ECC is not a compliance obligation to satisfy at the start of a project. It is the mechanism that determines whether the contractor can demonstrate time entitlement clearly and quickly, or whether every delay argument becomes a reconstruction exercise fought from a poor position.
The contractors who manage NEC projects well, those who recover their time entitlement cleanly, settle compensation events quickly, and retain their commercial position when things change, are not necessarily the ones with the most sophisticated planning software. They are the ones who understand that the accepted programme is a live commercial document, that it must be maintained throughout the project to carry contractual weight, and that the clause 31 process is the means by which that maintenance is formalised.
That understanding is not complicated. The discipline it requires is not large. A monthly update cycle, a formal submission, a tracked acceptance window. The commercial protection it provides when something goes wrong is substantial.
FAQ
What happens if there is no accepted programme on an NEC project?
Without an accepted programme, the compensation event assessment mechanism cannot function as NEC intends. The project manager has the right to assess compensation events themselves under clause 64, using actual records rather than the contractor's forecast. That assessment almost always produces a lower entitlement than the contractor expected. NEC's own FAQs confirm that the contract cannot be administered as properly intended without an accepted programme in place.
Can the project manager refuse to accept a programme for any reason?
No. Clause 31.3 sets out four exhaustive grounds for non-acceptance: the plans are not practicable, the required information is not shown, the programme does not represent the contractor's plans realistically, or the programme does not comply with the scope. Non-acceptance on any other ground is itself a compensation event under clause 60.1(9).
What is the difference between the accepted programme and the activity schedule?
They are different documents serving different purposes. The activity schedule (used under options A and C) sets out the prices for activities. The accepted programme sets out the sequence, timing and method. NEC4 requires the contractor to show how each activity on the activity schedule relates to the operations on the programme, but the documents are not interchangeable.
Does programme acceptance mean the project manager agrees with the contractor's methodology?
No. Clause 14.1 is clear that acceptance does not transfer the contractor's liabilities. The project manager accepts that the programme meets the requirements of clause 31.2 and represents the contractor's realistic plans. It is not an endorsement of methodology or a guarantee that the programme will be achieved.
How does the deemed acceptance provision work in NEC4?
If the project manager does not respond within two weeks of programme submission, the contractor may notify the project manager of that failure. If the project manager then fails to respond within a further one week, the programme is deemed accepted. The key point is that deemed acceptance does not happen automatically: the contractor must issue the notification of failure. Without that notification, the two-week period simply passes without consequence.
What is the 25 percent withholding sanction and when does it apply?
Clause 50.5 allows the project manager to withhold one quarter of the price for work done to date if the contractor has not submitted a first programme showing the information the contract requires. It applies only to the absence of a first compliant programme submission, not to failures to update the programme under clause 32. Once the first accepted programme is in place, clause 50.5 no longer applies.
How often should the programme be updated under NEC?
Clause 32 requires revisions at intervals no longer than those stated in the contract data, which is typically four weeks. In practice, revisions should be issued whenever implemented compensation events need to be incorporated, whenever the sequence changes materially, and at minimum at the contractual interval. The goal is to keep the accepted programme close enough to the live job that it can serve as a credible baseline for any compensation event that arises.
Need support keeping your programme accepted and current?
If the accepted programme is behind the live project, compensation event quotations are being built without a current baseline, or the clause 31 process has stalled, specialist programme support keeps the contractual record in the position it needs to be in.
Comments