How to Review a Statement of Work (SOW) in India

A Statement of Work, usually just called an SOW, is the document that carries the actual work under a Master Services Agreement: what gets built, by when, for how much, and how anyone will know it is done. The MSA sets the rules of the relationship once. The SOW is where those rules meet a real project, and most disputes start here, not over liability caps or governing law, but over whether "the dashboard" the vendor delivered is the dashboard the client asked for, and who pays for the gap.

Adira, which publishes this guide, makes contract review and CLM software, so we have a commercial interest in you reviewing SOWs more carefully. The explanation below stands on its own regardless. If you want to mark up one SOW by hand today, Weave, Adira's free browser tool, lets you do that without an account.

What an SOW does, and why scope creep lives here

An MSA is deliberately generic, built to work for the tenth project as well as the first. An SOW is the opposite: specific to one piece of work, and that specificity is the point. A good SOW answers four questions precisely enough that a stranger could read it and know what was promised: what gets delivered, by when, on what does that depend, and how does anyone confirm it is done.

Scope creep is not really a drafting failure. It is what happens by default when an SOW is vague enough that "can we just add X" has no clear answer, so the answer becomes whatever the two people on the call that week agree to. Every clause below closes one version of that gap.

Deliverables and specifications: the certainty problem

This is where most SOWs fail first, and it is a legal problem, not just a project-management one. "Develop a CRM integration as discussed" is not a scope, it is a placeholder for a conversation neither side can point back to once there is a disagreement. A workable deliverables clause names what is being built, in what format, against what specification or acceptance criteria, ideally in a schedule or annexure the SOW body simply references.

The Indian position. Indian contract law has a general rule that reaches this exact problem. Section 29 of the Indian Contract Act, 1872 says:

"Agreements, the meaning of which is not certain, or capable of being made certain, are void." Source: Section 29, Indian Contract Act, 1872 (Indian Kanoon)

An SOW that describes deliverables only in outcome language, "a scalable, user-friendly platform", with no functional spec and no measurable criteria, risks exactly this: not that the whole MSA falls apart, but that the specific obligation has no fixed content a court can hold either side to. Section 29 does not require poetic precision. A clause with a mechanism for fixing its own detail, a referenced spec document, named test cases, is not vague even if the spec runs to fifty pages. What fails is language with no such mechanism at all.

A runnable test: open the deliverables section and ask, for each item, could someone with no context on the project tell from the document alone whether it was delivered? If the answer depends on asking the project lead what they actually meant, the clause has a certainty problem before it has anything else.

Milestones and dependencies

Milestones convert a single delivery date into a sequence, and dependencies are where timeline disputes usually originate: a milestone slips not because the vendor is behind, but because the client was late providing an API key, test data, or sign-off. A workable clause states, per milestone, the deliverable, the date, and any client-side dependency, with an explicit rule that client delay extends that milestone date by the same number of days. Without it, "time is of the essence" language elsewhere can leave a vendor technically in breach for a delay the client caused.

Acceptance criteria and deemed acceptance

This is the clause that decides the exact moment a delivery stops being "work in progress" and becomes something the client has approved, which usually triggers the payment milestone and starts the warranty clock. Most SOWs pair a defined test process with a deemed-acceptance fallback: if the client does not reject within a stated window, the deliverable is treated as accepted whether or not anyone actually reviewed it.

For contracts involving goods, Sections 41 to 43 of the Sale of Goods Act, 1930 set the statutory baseline, including Section 42's default that a buyer is deemed to accept goods "after the lapse of a reasonable time" without a rejection notice. A pure software or services SOW sits outside that Act, so acceptance mechanics depend entirely on what the SOW itself says. Our full acceptance and deemed-acceptance guide covers the statute, a December 2025 Bombay High Court ruling on when using part of a delivery counts as accepting the whole thing, and a bad-to-better rewrite. For an SOW specifically, check three things: the review window is matched to what is actually being reviewed, a cure-and-re-test right exists after a rejection, and running acceptance tests is expressly carved out from counting as the "use" that triggers acceptance.

Change control: where scope creep either gets stopped or doesn't

An SOW without a defined change process does not prevent changes, it just means changes happen off the record. A client's project lead emails "can we just add X," a vendor's delivery lead replies "sure," and six weeks later nobody agrees on the extra invoice or the pushed-out date, because nothing was ever signed.

Section 62 of the Indian Contract Act, 1872 confirms that parties can alter a contract by agreement, written or not, "the original contract need not be performed" once they do. That is exactly why a change-control clause matters: Indian law will not stop an informal change from binding you, it only decides how hard that change is to prove later. Our variation and amendment clause guide covers Section 62, the evidentiary rule that follows it, and a 2025 Supreme Court case on inferring a waiver from conduct. For an SOW, the practical fix is a numbered Change Order process: a written Change Request Form stating the price and timeline impact, a response deadline after which the request lapses (silence should end it, never count as acceptance), and a signed Change Order referencing the SOW it amends before work begins.

Assumptions and exclusions: what the SOW does not promise

Every SOW rests on assumptions the vendor is not stating as deliverables but is quietly relying on: timely client feedback, that existing systems being integrated with are stable and documented, that a named third-party API stays available. Left unstated, these do not vanish. They become an argument after something goes wrong about who should have known better.

Indian courts do not readily read an unstated assumption into a contract for you. In Nabha Power Limited v Punjab State Power Corporation Limited, (2018) 11 SCC 508, decided by the Supreme Court of India on 5 October 2017, the Court set a five-fold test before any term can be implied into a commercial contract: it must be reasonable and equitable, necessary to give business efficacy to the contract, so obvious it goes without saying, capable of clear expression, and not contradict any express term. The Court was explicit that a business-efficacy implication only steps in where a plain reading cannot achieve what the parties, as prudent businessmen, intended, and that a court should not readily rewrite the bargain actually struck. Read the judgment on Indian Kanoon.

Do not assume an unstated assumption will be implied in your favour. If price and timeline depend on the client supplying test data within five days, or an existing API staying available, say so expressly, with a stated consequence if it turns out wrong. An exclusions list, work the SOW does not cover, third-party licence costs, infrastructure the client must separately provide, does the same job for scope on the other end.

Fees: fixed price versus time-and-materials

A fixed-price SOW ties the fee to defined deliverables, so scope changes must go through change control to change the price. A time-and-materials (T&M) SOW bills for actual hours or resources, honest about uncertain scope but needing a stated cap or not-to-exceed figure, or the client is signing an open-ended bill. Many real SOWs are hybrid: fixed price for a well-defined first phase, T&M for exploratory work after.

Check payment terms against the vendor's MSME status. Section 15 of the MSMED Act, 2006 caps payment to a registered micro or small enterprise supplier at forty-five days from acceptance regardless of what the SOW says, and Section 16 imposes compound interest at three times the RBI-notified bank rate, "notwithstanding anything contained in any agreement between the buyer and the supplier." A blanket net-60 term in the parent MSA does not survive contact with a Section 15 supplier here. See our full payment terms guide for the mechanics and the Silpi Industries Supreme Court case on when MSME registration has to exist.

IP in SOW deliverables

Check whether the SOW's IP language, or the MSA's if silent, actually assigns ownership of what is built under this engagement, rather than leaving it to a licence. Silence does not default to ownership. Most disputes are not about the IP clause being missing, it is usually present in the MSA, but about whether it reaches SOW-specific deliverables built on a vendor's pre-existing tools. A workable SOW confirms the MSA's IP clause covers these deliverables unmodified, or expressly carves out and licenses back any named "Background IP." See our IP assignment explainer for why silence on duration and territory does not default to permanent, worldwide ownership.

Precedence: does the SOW or the MSA win on a conflict

An SOW that varies the MSA's price or timeline terms is normal, that is what SOWs are for. An SOW that quietly varies the MSA's liability cap or indemnity scope, because a sales team negotiated a client-specific term into it with no legal review, is a different problem, and it turns on what the MSA's precedence clause says an SOW is allowed to change. Our guide to reviewing an MSA covers the precedence clause in full, including a bad-to-better rewrite. For this SOW, check whether it references the MSA section it is varying, if any, or whether it silently repeats or contradicts a term that was never meant to move.

Red flags table

Normal	Red flag	Why it matters
Deliverables reference a spec, schedule, or defined acceptance criteria	Deliverables described only in outcome language	Risks a Section 29 certainty problem; both sides can honestly disagree on whether it was delivered
Milestones state client-side dependencies with an automatic extension for client delay	Milestone dates fixed regardless of client-caused delay	Vendor can end up technically in breach for a delay the client caused
Acceptance window matched to complexity, with a cure-and-re-test right	Deemed-acceptance window unrealistically short, no cure right	A defect nobody had time to find gets waived by silence
Numbered Change Order process, with a response deadline and signed record before work begins	No defined change process; changes happen by email or verbal go-ahead	Scope and price drift with nothing either side can point to later
Assumptions and exclusions stated expressly, with a consequence if one fails	Assumptions left unstated, relying on them being "obvious"	Nabha Power's five-fold test means a court will not readily imply what you failed to write down
T&M fees carry a stated cap or not-to-exceed figure	T&M with no cap at all	Client is signing an open-ended bill
Payment terms checked against supplier MSME status	Blanket net-60/net-90 with no MSME carve-out	Sections 15 and 16 of the MSMED Act override contrary terms automatically
SOW confirms which MSA clauses it varies, by section reference	SOW silently repeats or contradicts MSA risk terms	Creates a conflict the MSA's precedence clause may not have anticipated

Bad clause versus better clause: deliverables and acceptance

Bad: "Vendor shall develop and deliver a customer support portal for Client, integrated with Client's existing systems, to a high standard of quality. The portal shall be deemed accepted five (5) days after delivery unless Client notifies Vendor in writing of any defect."

What is wrong: "a high standard of quality" and "integrated with Client's existing systems" are not testable specifications, so there is a real Section 29 certainty problem underneath what looks like a normal sentence. Five days is not enough to test a portal integration properly, and there is no cure right if a defect is found.

Better: "Vendor shall develop and deliver the customer support portal described in Schedule A (the 'Deliverable'), including the functional specification, integration points with the systems named in Schedule A, and the acceptance test cases set out in Schedule B. Client shall have fifteen (15) business days from delivery to test the Deliverable against Schedule B and either accept it in writing or provide written notice of specific non-conformities. Vendor shall remedy any notified non-conformity within ten (10) business days and resubmit for a further five (5) business day review. If Client does not reject within the applicable review period, the Deliverable is deemed accepted. This Statement of Work assumes Client will provide API credentials and test data for the systems named in Schedule A within five (5) business days of Vendor's written request; a delay beyond this shall extend the corresponding milestone date by an equal number of days."

What changed: naming Schedule A and B as the actual specification, rather than descriptive language, closes the Section 29 gap. A cure-and-re-test cycle means a first failed test is not fatal. The stated assumption about client-provided credentials, with a consequence for delay, moves an unstated risk into an express term Nabha Power's five-fold test would not have implied for you.

The SOW review checklist

1. Do deliverables reference a spec, schedule, or defined acceptance criteria, not just outcome language?
2. Does each milestone name its client-side dependencies, with an automatic extension for client-caused delay?
3. Is the acceptance review window matched to what is being tested, with a cure-and-re-test right?
4. Is there a numbered Change Order process, with a response deadline and a signed record before change work begins?
5. Are assumptions and exclusions stated expressly, with a consequence if one turns out to be wrong?
6. If fees are time-and-materials, is there a stated cap or not-to-exceed figure?
7. Does payment account for the vendor's MSME status and the Section 15 forty-five day cap?
8. Does the IP clause reach these deliverables, and are pre-existing tools carved out and licensed back?
9. Does the SOW state which, if any, MSA clauses it varies, by section reference?
10. Is it signed by someone with authority to bind each party, and does it name the MSA it sits under, with date?

US and global contrast

US-style SOWs share the same basic shape, deliverables, milestones, acceptance, fees, under an MSA, but two things differ. US contracts routinely rely on "work made for hire" language to vest IP in the client automatically; Indian law has no general equivalent, so a reused US template can leave IP ownership weaker than intended without an actual assignment clause. And American commercial practice leans more heavily on trade usage and course of dealing to fill SOW gaps than Indian courts do after Nabha Power's five-fold test, which makes express drafting of assumptions more important in an Indian-law SOW, not less.

FAQ

Is an SOW a separate contract, or part of the MSA? Structurally a separate, shorter document, but it only has legal effect because it is executed under a named MSA, which supplies risk terms, liability, IP, confidentiality, the SOW does not repeat. Check that it names the MSA it sits under, with date.

Can an SOW override the MSA's liability cap or IP terms? Only if the MSA's precedence clause allows it. Some MSAs let an SOW vary named provisions if it references the section being varied; others treat the MSA as controlling on risk terms regardless. Read the precedence clause first.

What is the difference between a change order and simply signing a new SOW? A change order amends an existing SOW, keeping its structure and prior milestones intact except for what it changes. A new SOW is a fresh, standalone scope. Use a change order for an in-flight engagement, a new SOW for genuinely separate work.

We are mid-project and the client keeps adding small requests informally. What should we do? Route every request, however small, through your Change Order process before doing the work. Under Section 62 of the Contract Act, an informal exchange can still bind you to a variation; the problem is proving later what was agreed, which a signed Change Order avoids.

Does a fixed-price SOW mean the price can never change? No, it means price does not change without going through change control. Scope, timeline, or assumption changes outside the original Schedule A should trigger a Change Order with a stated price impact, not a silent absorption of extra work.

This guide explains how SOWs are generally structured under Indian law, and the specific statutory points, Section 29 on certainty, the MSMED Act's payment timelines, and the Nabha Power test for implied terms, that most templates get wrong. It is not legal advice, and it does not tell you whether your specific SOW's deliverables are certain enough, whether an assumption you left unstated would be implied in your favour, or whether your SOW is safe to sign as drafted. For that, especially before a high-value or long-running engagement, have a lawyer review the actual document.