Master Service Agreement vs Statement of Work in India

Why this structure matters

A single service agreement may be enough for a one-time, simple engagement. But if the relationship is ongoing, multi-project, phase-based, or likely to evolve, a single agreement can become too rigid or too vague. If every project requires a fresh full agreement, the process becomes slow. If the parties rely only on proposals and invoices, the legal position may be incomplete. The MSA plus SOW model solves this problem. The MSA acts like the master rulebook. It says how the parties will generally work with each other. The SOW acts like the project card. It says what is being done now. A business can sign one MSA and then issue multiple SOWs for separate projects, product modules, campaigns, locations, clients, phases, retainers, or support services. For example, a digital agency may sign an MSA with a client covering confidentiality, IP, payment defaults, liability caps, termination, and dispute resolution. Then it may issue separate SOWs for website development, SEO services, social media management, paid advertising, landing page design, and monthly reporting. Each SOW has different deliverables and pricing, but the legal framework remains consistent.

What belongs in the MSA

The MSA should contain the clauses that apply across the relationship regardless of the specific project. These include the identity of the parties, service ordering process, how SOWs are created, how fees are invoiced, confidentiality, intellectual property ownership, licence rights, data handling, compliance obligations, warranties, limitation of liability, indemnity, termination rights, consequences of termination, dispute resolution, governing law, jurisdiction, notices, assignment, subcontracting, force majeure, and survival clauses. The MSA should also create a hierarchy of documents. This is essential. If the MSA says one thing and the SOW says another, which document controls? A well-drafted agreement may state that the MSA controls general legal terms, while the SOW controls project-specific commercial details, unless the SOW expressly states that a particular clause is intended to override the MSA. Without this hierarchy, inconsistent documents create avoidable disputes. The MSA should not contain highly specific project details that change frequently. If the master agreement is overloaded with deliverables, timelines, and pricing for one project, it becomes less useful for future work. The MSA should be stable enough to support multiple SOWs.

What belongs in the SOW

The SOW should be operationally precise. It should define the project, scope, deliverables, formats, milestones, timeline, acceptance criteria, client responsibilities, dependencies, assumptions, fees, payment schedule, reimbursable expenses, revision rounds, change request process, and project contacts. A good SOW should make it easy for both business and delivery teams to understand what must happen. For software work, it may include features, modules, technical stack, integrations, testing responsibilities, deployment support, bug-fix windows, source code handover, and documentation. For marketing work, it may include number of posts, campaign deliverables, ad account access, reporting frequency, creative formats, approvals, and exclusions. For consulting work, it may include sessions, reports, templates, implementation support, and timelines. The SOW should also state what is excluded. Exclusions are not negative; they are protective. If API integration, copywriting, hosting, content upload, maintenance, travel, paid media budget, design source files, legal compliance review, or third-party costs are not included, the SOW should say so. Many disputes arise not because the parties are dishonest, but because each side silently assumes something different.

Scope creep and change control

Scope creep is one of the most common problems in Indian service relationships. A client may ask for "small changes" that become new features. A founder may request an additional dashboard, API, workflow, report, or integration after the price is fixed. A brand may ask for extra creative options, urgent revisions, or additional campaign formats without approving additional fees. An MSA and SOW should include a change control process. This can be simple: any material change in scope, deliverables, timeline, assumptions, or fees must be recorded in writing through a change request, revised SOW, email approval, or signed addendum. The change request should describe the change, additional fee, timeline impact, and dependencies. This does not mean every tiny correction needs a legal document. The agreement can allow ordinary revisions within the defined scope. But when the change affects cost, time, deliverables, responsibility, or risk, it should be captured. This protects both sides: the vendor is not forced into unpaid work, and the client gets clarity on what is being purchased.

Payment structure in MSA and SOW

The MSA may state general payment principles such as invoice timing, taxes, TDS, late payment consequences, suspension rights, dispute process, and reimbursement rules. The SOW should state the actual fee for that project, whether payment is advance, milestone-based, monthly, retainer-based, or completion-based. For agencies and consultants, milestone-based payment often reduces risk. For ongoing services, monthly advance payment or monthly invoicing may be appropriate. For development work, the SOW should avoid making all payment dependent on vague final satisfaction. It is better to link payments to measurable milestones, submissions, approvals, or completion of defined phases. The agreement should also handle disputed invoices. If the client disputes part of an invoice, should the undisputed portion still be paid? What is the deadline for raising invoice objections? Can services be suspended after non-payment? These details are especially important for MSMEs, freelancers, agencies, and professional service businesses.

IP ownership in MSA and SOW

IP ownership should be handled with precision. The MSA may state the general principle: client-owned deliverables, vendor-owned pre-existing materials, third-party materials subject to their licences, and limited rights for tools, templates, libraries, know-how, or reusable components. The SOW may identify specific deliverables and any special IP treatment. For example, in a software SOW, the client may own the custom code developed specifically for the project after full payment, while the vendor retains ownership of pre-existing frameworks, generic modules, libraries, and know-how. In a branding SOW, the client may receive ownership of final approved logo files after full payment, while unused concepts remain with the agency. In a consulting SOW, the client may receive internal business use rights to reports and templates, but not the consultant's underlying methodology. This separation avoids over-transfer and under-transfer. The client gets what it needs. The service provider protects its reusable assets.

Termination across MSA and SOW

Termination must be drafted at both levels. The MSA may allow termination of the overall relationship. The SOW may allow termination of a specific project without ending the entire MSA. This distinction is important where multiple projects run simultaneously. The agreement should explain whether termination of the MSA automatically terminates all active SOWs, whether SOWs continue until completed, what happens to unpaid fees, what transition support is required, what deliverables must be handed over, and which clauses survive termination. Confidentiality, IP, payment, limitation of liability, indemnity, dispute resolution, and data return obligations usually survive.

Indian legal context

In India, an MSA and SOW are generally governed by contract law principles. The Indian Contract Act, 1872 sets the foundation for valid contracts, performance, breach, damages, and consequences of non-performance. If time is made essential for a deliverable, the agreement should handle timelines carefully. If electronic approvals are used, the agreement should recognize email, digital signature, and other written approvals where appropriate. The practical legal issue is not only whether the contract exists. The question is whether the documents, read together, clearly prove scope, responsibility, price, and breach. A well-structured MSA and SOW reduce ambiguity and create a better evidentiary record if a dispute arises.

Common drafting mistakes

Common mistakes include using an MSA without any SOW process, using SOWs that contradict the MSA, failing to define document hierarchy, leaving acceptance criteria vague, ignoring client dependencies, failing to list exclusions, transferring all IP without identifying pre-existing materials, using no change control process, and failing to state what happens to active SOWs when the MSA ends. Another mistake is treating the proposal as marketing material and the agreement as legal material. In reality, the proposal often becomes evidence of scope. If the proposal, invoice, email, and agreement conflict, the dispute becomes harder. A good MSA-SOW system aligns all documents.

How Inamdar Legal can assist

Inamdar Legal assists with drafting MSAs, preparing SOW templates, reviewing client-provided MSAs, redlining vendor contracts, preparing change request language, structuring IP clauses, aligning payment and acceptance terms, and creating practical contract systems for repeat service businesses. The objective is to create documents that the legal team, founder, account manager, delivery team, and client can actually use.

When to Review This

• MSA and SOW document hierarchy
• Scope, acceptance, and change control
• Payment, IP ownership, and project terms
• Termination across master and project levels