Why Every Subcontractor Package Needs a Clear Exclusions List

Why exclusions matter as much as inclusions
Subcontractor disputes often begin long before the invoice arrives.
They usually begin with an assumption about what was included, what was left out, and what someone thought was obvious on the day the package was agreed. If that part is not written down clearly, the job can drift into arguments about extras, making good, access, waste removal, temporary works, or who was meant to do the final return visit.
A clear exclusions list is one of the simplest ways to stop that drift.
Most package descriptions focus on what the subcontractor is doing. That is useful, but it is only half the picture.
If the scope says what is included but never says what is excluded, people start filling in the blanks themselves. Site assumes one thing. The subcontractor prices another. Commercial assumes the package is tighter than it really is. Accounts only finds out when a query lands with the invoice.
That gap causes predictable problems:
- the subcontractor prices an assumption the main contractor never intended
- the site team expects making good that was never included
- the office receives a variation that should have been agreed earlier
- accounts has to decide whether an invoice line is part of the package or an extra
The work still gets done, but the record no longer tells the same story to everyone involved.
Write the scope as two parts
A useful package record should show both sides of the deal:
- what is included
- what is excluded
That sounds basic, but it makes the commercial intent much harder to misunderstand.
For example, a fitting-out package might include the installation and fixings, but exclude:
- making good to finished decoration
- access equipment
- out-of-hours working
- waste removal
- temporary protection
- specialist testing and certification
Each exclusion removes a possible argument later. If the item matters enough to affect cost, delay, or responsibility, it is worth writing down.
Be specific rather than vague
An exclusion such as "making good excluded" is better than nothing, but it is still too broad for many live jobs.
If the package needs to be clear, spell out the detail:
- making good to painted finishes excluded
- ceiling tile replacement excluded
- scaffold provision excluded
- permits and road closures excluded
- final clean excluded unless stated otherwise
The same principle applies to inclusions. The more specific the wording, the less room there is for a later argument about what the team "meant".
This is especially important on fit-out, refurbishment, and maintenance jobs where the site conditions change quickly and the package can be affected by access, phasing, or other trades.
Link the exclusions to the job reference
An exclusions list only works if it stays attached to the live job record.
If the package description sits in one email, the exclusions are in a WhatsApp message, and the approval is in a separate thread, nobody has a single source of truth. The office then has to reconstruct the package from fragments when the invoice arrives.
A better record includes:
- the job reference
- the package name
- the drawing or revision number
- the inclusions
- the exclusions
- the approval date
- the person who approved it
- any later revision or variation
That keeps the commercial story readable for site, QS, and accounts.
Separate exclusions from variations
An exclusion is not the same as a variation.
An exclusion says the subcontractor was never pricing that item in the first place. A variation says the scope changed after the package was agreed. If the team blurs those two, the record becomes harder to trust.
That distinction matters when a query comes in later:
- if the item was excluded, it should not appear as a surprise
- if the item was added later, it should follow the variation route
- if nobody can tell which is true, the paperwork has not been controlled properly
This is where scope control protects margin. It stops the business paying twice for the same work or arguing over something that should have been settled before site start.
What accounts needs to see later
Accounts should not have to guess whether a line on an invoice belongs to the original package.
By the time the invoice arrives, the live record should already show:
- what the subcontractor agreed to do
- what was expressly excluded
- what changed after approval
- which version is current
- whether any extra work was authorised separately
If that is not clear, the invoice should be held until the job team resolves the record. That is much easier than trying to recover the truth after the payment run has moved on.
A simple package checklist
Before the subcontractor starts, check that the package record answers these questions:
- What exactly is included?
- What is explicitly excluded?
- Who approved the package?
- What job reference and drawing revision apply?
- What happens if the scope changes?
- Who signs off any extra work?
- Where will the live record live once the job starts?
If any of those answers lives only in someone’s memory, the package is not ready yet.
How BuilderDash helps
BuilderDash helps by keeping the package scope, approval trail, and job reference together in one place.
That makes it easier to see whether an item was genuinely excluded, whether a later change was approved, and whether the invoice matches the version of the package everyone agreed to at the start.
For small and mid-sized contractors, that means fewer scope disputes, fewer invoice queries, and a cleaner trail from site instruction to commercial sign-off.
Suggested internal links
- How a Subcontractor Start Pack Keeps the First Day Under Control
- What Every Purchase Order Approval Should Contain Before It Becomes a Commitment
- What Every Construction Invoice Pack Should Contain Before Accounts Touch It
- What to Do When an Invoice Arrives Without a PO Number
Call to action
If package disputes keep coming back because nobody wrote down what was excluded, tighten the scope record before the next subcontractor starts. BuilderDash helps you keep the live package, approvals, and reference trail in one place so the job does not drift from the original agreement.
Run your projects properly with BuilderDash.
One system for every enquiry, job, quote and invoice - built for project-based trades, not reactive call-outs.


