Statement of Work Template: Filled Example and Acceptance Tests

A statement of work (SOW) sets out a project's deliverables, boundaries, timetable, acceptance process and commercial terms. The template below turns those fields into a usable project schedule, with a filled example showing how to reject a defective deliverable and record a proposed scope change. Copy it into your document editor and adapt it to the governing agreement.

This is a starting structure for business services. A construction, regulated-data or government procurement project needs its own requirements. This operational template assumes the parties have suitable governing terms; its title and filled fields do not supply a project-specific enforceability assessment.

Choose the document's role before filling it in

A scope of work describes the work included and excluded; here, it is one part of the larger statement of work. Organizations sometimes use the labels differently, so examine the content. A proposal presents an offer for discussion. An agreed SOW should make the delivery and approval rules usable.

If a master services agreement (MSA) already governs the relationship, identify its parties, date and version. Check incorporation, authorized signatories, change procedures and document priority. Our master-agreement and document-conflict guide provides the cluster starting point. If there is no MSA, this project template needs suitable general terms, including liability, termination, disputes and governing law.

SOW, scope, MSA and SLA: give each document a job

Use the SOW to describe this project. Use the MSA for relationship terms that recur across projects. A service level agreement (SLA) describes recurring service measurements and the agreed response to a miss; a one-time deliverable's acceptance test serves a different purpose. A purchase order can record an ordering or payment reference, but check whether its printed terms introduce another conflict. The document names do not resolve priority.

Choose the drafting approach that fits the work. A detailed task SOW suits a known process with required steps. An outcome-focused SOW specifies results and leaves the delivery method flexible. For an uncertain software project, agree a discovery phase, budget and decision gate before commissioning later work. These are drafting choices, not universal legal categories. The Oregon DOT SOW Writing Guide, pages 3 to 4 and 8 to 9 illustrates deliverables, recurring services and phased commissioning in its own procurement context.

Copyable statement of work template

Replace every bracketed field. Attach the referenced specifications and review the resulting document as a whole, rather than leaving essential decisions in an email thread.

STATEMENT OF WORK [number and version]
Client: [full legal name, address]
Provider: [full legal name, address]
Project: [name and intended result]
Effective date: [date or defined signature event]
Governing agreement: [MSA title, parties, date and version, or attached general terms]
Document priority: [consistent with governing agreement; identify any expressly agreed exception]

1. PURPOSE AND SCOPE
The provider will [specific work] to produce [identified result].
Included activities: [list].
Excluded activities: [list, including ongoing support if excluded].
Work location and approved systems: [details].

2. DELIVERABLES
For each deliverable: [ID, description, format, specification version, delivery method, due date and time zone].
Acceptance criteria and evidence: [observable tests and required results].

3. DEPENDENCIES AND RESPONSIBILITIES
Client supplies [inputs/access/decisions] by [date].
Provider supplies [people/tools/reports].
If a dependency is late or inaccurate, [notification and agreed schedule/cost review process].
Project contacts: [names, roles, deputies and communication channel].
Decision rights: [who can review, accept, approve changes and sign amendments].
Status reporting: [frequency, contents, recipients and issue escalation].
Business day: [working days, excluded holidays, time zone and counting rule].

4. REVIEW AND ACCEPTANCE
Reviewer: [name or role and substitute].
Review starts when [specified complete delivery is received].
Response due: [window, business-day definition and time zone].
Response method: [written acceptance or identified criteria failures].
Defect correction and retest: [responsibility, timing and process].
Partial acceptance: [permitted or excluded, with payment effect].
Silence/deemed acceptance: [state agreed rule explicitly].

5. FEES AND PAYMENT
Currency and agreed fee model: [fixed fee, capped time charges or other].
Milestone / invoice trigger / amount: [list].
Invoice requirements and payment due date: [details].
Taxes, expenses and third-party charges: [included, excluded and approval conditions].
Disputed invoices: [notice, handling and payment of undisputed sums as agreed].

6. CHANGE CONTROL
Request record: [ID, proposed scope, fee and schedule impact].
Approval authority and method: [consistent with governing agreement].
Effective change: [approval event, version and updated milestones].
Pending request treatment: [continue baseline work or agreed pause].

7. PROJECT-SPECIFIC TERMS
Security, confidentiality and personal-data handling: [requirements or precise references].
Data: [categories, permitted use, approved systems, locations, access and subprocessors].
Security evidence: [controls, incident contact and notification, audit evidence and deletion method].
Do not send production personal data until the required processing and security terms are agreed.
Work-product ownership and licenses: [terms or precise references, including existing materials].
Background and third-party materials: [schedule, licenses, restrictions and delivery of source files].
Client inputs and data: [rights retained, provider use permissions and return/export format].
Support, handover, access removal and retention: [requirements].
Termination and unfinished work: [governing terms and project-specific settlement].
Closeout: [handover evidence, open defects, final invoice, access removal and retained records].
Governing law, dispute process, notices and liability: [precise general-terms references].

8. APPROVAL
Client authorized signatory: [name, title, signature and date].
Provider authorized signatory: [name, title, signature and date].
Attachments incorporated: [names, versions and dates].

Acceptance drafting choice: agree what happens if a reviewer is silent. The example below uses express written acceptance, with escalation for delay. If the parties choose deemed acceptance, define its trigger, notice, review opportunity and effect on defects. Do not introduce that mechanism accidentally through a blank field.

How to fill the template without leaving hidden decisions

1. Freeze the baseline. Give the specification, input list and attachments version numbers. Separate the business objective from the actual purchased outputs. A goal such as improving reporting does not say whether dashboards, training or support are included.
2. Assign the work and its inputs. Identify who supplies access, source data, equipment, feedback and third-party approvals. State the notice and schedule review process for a missed dependency. Avoid promising an automatic extension or extra fee unless that is the agreed mechanism.
3. Map delivery to a decision. Give each output a due event, format, reviewer, test and evidence location. Specify whether approval is for each milestone or the whole package, and whether an approved draft permits later work to start.
4. Separate approval powers. A project reviewer may check a file without authority to increase the budget. Name the acceptance reviewer, commercial approvers and amendment signatories separately, with deputies.
5. Reconcile money and closure. State what makes a milestone invoiceable, what a conforming invoice contains and when payment falls due. Then define handover, support boundaries, data return and access removal.

The Texas DIR SOW process guide identifies roles, deliverables, schedules, service levels and acceptance, with security and transition considerations. Its state-agency review requirements and master-contract constraints belong to that program; they are not conditions imposed on every commercial SOW.

Write criteria that can actually be tested

Replace “provide a satisfactory export” with an identified file, input set and pass condition. Specify who runs the check and where the evidence is saved. In US federal performance-based acquisition, FAR 37.602(b) directs agencies, to the maximum extent practicable, to describe required results and enable assessment against measurable standards. That is a federal procurement rule; the private-service example here adopts a similar drafting technique without claiming the FAR governs it.

Capture promises that influenced the purchase in the operative documents. Our vendor-promises guide helps distinguish a sales assurance from the agreed specification.

In that same federal context, FAR 37.601(b) pairs measurable standards with a method of assessment; FAR 37.603(a) requires standards that permit assessment. The useful commercial drafting lesson is to include the measurement method, not just an ambitious target. Separately, FAR 46.501 to 46.503 distinguish conformity, acceptance responsibility and place of acceptance. The private example below uses its own expressly agreed review procedure.

Filled example: 24 rows delivered, one required record missing

Hypothetical project: Cedar Operations hires Harbor Data Services to format a small data export. All organizations, dates and amounts below are invented. The agreed scope is the approved input list of 24 unique IDs, R001 through R024, frozen on October 12, 2026. It excludes new records, analytics, hosting and ongoing support.

Completed SOW you can copy and adapt

This fictional schedule shows the template filled in, including the terms that a short scope paragraph leaves unresolved. It assumes the parties have already executed the identified MSA. Its dates, fees, authority and operating controls are chosen examples, not legal defaults.

SOW 01 v1: Cedar export formatting
Client: Cedar Operations LLC, 100 Example Lane, Sacramento, CA.
Provider: Harbor Data Services LLC, 200 Example Lane, Sacramento, CA.
Effective: October 12, 2026, after both authorized signatures.
Governing terms: Cedar / Harbor MSA dated October 1, 2026, v1.
Priority: MSA controls conflicts. No exception is made by this SOW.

1. Objective and boundaries
Create an import-ready export of the frozen synthetic input list.
Included: format 24 records, preserve source values, document field mapping and correct failures against the baseline criteria.
Excluded: new records, data enrichment, analytics, hosting and ongoing support.
Place: remote work using Cedar's approved secure project folder.

2. Inputs and responsibilities
Cedar supplies Input List v1 and Mapping Specification v1 on October 12 by 17:00 UTC and grants named-user folder access.
Harbor project lead Maya prepares, tests and submits the files.
Cedar reviewer Lee runs the acceptance checks; deputy Pat acts if Lee is unavailable.
Project leads send status and issues in the project email channel on October 16 and at delivery.
If inputs or access are late, Maya records the affected task within one calendar day. Leads assess impact; only authorized approvers can approve revised dates or fees. No automatic fee increase.

3. Deliverables and evidence
D1: export-v1.csv, UTF-8, record_id / start_date / amount, delivered October 20 by 17:00 UTC.
D2: mapping-v1.pdf, source and output fields plus transformations, same deadline.
Pass: IDs R001 through R024 each occur once, with no extras; all source values match; dates use YYYY-MM-DD; required columns and D2 are present.
Lee saves an ID comparison, value comparison and format check in the project folder. Both files form one acceptance package.

4. Review and correction
Review begins when both deliverables and Harbor's test report are received in the secure folder.
Written acceptance or a criteria-specific failure notice is due October 22 by 17:00 UTC for timely complete delivery.
For a later complete delivery, response is due two calendar days after receipt at 17:00 UTC. Leads record the new response date.
Baseline failures are corrected without an additional fee by October 23 in the timely-delivery scenario; retest and response are due October 24 by 17:00 UTC.
If those dates cannot be met, the parties record the reason and use the MSA escalation and remedy process.
No partial or automatic acceptance through silence. Missed responses escalate to both project leads.

5. Fee and invoices
Fixed fee USD 6,000: USD 2,000 invoiceable at October 12 kickoff and USD 4,000 after express acceptance of D1 and D2.
Invoices identify SOW, milestone, acceptance evidence where applicable and payment details.
Payment due 30 calendar days after receipt of a conforming invoice. Example arithmetic assumes no tax; reimbursable expenses are excluded.
Disputed invoice handling follows MSA section 4, including its undisputed-payment procedure.

6. Changes
Record requested IDs, specification, fee and schedule impact in a numbered change request. Cedar commercial approver Alex and Harbor commercial approver Dana must both sign the change record under MSA section 5 before the revised baseline is effective.
Pending requests do not authorize extra work. Continue baseline work unless the parties agree a documented pause.

7. Data, ownership and closeout
Only synthetic data is permitted. Named-user access, encrypted transfer, no public links or subcontractor access; suspected unauthorized access is reported immediately to both project leads under the MSA incident procedure.
Client retains its input data and permits use only for this project. Confidentiality follows MSA section 7.
New mapping-document rights and any assignment follow MSA section 8. Harbor's listed pre-existing tools remain Harbor's; the MSA license must cover any tool component embedded in a delivered file. No third-party component is included in this example.
Deliver editable mapping source with the accepted package. Remove Harbor folder access at closeout; return or delete working copies within 10 calendar days after acceptance, subject to the MSA retention and legal-hold provisions. Record deletion evidence and any retained category.
Termination, unfinished work, liability, notices, California governing law and disputes follow MSA sections 9 through 13. Project escalation does not replace formal notices.

8. Synthetic approval record
Alex, authorized Cedar signatory: approved October 12, 2026.
Dana, authorized Harbor signatory: approved October 12, 2026.
Attachments: Input List v1; Mapping Specification v1; access list v1.
Example only: these are fictional approvals, not real signatures.

Here, correcting the baseline defect is part of meeting the agreed criteria, rather than a new four-record expansion. The response records an operational failure under this example's wording; it does not decide every remedy that might be available under a real contract. Our vendor-obligation facts record helps preserve the actual promise, delivery and response.

Review dates and invoice dates are separate

In this scenario, the kickoff invoice is received October 12: adding 30 calendar days gives November 11. If the accepted-package invoice is received October 24, payment falls due November 23. Do not count the receipt date as day one when using this example's date-addition convention. The October 22 review deadline does not make the final invoice payable. Likewise, “two business days” needs a holiday calendar and counting rule; the example deliberately uses calendar days, so its October 24 response can fall on a Saturday.

Record a scope change separately

Suppose Cedar requests four additional records for $800. The request alone leaves the baseline at 24 records and $6,000. If authorized approval is later given, record the new 28-record scope, $6,800 total and revised delivery date. If the $2,000 kickoff amount remains unchanged, the final milestone becomes $4,800. Preserve whether approval is pending, rejected or effective.

Change CR-01, proposed only
Baseline: SOW 01 v1, 24 records, total $6,000
Requested addition: four identified records
Proposed addition to fee: $800
Proposed revised delivery date: [agree before approval]
If approved: 28 records, total $6,800; final milestone $4,800
Approvers / approval evidence / effective date: [not yet completed]
Status: pending; baseline remains in force under this example's agreed procedure

Use the amendment template when the change needs that form. Actual modification rules depend on the agreement and governing law; this proposed workflow does not decide the effect of different real-world conduct or communications.

Completed alternative, if CR-01 is approved: assume Alex and Dana sign on October 25, after baseline acceptance, for new IDs R025 through R028. Record the expanded deliverable due October 28, review October 30, and no change to the already earned baseline acceptance milestone. The additional $800 is invoiceable only on acceptance of the four-record extension. This staged option totals $6,800 through invoices of $2,000, $4,000 and $800. It is different from revising an unearned final milestone to $4,800. Do not quietly replace an already earned invoice trigger with a new one.

CR-01 v2, fictional approved extension
Baseline: SOW 01 v1 accepted October 24; USD 6,000.
Addition: R025 through R028, same format and checks, no new columns.
Price: USD 800, separate acceptance milestone; total USD 6,800.
Delivery: October 28, 17:00 UTC. Review: October 30, 17:00 UTC.
Failure correction: one calendar day after criteria-specific notice; retest response the following calendar day.
Authorized approvals: Alex and Dana, October 25, 2026.
Effective: both approvals recorded; SOW 01 v1 plus CR-01 v2.
Status: approved in this alternative scenario. Original acceptance evidence retained.

Check the SOW against the governing agreement

Before signature, compare each project term with the identified MSA version. Resolve any conflict through its actual priority and amendment provisions, and state precisely any authorized exception. Do not assume that a later SOW automatically replaces an earlier agreement.

Check that acceptance and payment terms fit the MSA, security terms cover the work, and ownership provisions address both new deliverables and existing materials. Link versions and attachments in the contract repository. Hand the approved criteria, invoice triggers and authority map to the people handling contract administration.

Ownership, security and termination need operative terms

Delivery is not an IP assignment. For US copyright, 17 USC section 201(a) and (b) set initial ownership and the distinct work-made-for-hire rule. Do not assume paying a contractor makes every deliverable a work made for hire. 17 USC section 204(a) requires a signed writing for a transfer of copyright ownership other than by operation of law. Identify the rights owner, assigned work, timing and background-material license in the operative documents. This copyright point does not decide ownership of every data field, patent or third-party component.

For security, replace “industry standard protection” with the agreed systems, access roles, data categories, approved locations, subprocessors, incident contacts and evidence. Identify whether personal data is permitted and which processing terms apply. A promise to keep information confidential does not specify how data will be processed, backed up or deleted. Different privacy and sector laws have different triggers; this template supplies fields, not a universal compliance warranty.

Termination should connect to the MSA's actual rights, notice method and settlement provisions. Decide how unfinished deliverables, prepaid amounts, accepted milestones and approved expenses are handled. At closeout, transfer files and credentials through approved channels, record open defects, remove access, return or delete data and identify permitted retained records. Do not make deletion conflict with a legal hold or agreed backup retention.

Adapt the structure to the project

• Software and implementation: name environments, integrations, test data, migration reconciliation, performance limits, source files and release authority. Separate production deployment from acceptance if different people approve them.
• Consulting and creative work: define report or asset formats, rounds of revision, client feedback dependencies, use rights and final editable-file handover. A new creative direction can differ from correction against the approved brief.
• Construction or equipment: add site readiness, drawings, permits, safety responsibilities, commissioning evidence and the applicable sector contract. This service-export example does not supply those terms.
• Recurring support: define service hours, severity, response versus resolution, monitoring evidence and agreed remedies. Avoid using completion of a one-time project as the sole measure of an ongoing service.
• Government procurement: follow the actual solicitation, contract and agency process. FAR 8.405-2(a) and (b) specify SOW contents for the Federal Supply Schedule services within that provision's scope, including location, performance period, deliverable schedule, standards and special requirements. Those requirements do not automatically govern private purchases.

Before-signing checklist

• Both legal parties and the governing agreement are identified.
• Scope, exclusions, dependencies and attachments have precise versions.
• Each deliverable has a format, due date, reviewer and testable criteria.
• Correction, retest, review delay and partial acceptance are addressed.
• Payment triggers, due dates, taxes and expenses are consistent.
• Change approval authority and effects on price and timing are clear.
• Security, data, ownership, support and termination terms fit the project.
• Document priority and signatory authority have been checked.
• The approved version and subsequent decisions will remain retrievable.

Frequently asked questions

What should a statement of work include?

Parties, purpose, scope and exclusions, deliverables, responsibilities, dates, acceptance criteria, fees, change control and approval. Reference or add the general terms needed for the particular relationship.

Can I use this template in Word or PDF?

Yes. Copy the template into your document editor, complete its fields and attach the specifications. Export the agreed version if needed. This page provides copyable text; it does not claim a separate downloadable file.

Is a SOW automatically a binding contract?

This operational template does not determine a project's enforceability. Review the completed terms, assent, incorporation, authority and governing law for the actual transaction. The filled example assumes an executed MSA rather than supplying those general terms.

Does the SOW override the master agreement?

Check the actual priority and amendment provisions. Identify the precise conflict and any authorized exception instead of assuming that the newer document controls.

What is the difference between a defect and new scope?

Compare the delivered work with the baseline criteria. In this example, supplying missing R024 corrects an agreed deliverable. Adding four new records expands it and needs the agreed change process.

Who should write and approve the SOW?

The project owner and provider should develop the scope with the people who can validate technical requirements, budget, security and legal terms. Record who can accept delivery and who can authorize commercial changes. Approval by the first group does not necessarily confer the second authority.

How detailed should the SOW be?

Detailed enough for another reviewer to identify the included output, run the agreed checks and trace the payment trigger. Reference a versioned technical specification rather than duplicating it inconsistently. Phase uncertain work instead of pretending later requirements are settled.

Can an email change the SOW?

Check the agreement's change mechanism, authority and applicable law. This example requires its specified signed change record. An ordinary project email is not treated as that approval in the example; the legal effect of different real conduct remains a separate question.

Does the customer own everything after payment?

Do not infer that from payment alone. Check the assignment or license, background materials, third-party rights and the separate treatment of client data. The US copyright formalities explained above are one relevant issue, not a complete ownership analysis.

What happens if the client does not review on time?

Use the agreed escalation or deemed-acceptance mechanism. This example escalates and requires express acceptance. If you choose deemed acceptance, specify complete submission, notice, review opportunity, exclusions and its effect on defects and payment.

Can this template be used in the UK or India?

The operational fields can help organize a project, but this page does not establish enforceability or local tax, IP, data or procurement requirements in those jurisdictions. Its legal illustrations use expressly scoped US federal sources; the fictional project selects California law without analyzing its local requirements. Use appropriate local governing terms rather than importing their legal rules.

Sources

Primary legal and official procurement materials inspected October 6, 2026. The private-service templates and scenarios are original editorial examples.

• FAR 37.602, Performance work statement: measurable results in US federal procurement.
• FAR 37.601(b): federal performance-based services, standards and assessment methods; FAC 2026-01.
• FAR 37.603(a): measurable federal performance standards; FAC 2026-01.
• FAR 46.501 to 46.503: federal acceptance, responsibility and location, subject to contract terms; FAC 2026-01.
• FAR 8.405-2(a) and (b): SOW content for covered Federal Supply Schedule services; FAC 2026-01.
• Oregon DOT, SOW Writing Guide for Personal Services, form version March 2, 2021, pages 3 to 4 and 7 to 9: deliverables, recurring work and phases; guidance for its own procurement context.
• Texas DIR, Statement of Work Process, checked October 6, 2026: project elements and transition considerations; state program scope.
• 17 USC section 201(a) and (b), official 2024 edition, PDF page 1: initial copyright ownership and work-made-for-hire rule; cross-checked with the Copyright Office's current chapter text.
• 17 USC section 204(a), official 2024 edition, PDF page 1: signed writing for specified copyright transfers; cross-checked with the Copyright Office's current chapter text.
• US Copyright Office, Copyright Law chapter 2, checked October 6, 2026: cross-check of sections 201 and 204.

By Anirudh Menon, Viaclause editor. General information. The banner is an AI-generated illustration of fictional people.