Statement of Work in United States: Template, Key Clauses and Local Law (2026)

Is a statement of work legally binding in the United States? Yes. A statement of work is a binding contract in the United States, either on its own or, more often, as an order under a master services agreement (MSA). The SOW describes one project: the deliverables, timeline, acceptance criteria, and fees. The MSA holds the standing legal terms (liability, IP, confidentiality), and the SOW incorporates them. There is no federal SOW statute; it is governed by ordinary state contract law chosen in the MSA. This is general information, not legal advice. For a large or fixed-price engagement, ask a licensed US attorney. ## What US law applies to a statement of work An SOW is an ordinary commercial contract, so the same rules as any US agreement apply: offer, acceptance, consideration, and intent to be bound, under the state common law chosen in the governing MSA. Because an SOW usually incorporates the MSA by reference, the MSA's governing law, liability cap, IP terms, and dispute resolution flow into it automatically. If the two conflict, the order-of-precedence clause decides which wins, so that clause matters. Two practical points. First, in US government contracting, "statement of work" and the related "performance work statement" have formal meaning under the Federal Acquisition Regulation (FAR); this page is about commercial SOWs, which are lighter and freely negotiable. Second, an SOW can accidentally change the deal if it contradicts the MSA, so keep legal terms in the MSA and scope in the SOW. Electronic signature is valid under E-SIGN and UETA. ## Key clauses in a US statement of work ### Reference to the MSA

State that the SOW is issued under, and governed by, the named MSA, and set the order of precedence if they conflict. ### Scope and deliverables Describe exactly what will be delivered. Specific, testable deliverables prevent disputes; vague scope invites them. ### Out of scope List what is not included, which is as useful as the scope itself for avoiding scope creep. ### Timeline and milestones Set the schedule, milestones, and any dependencies on the customer. Say what happens if a dependency slips. ### Acceptance criteria and process Define how deliverables are reviewed, the acceptance window, and what counts as acceptance or rejection. This clause controls payment triggers, so be precise. ### Fees and payment schedule State whether the project is time-and-materials, fixed-price, or milestone-based, and tie payment to milestones or acceptance. Cover expenses and taxes. ### Roles, staffing, and responsibilities Name key personnel and the customer's responsibilities (access, data, approvals). ### Assumptions List the assumptions the estimate relies on, so a wrong assumption triggers a change order rather than a dispute. ### Change control Describe how changes to scope, timeline, or fees are requested, priced, and approved. A clear change-control clause is what keeps a fixed-price SOW from bleeding. ### Deliverable IP Confirm how the MSA's IP terms apply to these specific deliverables, including any customer-owned work product. ## A simple US statement of work skeleton 1. SOW number, parties, and reference to the MSA 2. Order of precedence 3. Project background and objectives 4. Scope of services and deliverables 5. Out of scope 6. Timeline, milestones, and dependencies 7. Acceptance criteria and process 8. Pricing model and payment schedule 9. Expenses and taxes 10. Key personnel and customer responsibilities 11. Assumptions 12. Change control 13. Deliverable intellectual property 14. Signatures ## Points worth negotiating Make the deliverables and acceptance criteria concrete, because they decide when you get paid and when the project is done. Negotiate the change-control process so new work is priced, not absorbed. For fixed-price work, protect yourself with clear assumptions and dependencies. Confirm the pricing model (time-and-materials versus fixed-price) matches the risk you are willing to carry. Keep legal terms in the MSA so the SOW does not accidentally rewrite them. ## Where a single contract workspace helps One MSA can spawn dozens of SOWs, each with its own milestones, acceptance dates, payment triggers, and assumptions, all of which have to stay aligned with the parent MSA. Tracking that by hand is where mistakes creep in, and it is exactly what an AI contract workspace is built for: the MSA and every SOW become a linked, structured clause tree, positions are marked favourable, neutral, or unfavourable to your company, and milestone and acceptance dates surface automatically. Adira is one such workspace. Adira is India-first today, and deeper United States jurisdiction coverage is on its roadmap, so for US-governed work treat it as a drafting and tracking aid and confirm specifics with a US attorney. The structure above does not change; a workspace just keeps the SOWs and their MSA in sync.