All templates

Ops

Statement of Work (SOW)

SOW template for services founders or project addenda to an MSA: scope, deliverables, milestones, acceptance, change-requests, fees, IP. Educational only.

Last updated June 16, 2026

What it is

A project-level agreement that sits underneath an executed Master Services Agreement (MSA), or as a standalone services contract for one-off engagements. Defines the specific work, what 'done' looks like, when payment happens, and how scope changes are handled.

When to use it

Every project under an MSA, every standalone services engagement, every custom-build addendum to a SaaS deal. The SOW is where scope-creep disputes are won or lost — write it specifically and accept changes only through the change-request flow.

Important: Educational only. Not a legal document. Final SOW language should be reviewed by a qualified commercial lawyer in your jurisdiction. The IP, indemnification, and acceptance clauses in particular are jurisdiction-sensitive and contract-stack-dependent (must align with the underlying MSA).

The template

# Statement of Work [#XXXX]

**Under:** Master Services Agreement dated [Date] between [Provider Name] ("Provider") and [Client Name] ("Client"). (OR: Standalone — references no MSA.)

**SOW effective date:** [Date]
**Project name:** [Name]

---

## 1. Background

[2-3 sentences describing the Client's situation and the high-level objective of the engagement. Keep factual; this is referenced in disputes about intent.]

## 2. Scope of services

Provider will perform the following services:

1. **[Workstream 1]** — [Specific deliverable description]
2. **[Workstream 2]** — [Specific deliverable description]
3. **[Workstream 3]** — [Specific deliverable description]

**Specifically excluded from scope** (must use a change request to add):
- [Item explicitly out of scope 1]
- [Item explicitly out of scope 2]
- [Anything that comes up in conversation but isn't on the scope list above]

## 3. Deliverables

| # | Deliverable | Format | Acceptance criteria |
|---|---|---|---|
| 1 | [e.g., Discovery report] | PDF, ≤30 pages | Client reviews and accepts within 5 business days; if no response, deemed accepted |
| 2 | [e.g., MVP web application] | Hosted, source code in private GitHub repo | Passes the acceptance test plan in Schedule A; security review completed |
| 3 | [e.g., Training session] | 2-hour Zoom + recorded video | Delivered to ≥5 named attendees |

## 4. Milestones and timeline

| Milestone | Target date | Dependent on |
|---|---|---|
| Kick-off | [Date] | SOW signature; Client purchase order |
| [Milestone 1] | [Date] | Kick-off complete |
| [Milestone 2] | [Date] | Milestone 1 acceptance |
| Final delivery | [Date] | All milestones accepted |

Provider will use commercially reasonable efforts to meet target dates. Material slippage (>10 business days) of any milestone driven by Provider triggers a status review meeting within 5 business days.

## 5. Acceptance procedure

1. Provider delivers the deliverable per Section 3.
2. Client has **[5 / 10] business days** to review and either accept or reject in writing, identifying specific gaps against the acceptance criteria.
3. If Client rejects, Provider has **[5 / 10] business days** to remediate. The cycle repeats up to **[2 / 3] times**.
4. If Client does not respond within the review window, the deliverable is deemed accepted.
5. If after the maximum remediation cycles the deliverable is still rejected, the parties enter a 5-business-day escalation period before invoking the dispute procedure in the MSA.

## 6. Change-request procedure

Any change to scope, deliverables, timeline, or fees must be documented in a Change Request signed by both parties' authorised representatives.

Verbal changes (in meetings, on Slack, in calls) **do not bind** either party until the Change Request is signed. Provider may continue working on out-of-scope items only at Provider's risk and without expectation of additional fee unless and until the Change Request is executed.

The Change Request will state: (a) the changed scope / deliverable, (b) the impact on timeline, (c) the impact on fees, (d) any other affected terms.

## 7. Fees and payment schedule

| Trigger | Amount | Invoice timing |
|---|---|---|
| Signature | $[X] (XX% of total) | On SOW execution |
| Milestone 1 acceptance | $[X] | On acceptance |
| Milestone 2 acceptance | $[X] | On acceptance |
| Final acceptance | $[X] | On final acceptance |

**Total fixed fee:** $[X] (excluding expenses, excluding VAT/sales tax).

[**OR for time-and-materials:** Provider will invoice monthly at $[X]/day for actual days worked, capped at $[Y] without prior written approval.]

Payment terms: **Net 14 days** from invoice. Late payments accrue interest at [4]% above [Bank of England base rate / Federal Reserve prime rate]. Provider may suspend work for invoices unpaid more than 30 days.

## 8. Reasonable expenses

Pre-approved expenses (travel, third-party services, software licences exclusively for the project) will be invoiced at cost plus a [0% / 10%] administration fee. Receipts provided on request. Single expenses over $[500] require advance written approval.

## 9. Intellectual property

[**Default (Provider builds for Client):** All work product created by Provider in performance of this SOW, on payment in full of all sums due, is assigned to Client. Provider retains ownership of pre-existing tools, frameworks, and methodologies (the "Provider IP") and grants Client a non-exclusive, perpetual licence to use Provider IP solely as embedded in the deliverables.]

[**Alternative (license, not assignment):** Work product remains owned by Provider; Provider grants Client a [exclusive / non-exclusive], [worldwide], [perpetual], [royalty-free] licence to use, modify, and distribute the work product for [stated purpose].]

## 10. Term and termination

This SOW commences on the effective date and continues until the final deliverable is accepted, or until earlier terminated.

Either party may terminate this SOW:
- For convenience on **30 days'** written notice (Provider entitled to fees for work completed plus reasonable wind-down costs)
- For material breach not cured within **14 days** of written notice
- Immediately on insolvency, bankruptcy filing, or change of control of the other party

On termination, Provider delivers all work-in-progress in then-current form; Client pays for work performed up to termination plus accepted deliverables not yet invoiced.

## 11. Other terms

All other terms not addressed in this SOW (warranties, limitations of liability, indemnification, confidentiality, governing law) flow from the MSA referenced above. If there is a conflict between this SOW and the MSA, **this SOW prevails** for matters of scope, deliverables, fees, and timeline; the MSA prevails on all other matters.

[**For standalone SOWs (no MSA):** Insert here the standard MSA clauses for warranties, limitation of liability, indemnification, confidentiality, governing law.]

---

**Signed for Provider:**
Name: _______________________
Title: _______________________
Date: _______________________

**Signed for Client:**
Name: _______________________
Title: _______________________
Date: _______________________

---

## Schedule A — Acceptance test plan

[Project-specific test cases that constitute acceptance. Be specific. "The web application loads without errors and supports user registration, login, and account deletion" is better than "the deliverable works."]

## Schedule B — Project team

| Role | Provider side | Client side |
|---|---|---|
| Project sponsor | [Name] | [Name] |
| Technical lead | [Name] | [Name] |
| Day-to-day contact | [Name] | [Name] |
| Acceptance signatory | [Name] | [Name] |

Changes to the named acceptance signatory require written notice.

Common mistakes

  • Vague scope statements ('build the app' instead of 'build the user registration, login, dashboard, and account-deletion flows') — invites scope-creep arguments
  • No explicit out-of-scope list — every project I've audited that ended in dispute had no out-of-scope list
  • Accepting verbal change requests because the client is 'a good guy' — they cost millions in aggregate across the services industry
  • Acceptance criteria that aren't testable ('the app should be intuitive') — write criteria a third party could verify
  • IP clauses copied from MSA into SOW with conflicting terms — read both side-by-side before signing

Related resource

Founder Legal Checklist