The Key Clauses in a Statement Of Work, Explained

What are the key clauses in a statement of work? A statement of work (SOW) is the document that describes one specific project under a broader agreement, usually a master service agreement. Its key clauses are the scope and deliverables, acceptance criteria, timeline and milestones, pricing and payment, assumptions and dependencies, roles and responsibilities, change control, reporting and governance, any project-specific IP or confidentiality terms, and the relationship to the governing agreement. Where an MSA sets the legal terms, a SOW sets the practical ones: what gets built, by when, for how much, and how both sides know it is done. Below, each clause is explained in plain English. This is an explanation of common clauses, not legal advice. For a high-value engagement, have the SOW and its governing agreement reviewed by a lawyer. ## Scope and deliverables The scope clause is the heart of a SOW. It describes the work in enough detail that both sides agree on what is included, and it lists the specific deliverables: the report, the software module, the design files, the trained staff. The single most useful addition is an explicit out-of-scope list. Naming what you will not do prevents most disputes, because scope creep usually hides in the gap between "we assumed" and "we expected". ## Acceptance criteria The acceptance clause says how a deliverable is judged complete. It should state the test or standard, who checks it, how long the review window is, and what happens if the deliverable fails: a chance to fix it, and a deadline. Acceptance is tied to payment, so vague criteria mean endless revisions on one side and withheld payment on the other. Write criteria that can be objectively measured. ## Timeline and milestones The timeline clause sets the schedule: start date, key milestones, and the end date. Milestones work best when each one is a concrete, checkable event, such as "design approved" or "phase one deployed". If payment is milestone-based, the milestones must line up exactly with the payment schedule. ## Pricing and payment The pricing clause states how much the project costs and on what basis. The three common models are fixed price (one agreed sum for a defined scope), time and materials (agreed rates against hours worked), and milestone-based (a payment released as each milestone is accepted). The clause should also cover expenses, taxes such as GST or VAT, invoice timing and payment due dates. Match the payment trigger to acceptance, not just to the calendar. ## Assumptions and dependencies The assumptions clause lists what the provider is relying on to deliver on time and on budget: that the customer gives access to systems, supplies data by a date, makes decisions within a set time, or provides a point of contact. Dependencies are tasks that must happen before the provider can proceed. This clause is where a provider protects itself: if an assumption fails, the timeline and price can fairly shift. It is also where a customer should check it is not signing up to obligations it cannot meet. ## Roles and responsibilities The responsibilities clause names who does what on each side, often as a simple table. It usually identifies a project lead or single point of contact for each party, which keeps decisions moving. Clear ownership of tasks reduces the "I thought you were doing that" failures that stall projects. ## Change control The change control clause sets the process for handling new requests after work starts. A good one requires any change to scope, timeline or price to be written in a change request and signed by both sides before the work is done. This is the main defence against scope creep: new asks are welcome, but they go through a visible process rather than being absorbed silently. ## Reporting and governance The governance clause describes how the project is tracked: status reports, their frequency and format, review meetings, and how issues are escalated. For longer projects this clause keeps both sides honest about progress and surfaces problems early, while they are still cheap to fix. ## Project-specific IP and confidentiality Most IP and confidentiality terms live in the MSA, but a SOW can add project-specific points: who owns a particular deliverable, whether a dataset is especially sensitive, or whether named subcontractors are allowed on this project. Where the SOW adds nothing, the MSA terms simply apply. ## Relationship to the governing agreement The incorporation clause states that the SOW is governed by a named MSA and is subject to its terms. This is important for the order of precedence: if the SOW and MSA conflict, the agreement should say which wins. A common default is that the MSA governs legal terms and the SOW can vary only commercial terms, and only where it says so expressly. ## Common SOW mistakes to avoid Even a well-structured SOW fails if a few habits creep in. The first is copying scope from a proposal or a sales deck, which is written to persuade rather than to define, and leaves gaps a lawyer would have closed. The second is letting the payment schedule drift away from the milestones, so money is due on dates that have nothing to do with delivered work. The third is burying the customer's own obligations in prose instead of listing them as assumptions, which makes it hard to prove later that a delay was the customer's fault. Fix these three and most SOW disputes never start. ## A quick SOW quality check - Can a stranger read the scope and know what is in and out?

• Are acceptance criteria testable, with a named reviewer and a deadline?
• Do payment triggers match milestones and acceptance?
• Are the customer's obligations written as assumptions, with consequences if missed?
• Is there a written change control process, and does the SOW name its governing MSA? ## Where a contract workspace helps Understanding these clauses lets you write or review a SOW that actually prevents disputes. The ongoing work is keeping each SOW aligned with its MSA, tracking milestone and acceptance dates, and making sure a change request on one project does not quietly break a term in the master agreement. That is simpler when drafting, reviewing, tracking and governing a SOW and its governing MSA live in one AI workspace tuned to your company. A platform such as Adira is built this way, linking a SOW to its MSA so conflicts and per-project risk surface and milestone dates stay visible instead of lost in email. The guide above is enough to write a strong SOW; a workspace keeps its scope, dates and dependencies joined up with everything else you sign.