Okategoriserad

JCT vs NEC: Which Contract Works Better for Cost Control and Payment Certainty?

november 25, 2025

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:

NEC: early warnings and compensation events

NEC has a different personality.

It pushes two ideas hard:

  1. 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.
  2. 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.

AspectJCTNECPractical impact for cost control
Contract styleTraditional building contract with detailed clauses and rolesManagement-style contract with short clauses and collaborative toneDifferent language, similar need for discipline in how the team actually works
Payment mechanismInterim applications, due dates, payment notices, pay less noticesAssessment dates, amounts due and payment certificatesJCT punishes late/missing notices; NEC punishes poor assessments and weak records
Change controlVariations, relevant events/matters, often pushed towards final accountEarly warnings and compensation events, meant to be dealt with quicklyJCT lets change drift; NEC tries to force early agreement but time-bars bite
Programme roleProgramme underpins extensions of time but can drift into backgroundAccepted Programme is a central contract documentNEC rewards a live programme; JCT tolerates a messier one (until there’s a dispute)
Typical failure modeUnlogged variations and vague applications causing final account fightsMissed notifications and stale programmes causing disputed compensation eventsDifferent traps, same outcome if you don’t run the processes
Works best when…You’re good at valuations, notices and structured variation logsYou’re good at early warnings, live programming and quick decisionsPick 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.

StepUnder JCTUnder NEC
Change arisesArchitect/CA issues an instructionEvent occurs and should trigger an early warning
Notifying / loggingTreated as a variation and added to the variation logNotified as a compensation event
Pricing the changeContractor prices variation; value agreed or argued overContractor submits quotation; Project Manager accepts or assesses
Time impactExtension of time requested based on relevant eventsTime impact shown on programme and included in compensation event
When it’s really resolvedOften partly parked until later valuations / final accountIntended 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:

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:

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:

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.

Vanliga frågor och svar

Vi har svar på alla dina frågor. Om du inte hittar svaret nedan är du välkommen att kontakta oss via chatten.

JCT is more traditional, with fixed roles and structured valuation and payment rules. NEC is management-driven, built around early warnings, compensation events and a live programme.

Neither is automatically better. NEC works well if you stay on top of early warnings and compensation events; JCT works well if you manage valuations, variations and notices properly.

JCT uses interim applications, payment notices and pay less notices. NEC uses assessment dates and certificates issued by the Project Manager. Good records matter more than the contract label.

In JCT, the programme mostly matters when discussing delays and extensions of time. In NEC, the Accepted Programme drives almost everything — if it’s not kept up to date, you lose control of time and cost.

Ladda upp din projektbudget och följ den ekonomiska utvecklingen i realtid

Inget kreditkort krävs. Ingen försäljning eller IT-support behövs.