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

What is a statement of work in Canada, and when do you need one? A statement of work (SOW) in Canada is the document that describes a specific piece of work: what will be delivered, by when, to what standard, and for how much. It usually sits under a master services agreement (MSA) that already sets the standing legal terms, so the SOW can focus on the project detail without repeating the whole contract. On its own an SOW can also be a short standalone contract for a single engagement. You need an SOW whenever you define a project rather than an open-ended relationship. It is common for IT and software delivery, consulting, design and creative work, construction and professional services. The SOW is where scope lives, which is why unclear SOWs are the usual cause of scope creep, payment disputes and missed deadlines. ## Is an SOW a contract in Canada? It depends on how it is set up. - Under an MSA, the SOW is not a full standalone contract. It incorporates the MSA's terms and adds the project detail. The MSA governs matters such as liability, IP and confidentiality, and the SOW governs scope, schedule and price. A good MSA includes an order-of-precedence clause so everyone knows the MSA wins unless the SOW expressly overrides a named term.

• Standalone, an SOW signed with offer, acceptance and consideration (in the common law provinces) or by the exchange of consent (in Quebec, under the Civil Code of Quebec) can itself be a binding contract. If you use an SOW this way, it needs the legal terms an MSA would normally carry. As with all Canadian contracts, name a governing province, because contract law is provincial and the common law provinces and Quebec treat contracts differently. ## What goes in a Canadian statement of work? | Section | What it covers | | --- | --- | | Background and objectives | Why the work is being done and the outcome sought | | Scope of services | The specific tasks and what is in and out of scope | | Deliverables | The concrete outputs, each described and dated | | Acceptance criteria | How a deliverable is tested and approved | | Timeline and milestones | Dates, phases and dependencies | | Roles and responsibilities | Who does what, on both sides | | Fees and payment schedule | Fixed price, time and materials, or milestone-based, plus GST/HST | | Assumptions and dependencies | What the plan relies on, such as client inputs | | Change control | How scope changes are requested, priced and approved | | Governing document | The MSA it sits under, and order of precedence | ### Scope and acceptance The two sections that prevent most disputes are scope and acceptance. Write scope as specific tasks and name what is out of scope, not only what is in. For each deliverable, state the acceptance criteria and a review window, so approval is objective rather than a matter of opinion. Pair this with a change control clause, so new requests are priced and approved rather than absorbed for free. ### Fees, payment and tax State the pricing model clearly: fixed price, time and materials with rates and an estimate, or payment on milestones. Add the invoicing cycle, any late-payment interest, and that GST or HST, and provincial sales tax where it applies, are added to the fees. The Canada Revenue Agency sets the GST/HST rules. ### Intellectual property If the SOW stands alone rather than under an MSA, address IP in the SOW itself. Under the federal Copyright Act the author is usually the first owner, and a contractor is not an employee, so the client does not own the deliverables automatically. Assign the IP in writing where the client needs ownership, and include a moral rights waiver. ## A simple Canadian statement of work template (structure) 1. Project title, parties and effective date

2. Reference to the governing MSA (if any) and order of precedence
3. Background and objectives
4. Scope of services (in scope and out of scope)
5. Deliverables and acceptance criteria
6. Timeline, milestones and dependencies
7. Roles and responsibilities
8. Fees, payment schedule, expenses and taxes
9. Assumptions and client dependencies
10. Change control process
11. Project-specific terms (IP, confidentiality, data) if standalone
12. Signatures ## Common mistakes to avoid - Vague scope with no out-of-scope list, which invites scope creep.

• No acceptance criteria, so deliverables are approved on feeling, not fact.
• No change control, so every new request becomes a free extra.
• A standalone SOW that forgets the legal terms an MSA would normally carry, such as IP and liability.
• Treating GST/HST and provincial tax as an afterthought in the fees. ## Doing this across many projects An SOW is rarely a one-off. A busy provider or client runs many at once, each referencing an MSA, each with its own milestones, acceptance windows and change orders. Managed in scattered documents, it is hard to see which SOW is current, whether a change order was signed, or what was actually delivered. The drafting, clause review, version history and milestone tracking can sit in one AI contract workspace tuned to how your company contracts. Adira is one such workspace. Its legal depth is strongest for India today, with Canadian-law support on the roadmap, so use it as a drafting and review aid rather than a substitute for Canadian legal advice. ## Is this legal advice? No. This is general information, not legal advice. Whether an SOW is a standalone contract or a schedule under an MSA changes its legal effect, and contract law differs across the provinces and Quebec. For a specific project, confirm the position with a qualified Canadian lawyer. ## Frequently asked questions