But how does it differ from a contract, an MSA, or a scope of work? This guide explains what goes into a statement of work, how these documents fit together, and what to include to avoid misunderstandings and scope creep.
Key takeaways
- A statement of work (SOW) describes a project's deliverables, timelines, responsibilities, and payment terms. Once agreed and signed, it can form part of a legally binding contract.
- A clear out-of-scope list, measurable acceptance criteria, and a written change process help freelancers manage scope creep and avoid disputes.
Statement of work (SOW) explained
A statement of work (SOW) is a document that states the specifics of a project, such as what you’ll deliver, by when, how the client will check it, and ultimately how you’ll get paid.
Is it a contract? Sort of. A statement of work is legally binding once both parties sign it, but it usually works alongside a master service agreement (MSA) that covers the legal side.
The best way to differentiate the two is to remember that the MSA covers the relationship, and the SOW covers the work.
Statement of work (SOW)
- Covers: one project, in detail.
- Signed: once per project.
Master service agreement (MSA)
- Covers: the legal side of the relationship, such as confidentiality, liability, and intellectual property.
- Signed: once per client.
Scope of work
- Covers: the work itself, and nothing else.
- Remains inside the SOW.
Now, if the MSA already covers liability and intellectual property, should the SOW repeat those terms? Ideally, no. Keeping two versions of the same clause in sync is a chore, and sooner or later someone will edit one and forget the other. When these documents conflict, the MSA usually takes priority, but there’s no universal rule, so check the order-of-precedence clause before you sign.
It’s also good to know what a statement of work is not:
- A proposal you sent before the client said yes
- A “sounds great, go ahead” email
- A shared document that both parties edit and nobody signs
Without a clearly agreed SOW, it can be difficult to settle disagreements about what was originally included in the project.
Three types of SOW
SOWs come in three main types, and the main difference comes from the answer to the question “who decides how the work gets done?”
Design (or detail) SOW
With a design SOW, the client tells you exactly how to do the work, down to the specifics and processes, and judges the result based on that. They decide the method, but anything the specification doesn’t mention becomes a judgment call, which naturally leads to arguments.
Level of effort SOW
A level of effort SOW, also called “time and materials”, pays for the hours or days you put in, usually through an estimate or a limit. You decide most of the methods yourself. Just make sure the SOW says what happens when you reach the limit, because a limit with no plan behind it can leave both sides confused.
Performance-based SOW
With a performance-based SOW, you agree on the outcome and how it will be measured, and the method is up to you. It’s common in U.S. government contracts, where it’s the preferred method for acquiring services. Agencies writing a performance work statement are expected to “describe the work in terms of the required results” instead of methods or hours.
So which type should you pick? If the result is easy to define, describe outcomes, so you’re free to work your way, and the client has something concrete to check. If it's unclear, bill for time, since promising a fixed result on vague requirements can end up with you working weekends.
What goes into an SOW (with an example)
A freelance project needs about a dozen sections. Let's take the example of a data engineer in Barcelona building a sales dashboard for a retail chain over eight weeks.
The most important sections here are the scope, acceptance criteria and the change process. Think them through and don't rush them.
Scope: say what’s out, too
Good fences make good neighbors, and the scope section allows for the fence to go up.
Most people list what’s included and stop there. Why bother writing down what you won’t do? Because anything the SOW doesn’t mention is open to interpretation and people tend to read vague documents in whatever way suits them. Clients included. You included.
Getting back to our example of the data engineer in Barcelona, let’s say that the client asks for a mobile version and warehouse stock data, six weeks after the project has started. With a vague scope, that request turns into a week of polite, tense emails. With one line in the SOW, it takes 30 seconds:
“A mobile app and warehouse inventory data are out of scope and can be quoted separately.”
The client can still have both. They simply become new work, with their own price and deadlines. Nobody feels cheated, and you have a natural reason to send a second quote.
Acceptance criteria: agree on what “done” means
Who decides when a deliverable is finished? If the SOW doesn’t state it specifically, the answer is whoever holds the money. But an unhappy client can ask for one more round of revisions, then another, moving the goalposts each time.
The way out is to define “done” as something you can test. “The dashboard should be fast” boils down to an opinion. “The dashboard loads in under three seconds with 12 months of data” is a yes-or-no check that anyone can run.
Then add a sign-off step: who approves each deliverable, and how long they have to review it. Many SOWs also include a deemed-acceptance clause, where a deliverable counts as accepted if the client raises no issues within a set period, say ten business days. It can feel a bit pushy to write it. Without it, though, finished work can wait in someone’s inbox for a month, and so can your invoice.
Change process: agree on extras before starting
Even with a clear scope, clients will sometimes ask for more. A new feature here, an extra report there. Each request might sound small, but a few of them can quickly eat into your time and budget.
That's why your SOW needs a change process. Say the retail client wants warehouse inventory added to the dashboard halfway through the project. Instead of squeezing it into the original agreement, you send a new quote explaining the extra cost and how it affects the deadline.
The rule is simple: put changes in writing, agree on the price and timeline, and get approval before starting. You can still say yes to extra work, just not at your own expense.
How to write a statement of work, step by step
You can get a skeleton from any template. The actual usefulness comes from the conversations around it.
- Talk to stakeholders early. Find out who will use the result, who approves it and who pays the invoice. Sometimes, those are three different people, and they’re not always on the same page.
- Agree on objectives before tasks. What should be different when the project is done? Every deliverable should trace back to that answer, and anything that doesn’t is a candidate for the out-of-scope list.
- Break the work down. Use a work breakdown structure on bigger projects: split each deliverable into specific tasks until each one has an owner and a rough duration. An unrealistic timeline is far easier to catch on paper than once you’re elbow-deep in the work.
- Write for someone who wasn’t in the room. Skip jargon and phrases like “as discussed.” A new project manager, a finance team or, if things go badly, a lawyer might read it months from now.
- Review, version and sign. Walk the client through the draft, keep version control simple (v1, v2, final) and wait for formal sign-off from both parties before work begins. Don't start early “just to get ahead” because that work might go unpaid.
How Hightekers can help
With a solid SOW, the work itself is settled. The admin around it still lands on someone, and for self-employed freelancers, that someone is you.
Hightekers works with freelancers in France, Belgium, the Netherlands, Spain, Switzerland and the UAE. Members find their own projects and agree on the work with their clients directly. Depending on the country, Hightekers provides a direct employment contract and handles client contracts, invoicing, payroll and compliance. Freelancers can also benefit from a regular monthly salary, late-payment protection and employee benefits, subject to local rules and eligibility.
Want to see what that could look like for your next project? Request a personalized simulation to estimate your take-home pay based on your day rate and circumstances.
Frequently Asked Questions
Is a statement of work legally binding?
Yes, once both parties sign it. It usually works alongside a broader agreement, such as a master service agreement, and together they form the contract.
Who writes the statement of work?
Either side can. Freelancers often write the first draft and send it to the client for review. What matters is that both sides agree on what's included before the work begins.
What’s the difference between an SOW and an RFP?
An RFP (request for proposal) is how a client invites bids for a project. An SOW sets out the actual work. Clients sometimes attach a draft SOW to an RFP so freelancers know exactly what they're pricing.
