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
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.
Related
Go from a number to a plan
The guides behind this tool, and the other free tools alongside it.
