A statement of work (SOW) is the project-specific document that sits alongside a consulting agreement and spells out exactly what will be delivered, by when, for how much, and how the client will accept it. To write one, define the requirements and what is out of scope, list the deliverables, set the price and payment schedule, describe the acceptance procedure, and explain how changes will be handled. A clear SOW helps keep a consulting project from turning into a dispute.
Many consultants and the companies that hire them spend time negotiating the consulting agreement and then treat the SOW as an afterthought. Yet the SOW is where many misunderstandings start: a feature the client assumed was included, a deadline that slipped, or a fixed fee that grew into open-ended work.
Consulting Agreement vs. Statement of Work
Before a project starts, you typically want two documents in place:
- The consulting agreement (sometimes called a master services agreement or independent contractor agreement) sets the legal framework: confidentiality, ownership of intellectual property, warranties, limitation of liability, indemnification, independent contractor status, termination and dispute resolution.
- The statement of work describes a specific project under that framework: the scope, deliverables, timeline, fees and acceptance criteria.
Clients often prefer to use their own form of consulting agreement so their vendor contracts stay consistent. That can be fine, but either side should have the agreement reviewed before signing, and should read it carefully themselves. Our post on contract review explains what to look for. Also make sure the two documents fit together: the agreement should say which document controls if the SOW conflicts with it.
Why the SOW Matters
You cannot meet expectations that were never defined. A well-drafted SOW gives both sides clarity on three things: what is being built or delivered, how and when the consultant gets paid, and when the work is considered done.
What to Include in a Statement of Work
Most SOWs should cover at least the following sections.
1. Project Description and Requirements
Start with a short description of the project and its purpose, then list the functional requirements. For a software project, that may include the technology stack, supported browsers and devices, performance expectations, and any restrictions on third-party or open-source components (for example, only libraries under permissive licenses).
2. Client Responsibilities and Resources
Many delays come from the client side. Spell out what the client will provide, such as design assets, data, access to code repositories, test environments and a decision-maker who can answer questions promptly. Tie the schedule to timely access so the consultant is not blamed for delays outside its control.
3. Out of Scope
An express out-of-scope section is one of the most useful parts of a SOW. For example, the SOW might state that any screen or workflow not shown in the attached mockups is out of scope and will be handled through a change order.
4. Deliverables
List each deliverable specifically: source code, documentation, reports, training sessions or configured systems. Specific deliverables also make the IP assignment in the consulting agreement easier to apply, because everyone knows what is being transferred.
5. Schedule and Milestones
Set milestones and target dates, along with any working expectations that matter to the client, such as regular status updates or code commits. Avoid language that dictates hours or methods more than necessary (see the classification discussion below).
6. Fees and Payment Terms
State whether the project is fixed-fee, time-and-materials, or a hybrid. Common structures include a deposit on signing with the balance on completion, or payments tied to accepted milestones. Include invoicing and payment timing, expense reimbursement, and the rate for additional work.
7. Acceptance Procedure
Define how deliverables are reviewed and accepted. A typical clause gives the client a set number of business days to test and either accept or reject in writing with specific reasons, and treats the deliverable as accepted if the client does not respond in time. Include how many rounds of fixes are covered.
8. Change Orders
Require changes to scope, schedule or price to be documented in a written change order signed by both parties before the extra work begins.
9. Post-Delivery Support
If the consultant will provide support or maintenance after delivery, say so and set the terms, such as a monthly retainer, response expectations, and how either side can end it on written notice. Clear terms prevent a client from expecting free fixes years after delivery.
A Simple Example
Suppose a startup hires a development firm to build a web marketplace. A workable SOW might say: the consultant will build a single-page web application and back end using an agreed technology stack; the client will provide brand assets and repository access within five business days; screens not shown in the attached mockups are out of scope; the fixed fee is paid half on signing and half on acceptance; change requests are billed at an agreed daily rate; deliverables are accepted unless the client rejects them in writing with reasons within a set number of business days; and post-launch email support is available on a monthly retainer terminable by either party on 30 days’ written notice.
Legal Points the SOW Should Not Undercut
- Intellectual property. Absent a written assignment, an independent contractor generally owns the copyright in work it creates. Make sure the consulting agreement assigns IP in the deliverables and that the consultant keeps rights to its pre-existing tools only as intended. Our intellectual property page covers this further.
- Worker classification. California generally applies the ABC test to decide whether a worker is an employee or an independent contractor, with certain exemptions, including some business-to-business relationships that meet specific requirements. A SOW focused on results and deliverables, rather than controlling how and when the work is done, is more consistent with contractor status, though the actual relationship controls. See our post on AB 5 and the gig economy.
- Freelance worker protections. California’s Freelance Worker Protection Act, effective in 2025, requires written contracts with certain freelance workers who provide professional services and sets payment-timing rules. Check whether it applies to your engagement.
- Order of precedence. State which document controls in a conflict, so a SOW cannot accidentally override negotiated liability limits or confidentiality terms.
The Takeaway
A good statement of work turns a general business relationship into a specific, measurable project. Define requirements and what is out of scope, list deliverables, tie payment to milestones or acceptance, describe acceptance and change orders, and address support after delivery. Pair it with a solid consulting agreement to reduce the risk of misunderstandings.
Frequently Asked Questions
What is the difference between a consulting agreement and a statement of work?
The consulting agreement sets the general legal terms of the relationship, such as confidentiality, IP ownership, liability limits and termination. The statement of work describes a specific project: scope, deliverables, schedule, price and acceptance. Many relationships use one master agreement and a new SOW for each project.
Who owns the work a consultant creates?
Under U.S. copyright law, a consultant who is an independent contractor generally owns the copyright in what they create unless a written agreement assigns it to the client or the work qualifies as a work made for hire. That is why the consulting agreement should contain a clear IP assignment, and the SOW should list exactly which deliverables are covered.
Should a statement of work include a change order process?
Yes. Scope changes are a frequent source of consulting disputes. A short clause requiring written change orders, with the effect on price and schedule spelled out before work starts, keeps both sides aligned and makes billing for extra work easier to support.
Can a statement of work affect whether a consultant is treated as an employee?
It can be relevant. In California, worker classification is usually decided under the ABC test, and a SOW that focuses on defined deliverables rather than controlling how, when and where the consultant works is more consistent with contractor status. The label in the contract is not decisive, so the actual working relationship matters.
How Sutter Law Can Help
Sutter Law advises companies and consultants on consulting agreements, statements of work and related contract negotiation. Contact us for a free consultation to discuss your project paperwork.
This article is general information, not legal advice. Reading it does not create an attorney-client relationship.
