Master Services Agreements and Statements of Work

By Hank FasthoffJuly 6, 2026

A master services agreement (MSA) can state the recurring terms of a commercial relationship without committing either party to a particular project. Each statement of work (SOW) can then authorize defined services, deliverables, fees, and dates. This structure reduces repeated negotiation only when the documents identify when an obligation begins, which terms apply to each project, how the parties approve changes, and what happens when the documents conflict.

The contract in James Construction Group, LLC v. Westlake Chemical Corp., 650 S.W.3d 392 (Tex. 2022), used the same basic structure. That contract imposed no duty to offer or accept services until both parties executed a work order. Litigation over performance turned on administrative terms in the contract. Because the contract required written notice as a condition of specified remedies, oral notice failed to satisfy that condition.

Several Documents Can Form One Agreement

Texas law treats a document incorporated by reference as part of the agreement as though its terms appeared in the signed contract. TotalEnergies E&P USA, Inc. v. MP Gulf of Mexico, LLC, 667 S.W.3d 694 (Tex. 2023), applied that principle to arbitration rules incorporated into a commercial agreement. You can use the same principle to incorporate an executed SOW. A precise incorporation clause identifies the MSA, the parties, and the project to avoid a dispute over which version applies.

Incorporation language isn't the only way several writings can form one contract. Copano Energy, LLC v. Bujnoch, 593 S.W.3d 721 (Tex. 2020), recognized that courts may read several documents together, even when the parties signed them at different times and the documents don't refer to one another. The writings must contain the essential terms and show an intent to be bound. In Copano, the emails described terms for future negotiations, and no writing showed agreement to be bound by those terms. You gain a stronger record by controlling versions because scattered emails and attachments can complicate a dispute over contract formation.

Your MSA can state whether either party has an obligation before an SOW becomes effective. It can also identify the required approval, whether electronic signatures qualify, and whether a purchase order serves only an administrative purpose. A customer or provider can introduce competing terms through a purchase order if the contract leaves its legal effect unresolved.

The MSA Addresses Recurring Terms

An MSA usually addresses terms expected to apply across projects. Those terms may include invoicing procedures, confidentiality, information security, intellectual property defaults, indemnity, insurance, liability limits, dispute resolution, notices, suspension, and termination. The allocation depends on the relationship. A project involving regulated data, licensed technology, or unusual insurance may require an SOW amendment or a separate exhibit.

A complete MSA separates payment mechanics that apply across the relationship from the price for each project. It can state invoice timing, payment deadlines, taxes, expense rules, disputed invoice procedures, and late payment consequences. Each SOW can state fixed fees, hourly rates, milestones, usage charges, or another pricing method for the services it authorizes.

When one MSA governs several SOWs, a complete liability provision defines how its limits apply. A cap based on fees paid under the agreement can produce a different result from a cap based on fees paid under the affected SOW or during the preceding 12 months. The contract can also address whether related claims under several SOWs share one cap and whether indemnity, confidentiality, security, or intellectual property claims receive different treatment.

Each SOW Defines the Authorized Project

A complete SOW identifies the services, deliverables, schedule, fees, dependencies, assumptions, and responsibilities for that project. You can define scope through exclusions as well as inclusions. If the customer must provide data, approvals, system access, personnel, or equipment, the SOW can connect each dependency to its effect on timing and price.

Deliverables and services require separate descriptions. A provider may perform discovery, configuration, development, testing, training, or support while producing software, reports, designs, or documentation. A precise SOW distinguishes obligations that require a stated result from obligations that require performance of described services.

Realistic dates account for dependencies and approval periods. A calendar deadline can become unworkable when the customer controls access or feedback needed for performance. The SOW can state which dates are fixed, which depend on a preceding event, and how an excused delay affects subsequent milestones.

Acceptance Requires Objective Criteria

A complete acceptance process identifies which deliverables require review, the criteria used for review, the review period, and the response to a valid rejection. A rejection notice can identify the unmet criterion with enough detail for correction. The contract can then provide for correction, another review period, a fee adjustment, or termination when repeated efforts fail.

The review period has to fit the deliverable. Ten days may be adequate for a report and inadequate for an enterprise implementation that requires integration testing. Deemed acceptance can provide finality when a customer fails to respond, but the contract can distinguish silence from productive use, partial use, and use required for testing.

Acceptance, warranty, and payment address different issues. Acceptance confirms conformity at a defined review point. A warranty can cover defects discovered after acceptance, while payment provisions determine when an invoice becomes due. If you combine all three into one sentence, a test failure can produce an argument over payment and warranty rights.

Intellectual Property Requires More Than an Ownership Label

Your MSA can state default ownership rules, while an SOW identifies the deliverables, provider tools, customer materials, licensed components, and project exceptions. A client ownership model distinguishes an assignment of deliverables from a license to technology that the provider owned or developed outside the project. A provider ownership model defines the customer's license by users, purpose, territory, duration, transfer rights, and access to embedded tools.

Copyright transfers require a signed writing under 17 U.S.C. Section 204(a). For a valid work for hire, 17 U.S.C. Section 201(b) treats the employer or commissioning party as the author and initial owner. Commissioned material receives that treatment only when the arrangement satisfies the definition in 17 U.S.C. Section 101. The legal mechanism has to fit the deliverable and provide the licenses needed for any retained materials embedded in it.

Software projects also require treatment of open source components, code from third parties, data, models, and artificial intelligence tools. The documents can allocate responsibility for approvals, notices, source code obligations, training uses, output review, and restrictions imposed by another provider's terms.

Order of Precedence by Subject

If you provide that the MSA always controls, you may defeat an intentional exception in an SOW. If you provide that every SOW controls, a project document may alter indemnity, liability, security, or dispute terms through an unnoticed sentence. A more precise provision assigns priority by subject and states how an SOW may depart from an MSA default.

For example, the MSA may govern legal and administrative terms while the SOW governs scope, deliverables, fees, schedule, and acceptance for its project. If an SOW may change an MSA provision, it can identify the affected section and state that the change applies only to that SOW. This method distinguishes a deliberate exception from an accidental inconsistency.

In TotalEnergies, inconsistent dispute provisions across related agreements increased the expense. The parties responded to a $41 million demand with proceedings before a state court and two arbitral bodies under three contracts. Although the case concerned arbitration rather than an MSA and SOW, coordinated forum and dispute terms across related documents reduce that risk.

Scope Changes Require Defined Authority

A complete change procedure identifies who may request a revision, who may approve it, what information the request must contain, and when revised services may begin. Price, schedule, staffing, dependencies, deliverables, and acceptance criteria often require review together. Authorization by a project manager may differ from authority to amend the MSA.

Written amendments provide the strongest record, especially when the MSA makes a writing a condition of payment or another remedy. James Construction held that substantial compliance couldn't satisfy a written notice condition without a writing. Emails, tickets, meeting notes, and revised project plans may document events, but they may fail a contractually required method or omit the resulting price and schedule.

A no oral modification or nonwaiver provision reduces uncertainty without eliminating every waiver argument. In Shields Limited Partnership v. Bradberry, 526 S.W.3d 471 (Tex. 2017), the Supreme Court of Texas recognized that parties may waive a nonwaiver provision through conduct inconsistent with it. The Court enforced the clause because the contract excluded acceptance of late rent as a basis for waiver, and the landlord did nothing inconsistent with that term. Consistent use of the change procedure provides stronger protection than language ignored during performance.

Termination Must Distinguish the Relationship From the Project

Ending an MSA doesn't automatically end every active SOW unless the contract provides that result. The documents can state whether an outstanding SOW continues under the MSA after notice of nonrenewal or termination without cause. They can also address whether a material breach affecting one project permits termination of that SOW, every SOW, or the entire relationship.

Project termination provisions can address completed services, committed costs, transition assistance, unfinished deliverables, refunds, customer data, access credentials, and return of property. The MSA can identify obligations that continue after either document ends, including payment, confidentiality, licenses, audit rights, indemnity, liability limits, and dispute procedures.

Contract Administration and Version Control

The MSA and SOW model depends on consistent administration. A complete SOW identifies its number, effective date, MSA date, amendments, exhibits, and authorized signers. A central record can show active SOWs, remaining commitments, approved changes, invoices, acceptance decisions, notices, and termination dates.

The trigger for an MSA review is a change in the relationship instead of an invented project count or calendar rule. New service types, regulated data, larger fees, use of artificial intelligence, entry into another jurisdiction, or a different risk allocation may justify an MSA amendment. A focused SOW can handle a true project exception, while a recurring change goes into the terms that govern future projects.

Parties receive the intended benefit from the MSA and SOW structure when the documents divide responsibility with precision. The MSA states the recurring rules, each SOW authorizes a defined project, and the administration record shows which terms governed when the parties performed.