If you work in UK construction long enough, you eventually end up in the pub argument: “JCT or NEC?”
One side swears JCT is clearer and safer. The other insists NEC is fairer and more modern. Both sides usually have scars to show for it.
Most write-ups on this topic dive into legal philosophy. This one’s different. Let’s look at what JCT vs NEC actually does to your day-to-day workflow: how you get paid, how changes are handled, how the programme drives money, and what all of that means for cost control.
If you want a refresher on the JCT side of the world before we start, the big overview is here: JCT Contracts Explained: Types, Payment Terms, and How to Manage Them in Practice.
JCT vs NEC in one sentence each
Very roughly:
- JCT is a traditional building contract: detailed clauses, clear roles, strong focus on valuations, payment notices and variations.
- NEC is a management contract: short clauses, collaborative language, strong focus on early warnings, compensation events and a live programme.
Both can work brilliantly. Both can be a mess. The difference comes from how your team behaves inside the structure, not from magic words in the front cover.
On the JCT side, you’ve got a whole family of forms – Standard Building, Design and Build, Intermediate, Minor Works and friends. If you’re still choosing the right flavour, this guide is useful context: JCT Contract Types Explained: How to Choose the Right Form for Your Project.
How payment actually works: JCT vs NEC
Let’s start with the thing everybody cares about first: cash.
Under most JCT forms, interim payment is a rhythm of applications, due dates, payment notices, pay less notices and final dates for payment. The contractor typically submits an application; that sets or ties into the due date; then the contract administrator issues a payment notice stating the notified sum, and if the payer wants to pay less, they must serve a valid pay less notice before the final date for payment.
The whole thing is very rules-based. If a notice is late or missing, the consequences can be significant. We unpack that cycle properly in JCT Payment Terms and Timeline: A Simple Guide (with Examples).
Under NEC, you’re talking about assessment dates and payment certificates rather than applications / payment notices, but the core idea is similar: on each assessment date, the Project Manager assesses the amount due, issues a certificate, and the Contractor gets paid by the time stated in the Contract Data.
So where’s the real difference?
In practice:
- JCT leans more on the contractor’s application as the starting gun for the cycle.
- NEC leans more on the Project Manager’s assessment on the assessment date, whether or not the contractor does anything fancy.
That has consequences for behaviour. Under JCT, you suffer if you miss your application dates or if your applications are vague. Under NEC, you suffer if the Project Manager doesn’t take the assessment process seriously or if you don’t keep the records they need to assess you fairly.
In both worlds, a sloppy process gives you surprise cashflow. The “better” system is the one your team actually runs properly.
Change control: variations vs compensation events
This is where the two contracts really feel different.
JCT: variations and relevant events
JCT handles change with familiar tools:
- Instructions that change the works.
- Variations, valued using contract rates, dayworks or other agreed methods.
- Relevant events and relevant matters, for time and money.
It’s very recognisable to anyone who has worked under traditional building contracts. The danger is that variations can quietly accumulate. If you don’t log instructions and value them promptly, you end up with a vast “to be confirmed” pile and a final account that feels like archaeology.
If you want to see how this plays out in specific forms, we go into it in these deep dives:
- JCT Standard Building Contract: Key Clauses That Affect Cost Control
- JCT Design and Build: How to Manage Design Risk and Variations
- JCT Minor Works: Keeping Small Projects Under Control Without Overkill
- JCT Intermediate Contract: When It Fits and How to Administer It
NEC: early warnings and compensation events
NEC has a different personality.
It pushes two ideas hard:
- Early warnings – both parties must warn each other as soon as they are aware of a matter that could increase cost, delay completion or affect performance.
- Compensation events – defined events that entitle the Contractor to time and money, which should be notified, assessed and (in theory) agreed quickly.
The promise is appealing: instead of saving everything for final account battles, deal with change as it happens; link it to the programme; keep people honest.
The catch? You have to actually:
- Raise early warnings on time.
- Notify compensation events correctly.
- Respond within the time limits.
- Keep the programme updated.
That’s a lot of discipline. If the project team treats NEC like a JCT-ish contract with different headings, it can be worse than JCT because the “collaborative” mechanisms get ignored and only the time-bars remain.
From a cost-control point of view, you can think of it like this:
- JCT lets you drift… and then dumps the complexity into final account.
- NEC tries to stop you drifting… and punishes you if you do it anyway.
Programme management: whose schedule actually matters?
Both JCT and NEC care about the programme. They just care in different ways.
Under JCT, the contractor usually has to provide a programme and keep it reasonably up to date. Delays are dealt with through extensions of time, linked to relevant events. In reality, the programme can sometimes float in the background while commercial discussions happen off to the side.
Under NEC, the programme is front and centre. The “Accepted Programme” is a contract document. Compensation events are often assessed by reference to its impact on planned Completion. If you don’t submit a programme when you should, the Project Manager can assess events on a programme of their own, which is… not ideal.
Practically:
- JCT can make it easier to fudge dates for a while, and then argue later.
- NEC makes it harder to ignore the programme, but also more punishing if you fail to run it properly.
From a QS / PM viewpoint, NEC gives you better tools to see the cost and time impact of change in real time if you keep the programme live. JCT lets you get by with a messier programme, but you pay for it in uncertainty and back-ended disputes.
| Aspect | JCT | NEC | Practical impact for cost control |
|---|---|---|---|
| Contract style | Traditional building contract with detailed clauses and roles | Management-style contract with short clauses and collaborative tone | Different language, similar need for discipline in how the team actually works |
| Payment mechanism | Interim applications, due dates, payment notices, pay less notices | Assessment dates, amounts due and payment certificates | JCT punishes late/missing notices; NEC punishes poor assessments and weak records |
| Change control | Variations, relevant events/matters, often pushed towards final account | Early warnings and compensation events, meant to be dealt with quickly | JCT lets change drift; NEC tries to force early agreement but time-bars bite |
| Programme role | Programme underpins extensions of time but can drift into background | Accepted Programme is a central contract document | NEC rewards a live programme; JCT tolerates a messier one (until there’s a dispute) |
| Typical failure mode | Unlogged variations and vague applications causing final account fights | Missed notifications and stale programmes causing disputed compensation events | Different traps, same outcome if you don’t run the processes |
| Works best when… | You’re good at valuations, notices and structured variation logs | You’re good at early warnings, live programming and quick decisions | Pick the one that fits both the project and your team’s habits |
Two mini-scenarios: same issue, two contracts
Let’s run a deliberately simplified scenario under each form to see how they feel.
Scenario: client instructs a scope change mid-project
Same facts:
- Mid-way through the job, the client decides to add extra M&E work and some finishes upgrades.
- It’s clearly additional scope; everyone agrees it’s not included in the original contract sum.
- The change will push the programme by two weeks if nothing else moves.
Under JCT, the usual pattern is:
- Architect / contract administrator issues an instruction.
- You treat that as a variation and price it.
- You submit your valuation; some back-and-forth happens on rates and quantities.
- You ask for an extension of time if the delay meets the “relevant event” criteria.
- You incorporate the agreed value into the contract sum and future interim applications.
It’s perfectly functional… if you capture the instruction, price it promptly, and keep the paper trail tight. If you don’t, it drifts into the fog of “to be agreed in the final account”, where memories are shorter and people are grumpier.
| Step | Under JCT | Under NEC |
|---|---|---|
| Change arises | Architect/CA issues an instruction | Event occurs and should trigger an early warning |
| Notifying / logging | Treated as a variation and added to the variation log | Notified as a compensation event |
| Pricing the change | Contractor prices variation; value agreed or argued over | Contractor submits quotation; Project Manager accepts or assesses |
| Time impact | Extension of time requested based on relevant events | Time impact shown on programme and included in compensation event |
| When it’s really resolved | Often partly parked until later valuations / final account | Intended to be resolved when the compensation event is assessed |
Under NEC, the playbook is different:
- The instruction is (or should be) treated as a compensation event.
- You notify it, submit a quotation, and show the effect on both cost and programme.
- The Project Manager accepts or rejects the quotation, or sets their own assessment.
- The Accepted Programme is updated to reflect the change.
When it works well, NEC forces everyone to confront cost and time implications early. You don’t “bank” problems for later. When people ignore the process, NEC can feel like living in a maze of missed notifications, disputed assessments and arguments about time-bars.
So which is better? For cost control, the honest answer is: whichever one your team has the discipline to run properly.
Cost control in the real world, not the contract commentary
In theory, NEC should give better real-time visibility and quicker agreement of change. In theory, JCT should give clear, structured valuation and solid protection if notices are late or missing.
In real life, what matters is:
- How you track instructions, early warnings and compensation events.
- How your payment applications and certificates line up with real progress.
- How your forecasts talk to your budgets, not just to the contract.
On both JCT and NEC projects, the biggest killers of margin are the same:
- Untracked change that only surfaces at final account.
- Payment cycles that slip because dates and notices live in someone’s head.
- Programmes that are out of date, so time impacts are always fuzzy.
That’s why the other JCT pieces we’ve put together focus so much on workflow, not theory:
- JCT Payment Terms and Timeline: A Simple Guide (with Examples)
- Free JCT Templates: Payment Schedule, Valuation & Variation Logs
The “NEC version” of the same thinking looks very similar: clean early warning and compensation event logs, linked to a live programme and a cost forecast.
How software should adapt: JCT-aware and NEC-aware, not opinionated
This is where Planyard comes in, but not as a “JCT good, NEC bad” cheerleader.
From a tooling perspective, you actually want something a bit boring: a system that can handle both JCT and NEC jobs with slightly different configurations.
For JCT projects, that means:
- Contract set up with original contract sum, retention, and JCT-style payment dates.
- Interim applications built from live valuations and variation data.
- Payment notices and pay less notices tracked cleanly against each application.
- A proper history so that when you reach final account, you’re not reconstructing three years of emails.
That’s what JCT Payment Application Software and JCT Contract Management Software for Contractors and QSs are aiming to support: the same JCT mechanisms, minus the spreadsheet gymnastics.
For NEC projects, the shape is slightly different:
- Contract set up with NEC-style assessment dates instead of JCT due dates.
- A log of early warnings and compensation events that talks to both the programme and the budget.
- Assessments that clearly show which events and scope changes are included.
- A tie-in between the Accepted Programme and cost forecasts.
Under the hood, you still want the same things: one source of truth for contract sum, changes, assessments and payments. The software doesn’t have to pick a side in the JCT vs NEC debate; it just has to respect both rulebooks.
So… which is actually better?
If you want the clickbait answer: neither wins automatically.
If your team:
- Updates the programme,
- Logs change as it happens,
- Follows the notification rules, and
- Keeps cost and time aligned,
then NEC’s early-warning / compensation-event world can give you excellent control and fewer shocks.
If your team:
- Submits clear applications,
- Tracks variations properly,
- Watches notice dates like a hawk, and
- Uses the contract’s valuation structure,
then JCT can give you very solid protection and predictable payments.
If you do none of the above, both will hurt.
A more honest framing is:
- Pick the contract that suits the project and the client.
- Understand how that choice shapes your payment, change and programme workflows.
- Build tools and habits that make those workflows easy to follow.
On the JCT side, the rest of this content hub helps with that:
- JCT Contracts Explained: Types, Payment Terms, and How to Manage Them in Practice
- JCT Contract Types Explained
- JCT Payment Terms and Timeline
- JCT 2024: Key Changes for Contractors, QSs and Cost Control
And when you’re ready for a system that doesn’t really care whether the front cover says JCT or NEC, it’s worth a look at:
- JCT Contract Management Software for Contractors and QSs
- Automate JCT Payment Applications and Notices
The contract you pick decides the rules of the game. The way you run payment, change and the programme decides whether you actually enjoy playing it.