Statement of Work (SOW) Template: How It Links to Invoices

Quick answer: A statement of work template defines a project's scope, deliverables, timeline, acceptance criteria and payment schedule. Each payment in the SOW becomes an invoice: reference the SOW number, the milestone, the acceptance date and any purchase order, and bill change orders as separate lines so the client can match every charge to signed paperwork.

Many freelancers first meet a statement of work when a larger client sends one over and says, "We need this signed before we can raise a PO." It can feel like extra bureaucracy, but a good SOW is the best tool you have for getting paid on project work. It fixes what you are delivering, how the client will judge it and exactly when each payment becomes due. When the invoice arrives, accounts payable can match it to the SOW and approve it without chasing anyone.

This guide walks through the sections of a statement of work template, how a SOW differs from a contract and an MSA, how to build a milestone payment schedule and how to word invoices so they link cleanly back to the SOW. When you are ready to bill, our free invoice generator lets you add the SOW and PO references, and the corporate invoice template fits the formal style enterprise clients expect.

What a statement of work template should include

SOW formats vary by industry, but most cover the same ground. Use the sections below as a checklist when drafting your own statement of work template.

1. SOW number, parties and date. A unique identifier such as SOW-2026-014, the legal names of both parties and the effective date. Reference the governing contract or MSA.
2. Background and objectives. Two or three sentences on why the project exists and what success looks like.
3. Scope of work. The activities you will perform, written plainly. Include an "out of scope" list; it prevents more disputes than anything else in the document.
4. Deliverables. Each tangible output, with format and quantity, such as "responsive website, 8 page templates" or "brand messaging guide, PDF, up to 20 pages."
5. Timeline and milestones. Key dates, with dependencies on the client noted, such as content supplied by a certain date.
6. Acceptance criteria and process. How each deliverable will be reviewed, the standard it must meet and the review period.
7. Roles and responsibilities. Who on each side approves work, supplies materials and answers questions.
8. Pricing and payment schedule. Fixed price, time and materials or a monthly fee, with each payment's trigger and amount.
9. Assumptions and change control. What you are assuming to be true, and how changes are requested, priced and approved.
10. Signatures. Authorized signatories for both parties.

Government buyers take this structure even further. In the US federal system, for example, performance-based requirements focus on measurable outcomes rather than methods, as described in FAR 37.602 on performance work statements. You do not need that level of formality for most private clients, but the principle of measurable outcomes is worth borrowing.

SOW vs contract vs MSA

These three documents often travel together, and the terms are sometimes used loosely. Here is how they usually relate.

Document	What it covers	How often it is signed	Link to invoices
Master services agreement (MSA)	General legal terms: payment terms, liability, confidentiality, IP, termination	Once per client relationship	Sets default payment terms and late fee rules
Statement of work (SOW)	One project's scope, deliverables, timeline, acceptance and payment schedule	Once per project	Defines when and how much to invoice
Standalone contract	Legal terms and project details in one document	Once per job, common for small projects	Contains both the terms and the payment schedule
Change order	An amendment to a SOW's scope, price or timeline	Whenever scope changes	Authorizes extra invoice lines
Purchase order (PO)	The client's internal authorization to spend	Issued by the client after the SOW is signed	PO number must appear on the invoice

For smaller clients, a single document often works best. Our freelance contract template covers the legal clauses, and you can attach a short SOW as a schedule for each project. If you are unsure whether a document is a quote or a commitment, our comparison of an invoice vs an estimate clarifies where each one fits.

Pricing models in a SOW

The pricing section determines how your invoices will look for the life of the project.

Pricing model	How payments are triggered	Risk sits with	Invoice pattern
Fixed price with milestones	Acceptance of each milestone	Mostly the freelancer, if estimates are wrong	One invoice per accepted milestone
Time and materials	Hours and expenses incurred each period	Mostly the client	Monthly invoices with timesheets, often with a not-to-exceed cap
Monthly fixed fee	Calendar month	Shared	One invoice per month, usually in advance
Hybrid	Fixed fee for defined phases, hourly for the rest	Shared	Milestone invoices plus monthly hourly invoices

For fixed-price work, our guide to milestone payments explains how to size each payment so your cash flow keeps pace with the effort, and the deposit invoice guide covers the upfront payment many SOWs begin with.

Sample SOW payment schedule

Here is an illustrative payment schedule for a fixed-price web application project with a total price of $24,000.00. The percentages are an example, not a standard.

Milestone	Trigger	Percentage	Amount
M0: Mobilization deposit	SOW signed and PO issued	20%	$4,800.00
M1: Discovery and designs	Written acceptance of designs	20%	$4,800.00
M2: Beta release	Beta passes acceptance tests in Section 6	35%	$8,400.00
M3: Final release	Production launch and final acceptance	25%	$6,000.00
Total		100%	$24,000.00

Check the arithmetic before anyone signs: 20% × $24,000.00 = $4,800.00; 35% × $24,000.00 = $8,400.00; 25% × $24,000.00 = $6,000.00. Adding $4,800.00 + $4,800.00 + $8,400.00 + $6,000.00 gives $24,000.00, so the schedule matches the contract price. A schedule that does not add up is an easy way to create an argument at the final invoice.

The matching milestone invoice

Suppose the beta is accepted on 20 October and the client approved a change order for an extra reporting screen at 10 hours × $150.00. The M2 invoice might look like this:

Description	Qty	Rate	Amount
SOW-2026-014, Milestone M2: Beta release, 35% of $24,000.00 (accepted 20 Oct 2026)	1	$8,400.00	$8,400.00
Change order CO-02: additional reporting screen (signed 2 Oct 2026)	10 hrs	$150.00	$1,500.00
Total due			$9,900.00

The math: $8,400.00 + (10 × $150.00 = $1,500.00) = $9,900.00. Put the PO number, such as PO 4500123, in the reference field, and note "Payment terms per MSA: Net 30." If sales tax or VAT applies to your services, calculate it on the taxable lines only and show it as a separate line below the subtotal.

Invoicing time and materials SOWs

Time and materials SOWs work differently. Instead of milestone triggers, you invoice at a fixed interval, usually monthly, for hours worked and approved expenses. Each invoice should show the SOW number, the period, hours by role or task, the rate for each role and any expenses with receipts. If the SOW sets a not-to-exceed cap, show the cumulative amount billed to date against the cap, for example "Billed to date: $18,250.00 of $30,000.00 cap." That running total warns the client early if the budget is running low and gives you a natural moment to discuss a change order before you hit the ceiling rather than after.

How to reference a SOW on your invoices

Enterprise accounts payable teams often run a matching check before paying: does the invoice match an approved PO, and does the PO match a signed SOW? Make that check easy.

• Use the SOW number in every line description for milestone or fee lines, not just in the notes.
• Add the PO number in the reference field. Our guide to the PO number on an invoice explains where it goes and why missing POs cause rejections.
• Name the milestone and acceptance date, and attach or mention the acceptance email if the client asks for evidence.
• Bill change orders separately with their own numbers. If the PO has not been increased to cover a change order, ask the client to amend it before you invoice.
• Keep invoice numbers sequential across all clients; the invoice number generator can suggest a format.
• Send to the right inbox. Many companies route invoices through an approval process; our overview of the invoice approval workflow shows what happens after you hit send.

Acceptance criteria that protect your invoices

Milestone invoices are usually payable only after acceptance, so vague acceptance terms can delay payment indefinitely. Write criteria that are objective: "all test cases in Appendix B pass," "matches approved Figma designs at the three listed breakpoints," or "report delivered in agreed template with sections 1 to 6 complete." Set a review window, such as five business days, and add a deemed-acceptance clause: if the client does not reject the deliverable in writing with reasons within that window, it is treated as accepted. That single sentence turns an open-ended wait into a predictable invoice date.

Also define what happens when a deliverable is rejected: how many rounds of fixes are included, and the point at which further changes become a change order. Our guide to handling scope creep with change orders includes wording you can adapt.

Statement of work checklist

• Unique SOW number and reference to the governing MSA or contract.
• Objectives in plain language.
• In-scope activities and an explicit out-of-scope list.
• Deliverables with format, quantity and owner.
• Timeline with milestones and client dependencies.
• Objective acceptance criteria, review period and deemed-acceptance clause.
• Pricing model and a payment schedule that adds up to the total.
• Payment terms, or a reference to the MSA's terms; see our guide to invoice payment terms.
• Expenses policy: what is reimbursable and whether approval is needed.
• Change control process and rates for additional work.
• Named contacts for approvals and invoices.
• Signatures from authorized people on both sides.

Common mistakes with SOWs and SOW invoices

• Starting work before the PO arrives. Many companies cannot pay an invoice without a PO, no matter how good the work is. Wait for it, or get written confirmation that it is coming.
• No out-of-scope list. Without one, every adjacent request becomes an argument about what was "obviously included."
• Subjective acceptance criteria. "To the client's satisfaction" lets acceptance, and payment, slide indefinitely.
• Payment schedule that does not match the price. Check that percentages add up to 100% and amounts to the total.
• Back-loaded payments. If 70% of the fee is due at final acceptance, you are financing the client's project. Use a deposit and spread payments across milestones.
• Invoices without SOW or PO references. These are the invoices that come back weeks later with "please resubmit."
• Unsigned change orders. Doing extra work on a verbal yes makes it very hard to bill. Get a signature first.

Bringing it together

A statement of work is where good invoices start. When the SOW names each deliverable, defines acceptance objectively and ties every payment to a clear trigger, invoicing becomes almost mechanical: a milestone is accepted, you issue the invoice with the SOW number, milestone and PO, and the client's matching check passes. The same approach works for consulting engagements; our consulting invoice template shows how to apply it to hourly and retainer work.

Our generator builds the PDF in your browser; it does not track milestones or send invoices for you, so keep a simple tracker listing each SOW milestone, its invoice number, the date sent and the date paid. That log, plus a well-written SOW, covers most of what a freelancer or small studio needs to bill project work with confidence.