Contract vs SOW: When You Need Both
A contract sets the terms of your relationship. A SOW defines the work. Most freelancers confuse them — here's the difference.
You signed a contract. Six weeks in, the client is asking for things that weren't discussed at kickoff. When you point to the contract, there's nothing there about what the project actually was. The contract describes how you work together. It says nothing about what you're building.
A contract and a Statement of Work are not the same document. Many freelancers treat them as interchangeable. That's where most scope disputes start.
What a contract covers
A contract (often called a Master Services Agreement, or MSAA standing contract covering the rules of your working relationship — liability, IP ownership, and how disputes get resolved. Signed once, applies to every project with that client.) governs the relationship, not the work. It stays fixed across every project you do with a client. It covers liabilityLegal responsibility if something goes wrong. A contract's liability clause limits how much you can be held accountable for. Without one, exposure is uncapped., IPOwnership rights to creative work. The key question: who can use, sell, or modify the deliverables? Standard freelance practice: IP transfers to the client on final payment. ownership, confidentialityA mutual agreement to keep certain information private. Covers client plans, proprietary processes, and unreleased work. Often formalized as an NDA., dispute resolution, and how either party ends the relationship.
According to SpotDraft's comparison of MSAs and SOWs, an MSA is designed to be signed once and referenced many times. You write it once, get it signed, and attach project-specific SOWs to it as you go.
What an SOWA per-project document that defines what you're building, when it's due, and what it costs. It's what you point to when a client asks for more than you agreed. covers
A Statement of Work (an engagement agreement) defines a specific project within that relationship. The contract governs how you work together. The SOW names the deliverables, scope, timeline, payment, and what "done" looks like.
The SOW is project-specific. You write a new one for each engagement. Under contract law, a well-written SOW is itself a binding agreement when signed. So if you can only have one document, make it the SOW. Scope disputes happen at the project level, not the relationship level.
Why disputes happen without both
Most project disputes fall into one of two categories:
- "I thought you owned this": an IP dispute the contract should cover
- "I thought that was included": a scope dispute the SOW should cover
With only one document, half your potential disputes have no paper trail. The contract can't tell you whether the onboarding email sequence was in scope. The SOW can't tell you who owns the work if you never settled IP terms. Having both means that when a question comes up, you know exactly where to look.
How they work together
Sign the MSA when you onboard a new client. For every subsequent project, send only the SOW. Your standing terms are already in place. You don't re-negotiate your core terms every time a new project starts. It's faster, and it keeps your agreements consistent.
If your contract says IP transfers on final payment, that holds for every project with that client. You don't have to remember to add it to each SOW.
When one document is enough
For a one-time project with a new client, an SOW that includes basic payment and IP terms is often sufficient. You don't need a full MSA for every logo project. But as client relationships become ongoing, separating the two makes sense: repeat work gets simpler and your standing terms carry forward automatically.
For high-value or long-term work, use both. If something goes wrong, the MSA tells you how to resolve it. The SOW tells you what you're actually arguing about.
Summary
Use this to audit your current paperwork. If a section is missing, fill it before your next engagement.
Your contract (MSA) should cover:
- Governing law (which state or country)
- Dispute resolution (arbitrationA way to resolve disputes outside of court. Both parties agree in advance to let a neutral third party decide. Usually faster and cheaper than litigation. or litigation, and where)
- IP ownership (work-for-hireA legal arrangement where the client owns everything you create because it was commissioned work. Standard for most freelance relationships once paid — which is why IP clauses matter. clause, or license terms)
- Confidentiality and NDAA confidentiality agreement that prevents you or the client from sharing proprietary information — business plans, unreleased work, your processes — with outside parties. terms
- Termination with notice period (typically 30 days)
- Limitation of liability
Your SOW (per project) should cover:
- Specific deliverables: named, with formats
- Out of scope: explicitly listed
- Timeline and milestones
- Revision rounds and definition of a revision
- Payment amount, depositUpfront payment before work begins. Standard is 50% for project work. Commits the client before you've spent an hour — and means you have something in hand before delivering anything., and schedule
- Kill feeA payment owed if a client cancels after work has begun. Typically 25–50% of the remaining balance. It compensates you for time blocked and work already done — not a penalty. and cancellation terms
- Acceptance criteriaThe specific conditions that define "done." Work is complete when it meets these — not when the client simply likes the direction. Vague acceptance criteria is how revision cycles never end.: how you define done
LumenBill generates both documents from your project details. Your MSA is a standing template; the SOW is generated per project with your client's name, scope, and payment terms pre-filled.
Written by Robin Kelmen with AI assistance. Sources linked inline. Last reviewed February 2026.