Statement Of Work Template

Free Word download β€’ Edit online β€’ Save & share with Drive β€’ Export to PDF

3 pagesβ€’20–30 min to fillβ€’Difficulty: Standardβ€’Signature requiredβ€’Legal review recommended
Learn more ↓
FreeStatement Of Work Template

At a glance

What it is
A Statement of Work (SOW) is a legally binding exhibit to a master services agreement that defines exactly what a service provider will deliver on a specific engagement β€” scope, deliverables, milestones, acceptance criteria, fees, expense policy, dependencies, and assumptions. This free Word download gives you a structured, professional-services-ready starting point you can edit online and export as PDF for client signature.
When you need it
Use it whenever you begin a new client engagement under a master services agreement, or as a standalone contract when no MSA exists. It is the governing document for any project where scope creep, payment disputes, or acceptance disagreements could arise.
What's inside
Project background and objectives, detailed scope of work, out-of-scope exclusions, deliverables list with acceptance criteria, milestone schedule with payment triggers, fee structure, expense reimbursement policy, client dependencies and assumptions, change-order process, and authorized signatures from both parties.

What is a Statement of Work?

A Statement of Work (SOW) is a legally binding project-level contract that defines exactly what a service provider will deliver on a specific engagement β€” scope, deliverables, acceptance criteria, milestone schedule, fees, expense policy, client dependencies, and assumptions. It functions either as an exhibit to a master services agreement or as a standalone contract, and it is the document courts, arbitrators, and clients reach for first when a scope or payment dispute arises. Unlike a high-level service agreement, an SOW is designed to be operationally precise: every deliverable has acceptance criteria, every milestone has a due date, and every out-of-scope exclusion is named explicitly.

Why You Need This Document

Without a signed SOW, every professional-services engagement defaults to a contest of memories: what the client thought was included, what the provider thought was priced, and who said what on which call. The consequences are concrete β€” unpaid invoices for work that falls outside a vague scope description, client rejections of deliverables that lack objective acceptance criteria, and schedule disputes with no basis for charging for the delay. Scope creep alone costs professional-services firms an estimated 20–30% of project revenue annually when there is no formal change-order mechanism in place. A properly structured SOW β€” with explicit exclusions, milestone-linked payments, and a mandatory written change-order process β€” closes all of these gaps before the first line of work begins. This template gives you a court-ready starting point in under an hour, for any engagement from a $5,000 freelance project to a six-figure consulting retainer.

Which variant fits your situation?

If your situation is…Use this template
Time-and-materials engagement with variable monthly billingTime and Materials SOW
Fixed-fee project with defined deliverables and a completion dateFixed-Price Statement of Work
Ongoing retainer with a monthly hour bank and defined service scopeRetainer Services Agreement
Software development project with sprint-based milestonesSoftware Development SOW
Consulting engagement governed by an existing master services agreementMaster Services Agreement + SOW Exhibit
Construction or trade work requiring a detailed scope and payment scheduleConstruction Contract
Marketing or creative services with campaign-level deliverablesMarketing Services Agreement

Common mistakes to avoid

❌ Omitting an out-of-scope exclusions list

Why it matters: Without explicit exclusions, any task adjacent to the stated scope can be argued to be included β€” the most common driver of unpaid scope creep in professional services.

Fix: Add a dedicated exclusions clause listing the five to ten tasks most likely to be requested but not priced. Update it with each new engagement type.

❌ No acceptance criteria on deliverables

Why it matters: When a client rejects a deliverable without objective criteria, the dispute becomes subjective β€” 'it's not what we envisioned' β€” and the provider has no contractual standard to point to.

Fix: Write acceptance criteria specific enough that a neutral third party could determine whether the deliverable meets them. Include format, content requirements, and a review deadline with deemed-acceptance language.

❌ Tying all payment to final acceptance

Why it matters: A single end-of-project payment gives the client maximum leverage to withhold or delay payment over minor or fabricated deficiencies, leaving the provider cash-flow exposed for the entire engagement.

Fix: Structure at least three payment milestones with a non-refundable upfront deposit covering 25–30% of the total fee.

❌ Starting work before both parties sign

Why it matters: Work performed before execution creates an implied contract governed by jurisdiction-specific defaults β€” not your negotiated scope, fees, or IP terms. In a dispute, the SOW may be unenforceable.

Fix: Treat execution as a hard gate: no kick-off call, no access granted, no work started until both authorized representatives have signed and you have a copy.

❌ Client dependencies stated as best efforts rather than firm dates

Why it matters: When the client is late providing access, data, or approvals, a 'best efforts' obligation gives you no contractual basis to extend the timeline or issue a change order for the resulting rework.

Fix: List every client dependency with a specific due date and include a clause stating that each day of delay extends the corresponding milestone by one calendar day.

❌ No named authorized representative for deliverable acceptance

Why it matters: If anyone on the client's team can informally approve or reject deliverables, a later stakeholder can override an earlier approval β€” restarting acceptance cycles and delaying final payment.

Fix: Name a single client representative with explicit authority to accept deliverables and sign change orders. State that approvals from other individuals are not binding.

The 10 key clauses, explained

Project background and objectives

In plain language: Provides context for why the engagement exists, what business problem it solves, and the measurable outcomes both parties expect at completion.

Sample language
[CLIENT NAME] seeks to [BUSINESS OBJECTIVE]. [PROVIDER NAME] will deliver [HIGH-LEVEL DESCRIPTION OF ENGAGEMENT] to achieve [MEASURABLE OUTCOME] by [TARGET DATE].

Common mistake: Writing objectives so vaguely that success is unmeasurable β€” phrases like 'improve performance' or 'enhance the platform' give the client grounds to reject deliverables that are objectively complete.

Scope of work

In plain language: A precise, itemized description of every service and activity the provider will perform β€” the definitive boundary of what is included.

Sample language
Provider shall perform the following services: (a) [TASK 1]; (b) [TASK 2]; (c) [TASK 3]. All services will be performed remotely unless otherwise specified in this SOW.

Common mistake: Describing scope in general terms like 'build the website' without specifying page count, features, revision rounds, and integrations β€” leaving every disputed item open to interpretation.

Out-of-scope exclusions

In plain language: An explicit list of work that is NOT included in this SOW, preventing the client from treating common adjacent tasks as covered.

Sample language
The following are expressly excluded from this SOW and will require a separate Change Order if requested: (a) [EXCLUSION 1]; (b) [EXCLUSION 2]; (c) [EXCLUSION 3].

Common mistake: Omitting an exclusions clause entirely. Without it, any task not explicitly listed can be argued to fall within 'related services' β€” the most common trigger for unpaid scope creep.

Deliverables and acceptance criteria

In plain language: Lists each deliverable with a description, the format in which it will be submitted, and the specific, objective criteria the client must use to accept or reject it.

Sample language
Deliverable 1: [DELIVERABLE NAME]. Format: [FORMAT]. Acceptance Criteria: [SPECIFIC, MEASURABLE CONDITIONS]. Client shall accept or provide written rejection with specific deficiencies within [X] business days of delivery.

Common mistake: Stating only deliverable names without acceptance criteria. When the client says 'this isn't what we wanted,' there is no objective standard to resolve the dispute.

Project schedule and milestones

In plain language: Defines the start date, key milestones with due dates, and the final completion date β€” and states that the schedule is contingent on the client meeting its dependencies on time.

Sample language
Project Start Date: [DATE]. Milestone 1: [DESCRIPTION] β€” due [DATE]. Milestone 2: [DESCRIPTION] β€” due [DATE]. Final Completion: [DATE], contingent on Client providing [DEPENDENCY] no later than [DATE].

Common mistake: Publishing a fixed timeline without linking it to client dependency deadlines. When the client is late on an approval, the provider is still held to the original completion date.

Fees and payment schedule

In plain language: States the total project fee (or T&M rates), the invoicing schedule, payment terms, and what triggers each payment β€” typically milestone completion or calendar date.

Sample language
Total Fixed Fee: $[AMOUNT]. Payment Schedule: (a) $[AMOUNT] upon execution; (b) $[AMOUNT] upon acceptance of Milestone 1; (c) $[AMOUNT] upon final acceptance. Payment terms: Net [15/30] from invoice date.

Common mistake: Tying all payment to final acceptance with no milestone invoices. A single payment at completion leaves the provider carrying the full project cost and creates leverage for the client to withhold payment over minor issues.

Expense reimbursement policy

In plain language: Defines which out-of-pocket expenses are reimbursable, the pre-approval threshold, the documentation required, and the invoicing cadence for expenses.

Sample language
Client shall reimburse Provider for pre-approved out-of-pocket expenses including [TRAVEL / SOFTWARE / THIRD-PARTY FEES]. Expenses exceeding $[AMOUNT] per item require prior written approval. Receipts must accompany each expense invoice.

Common mistake: No expense clause at all, or a blanket 'all expenses reimbursable' without a pre-approval threshold β€” either leaves the client surprised by a large expense invoice or the provider absorbing project costs.

Client dependencies and assumptions

In plain language: Lists the specific assets, access, approvals, and decisions the client must provide by defined dates, and states that delays in client obligations extend the project timeline and may trigger a change order.

Sample language
Client shall provide the following no later than [DATE]: (a) [DEPENDENCY 1]; (b) [DEPENDENCY 2]. Provider's timeline and fees are based on the assumption that [ASSUMPTION]. If any assumption proves incorrect, Provider may issue a Change Order.

Common mistake: Framing client obligations as 'best efforts' rather than firm deadlines. Vague language makes it nearly impossible to enforce a schedule extension when the client is the source of the delay.

Change-order process

In plain language: Defines the formal mechanism for requesting, pricing, and approving changes to scope, timeline, or fees β€” establishing that no change is effective until both parties sign a written change order.

Sample language
Either party may request a change to this SOW by submitting a written Change Order Request. Provider will respond with a price and timeline impact within [X] business days. No change is effective until both parties execute a written Change Order.

Common mistake: Allowing verbal approvals or email threads to constitute change-order authorization. Verbal scope additions are routinely disputed at invoicing, leaving the provider with completed work and no payment.

Authorized representatives and signatures

In plain language: Identifies the named individuals authorized to act on behalf of each party for SOW purposes β€” approving deliverables, signing change orders, and binding the party contractually.

Sample language
Client Representative: [NAME], [TITLE] β€” authorized to approve deliverables and execute Change Orders on behalf of Client. Provider Representative: [NAME], [TITLE]. Signatures below constitute binding acceptance of this SOW.

Common mistake: Not naming a specific authorized representative, or naming someone who lacks actual authority to bind the company. Deliverable approvals from unauthorized employees create ambiguity about whether acceptance has legally occurred.

How to fill it out

  1. 1

    Reference the governing MSA or standalone status

    In the header, state whether this SOW operates as an exhibit to an existing master services agreement (cite its effective date) or stands alone as the full contract. Confirm which party's standard terms govern conflicts between documents.

    πŸ’‘ If no MSA exists, add a brief general terms section covering IP ownership, limitation of liability, and governing law β€” or incorporate them by reference to a standalone addendum.

  2. 2

    Write specific, measurable project objectives

    Describe the business problem being solved and the concrete outcome both parties expect. Avoid adjectives like 'improved' or 'enhanced' β€” use metrics: reduce onboarding time from 14 days to 7 days, migrate 500 user accounts, deliver a 40-page strategy report.

    πŸ’‘ Objectives that can be checked off as achieved or not achieved protect you in acceptance disputes far better than aspirational language.

  3. 3

    Define scope with an explicit exclusions list

    List every task included in the engagement with enough specificity that a third party could determine whether a given activity is in or out. Then add a separate exclusions section naming the most common adjacent tasks that are NOT included.

    πŸ’‘ Write the exclusions list by asking: 'What will this client almost certainly ask for that I haven't priced?' List those first.

  4. 4

    Build the deliverables table with acceptance criteria

    For each deliverable, specify its name, description, format, submission method, and the objective criteria the client must apply when accepting or rejecting it. Set a response window β€” typically 5–10 business days β€” and state that silence constitutes acceptance.

    πŸ’‘ Deemed acceptance language ('if Client does not respond within [X] business days, the deliverable is deemed accepted') is enforceable in most jurisdictions and prevents indefinite review cycles.

  5. 5

    Set the milestone schedule linked to client dependencies

    Enter each milestone date and tie it explicitly to the client delivering its dependencies on time. Include a clause stating that each day of client delay extends the corresponding milestone by one day.

    πŸ’‘ Send a written reminder to the client 5 business days before each dependency is due. This creates a paper trail if a schedule dispute arises.

  6. 6

    Structure fees with milestone-based payment triggers

    Divide the total fee into at least three installments: an upfront deposit (20–30%), one or more milestone payments, and a final payment on acceptance. For T&M, set monthly billing with a not-to-exceed cap if the client requires budget certainty.

    πŸ’‘ A 25–30% upfront deposit covers your cost of mobilization and signals client commitment β€” make it non-refundable in the event of client-initiated termination.

  7. 7

    Define the change-order process explicitly

    Include a change-order section stating that all scope, timeline, or fee changes require a written change order signed by both authorized representatives before work begins. Specify your response time for pricing a change request.

    πŸ’‘ Number change orders sequentially (CO-001, CO-002) and attach them to the SOW as exhibits β€” this keeps the contract document clean and traceable.

  8. 8

    Obtain signatures before work begins

    Both authorized representatives must sign before any work commences. Identify the signatory by name and title, and confirm they have actual authority to bind their organization. Use eSign to timestamp execution.

    πŸ’‘ Never begin work based on a verbal go-ahead or a 'we'll sign it shortly' email. Starting without an executed SOW voids your ability to enforce the scope and payment terms.

Frequently asked questions

What is a statement of work?

A statement of work (SOW) is a contract document that defines the specific services, deliverables, milestones, fees, and responsibilities for a single project or engagement between a service provider and a client. It operates either as a standalone agreement or as an exhibit to a master services agreement. The SOW is the primary document used to determine what was promised, what was delivered, and who owes what β€” making it the central document in any scope or payment dispute.

What is the difference between a statement of work and a master services agreement?

A master services agreement (MSA) establishes the overarching legal terms that govern all projects between two parties β€” IP ownership, confidentiality, indemnification, limitation of liability, and dispute resolution. A statement of work is a project-specific exhibit that operates under the MSA and defines only the commercial and delivery terms for one engagement. The MSA is signed once; a new SOW is issued for each project. If no MSA exists, the SOW must include or incorporate general legal terms to be complete.

What should a statement of work include?

A complete SOW should cover: project background and objectives, a detailed scope of work, explicit out-of-scope exclusions, a deliverables list with acceptance criteria, a milestone schedule linked to client dependencies, the fee structure and payment schedule, expense reimbursement policy, client obligations and assumptions, a change-order process, and authorized signatures. Missing any of these β€” especially acceptance criteria and exclusions β€” creates predictable disputes.

What is the difference between a fixed-price and a time-and-materials SOW?

A fixed-price SOW commits the provider to delivering the full scope for a single lump-sum fee, regardless of actual hours incurred β€” the provider bears the risk of underestimating effort. A time-and-materials SOW bills the client for actual hours at agreed rates plus expenses β€” the client bears cost risk. Fixed-price suits well-defined, stable scopes; T&M suits exploratory or frequently changing work. Many SOWs combine both: fixed price for defined phases, T&M for discovery or change requests.

Is a statement of work legally binding?

Yes, a properly executed statement of work is generally enforceable as a contract when it contains an offer, acceptance, and consideration β€” typically the provider's services in exchange for the client's fees. Signed by authorized representatives of both parties, it creates enforceable obligations on scope, payment, and timeline. Courts in the US, Canada, UK, and EU have consistently upheld SOW terms in professional-services disputes when the document is sufficiently specific.

How do I handle scope creep in a statement of work?

The SOW itself is the primary defense: a detailed scope clause, an explicit exclusions list, and a mandatory written change-order process prevent most scope creep before it starts. When a client requests work outside the SOW, respond in writing β€” email is sufficient β€” confirming it is out of scope and that you will issue a change order before proceeding. Never perform out-of-scope work informally with the expectation of billing later; most clients dispute those invoices successfully.

Can a statement of work be used without a master services agreement?

Yes, but you must add general legal terms directly to the SOW or in a standalone addendum. At minimum, a standalone SOW should cover IP ownership, confidentiality, limitation of liability, termination rights, and governing law. Without these terms, disputes default to jurisdiction-specific statutory rules, which are often less favorable to service providers. For recurring client relationships, establishing an MSA and issuing lightweight SOWs under it is generally more efficient.

What are deemed-acceptance provisions and why do they matter?

A deemed-acceptance provision states that if the client does not formally accept or reject a deliverable within a specified review period β€” typically 5 to 10 business days β€” the deliverable is automatically considered accepted. Without this language, a client can hold a deliverable in review indefinitely, blocking payment and extending the project timeline at no cost to them. Deemed acceptance is enforceable in most common-law and civil-law jurisdictions when the review period is reasonable and the client had actual notice.

Do I need a lawyer to draft a statement of work?

For straightforward domestic professional-services engagements, a well-structured template is typically sufficient. Engaging a lawyer is advisable when the total contract value exceeds $100K, the engagement involves regulated data or sensitive IP, the client insists on substantive revisions to standard terms, or the work spans multiple jurisdictions. A 1–2 hour template review by an experienced commercial lawyer typically costs $300–$600 and can prevent disputes worth multiples of that amount.

How this compares to alternatives

vs Master Services Agreement

An MSA establishes the permanent legal framework β€” IP, liability, confidentiality, dispute resolution β€” that governs all work between two parties. A SOW is a project-specific exhibit that operates under the MSA and defines only the commercial terms for one engagement. You need both: the MSA once, a new SOW for every project. A SOW alone without an MSA leaves significant legal gaps around IP and liability.

vs Independent Contractor Agreement

An independent contractor agreement establishes the general relationship between a business and a self-employed individual β€” classification, IP assignment, confidentiality, and general payment terms. A SOW defines the specific scope and deliverables for one project under that relationship. Contractors with repeat clients often use both: the ICA governs the relationship, the SOW governs each engagement.

vs Service Agreement

A service agreement is a standalone contract covering both the legal terms and the description of services for an ongoing or recurring engagement. A SOW is narrower and more precise β€” it is a project-level document designed to sit under an MSA, not replace it. Service agreements suit simpler or ongoing relationships; SOWs suit complex, milestone-driven projects where scope precision is critical.

vs Consulting Agreement

A consulting agreement defines the terms of an advisory relationship β€” engagement structure, fees, confidentiality, and IP β€” but typically describes services at a high level. A SOW provides the operational specificity that a consulting agreement lacks: itemized deliverables, acceptance criteria, milestone schedules, and a change-order mechanism. Complex consulting engagements often use both, with the consulting agreement as the MSA equivalent.

Industry-specific considerations

IT and software services

Sprint-based milestone structure, UAT acceptance criteria tied to specific test cases, API and infrastructure dependencies, and licensing cost pass-throughs.

Management consulting

Hypothesis-driven deliverables with defined formats (slide decks, financial models, reports), interview access dependencies, and workshop facilitation sessions as billable milestones.

Creative and marketing agencies

Revision rounds capped in the deliverables clause, brand asset access dependencies, platform credential requirements, and campaign-performance metrics as acceptance criteria.

Construction and engineering

Phase-based milestones tied to inspections and permits, retainage provisions, material cost pass-throughs with markup caps, and site-access dependency clauses.

Jurisdictional notes

United States

SOWs are generally governed by state contract law; choice-of-law clauses are broadly enforceable. IP ownership defaults vary β€” without a written assignment clause, work-for-hire doctrine applies only to employees and certain enumerated categories under the Copyright Act, meaning contractor-created deliverables may default to the contractor. California's strong-arm contractor protections limit non-compete clauses that restrict post-engagement work.

Canada

Canadian courts apply common-law contract principles in all provinces except Quebec, which applies civil-law rules under the Civil Code. Without explicit IP assignment language, a contractor may retain copyright in deliverables even when created for a paying client β€” a frequent surprise for Canadian businesses engaging freelancers. Quebec SOWs should be available in French when the client is a provincially regulated entity.

United Kingdom

Under the Copyright, Designs and Patents Act 1988, copyright in works created by independent contractors vests in the contractor, not the commissioning client, unless explicitly assigned in writing. IR35 off-payroll working rules may reclassify a contractor providing services through a personal service company as a deemed employee β€” the SOW's description of the engagement and working practices is material to that assessment.

European Union

IP ownership rules vary by member state, but most default copyright to the creator β€” explicit written assignment in the SOW is essential. Where the engagement involves processing personal data on behalf of the client, GDPR Article 28 requires a data processing agreement; the SOW should reference or incorporate one. Several EU member states impose mandatory written contract requirements for service engagements above certain thresholds.

Template vs lawyer β€” what fits your deal?

PathBest forCostTime
Use the templateFreelancers, small agencies, and consultants on domestic engagements under $50KFree30–60 minutes per SOW
Template + legal reviewEngagements over $50K, regulated industries, or clients who mark up standard terms$300–$6001–3 days
Custom draftedEnterprise professional-services contracts over $250K, multi-jurisdiction work, or sensitive IP development$1,500–$5,000+1–3 weeks

Glossary

Statement of Work (SOW)
A contract document that defines the specific services, deliverables, timeline, and fees for a single engagement between a client and a service provider.
Master Services Agreement (MSA)
An umbrella contract establishing the general legal terms β€” IP ownership, liability caps, warranties, dispute resolution β€” that govern all SOWs issued under it.
Deliverable
A specific, tangible output the service provider must produce and hand over to the client as defined in the SOW β€” a report, codebase, design file, or trained model.
Acceptance Criteria
The measurable conditions a deliverable must meet before the client is contractually obligated to approve and pay for it.
Milestone
A defined checkpoint in the project schedule, often tied to a payment trigger, at which a set of deliverables must be completed and accepted.
Scope Creep
The gradual expansion of project scope beyond what the SOW defines, typically driven by client requests that were not priced into the original agreement.
Change Order
A written amendment to an SOW that documents and prices a change to the scope, timeline, or fees β€” the formal mechanism for managing scope creep.
Time and Materials (T&M)
A billing model in which the client pays for actual hours worked at agreed hourly rates plus reimbursable expenses, rather than a fixed project price.
Fixed Price
A billing model in which the service provider agrees to deliver the full SOW scope for a single lump-sum fee, regardless of actual hours incurred.
Client Dependencies
Assets, approvals, access, or decisions the client must provide on time for the service provider to meet the SOW schedule β€” the client's contractual obligations.
Assumptions
Conditions the service provider has treated as true when scoping and pricing the engagement; if an assumption proves false, the provider typically has the right to issue a change order.
Retainage
A percentage of the total fee withheld until final acceptance of all deliverables, used to ensure the provider completes the engagement before receiving full payment.

Part of your Business Operating System

This document is one of 3,000+ business & legal templates included in Business in a Box.

  • Fill-in-the-blanks β€” ready in minutes
  • 100% customizable Word document
  • Compatible with all office suites
  • Export to PDF and share electronically

Create your document in 3 simple steps.

From template to signed document β€” all inside one Business Operating System.
1
Download or open template

Access over 3,000+ business and legal templates for any business task, project or initiative.

2
Edit and fill in the blanks with AI

Customize your ready-made business document template and save it in the cloud.

3
Save, Share, Send, Sign

Share your files and folders with your team. Create a space of seamless collaboration.

Save time, save money, and create top-quality documents.

β˜…β˜…β˜…β˜…β˜…

"Fantastic value! I'm not sure how I'd do without it. It's worth its weight in gold and paid back for itself many times."

Managing Director Β· Mall Farm
Robert Whalley
Managing Director, Mall Farm Proprietary Limited
β˜…β˜…β˜…β˜…β˜…

"I have been using Business in a Box for years. It has been the most useful source of templates I have encountered. I recommend it to anyone."

Business Owner Β· 4+ years
Dr Michael John Freestone
Business Owner
β˜…β˜…β˜…β˜…β˜…

"It has been a life saver so many times I have lost count. Business in a Box has saved me so much time and as you know, time is money."

Owner Β· Upstate Web
David G. Moore Jr.
Owner, Upstate Web

Run your business with a system β€” not scattered tools

Stop downloading documents. Start operating with clarity. Business in a Box gives you the Business Operating System used by over 250,000 companies worldwide to structure, run, and grow their business.

Free Forever PlanΒ Β·Β No credit card required