A software house MSA: connecting orders, billing and IP

A customer wants two developers now, a fixed-price integration next and monthly maintenance afterwards. If every assignment requires renegotiating the entire contract, sales and delivery will soon start holding each other up.

A Master Services Agreement, or MSA, establishes shared rules for the relationship. Individual orders, often called Statements of Work (SOWs), define the assignments. The combination should let you accept further work, bill under the appropriate model and grant the agreed rights without reopening the full negotiation each time.

What this article covers

Shared rules and individual orders

Use the MSA for ordering procedures, confidentiality, liability, baseline payment and IP mechanisms, and dispute resolution. Use each SOW for the service itself: scope, team, dates, pricing, billing model, acceptance criteria and departures from the framework.

Set a document hierarchy. If a SOW can override the MSA, decide how explicitly it must identify an override and who can approve it. Otherwise, a passing note in an order may become a dispute about responsibility for the whole project.

Shared rules do not require identical orders. Suppose a software house develops an application on an hourly basis and delivers a separate integration for a fixed fee. Both can sit under the same MSA, with different payment and acceptance mechanisms.

T&M, fixed price and staff augmentation need different terms

Under time and materials (T&M), payment typically follows agreed rates and work performed. Define time reporting, review of timesheets, budget limits and who can authorise tasks. State whether an estimate is indicative or a binding cap.

Under fixed price, the fee covers an agreed scope. Define its boundaries, acceptance criteria, customer dependencies and change pricing. Otherwise, each new feature request can return as an argument about what was supposedly included.

For staff augmentation, sometimes called body leasing, establish who manages tasks, how people are made available, replacement arrangements and the supplier’s responsibilities. The label does not determine the legal classification. Actual supervision and working arrangements also need employment-law review, including any applicable temporary agency work rules.

Keep payment out of an endless acceptance loop

Identify what triggers invoicing and how specific objections must be raised. For T&M, that may be a work report. For a defined deliverable, it may be a milestone submission and acceptance process. A signed protocol should not be the only route if the contract says nothing about customer silence.

Distinguish defects from new requirements. Define what an objection must contain, which defects prevent acceptance and how undisputed work is paid. Charging by the hour does not remove responsibility for performing agreed obligations properly.

Return to the fixed-price integration. The customer must provide API access and test data, but supplies them late. The SOW should address the resulting effect on dates and any agreed team standby costs. A final deadline without those dependencies can turn a planning issue into a breach dispute.

Match IP to the work that actually exists

Separate customer-specific deliverables, the supplier’s existing tools and libraries, and third-party components. The customer may need rights to develop and commercialise the product while the software house needs to reuse its framework on other projects. Define those boundaries rather than promising ownership of everything.

Specify which deliverables are assigned, when the assignment takes effect and how versions are identified. If transfer depends on payment, address use before settlement and partial payment. Releases, repositories and work reports should help identify what has been delivered and billed.

Implementation depends on the governing law. Under Polish law, copyright assignment requires written form for validity and the fields of exploitation must be expressly listed (Copyright Act, Articles 41 and 53, in Polish). An order email or an “approve” click alone does not replace that form. Reconcile the ordering mechanism with the assignment formalities. The IP due diligence checklist covers the wider chain of title.

Do not promise to assign third-party or open-source rights as your own. Establish component-use rules and licence information for the customer. Check whether rights obtained from subcontractors support the promises made in the MSA.

Review liability alongside the annexes

A reasonable-looking cap can be undermined by broad carve-outs, cumulative penalties and additional commitments in a security annex. Read these provisions together and against the nature and value of the orders.

There are limits to contractual freedom. For example, Polish law does not permit exclusion of liability for intentionally caused damage (Civil Code, Articles 353¹ and 473 § 2, in Polish). There is no single cap suitable for every engagement. Where maintenance or security is involved, connect liability to the SLA and security acceptance criteria.

What happens to open orders when the MSA ends?

Decide whether terminating the framework also ends active assignments or only prevents new ones. Cover work in progress, access, documentation and final payment. Specify which rights and obligations survive.

For the supplier, this supports team planning and collection of payment due. For the customer, it supports taking over the deliverables and continuing the project without negotiating every account and file again.

Key points

• The MSA sets shared rules; each SOW defines its scope, price and delivery model.
• T&M, fixed price and staff augmentation need appropriate reporting, acceptance and responsibility arrangements.
• Link invoicing to recorded work and a defined objection process.
• Separate customer IP, reusable components and third-party material, and observe assignment formalities.
• Address termination of the framework and individual orders separately.

In our IT supplier engagement example, a signed agreement enabled paid work with agreed ordering, billing and IP rules. Connecting delivery to the contract is the starting point for our IT contract support.