How to Review a Statement of Work (2026 Checklist)

A statement of work (SOW) is the document that turns a services relationship into a concrete project. It says what will be delivered, to what standard, on what schedule, for what price, and who does what. It usually sits under a master services agreement (MSA) that carries the heavier legal terms. Reviewing a SOW well is less about legal drafting and more about precision: vague scope, soft acceptance and open-ended change control are where projects overrun and invoices get disputed. This is general guidance, not legal advice. ## The fast answer: what to check first Read for three things before anything else. First, is the scope specific enough that a stranger could tell whether the work was done? Second, are there objective acceptance criteria tied to payment? Third, is there a change-control mechanism so new requests do not silently expand the job? If those three are weak, the rest of the SOW will not save you. ## Clause-by-clause review checklist ### Scope of work The scope should describe the work in enough detail that both sides read it the same way. Look for what is included and, just as important, what is excluded. Assumptions and dependencies belong here too: what the vendor is relying on you to provide (access, data, people, approvals) and by when. Where an assumption fails, that is usually a change, so make the assumptions explicit. ### Deliverables Each deliverable should be named, described, and given a format and a due point. A table works well: deliverable, description, format, due date, owner. Avoid lists that mix firm deliverables ("the migrated database") with activities ("ongoing support"); they are reviewed and accepted differently. ### Acceptance criteria and process This is the heart of the SOW. For each deliverable there should be a defined test of completion and a review window, with what happens if you accept, reject with reasons, or stay silent. Watch for "deemed acceptance" clauses where a deliverable is treated as accepted if you do not respond within a few days; shorten the risk by setting a realistic window and a clear right to reject with reasons and have the fix redone. ### Timeline and milestones Check the schedule is tied to real dates or to triggers (for example "10 business days after you provide the test data"). Milestones should line up with payment and with acceptance. Confirm what happens to the schedule if your dependencies are late, versus if the vendor is late. ### Fees and payment Identify the pricing model: fixed price, time and materials, or capped time and materials. For fixed price, confirm what is included and how out-of-scope work is priced. For time and materials, check rates, estimated hours, any cap, and reporting. Tie payment to accepted milestones, not to calendar dates alone, and check expenses, taxes and currency. ### Change control A good SOW has a simple written change process: either side can propose a change, the other prices its effect on scope, schedule and fee, and no change takes effect until both sign. Without this, scope creep is unmanaged and disputes follow. ### Roles, responsibilities and governance Name the key people, the escalation path and the meeting cadence. A short responsibility matrix (who is responsible, accountable, consulted, informed) removes a lot of later argument. ### Personnel and subcontracting If named people matter, say so, and set terms for replacing them. Check whether the vendor can subcontract and whether it stays responsible for its subcontractors. ### Intellectual property and acceptance of IP The MSA usually sets IP ownership, but the SOW should say what IP is created and whether it is assigned or licensed. Confirm it does not contradict the MSA. Pre-existing (background) IP and third-party or open-source components should be flagged. ### How the SOW fits the master agreement A SOW should reference the MSA and state that the MSA governs in case of conflict, unless a specific SOW change is intended and clearly marked. Read the two together: the SOW should not quietly rewrite liability, warranty or IP terms unless that is the deliberate intent. ## Red flags to push back on Scope described only by outcomes with no detail on method or exclusions. No acceptance criteria, or acceptance "at the vendor's reasonable determination". Aggressive deemed-acceptance windows. Payment tied to dates regardless of delivery. A change process that lets the vendor charge for changes but gives you no say. A SOW that contradicts the MSA without saying which wins. ## How the law changes by jurisdiction Contract law is national, so the same words do not behave the same everywhere. In common-law systems (India, the UK, Singapore, Australia, the US) courts lean on the written terms and read ambiguity against the drafter. Governing-law and jurisdiction clauses decide which country's rules apply and where disputes are heard; check they match where the parties and the assets actually are. In India, stamp duty and, for many instruments, registration are live concerns, and the Indian Contract Act 1872 governs formation. In the US, state law varies and the Uniform Commercial Code may apply where goods are involved. Across the EU and UK, data and consumer rules add mandatory terms you cannot contract out of. When in doubt, take local advice; this page is general information, not legal advice. ## A simple review workflow Start with scope, deliverables and acceptance, because they drive everything else. Then check the schedule and payment line up with acceptance. Then change control, roles and IP. Finally read the SOW against the MSA for conflicts. Keep an issues list with clause reference, risk and proposed fix, and confirm assumptions and dependencies with the delivery team, not just the lawyers. ## One workspace for drafting, review and tracking Everything above is work you can do by hand: read the draft, mark the risky positions, line up your redlines, remember the dates. The friction is rarely the reading. It is that the draft, the comments, the versions, the signed copy and the renewal date usually live in five different places. The simple idea behind an AI contract workspace is to keep that work together: draft from your own catalogue, see each clause flagged favourable, neutral or unfavourable to you, edit clauses in plain English and get a clean diff, keep a live activity timeline so every version is traceable, and track key dates and obligations so renewals and notices do not slip. Adira is one such workspace, built on Anthropic's Claude and tuned to how your company contracts. It is India-first today; deeper support for other jurisdictions and a single legal health pane (the Company Command Centre) are on the roadmap. None of that replaces legal advice on a specific deal. It just means the review you ran once does not have to be rebuilt from scratch next quarter.