SoftwareCrafting Logo

Free Template

Statement of Work Template

Most project disputes trace back to a missing exclusions section.

A statement of work is where scope becomes enforceable. This covers the clauses arguments actually come from.

The template

Fill the bracketed fields and delete what does not apply. If you can only complete one section properly, make it exclusions.

Before you use this: This is a starting point, not legal advice. We are engineers, not lawyers. Have counsel review anything you intend to sign, particularly liability, payment, and governing-law terms.

STATEMENT OF WORK

Project: [PROJECT NAME]
Client: [CLIENT LEGAL NAME]
Supplier: [SUPPLIER LEGAL NAME]
Effective date: [DATE]
SOW reference: [NUMBER]

1. BACKGROUND AND OBJECTIVE
[One paragraph: what the Client is trying to achieve, and what success looks
like in business terms rather than technical ones.]

2. SCOPE OF WORK
The Supplier shall deliver:
  2.1 [Deliverable one — describe the functionality, not the implementation]
  2.2 [Deliverable two]
  2.3 [Deliverable three]

3. EXCLUSIONS
For the avoidance of doubt, the following are NOT in scope and would require a
change request:
  3.1 [e.g. Native mobile applications]
  3.2 [e.g. Migration of historical data from the legacy system]
  3.3 [e.g. Third-party licence and subscription costs]
  3.4 [e.g. Content creation, copywriting, and photography]
  3.5 [e.g. Ongoing maintenance after the stabilisation period]

4. DELIVERABLES AND ACCEPTANCE
Each deliverable is accepted when it meets the acceptance criteria below and
the Client has confirmed in writing, or [10] business days have passed since
delivery without written objection.

  Deliverable: [NAME]
  Acceptance criteria: [Specific and testable. "The user can complete checkout
  with a test card and receives a confirmation email" — not "checkout works".]

5. TIMELINE AND CLIENT DEPENDENCIES
Indicative schedule:
  [Phase]        [Start]        [End]
The schedule assumes the Client provides, within [2] business days of request:
  5.1 Decisions on open product questions
  5.2 Access to environments, repositories, and third-party accounts
  5.3 Content, designs, and brand assets
Delay in any dependency extends the schedule by at least the period of delay.

6. COMMERCIAL TERMS
Total fee: [AMOUNT] [CURRENCY], exclusive of taxes.
Payment schedule:
  6.1 [X]% on signature
  6.2 [X]% on acceptance of [milestone]
  6.3 [X]% on final acceptance
Invoices are payable within [15] days. Expenses require prior written approval.

7. CHANGE CONTROL
Any change to scope, deliverables, or timeline shall be documented in a written
change request stating the change, the cost impact, and the schedule impact,
and takes effect only when signed by both parties.

8. INTELLECTUAL PROPERTY
All work product created under this SOW vests in the Client on creation. The
Supplier retains ownership of pre-existing materials and general know-how, and
grants the Client a perpetual, non-exclusive licence to use any such materials
embedded in the deliverables. Work shall be committed to a repository
controlled by the Client from the outset.

9. WARRANTY
The Supplier warrants that deliverables will materially conform to the accepted
acceptance criteria for [30] days after acceptance, and will remedy
non-conformities in that period at no charge. This does not cover changes in
third-party services, changes requested after acceptance, or modifications made
by others.

10. EXIT AND HANDOVER
On completion or termination, the Supplier shall deliver: source code and
history, documentation sufficient for another engineer to continue,
environment and deployment instructions, and transfer of any credentials held.
Handover is included in the fee and is not separately chargeable.

11. TERMINATION
Either party may terminate on [14] days written notice. The Client shall pay
for work performed to the termination date. Clauses 8, 10, and 12 survive.

12. LIABILITY AND GOVERNING LAW
[Liability cap and exclusions — have counsel draft this clause.]
This SOW is governed by the laws of [JURISDICTION].

Signed:

Client:   ______________________   Name: ____________   Date: __________
Supplier: ______________________   Name: ____________   Date: __________

Quick Answer

Updated August 22, 2026

What should a statement of work include?

Eight things: what is being built, what is explicitly excluded, deliverables and acceptance criteria, timeline and dependencies, commercial terms and payment schedule, change control, IP ownership, and exit and handover. The section that prevents the most disputes is exclusions — writing down what is not in scope is more useful than any amount of detail about what is, because disagreements almost always concern something nobody wrote down at all. Acceptance criteria come second: "working" is not a testable standard.

Sections

8 core clauses

Most disputes come from

Missing exclusions

Pairs with

An NDA and IP assignment

Best for

  • Fixed-scope projects where the deliverable is defined
  • Any engagement above roughly $15,000
  • Adding structure to a dedicated-team engagement per phase

Not best for

  • Open-ended dedicated-team work, where a lighter master agreement fits
  • Very small pieces of work where the SOW costs more than the task
  • Substituting for jurisdiction-specific legal review
Get a real number for your project

FAQ

Questions about this tool

What is the difference between an SOW and a contract?

A master services agreement sets the standing legal terms — liability, confidentiality, governing law. The statement of work sets what is being built, for how much, by when, under that agreement. For a single project the two are often combined, which is fine.

Why is the exclusions section so important?

Because disputes are almost never about something written in the scope. They are about something nobody wrote anywhere, where each side assumed a different answer. Listing what is out of scope surfaces those assumptions while it is still cheap to resolve them.

What makes a good acceptance criterion?

Something testable by someone who was not in the conversation. "The user can complete checkout with a test card and receives a confirmation email within one minute" is testable. "Checkout works" is not, and it is where arguments start.

Do we need an SOW for a dedicated-team engagement?

Less so — dedicated-team work is bought by the month, not by deliverable, so a lighter master agreement plus a sprint-level plan usually fits better. An SOW per phase is a reasonable middle ground when a stakeholder needs a defined number.

Should the SOW say where the code lives?

Yes, and it is a small clause with outsized value. Requiring work to be committed to a repository the client controls from the outset makes ownership a practical fact rather than only a legal claim, and it makes any exit straightforward.

Ready when you are

Not sure
where to start?

Tell us your goal and we'll suggest the smallest, fastest way to get there. We reply in under 4 working hours.