Freelance guide
How to Write a Statement of Work — Template, Required Elements, and Common Mistakes
A statement of work is the document that converts an agreement in principle into specific, measurable commitments both sides can hold each other to. Unlike a freelance contract — which sets the legal terms governing a working relationship — a statement of work defines the deliverables, timeline, acceptance criteria, and payment schedule for a single project. This guide covers what every SOW needs, two fill-in templates, and how the SOW payment schedule feeds directly into each invoice you send.
- SOW vs. contract vs. scope of work
- 7 elements every SOW needs
- Fixed-price template
- Time-and-materials template
- Wiring the SOW into your invoices
- Common SOW mistakes
- FAQ
SOW vs. scope of work vs. freelance contract
These three terms are used interchangeably in practice, but they do different jobs. Understanding the distinction prevents confusion when a client says “send us your SOW” and you need to know what to include.
| Document | What it governs | When to use it |
|---|---|---|
| Freelance contract / MSA | Legal terms: IP ownership, confidentiality, termination, governing law — the rules that apply to all projects with a client | Set up once per client relationship; rarely changes |
| Statement of work (SOW) | Project specifics: deliverables, timeline, acceptance criteria, payment schedule, revision scope — for one engagement | One per project; attached to or governed by the contract |
| Scope of work | The deliverables section of a contract or SOW — usually a subsection, not a standalone document | Embedded in a contract when the SOW and contract are combined in a single document |
For a one-off project with a new client, a standalone SOW that also covers IP and payment terms is usually sufficient — it acts as both the project spec and the legal agreement. For ongoing client relationships, a master service agreement signed once and a fresh SOW per project is more efficient: you keep the legal boilerplate out of every project document and only re-negotiate the project-specific terms.
Many enterprise clients will present their own master service agreement for you to sign; they then request your SOW as the project-specific attachment. In that scenario, the SOW only needs to cover deliverables, timeline, payment schedule, and acceptance criteria — the legal terms are already set in their MSA.
7 elements every SOW must include
Project description
One to three sentences explaining what the project achieves and why. This is context, not a deliverable list — it sets the frame for everything that follows and is what both parties refer to if the scope becomes ambiguous.
Example: “Redesign and rebuild the marketing website for Acme Studio, migrating from WordPress to a static site, with the goal of reducing page load time and updating the visual identity to match the 2026 brand refresh.”
Deliverables
The specific, measurable outputs you will provide. Each deliverable should be concrete enough that both sides can unambiguously confirm receipt. This is the element most freelancers write too vaguely.
Too vague: “A new website.”
Correct: “Six static HTML pages (Home, About, Services, Case Studies, Blog, Contact) matching the approved wireframes, responsive to mobile/tablet/desktop viewports, with a functional contact form using Formspree.”
Also list what is explicitly excluded. If you are not writing copy, say so. If you are not providing photography, say so. Exclusions prevent scope creep from assumptions.
Acceptance criteria
How both parties agree that each deliverable is done. Without acceptance criteria, “done” is subjective and the most common source of freelance disputes (“this isn’t finished”).
Write one criterion per major deliverable. For design: “Accepted designs match the approved wireframe in all three breakpoints (mobile, tablet, desktop) and are delivered as Figma frames with export-ready assets.” For development: “All pages render correctly in current-version Chrome, Firefox, Safari, and Edge; the contact form submits and delivers email; Google PageSpeed Insights scores ≥90 on mobile.”
Timeline and milestones
Specific dates for the kickoff, each major deliverable, and final completion. Include any dependency on client-supplied assets — “Client provides all copy and images by [date]; timeline extends by an equivalent period for delays caused by late client assets.” Without this clause, a client who goes dark for three weeks can come back and claim you missed the deadline.
Payment schedule
The total fee, how it is split across invoices, the due date for each invoice, and the late payment rate. This section feeds directly into every InvoiceQuick invoice you generate for the project. Milestone-based payment (e.g. 50% deposit + 50% on delivery) is the standard for project work; retainers are typically invoiced monthly on a fixed date.
Fee: USD [total]
Payment schedule:
Invoice #001 — 50% deposit: USD [amount], due before commencement
Invoice #002 — Balance on delivery: USD [amount], due within 14 days
of client acceptance of final deliverables
Late payment: Invoices unpaid after the due date accrue 1.5% per month.
Revision scope
How many rounds of revisions are included, what a round means, and what triggers a change order. A round should mean “one consolidated set of written feedback per deliverable, submitted within [X] business days of delivery.” Without this definition, a single “round” can stretch into weeks of back-and-forth.
Revisions: Two (2) rounds of revisions per deliverable are included.
A revision round is one consolidated set of written feedback per
deliverable, submitted within 5 business days of delivery. Additional
revisions, feedback outside this window, or requests that materially
change the approved scope are change orders billed at USD [rate]/hour.
Change order process
How scope changes are requested, acknowledged, and priced. A one-sentence process prevents the “but I thought that was included” dispute from arising every time a client asks for something extra.
Changes to this Statement of Work require written agreement from both
parties before work commences on the change. Changes are documented
by a written change order referencing this SOW and are billed at
Contractor's standard rate of USD [rate]/hour or a mutually agreed
fixed price for the additional scope.
Fixed-price SOW template
Use this structure for project-based work with a defined output. Fill in the italic highlighted fields.
STATEMENT OF WORK
Date: [date]
Client: [client legal name and address]
Contractor: [your legal name and address]
1. PROJECT DESCRIPTION
[1–3 sentences: what the project achieves and why]
2. DELIVERABLES
[List each deliverable as a specific, measurable output]
Exclusions: [List anything explicitly not included]
3. ACCEPTANCE CRITERIA
[One criterion per major deliverable: what does ‘done’ mean?]
4. TIMELINE
Kickoff: [date]
[Milestone 1 name]: [date]
[Milestone 2 name]: [date]
Final delivery: [date]
Note: Timeline assumes Client provides [assets/copy/approvals]
by [date]. Contractor delays caused by late Client assets
extend the timeline by an equivalent period.
5. PAYMENT
Total fee: [currency and amount]
Invoice #001 — 50% deposit: [amount], due before commencement
Invoice #002 — Balance: [amount], due within 14 days
of written client acceptance of final deliverables
Late payment: 1.5% per month on overdue balances
6. REVISIONS
Two (2) rounds of revisions per deliverable are included.
A revision round is one consolidated set of written feedback,
submitted within 5 business days of delivery. Additional rounds
or feedback outside this window are change orders at [rate]/hour.
7. CHANGE ORDERS
Changes to this SOW require written agreement before commencement.
Change orders are billed at [rate]/hour or a mutually agreed fixed price.
Signed: _________________________ Date: _____________
Client: [name and title]
Signed: _________________________ Date: _____________
Contractor: [your name]
Time-and-materials SOW template
Use this structure for ongoing or exploratory work where the total is not fixed in advance. The deliverables section lists the work to be performed rather than specific outputs; the payment section describes the billing rate and cap.
STATEMENT OF WORK (TIME AND MATERIALS)
Date: [date]
Client: [client legal name and address]
Contractor: [your legal name and address]
1. SERVICES
[Describe the nature of the services: e.g., ‘Front-end development
support for the Acme Studio platform, including bug fixes, feature
implementation per the agreed backlog, and code review.’]
2. RATE
[Daily/hourly rate] per [day/hour]
Billed: [weekly / bi-weekly / monthly] in arrears
Expenses: [reimbursed at cost / not included]
3. ESTIMATED SCOPE
Estimated [days/hours] over [period]
Cap: Contractor will not exceed [amount] without written
authorisation from Client.
4. TIMELINE
Start date: [date]
End date / review date: [date]
5. INVOICING
Invoices submitted [weekly/monthly] with a timesheet showing
dates, hours, and task descriptions. Due within 14 days of receipt.
Late payment: 1.5% per month on overdue balances.
6. CHANGE OF SCOPE
Additional services outside those described above require written
agreement and a new or amended Statement of Work.
Signed: _________________________ Date: _____________
Client: [name and title]
Signed: _________________________ Date: _____________
Contractor: [your name]
Wiring the SOW into your InvoiceQuick invoices
The SOW payment schedule is the spec for every invoice you generate. Keeping the two documents in sync prevents confusion when clients match invoices to purchase orders or question an invoice amount.
- Mirror the milestone label exactly. If the SOW says “Invoice #001 — 50% deposit,” that label should appear on the InvoiceQuick line item description verbatim. A client’s AP team matching an invoice to a purchase order looks at line descriptions, not just totals.
- Reference the SOW in the Notes field. Add a line: “Per Statement of Work dated [date].” This creates a paper trail connecting each invoice to the SOW without repeating the full scope on every invoice.
- Use a specific due date, not “NET 14.” If the SOW says “due within 14 days of client acceptance,” write the specific due date on the invoice (e.g. “Due: 1 October 2026”). A specific date is easier for accounts payable to schedule and harder to misread.
- Send the deposit invoice before starting. For milestone-based projects, the deposit invoice is your practical signal to proceed. Payment confirms the client is financially committed. Starting without the deposit — on the promise that it’s “coming” — is the most common setup for non-payment disputes.
- For T&M work, attach a timesheet. Use InvoiceQuick’s line items to list each work period (date range, hours, task summary) or attach a separate timesheet. Itemised billing reduces “what did I actually pay for?” questions and speeds approval through enterprise AP teams.
Create my invoice with InvoiceQuick →
Fill in your client, milestone label, and payment terms — download a clean PDF in seconds. No signup.
Common SOW mistakes
- Writing goals instead of deliverables. “Improve the user experience” is a goal. “Redesign the checkout flow to reduce steps from five to three, validated by a client sign-off on the Figma prototype” is a deliverable. The test: can both parties look at the deliverable and agree whether it has been produced? If yes, it is a deliverable. If not, it is a goal.
- No acceptance criteria. Without acceptance criteria, “it’s not finished” is the client’s unilateral call. Acceptance criteria are not about lowering the quality bar — they are about defining what the bar is so both parties can agree when it has been cleared.
- Missing the client-delay clause. If the client is supposed to provide assets, copy, logins, or approvals by a certain date, state that clearly — and state that contractor delays caused by late client materials extend the timeline by an equivalent period. Without it, a client who delays for two weeks can claim you missed the deadline.
- Not defining a revision round. Saying “two rounds of revisions included” without defining what a round means is almost as bad as saying nothing. Define the round: one consolidated set of feedback, in writing, within a specified window. Verbal feedback in a call, piecemeal feedback over email, and major direction changes are not included in a round.
- Vague payment trigger. “Payment on completion” is ambiguous when completion is disputed. “Payment within 14 days of written client acceptance of final deliverables as defined in Section 3” is not. Tie each invoice to a specific, documentable event.
- No change order clause. Without a change order process, every client request — however significant — lands in a grey zone between “extra work I should charge for” and “included revision I have to do for free.” A single paragraph establishing the process resolves this before it becomes a conversation.
- Starting before the SOW is signed. The single most common SOW mistake. A client who has not signed has not committed. Starting before the deposit invoice is paid and the SOW is confirmed removes all of your negotiating leverage before the project begins.
Also read:
- How to write a freelance contract — the 9 essential clauses, IP ownership, and kill fee language →
- How to create a free invoice PDF — what to include, numbering, and how to export →
- How to send an invoice by email — subject lines, follow-up cadence, and vendor portals →
If your freelance business has a website — a portfolio, a contact form, or a client onboarding portal — GDPR and CalOPPA require a privacy policy for it once you collect names or email addresses. ComplyKit generates a GDPR & CCPA-aware privacy policy, terms of service, and cookie notice free, in your browser, with no signup.
If any of your SOW deliverables include a live web property, consider adding a security headers scan to your definition of done: HardenCheck checks the site’s Content-Security-Policy, HSTS, X-Frame-Options, and other headers in seconds — enterprise clients and security-conscious buyers routinely run these checks before accepting handover.
Frequently asked questions
What is the difference between a statement of work and a scope of work?
In practice, these terms are often used interchangeably. The cleaner distinction: a scope of work is typically a section within a larger contract or brief. A statement of work is a standalone project document that covers deliverables, timeline, payment schedule, acceptance criteria, and revision scope for a single engagement. For a one-off project, many freelancers combine both into one document. For ongoing clients, separate SOWs per project attached to a master contract is more efficient.
Do I need a separate contract AND a statement of work?
For a first or one-off project, a single well-drafted SOW that also covers IP, confidentiality, and governing law is usually sufficient. For ongoing client relationships, setting up a master service agreement once — covering all legal terms — and issuing a short SOW for each new project is more efficient. Enterprise clients typically have their own master agreement and will ask you for an SOW as the project-specific attachment — in that case the SOW only needs deliverables, timeline, payment, and acceptance criteria.
What is a change order and when does it trigger?
A change order is a written amendment to the SOW that adds, removes, or modifies the original scope. It triggers when a client requests something outside the deliverables listed in the SOW — an extra page, a different technology, a feature not in the brief, or a change of direction that invalidates completed work. The SOW should state that changes require a written change order and additional billing. Without this clause, clients often assume all revisions are included regardless of scope.
What if the client keeps changing the scope?
With a well-written SOW, each scope change triggers a change order and a corresponding invoice line. For every request that goes beyond the agreed deliverables, send a brief written confirmation: “This falls outside the original SOW. I can add it as a change order for [amount] — please confirm in writing to proceed.” Written confirmation creates a paper trail and makes the client weigh whether the addition is worth the cost. The change order process is only effective if you use it consistently — the first time you absorb an out-of-scope request silently, clients assume everything is negotiable.
How long should a statement of work be?
As long as it needs to be to make every deliverable and acceptance criterion unambiguous — typically one to three pages for a standard freelance project. A one-sentence scope that says “build a website” is worse than a half-page that lists every page, every integration, and every supported browser. A 20-page document with vague deliverables is worse than a 2-page document with specific ones. Write for specificity, not length.
Should I invoice at the end of the project or use milestones?
For any project taking more than two weeks, milestone-based invoicing protects against non-payment risk. A standard structure: 25–50% deposit before work starts; one or two interim milestone invoices tied to specific deliverable approvals; final 25–50% on completion. Deposit invoices are the most important — they confirm the client is financially committed before you allocate time. For ongoing retainer work, a fixed monthly invoice on the first of each month is simpler and gives both sides predictability.
What if the client never signed the SOW but I’ve already started work?
In most common-law jurisdictions, conduct can constitute acceptance — a client who receives and approves your work has implicitly accepted your terms even without signing. “Implicitly accepted” is harder to prove than a signed document, and the terms may be disputed. If you have started without a signature: resend the SOW and ask for written confirmation by email. An email reply saying “agreed, please proceed” is substantially stronger than silence. For future projects, condition starting on receiving written SOW confirmation; paying your deposit invoice serves as a practical form of acceptance.
More free tools for freelancers
Once your SOW is signed and your first invoice is sent, here are the other tools freelancers and small agencies use alongside InvoiceQuick.
Generate a GDPR & CCPA-aware privacy policy, terms of service, and cookie-consent notice for your freelance business website — free, in your browser.
ADA & privacy risk ShipSafePaste a URL for a plain-English report on the accessibility and privacy gaps that get sites sued — useful before handing off a web project to a client.
Security headers HardenCheckScan a live site’s HTTP headers for missing Content-Security-Policy, HSTS, and other security hardening flags — a quick pre-handover check for web projects.
Secret scanning LeakCheckPaste code or a config file and see exposed API keys and secrets flagged before they reach your repo or client.