What Is a Statement of Work (SOW) and Why It Matters for Your Business Contracts?

A lot of business disputes start the same way. One side thinks the project included extra tasks, the other says those tasks were never agreed. A deadline slips, invoices are challenged, and everyone starts searching old emails to work out what was actually promised.

This is where a statement of work, usually called an SOW, matters. New Zealand businesses often make three avoidable mistakes here: relying on a proposal instead of a proper scope, using vague language like “support as needed”, and signing a supplier’s standard terms without checking how the SOW fits with the main contract. Those mistakes can lead to payment disputes, scope creep, delay claims, and damaged commercial relationships.

A well-drafted SOW spells out what is being delivered, when, by whom, and on what assumptions. It helps when you are hiring a contractor, engaging an agency, outsourcing a tech build, or delivering staged services to a client. The guide below explains what an SOW does, how it interacts with your contract, what to check before you sign, and the common traps that catch founders and SMEs.

Overview

A statement of work is the practical document that turns a commercial deal into clear deliverables, dates, responsibilities, and acceptance criteria. It usually sits under a master services agreement, services agreement, consultancy agreement, or contractor arrangement, and it is often the document people rely on most when a project goes off track.

The key question is not just whether you have an SOW, but whether your SOW is detailed enough to prevent arguments before work begins and flexible enough to manage changes during the project.

• Define the exact services, deliverables, milestones, and deadlines.
• State what is excluded, not just what is included.
• Set out assumptions, dependencies, and client responsibilities.
• Match payment terms to milestones, time-based fees, or acceptance stages.
• Explain how variations, extra work, and delays will be approved.
• Confirm which document wins if the SOW and the main contract conflict.
• Include sign-off or acceptance criteria so completion is measurable.
• Check liability, intellectual property, confidentiality, and termination terms across the full contract pack.

What What Is a Statement of Work Sow and Why It Matters for Your Business Contracts Means For New Zealand Businesses

A statement of work gives commercial detail to your legal agreement. For many New Zealand businesses, it is the document that decides whether a project runs smoothly or becomes a costly disagreement.

An SOW is not usually a stand-alone legal concept with one fixed statutory definition. In practice, it is a contract document that describes the specific work to be done under a broader agreement. You might see it attached as a schedule, signed as a separate work order, or issued as one of several project-specific statements under a master agreement.

What an SOW usually includes

A useful SOW should make the practical deal clear enough that someone outside the project could read it and understand what each side has agreed to do.

• The parties involved and the project name or reference.
• A description of the services or work.
• Deliverables, outputs, or milestones.
• Timing, deadlines, project phases, or service periods.
• Pricing, fee structure, invoicing triggers, and expenses.
• Client obligations, such as providing access, approvals, materials, or staff.
• Assumptions and dependencies.
• Acceptance testing, review periods, or sign-off criteria.
• Change request or variation process.
• Any project-specific intellectual property, data handling, security, or confidentiality requirements.

How an SOW differs from a proposal or quote

A proposal or quote often helps win the work. An SOW is the document that should define the work after the deal is agreed. Founders often rely on a sales deck or email thread, but those documents usually do not deal properly with exclusions, change control, acceptance, or risk allocation.

If you are reviewing a contract before you sign with a client or provider, do not assume the quote does the same job as an SOW. A quote may state price and broad deliverables, but it often leaves gaps around timing, quality standards, dependencies, and what happens if the scope changes.

Why SOWs matter in day-to-day business

The value of an SOW is practical. It gives both sides a shared reference point when decisions need to be made quickly.

For example, if you are engaging a software developer, the SOW might say whether the work includes discovery, design, integrations, testing, migration, post-launch support, and training. If those points are not set out clearly, the provider may charge extra for tasks the customer assumed were included.

If you run a marketing agency, consultancy, engineering business, creative studio, or managed services provider, an SOW can also protect your margins. It stops informal requests from quietly expanding the project without an agreed fee uplift or timeline adjustment.

How SOWs interact with New Zealand contract law

In New Zealand, the usual contract principles still apply. The main issue is whether the documents, read together, clearly record offer, acceptance, agreed written terms, and intention to create legal relations.

An SOW will usually be interpreted with the main agreement. That means you need to read both together, especially where one document deals with commercial scope and the other deals with legal risk. If they conflict, the order of precedence clause matters. This clause says which document overrides the other when there is an inconsistency.

That point matters because many disputes are not about whether work was requested, but about which document controls. A supplier may point to general exclusions in the main agreement, while the customer points to broad project language in the SOW. If the contract pack does not state which document takes priority, the argument gets harder and more expensive.

When a New Zealand business should use an SOW

You should consider using an SOW whenever services are detailed, staged, customised, or likely to change over time. It is especially useful where the relationship is ongoing and the parties expect to commission separate pieces of work under one umbrella agreement.

• Software development and implementation projects.
• Marketing retainers and campaign work.
• Consulting and advisory services.
• IT support, managed services, and system integrations.
• Construction-adjacent commercial services, design work, or specialist subcontracting.
• Recruitment, training, content production, and project-based professional services.

For simple one-off services, a short services agreement may be enough. But if the project has multiple stages, dependencies, third-party inputs, or changing requirements, an SOW usually adds clarity that the basic contract cannot carry on its own.

Legal Issues To Check Before You Sign

The safest time to fix an SOW is before work starts. Once the project is moving, commercial pressure often pushes businesses to “sort the paperwork later”, and that is where founders often get caught.

Scope and exclusions

The main legal and commercial risk is ambiguity. If a task is not clearly in or out, you are leaving room for disagreement.

Your SOW should define scope in plain language and separately identify exclusions. That is especially important before you accept the provider's standard terms or before you rely on a verbal promise made during sales discussions.

• Name each deliverable with enough detail to test whether it has been completed.
• State any work that is expressly excluded.
• Describe assumptions, such as the client providing content, access, approvals, or subject matter experts.
• Clarify whether revisions, meetings, travel, maintenance, support, or training are included.

Timing, milestones, and delays

A delivery date on its own is not enough. You need to know what happens if information arrives late, a dependency fails, or the customer changes direction halfway through.

A better SOW breaks timing into milestones and links those milestones to dependencies and approvals. If dates are estimates only, say that clearly. If delays caused by the customer extend the timeframe or increase fees, say that too.

Fees, invoicing, and variations

Payment terms should match the commercial reality of the project. A fixed fee project needs different contract drafting from a time and materials engagement.

• State whether fees are fixed, capped, hourly, daily, milestone-based, or usage-based.
• Explain when invoices can be issued and when payment is due.
• Set out how additional work is priced and approved.
• Clarify what counts as a reimbursable expense.
• Deal with partial completion, suspension, and cancellation.

If the SOW is silent on changes, extra work often gets done first and argued about later. A simple written variation process can save a lot of friction.

Acceptance criteria and sign-off

If you cannot measure completion, you cannot easily enforce payment or reject poor work. Acceptance criteria are one of the most overlooked parts of an SOW.

For service deliverables, acceptance may be based on objective criteria, agreed specifications, testing outcomes, or a review period. For creative work, you may need to define the number of revisions included and what counts as a change in brief rather than a defect.

Intellectual property

Ownership of project outputs should never be left to assumption. This matters particularly for software, designs, training materials, reports, databases, and branded content.

The SOW should work with the main contract to answer several questions.

• Who owns newly created material?
• Does ownership transfer only after full payment?
• Does the provider keep ownership of pre-existing tools, templates, code libraries, or know-how?
• What licence does the customer receive for background materials?
• Can either party reuse generic, non-confidential learnings or components?

If the project involves brand assets or product names, trade mark issues may also arise, especially where a provider is creating names, logos, or campaign concepts for the customer.

Privacy, confidential information, and data handling

If the work involves personal information, the Privacy Act 2020 may be relevant. The SOW should say what data is being accessed, why it is needed, and what security or handling standards apply.

This is common in HR tech, customer databases, analytics projects, outsourced admin, and software support. Even where a detailed privacy notice or privacy clause sits in the main contract, the SOW should still identify project-specific data flows and responsibilities.

Liability and remedies

The SOW does not usually carry all liability terms on its own, but it can create project-specific risk. For example, a delayed website migration, failed integration, or inaccurate business-critical report can have real knock-on effects.

Before you sign, check that the liability regime in the main agreement makes sense for the project described in the SOW. Think about liability caps, exclusions for indirect loss, service credits, re-performance obligations, and termination rights if milestones are missed.

Consumer law and fair dealing issues

Some business services in New Zealand may still be affected by laws around fair dealing, misleading representations, and service quality. The Fair Trading Act 1986 can apply to business conduct and representations made during negotiations. If the work is supplied to a consumer or in a context where consumer protections are relevant, the Consumer Guarantees Act 1993 may also need consideration.

That does not mean every B2B SOW is governed by consumer protections. But it does mean your scope descriptions, claims about performance, and marketing promises should line up with what the contract actually delivers.

Common Mistakes With What Is a Statement of Work Sow and Why It Matters for Your Business Contracts

The most common SOW mistakes are not technical drafting errors. They are practical gaps that show up when a live project gets messy.

Using vague scope language

Words like “support as required”, “full implementation”, or “end-to-end service” sound helpful in a sales conversation, but they are risky in a signed document. They create room for broad expectations without clear limits.

A better approach is to define tasks, outcomes, assumptions, and exclusions with enough detail that each side can test what is in scope.

Failing to separate included work from extra work

This is where margins disappear. A founder wants to keep the client happy, agrees to one or two extras, and then the whole project expands beyond the quoted price.

Your SOW should state what happens when the client requests additional work, changes priorities, or needs a faster turnaround. If no written approval is required for variations, it becomes much harder to recover extra fees.

Ignoring the relationship between the SOW and the main contract

An SOW on its own is rarely enough. If the main agreement says one thing and the SOW suggests another, you need to know which document prevails.

This often matters for intellectual property, payment timing, liability caps, and termination rights. Businesses sometimes spend time refining the scope but forget to check whether the main contract undercuts their commercial position.

Leaving acceptance too subjective

“Client satisfaction” is not a reliable completion test. If sign-off depends only on a general sense that the customer is happy, payment can be delayed indefinitely.

Use objective milestones, agreed review periods, or measurable specifications wherever possible. If feedback is not provided within a set time, the deliverable may be deemed accepted, provided that fits the deal and is drafted clearly.

Relying on emails and calls to fill the gaps

Verbal promises and scattered email approvals create evidentiary problems. People remember conversations differently, and project teams change.

Before you sign, or at least before you spend money on setup and delivery, pull the agreed points into one signed contract pack. That usually means the main agreement, the SOW, and any approved variation documents.

Forgetting operational detail

Some of the most expensive disputes come from basic project management points that were never written down.

• Who provides access to systems and premises?
• Who approves drafts, and within what timeframe?
• Who attends workshops or testing?
• What happens if a third-party provider causes delay?
• What information or materials must the client supply?

These points can feel administrative, but they often determine whether the provider can meet deadlines and whether delay fees or extensions are justified.

Copying an old SOW from another project

Templates are useful, but every project has its own risk profile. A copied SOW may contain the wrong assumptions, the wrong fee model, or deliverables that do not match what was actually sold.

This is especially risky for growing SMEs that are moving from informal service work into larger, staged projects with subcontractors, software integrations, or regulated data handling.

FAQs

Is a statement of work legally binding in New Zealand?

It can be, if it forms part of a valid contract and is properly agreed between the parties. In practice, an SOW is often binding because it is signed, attached to a signed agreement, or incorporated by reference into the main contract.

Do I need both a services agreement and an SOW?

Often yes. The services agreement usually sets the legal framework, such as liability, confidentiality, termination, and dispute rules. The SOW then sets the project-specific scope, timing, fees, and deliverables.

What is the difference between an SOW and a scope of works?

They are similar ideas, and businesses use the terms differently. “Statement of work” is common in commercial services and consulting, while “scope of works” often appears in trade, construction, or project delivery contexts. The real issue is whether the document clearly defines the work and how it fits into the contract.

Can an SOW be changed after signing?

Yes, but the contract should say how changes are approved. A written variation or change request process is the safest approach, especially where the change affects price, deadlines, deliverables, or risk allocation.

What should I do if the other side sends a very short SOW?

Do not assume the gaps will sort themselves out. Ask for more detail on scope, exclusions, timing, fees, acceptance, and responsibilities before you sign. It is usually much easier to negotiate clarity early than to argue about it after work starts.

Key Takeaways

• A statement of work is the project-specific document that defines what will be delivered, when, for how much, and on what assumptions.
• It matters because vague scope, missing exclusions, and unclear sign-off processes are common causes of contract disputes.
• An SOW usually works alongside a main services or contractor agreement, so both documents need to be read together.
• Before you sign, check scope, milestones, pricing, variation rules, acceptance criteria, intellectual property, privacy, and liability settings.
• The best SOWs deal with real founder issues, such as scope creep, extra work, client delays, and inconsistent verbal promises.
• If the project is customised, staged, or likely to change, a detailed SOW can save time, money, and commercial strain later.

If you want help with scope drafting, variation processes, intellectual property terms, liability clauses, you can reach us on 0800 002 184 or team@sprintlaw.co.nz for a free, no-obligations chat.