Limitation of Liability Clause for Freelance Software Developers

Start Here With a Fast, Defensible Contract Position#

Start by setting the structure, not just a number. Liability terms allocate risk, so your first move is to define how risk is organized before you negotiate the cap amount. Use these terms consistently from round one:

• Baseline position: what is excluded entirely, what is capped, and what is carved out.
• General cap: the contractual maximum exposure for claims inside the main limitation.
• Separate risk track: a way to handle excluded loss categories and monetary exposure as distinct drafting decisions.
• Fallback: a pre-approved alternative you can offer if your primary term is rejected.

Use a one-sentence opening#

Open with one clear line: you want defined excluded losses, a general cap for ordinary breach exposure, and any genuinely higher-risk issue handled on a separate track. Then run this pre-negotiation mini-playbook before redlines:

1. Map where disputes are likely to start. Check scope, acceptance, payment, and termination together. Define acceptance as acknowledgment that delivered services meet contract requirements, then state when acceptance occurs in your deal, such as at delivery, after testing, or after a review window.
2. Set the contract stack before debating percentages. State which documents form the agreement and the order of precedence if MSA and SOW terms conflict.
3. Route pushback by issue. If the client pushes for a higher cap, identify the driver and address that issue on a separate risk track when appropriate.
4. Prepare one fallback before the call. Keep exact replacement language ready so you are not drafting high-impact liability text live.

Decide the sequence before the cap number#

A practical red flag is any request to raise the cap before there is agreement on which claims it covers. Commentary on Drax Energy Solutions Limited v Wipro Limited ([2023] EWHC 1342 (TCC)) treated the clause as a single aggregate cap, with discussion that a pleaded £31m claim could be limited to £11.5m under the wording. The point is not that one cap model always wins. It is that cap mechanics should be explicit in the clause and coherent across the full contract set.

Keep a negotiation record you can defend#

Keep one evidence pack: the latest draft, issue log, approval notes, and fallback language. Update it each round when you send comments, receive revised language, or approve concessions. If someone else cannot reconstruct the negotiation history from that file set, tighten the record before you proceed.

In practice, that means the file set should let a reviewer answer four questions without digging through email chains: what your starting position was, what changed, who approved the change, and where the final wording landed. Use a simple operating rule: for every material liability move, save the marked-up draft, the clean draft, and the note that explains why the change was accepted or rejected. If the other side introduces a new carve-out or changes a cap formula input, log it as its own issue rather than burying it in general redline traffic.

After you settle structure, you can use the SOW generator to keep project documents aligned.

Limitation of Liability Has Two Levers You Must Control#

Treat this as two separate approvals: first, which loss categories are excluded or allowed, and second, how the monetary cap applies to claims that remain.

If you approve those as one blended decision, you can end up with a clean headline cap but broader exposure in the clause details. That is why the loss buckets come first and the money discussion comes second.

Define the loss buckets before you debate money#

Use plain language, but tie every internal example to the exact contract labels:

• Direct loss under English law is commonly framed as loss arising naturally from the breach itself.
• Consequential or indirect loss under English law is not a universal label and depends on the legal and contractual context.
• Incidental damages in a UCC sales context can include reasonable breach-related expenses such as inspection, transport, custody, and cover costs.
• Consequential damages in general legal usage can mean damages claimed as a consequence of the defendant's actions, but the meaning still depends on governing law and drafting.

These buckets do not have one universal meaning across jurisdictions or contract types. If your clause excludes "indirect, incidental, or consequential" loss, your working examples should use those same terms and fit the governing law and contract context.

Before you negotiate the cap, add two short notes beside the clause: expected excluded examples and expected claimable examples.

• If those examples cannot be mapped cleanly to the draft wording, pause and tighten the language first.

A useful discipline here is to test your examples in one sentence each. If you say a cost should be excluded, point to the actual label in the clause that excludes it. If you say a cost should remain claimable, point to the wording that keeps it inside the core remedy set. That simple exercise flushes out negotiation shorthand that sounds aligned but is not yet in the paper.

Run a cross-clause review, not a clause-only review#

A consequential-damages waiver can fail in practice when another clause puts the same exposure back in. Review the full contract set, including the main agreement, order forms, and attachments, in this order:

Focus on defined-term consistency across documents. Losses, Damages, Claims, and Liability should operate the same way everywhere.

Do this as a document sequence, not as a memory exercise. Start with the liability clause, then move clause by clause through each recovery path and write a yes, no, or unresolved note next to each one. If a payment clause says amounts are recoverable "notwithstanding any other provision," or a schedule uses broader recovery language than the MSA, fix that immediately. You are looking for paths that let the same loss category re-enter under a different label.

Test the cap structure before signoff#

Your second approval is how the cap behaves across multiple claims.

Commentary on Drax Energy Solutions Limited v Wipro Limited [2023] EWHC 1342 (TCC) described the clause as a single aggregate cap, with discussion of a pleaded £31m claim being limited to £11.5m under wording tied to 150% of charges in the preceding twelve months. The practical point is simple: make the cap model explicit and keep the rest of the contract aligned to it.

Escalate pushback by decision, not by volume#

Do not concede both levers at once:

• Hold structure when the other side wants a higher number before excluded categories and cap mechanics are settled.
• Offer a targeted fallback when pushback is tied to one named risk, such as IP indemnity or a specific service failure.
• Mark unresolved when broad loss language remains in indemnity, SLA, payment, or termination terms and no clear interaction with the cap is documented.

Keep one evidence pack to control late-stage drift: redlines, issue log, approval notes, and the latest clean copies of the main agreement, order form, and attachments. That record helps you catch cap logic that gets diluted or contradicted in later drafts.

For a step-by-step walkthrough, see How to Write a Limitation of Liability Clause for a Freelance Contract.

Choose the Liability Cap Structure Before You Negotiate Price#

Decide the cap structure before you settle fees. The cap is part of the commercial deal, and if you leave it to the end, you risk pricing work on assumptions the legal wording does not support.

Use the terms precisely#

• Aggregate cap: one total liability ceiling across all covered claims.
• Per-claim cap: separate caps can apply claim by claim instead of one contract-wide ceiling.
• Stacking risk: exposure that arises when claim limits are treated as cumulative rather than as one net total cap.
• Carve-out drift: exceptions to disclaimers or caps expand during negotiation and reduce the cap's practical protection.

These definitions affect price and risk. Commentary on Drax Energy Solutions Ltd v Wipro Ltd [2023] EWHC 1342 (TCC) describes drafting that supported competing readings. The clause used a 150% cap tied to charges in the preceding twelve months. Outcomes were discussed as around GBP11.5 million under a single total cap or around GBP23 million under a separate-cap reading, against a claimed GBP31.7 million exposure. If your clause can support both readings, your pricing assumptions are not reliable yet.

Pick a cap model from deal facts, not instinct#

Before any negotiation call, confirm these inputs in order:

1. Contract shape: Is this one defined SOW or an MSA with repeated or evolving work? If the cap is meant to cover the main agreement and all SOWs together, confirm that wording across the full contract set.
2. Scope clarity: Tighten deliverables, acceptance, and dependencies first. Vague scope can turn delivery disagreements into liability fights.
3. Change control: Make sure extra work is documented, priced, and approved in writing. Weak change control can make it easier for disputes to be framed as multiple claims, increasing stacking risk.
4. Payment model: Match the cap mechanics to fixed fee, milestones, or time and materials. If the formula uses charges or fees, confirm the fee base and lookback period before pricing.

Bring a cap position sheet, not just a redline#

Go into the call with a one-page cap position sheet: first position, approved fallback, and walk-away trigger. Align three internal owners before negotiation: pricing, delivery, and legal risk approval.

Then run one document-level check on the latest clean set: the MSA, every SOW or order form, and any SLA attachment. The Drax commentary shows why this matters, including wording tied to "this Agreement (including all Statements of Work)" and analysis referencing seven related SOWs. Cap behavior can drift if you review only the liability clause in isolation.

That sheet should do more than repeat the draft clause. It should show the cap model you are willing to sign, the formula inputs that must stay fixed, the carve-outs you can accept, and the issues that require internal approval before movement. If the commercial team is using one assumption and legal is negotiating another, you are not ready for the call. The sheet is there to keep those assumptions synchronized.

If the client pushes back, consider moving non-cap levers first: reporting discipline, cure periods, narrower carve-outs, clearer service-credit mechanics, and specific remediation language. Then revisit the cap number with pricing, delivery, and legal aligned.

We covered this in detail in Structuring a Limitation of Liability Clause for OpenAI API Client Work.

Set Uncapped Carve-Outs and Indemnification Without Blowing Up Risk#

Once you choose the cap structure, the next pressure point is what sits outside it. Liability terms are often negotiated late, and late-stage problems can come from carve-outs and indemnity wording that reopen exposure you never priced.

Separate the two risk decisions#

A liability clause allocates risk between the parties. An indemnity is a separate promise to cover specified losses, often tied to third-party claims, and it can include defense and settlement costs.

If you blend those decisions, indemnity language can move losses outside the general cap treatment. A third-party indemnity is a common example. It usually addresses outside claims, not an automatic remedy for direct breach claims between you and the client.

Use one drafting test for every proposed carve-out#

Before you accept any uncapped category, run the same four-part test:

This is a drafting discipline, not a statutory rule. If the wording does not pass this test in plain English, it is too broad. Also keep misconduct language tight. Some deals make wilful misconduct uncapped, but the result still depends on the wording and the facts.

A quick practical check is to ask whether the clause can be administered by the deal team without guesswork. If you cannot tell from the text whether a claim belongs in the general cap, a separate cap, or an uncapped bucket, the drafting is still carrying litigation risk. The same is true if the clause says one thing about a claim type and the indemnity says something broader about the same conduct.

Compare carve-outs in one table before trading redlines#

Use a fixed pushback order: narrow claim type first, then causation, then discuss cap treatment. For each disputed carve-out, document one fallback before the call, whether that is a narrower trigger, different cap treatment, or third-party-only indemnity scope.

Run one cross-document red-flag pass before signature#

Review limitation text, indemnity text, and related schedules together across the MSA and every SOW. This is where exposure can re-enter through inconsistent definitions or broader recovery language in attachments.

Use a direct check: align terms like indemnify, defend, hold harmless, losses, claims, and liabilities across all documents. If carve-outs are closed in the limitation clause but reopened in an SOW or schedule, the cap is weaker than it looks.

Finally, test mutuality by real control, not mirrored wording. Mirrored language can still leave one side carrying risks it cannot meaningfully prevent. Keep exceptions narrow, defined, and synchronized across the full contract set.

When you do this pass, compare the promise, the remedy, and the procedure separately. The promise is what conduct triggers liability. The remedy is what losses are recoverable and where the cap applies. The procedure is who controls defense, settlement, notice, and cooperation. Late-stage problems can surface only when those three pieces are read together.

Make MSA and SOW Language Consistent So the Cap Actually Works#

Your cap may not protect you as intended if the MSA, SOW, and attachments use different liability logic. If one document reads as a single aggregate cap, another reads as per-claim, or an attachment changes the cap base or covered parties, interpretation risk increases and exposure can expand.

Lock the terms that decide the outcome#

A Single Aggregate Cap is one overall limit across all claims. A Per-Claim Cap can apply separately claim by claim. Treat cap-base wording the same way. paid and payable can produce different cap outcomes when your contract uses a specific formula such as charges paid or payable in a defined lookback period.

Check covered parties explicitly. If the clause is framed as the supplier's liability to the customer, do not assume affiliates, subcontractors, or personnel are included unless they are expressly named.

Reconcile the signed stack side by side#

Use a cold-read test: if a first-time reader cannot tell which document controls and when, the drafting is not ready.

Apply go/no-go rules before pricing or signature#

Accept an SOW variance only when it is deliberate, priced, and explicitly tied to the same cap architecture. Amend before signature if the variance changes cap structure, cap-base wording (paid vs payable), covered parties, or conflict rules. Pause the deal if document control is unclear.

Drax v Wipro is the cautionary example. Interpretation of the liability cap was litigated as preliminary issues. Competing aggregate and per-claim readings had textual support, and the court read related clauses to resolve meaning. If your documents conflict, interpretation risk becomes your problem.

Operationally, treat any SOW variance as a separate approval event. Mark the exact sentence that departs from the MSA, note whether the change affects price or only wording, and confirm whether the same departure appears anywhere else in the stack. If you allow one local variation in an SOW, make sure later SOWs do not silently copy it without review.

Close with execution discipline#

• Reconcile the final liability text in the signed MSA, signed SOWs, and signed attachments, not email intent or draft comments alone.
• Store executed documents, redlines, approvals, and a final liability term map in one evidence pack.
• After liability terms are aligned, hand off to governing law, jurisdiction, and dispute-resolution alignment so the remedy path is coherent end to end.

Lock Down Governing Law, Jurisdiction, and Dispute Resolution Early#

Lock these terms before final pricing and signature, or you can spend the first phase of a dispute fighting about forum and process before you reach liability outcomes. Treat each lever as its own control:

• Governing law: which law applies to the contract.
• Forum selection: which court location will hear the dispute.
• Court jurisdiction: that court's power over the parties.
• Arbitration scope: which disputes are sent to arbitration.
• Arbitration rules: which procedural rules control the case.
• Arbitration seat/locale: where arbitration is based or held.
• Delegation: whether gateway arbitrability questions go to the arbitrator.
• Pre-dispute steps: whether mediation is required first, or can run concurrently.

Before signature, use these go or no-go checks:

• One governing law across the full contract stack.
• One dispute path in one fixed sequence.
• No SOW, schedule, or termination clause that reopens different remedies, venues, or escalation steps.

Also run this pre-signature red-flag checklist:

• Compare the signed MSA, each signed SOW, and signed attachments side by side.
• Confirm governing law is identical across all documents.
• Confirm the court versus arbitration path is identical across all documents.
• Confirm pre-dispute steps are consistent, including whether they are mandatory first steps or concurrent processes.
• Confirm termination and carve-out language does not bypass the agreed dispute path.

If wording conflicts across documents, interpretation risk becomes your problem. The same caution from Drax v Wipro applies here: inconsistent drafting across the contract stack can force contextual interpretation disputes before you ever reach the merits.

Use Practical Negotiation Scripts for Pushback on Liability and Indemnification#

Handle pushback as clause drafting, not as a fairness debate. Answer briefly, then move to paper. Name the lever before you negotiate it:

• Liability cap: the maximum exposure a party accepts under the contract, subject to agreed exceptions.
• Uncapped carve-out: a liability category left outside the general cap.
• Indemnification scope: usually third-party claims, not direct losses between you and the client.
• Duty to defend: the indemnifying party funds and manages defense for covered claims; whether it must be explicit can vary by jurisdiction.
• Payment holdback: temporary withholding of otherwise payable amounts, so trigger, amount, and release mechanics should be explicit.

Objection to response table#

Concede in the right order#

Concede in this sequence:

1. Tighten process first: reporting cadence, response windows, cooperation, and cure mechanics.
2. Narrow carve-out wording second: tighten trigger, causation, and claim type.
3. Move the cap last, only after scope is fixed.

Use walk-away triggers when the draft breaks your risk model:

• uncapped exposure for ordinary breach,
• indemnity expanded to client direct losses,
• defense duty without control rights,
• open-ended payment holdback.

Get to text and close the paper#

After each call, close to text immediately:

1. Send same-day redlines.
2. Update your fallback-language tracker.
3. Run a final cap-versus-indemnity drift check across the MSA and every SOW before signature.

A good operating habit is to send the follow-up in issue order, not in the order the conversation happened. Lead with the items that change exposure, attach exact replacement wording, and identify which points are agreed, open, or subject to internal approval. Final check question: did the cap stay in place while indemnity scope expanded? That keeps the next draft from blurring a concession on process into a concession on monetary exposure.

This is not theoretical. In Drax Energy Solutions Limited v Wipro Limited [2023] EWHC 1342 (TCC), the court had to construe whether wording tied to 150% of charges paid or payable in the preceding twelve months created one aggregate cap or multiple caps across an MSA and 7 SOWs. On that cap-construction issue, a £31m pleaded claim could be limited to £11.5m. Treat that as a drafting signal: rely on final aligned text across the full contract stack, not verbal alignment in negotiation.

This pairs well with our guide on How to Use an Indemnification Clause to Limit Your Liability.

Run Sanity Checks Before Signature and at Termination Events#

Your liability position is strongest when the signed documents and offboarding steps match what you negotiated. Two common failure points are version control before signature and notice or survival execution at termination.

Before signature, review the full contract stack, not just the signature packet: MSA, every SOW, schedules, order forms, product terms, and any incorporated or referenced documents. Confirm the contract's order of precedence from the signed language instead of assuming one document controls.

Use this pre-signature checklist:

1. Collect the full set and list every incorporated document by name.
2. Confirm hierarchy and resolve any conflict between MSA, SOW, schedules, order forms, and product terms.
3. Reconcile cross-references so cap, indemnity, dispute, and defined-term references point to the right clauses.
4. Check governing law and dispute resolution separately as two distinct fields.
5. Verify version integrity by comparing the clean final contract to the last approved redline. If you cannot confirm the match, do not sign.

This is also the right moment to do a line-by-line compare between the execution copy and the last approved negotiation draft. Do not assume a clean copy is safe because no changes are visible on the face of the document. A misplaced cross-reference, a missing schedule, or inconsistent wording can change the liability position even when the signature block looks ready.

At termination or offboarding, run a decision checklist from the signed text:

1. Survival: what obligations and claims survive, and for how long? Record the survival period after verification.
2. Notice mechanics: what notice clause applies, what triggers it, and what timing window does it set? Record that window from the executed contract.
3. Delivery validity: who must receive notice, at which address, and by which method.
4. Ownership: identify the deal-specific owner for each action and deadline.
5. Tracking: where each action item, send date, and proof of delivery is logged.

For tracking, keep the log practical. Record the document, clause reference, required action, owner, deadline, send method, recipient, and proof location. That way, if a later dispute turns on whether notice was valid or whether a survival obligation was preserved, you have the operational record ready and not just the signed paper.

A practical evidence pack to archive includes: signed agreement set, final redlines, clean-versus-redline comparison, approval emails, finalized term map, and any termination or breach notices sent. Final quality gate before signature or closure: remove conflicting references, duplicate exceptions, and mismatched schedule language so the final papers say one consistent thing.

Related reading: How to Write a Warranty and Disclaimer Clause for a Software Product.

Before you send the final draft, generate a clean baseline agreement. Then review the liability cap, carve-outs, and indemnity language in one pass with the Freelance Contract Generator.

Conclusion#

Your objective is not to win one redline. It is to sign with a liability position you can explain, price, and defend across the full contract stack. Set these terms early, price against the risk you are actually accepting, and do not let late edits quietly expand recoverable loss.

Drax v Wipro is a useful warning example. The dispute was not just about one sentence in the cap clause. Commentary shows the court drew on other clauses to interpret the cap, and the wording reached the agreement, "including all Statements of Work." The practical takeaway is simple: when your MSA, SOW, and related contract documents use inconsistent language, interpretation risk rises.

Before signature, run this final decision gate:

1. Excluded losses are explicit. State which categories are excluded, including any consequential or indirect losses you intend to exclude.
2. Cap mechanics are explicit. State whether the cap is a single aggregate cap or can apply per claim, and make formula inputs clear.
3. Carve-outs are narrow. For each carve-out, define the trigger, whether it is uncapped or under a higher cap, and whether treatment is mutual.
4. MSA and SOW language is aligned. Reconcile definitions, precedence, survival, indemnity interaction, and any attached terms.
5. Damage terms are consistent across documents. If terms like "direct," "indirect," or "consequential" conflict, stop and fix before signoff.

For reuse, keep a one-page clause stack for each deal: preferred position, fallback position, and walk-away position, linked to final signed documents, redlines, and approval history. If you are contracting under English law, especially on written standard terms, sanity-check whether the final limitation terms could meet UCTA's reasonableness test.

If you want a second set of eyes before signature, Talk to Gruv.