Statement of work

A statement of work (SOW) is a document that defines one project's scope, deliverables, timeline and price, usually under a master agreement both sides already signed.

What it is

An SOW turns a general relationship into a specific job. The service agreement or master agreement holds the legal terms. The SOW says what will be built or done this time, by when, and for how much. When the two conflict, the master agreement usually says which one wins.

SOWs are the most repeated contract in many service businesses. A busy agency or staffing firm may sign several a week with the same client. That makes them a good fit for templates and automation.

When it is used

A new project starts with an existing client.
A project changes enough to need a new or amended SOW.
A client's procurement team asks for one before it can issue a purchase order.
Contractors or consultants start a fixed piece of work.

What it usually contains

Section	What it covers
Reference to the master agreement	Which signed agreement this SOW sits under
Project summary	One paragraph on the goal
Scope	The work included, and a list of what is out of scope
Deliverables	Each thing handed over, with a short description
Milestones and timeline	Dates for each stage
Acceptance	How the client checks and accepts each deliverable, and how long they have
Fees	Fixed price, time and materials, or a mix, plus expenses
Payment schedule	What is billed when, often tied to milestones
Assumptions and dependencies	What the client must provide, and what happens if it is late
Change process	How scope changes are asked for, priced and approved
Contacts	Who leads the project on each side
Signatures	Authorised signers for both parties

Things to get right

Write acceptance criteria you can test. "Client is satisfied" invites disputes. "Passes the checklist in Appendix A within 10 business days" does not.
List what is out of scope. It is the section people most often wish they had written.
Number your SOWs. Put the number in the title and file name. It makes later amendments and invoices easy to match.
Price changes in writing. A change order should be signed the same way as the SOW.

General information only. This is not legal advice, and a lawyer should check how your SOW and master agreement fit together.

How to send it for signature with docuinked

In the app

Upload the SOW PDF, add both signers, and place initials on each page with pricing so nobody can say they missed it. Save it as a template if your SOWs share a layout.

By API

A project tool can send each new SOW when a project moves to "ready to sign". This example adds initials next to the fee table and keeps the SOW number in metadata.

curl https://docuinked.com/v1/documents \
  -H "Authorization: Bearer $DOCUINKED_API_KEY" \
  -H "Idempotency-Key: sow-1047" \
  -H "Content-Type: application/json" \
  -d '{"title": "SOW 1047, website rebuild phase 2",
       "pdf_url": "https://example.com/sow-1047.pdf",
       "metadata": {"sow": "1047", "project": "web-rebuild"},
       "signers": [{"name": "Morgan Diaz", "email": "morgan@example.com"},
                   {"name": "Alex Rivera", "email": "alex@example.org"}],
       "fields": [{"signer": 1, "kind": "initials", "anchor": "Fees initials:"},
                  {"signer": 1, "kind": "signature", "anchor": "Client:"},
                  {"signer": 2, "kind": "signature", "anchor": "Supplier:"}],
       "send": true}'

Using the SOW number as the Idempotency-Key means a rerun of the same step can never send SOW 1047 twice. See idempotency.

From an agent

An agent can read the project brief, fill the SOW and prepare it over MCP. Because scope and price are where mistakes cost most, the live send stops at an approval_url and a named person reads the draft before it goes. The approval covers the exact draft by its hash, so a later edit means a new approval. See approvals and human-in-the-loop.

Sources

Checked 2026-11-07.

ESIGN Act, 15 USC 7001: electronic signatures and records may not be denied effect solely for being electronic.

Common questions

What is the difference between an SOW and a proposal?

A proposal is a sales offer. An SOW is the agreed version, signed by both sides, that the work and invoices are measured against. Many teams turn the accepted proposal into the SOW.

Does an SOW need its own legal terms?

Usually not, if a master agreement is already signed. The SOW refers to it and adds the project details. Without a master agreement, the SOW needs those terms itself.

How do I handle a change halfway through a project?

Write a change order or amended SOW with the new scope, dates and price. Send it for signature like the original, and keep both in the project record.

Should every page of an SOW be initialled?

It is a habit, not a rule. Initials next to the fees and the scope are a cheap way to show both sides saw them.

Try it in test mode

Free during the beta. Test keys send no email, so you can build the whole flow first.

Get an API key Read the quickstart