Statement of Work Template (Free Download)

Below is a complete statement of work (SOW) template you can copy, adapt, and use today. Nope, you don’t need to enter your email or anything — just copy, paste, and fill in the blanks.

Remember, a template solves the blank-page problem but not the enforcement problem. A SOW only controls a project if something checks invoices against the budget you wrote and flags the scope changes nobody documented. Some sections of an SOW exist because the contract isn't enforceable without them. Others exist because your finance team, your ops team, or your best contractors will feel it if they're missing. And a few of the things that matter most can't live in a document at all.

First, the template.

Download a DOCX version of the Statement of Work Template here.

Key Takeaways

• A usable SOW needs eight sections: parties, scope, deliverables, timeline, pricing, acceptance criteria, change control, and out-of-scope exclusions.
• Write deliverables as artifacts with dates and formats. 
• The out-of-scope section prevents more disputes than any other part of the document, and it's the one most people skip.
• Templates standardize language. They don't enforce budgets, track expiry, or connect the contract to invoices, which is where SOWs can fail.

The Statement of Work Template

Copy everything from the heading below through the signature block. Replace the bracketed fields.

STATEMENT OF WORK

SOW Number: [SOW-001] Effective Date: [Date] Issued Under: Master Services Agreement dated [Date] between the parties below

1. PARTIES

Client: [Legal entity name, address] Provider: [Legal entity name, address] Client Project Contact: [Name, title, email] Provider Project Contact: [Name, title, email]

2. PROJECT OVERVIEW

[Two to three sentences describing the business objective. What is the client trying to accomplish, and why does this work exist? Keep it plain.]

3. SCOPE OF WORK

Provider will perform the following services:

• [Service or workstream 1, described specifically]
• [Service or workstream 2]
• [Service or workstream 3]

Provider will determine the methods, sequence, and personnel used to deliver these services, subject to the deliverables and timeline below.

4. DELIVERABLES

5. TIMELINE AND MILESTONES

Project start date: [Date] Project end date: [Date]

6. PRICING AND PAYMENT

Total SOW value: [Amount and currency] Pricing structure: [Fixed fee / milestone-based / time and materials with a not-to-exceed cap of [Amount]] Payment terms: [Net 30 from invoice receipt] Invoicing: Provider will invoice upon [milestone acceptance / monthly / project completion].

Expenses: [Pre-approved expenses reimbursed at cost, supported by receipts / No expenses reimbursed unless approved in writing in advance.]

Total charges under this SOW will not exceed [Amount] without an executed change order.

7. ACCEPTANCE CRITERIA

Each deliverable will be considered accepted when it meets the following criteria:

• [Objective criterion 1, for example: meets the specifications in Section 4]
• [Objective criterion 2, for example: passes agreed QA standards]
• [Objective criterion 3]

Client will review each deliverable within [5] business days of submission and provide written acceptance or a written list of specific deficiencies. If Client does not respond within [5] business days, the deliverable is deemed accepted.

Revisions: This SOW includes [2] rounds of revision per deliverable. Additional revisions require a change order.

8. OUT OF SCOPE

The following are expressly excluded from this SOW:

• [Excluded item 1]
• [Excluded item 2]
• [Excluded item 3]
• Any work not specifically described in Section 3

9. CLIENT RESPONSIBILITIES AND DEPENDENCIES

Client will provide:

• [Access, assets, approvals, or information the Provider needs]
• [Named decision-maker available for review cycles]

Delays caused by Client's failure to meet these dependencies may shift the timeline and, if material, require a change order.

10. CHANGE CONTROL

Any change to scope, deliverables, timeline, or pricing must be documented in a written change order signed by both parties before the affected work begins. No verbal instruction or email exchange modifies this SOW.

11. TERM AND TERMINATION

This SOW begins on the Effective Date and continues until all deliverables are accepted or the SOW is terminated.

Either party may terminate this SOW with [30] days' written notice. On termination, Client will pay for all work completed and accepted through the termination date, plus any non-cancellable committed costs.

12. GOVERNING TERMS

This SOW is governed by the Master Services Agreement referenced above. Where this SOW conflicts with the MSA, [the MSA / this SOW] controls.

SIGNATURES

Client: _________________ Name: _______ Title: _______ Date: _______ 

Provider: _________________ Name: _______ Title: _______ Date: _______

How to Fill In Each Section

The template is the easy part, but it’s the details you fill in that really matter.

• Scope of work. Describe what's being done specifically enough that two people read it identically. The sentence about the provider determining methods and personnel matter: it's part of what distinguishes a genuine services engagement from staff augmentation, which carries both cost and classification consequences.
• Deliverables. Name the artifact, the format, and the date. Make it unambiguous.
• Acceptance criteria. The deemed-acceptance clause (if the client doesn't respond in five days, it's accepted) protects providers from projects that stall in review limbo. The revision count protects both sides from unlimited rework.
• Pricing. Include the not-to-exceed language even on fixed-fee work. It's the sentence you point at when an invoice arrives above the agreed value.
• Out of scope. This costs five minutes to write and prevents more arguments than every other section combined. If you know what the provider might reasonably assume is included, and it isn't, name it here.
• Client responsibilities. Most missed deadlines trace back to the client instead of the provider: delayed feedback, missing access, an approver on vacation. Writing dependencies down means a slipped timeline is a shared fact rather than a negotiation.
• Change control. Scope creep almost never arrives as a formal request. It arrives as small favors and requests. The clause requiring changes in writing before work begins is what converts that into a justified transaction.

What Each Section Protects

The table below covers what each section does (and who it helps):

Core Engagement Terms

Parties, dates, rates, deliverables, budget. This is the substance an auditor or a classification test examines. The sentence in Section 3 about the provider determining methods, sequence, and personnel is part of what separates a genuine services engagement from staff augmentation. Vague scope is the first thing picked apart in a misclassification dispute, since the tests look at how the relationship works rather than what the contract calls the person.

Documented Acceptance

Section 7's deemed-acceptance clause covers if the client doesn't respond within five business days, the deliverable is accepted, which protects providers from projects that stall in review and gives both sides a record of when work was approved.

A Worker Classification Check 

This one isn't in the template because it can't be. It has to happen before signing. The engagement should run through a questionnaire appropriate to the worker’s jurisdiction, whether a standard ABC assessment in the U.S. or, for UK engagements, an IR35 review based on HMRC's CEST methodology. 

The output is a recommendation rather than a verdict, and the final classification decision rests with your organization. Skipping it doesn't remove the decision. It just means making it with no documented, jurisdiction-specific input behind it.

Adapting the Template by Engagement Type

One template doesn't fit every engagement. Adjust these sections:

• Fixed-fee project. Use the template as written. Milestone payments tied to acceptance.
• Time and materials. Replace fixed pricing with hourly or daily rates plus a hard not-to-exceed cap. Add timesheet submission and approval requirements. Keep deliverables defined anyway, since a T&M engagement with no defined outcome is difficult to manage and starts to resemble staff augmentation.
• Retainer. Replace milestones with a recurring scope and billing cycle. Define what happens to unused hours or capacity at period end (because that ambiguity causes friction every single time).
• International contractor. Add jurisdiction-specific terms. A US template doesn't hold up unmodified in Germany, Brazil, or the UK. Local labor law affects enforceability, and the wrong contract structure can undermine contractor classification.

Where Templates Generally Stop Working

Templates have limitations, and that’s the reason this page exists rather than just a download button.

A template standardizes language. It doesn't do anything after signature, though. The SOW you carefully wrote a $40,000 cap into becomes a PDF in a folder, and three months later an invoice for $52,000 gets approved because the person in AP has no visibility into what the contract said. The expiry date passes and the contractor keeps working because nobody was tracking it.

None of this is a template problem. It's an enforcement problem, and enforcement lives in the system (not the document).

How Worksuite Handles SOW Contracts

The template above ends its useful life the moment it's signed. It becomes a PDF, the PDF goes in a folder or an inbox, and from that point on it's a record of something rather than a control on anything.

Worksuite Contract Templates work differently. 

Legal builds and approves a template once, with pre-configured clauses, custom fields, signing order, and governing law. Every SOW issued from it inherits that approved language automatically and populates from engagement data your team already entered. That means no copy-paste from a Word doc or someone grabbing a version edited two years ago and forwarded around.

Once signed, the contract becomes a live operational object wired into the rest of your program:

• Talent Profiles. The SOW sits on the contractor's record next to their classification decision, onboarding documents, and insurance status. One place to answer who this person is and what you agreed to.
• Work History. Milestones, tasks, and timesheets tie back to the contract terms, so what's being delivered is measured against what was scoped.
• Invoices. Approval is gated on contract status. Unsigned contract, no approved invoice. And when an invoice would exceed the remaining SOW budget, it's blocked before it reaches AP.
• Payments. Payment runs draw from the same record, so the money going out matches the contract that authorized it.

Every stage, amendment, and approval is logged with a timestamp and an owner. That's what matters when a classification question surfaces two years later or an auditor asks you to prove what was agreed and when. A defensible audit trail becomes a byproduct of running the program in one system, rather than a reconstruction project you take on after someone asks.

Expiry triggers a renewal workflow. Native redlining keeps negotiation in a single thread rather than a chain of attachments.

Legal approves the template once. Operations issues from it at scale.

Book a live demo to see how Worksuite manages SOW contracts from template to final payment.

Want a DOCX version of the Statement of Work Template? Download it here.