Liability Caps and Indemnities in Software Development Contracts

Why do liability clauses matter so much?

Liability provisions determine how much financial risk each party carries if something goes wrong. They are among the most heavily negotiated clauses in any software contract because they define the worst-case scenario for both sides. Everything else in the agreement (scope, price, timelines, ownership) describes how the project is meant to run. The liability clause describes what happens when it does not.

That is why these clauses attract so much attention during procurement. A clause that looks like dry legal boilerplate is in fact the place where the two parties agree, in advance, who absorbs the cost of a failure and up to what amount. Getting it right protects both sides: the client wants meaningful recourse if the software causes real harm, and the development partner needs its exposure to stay proportionate to the fees so that taking the work on remains commercially viable.

Three mechanisms do most of the work: the liability cap, indemnities, and excluded losses. They interact, so it helps to understand each one and then see how they stack together.

What is a liability cap?

A liability cap sets a ceiling on the total amount one party can claim from the other. In software contracts this is usually expressed as a multiple of the contract value or the charges paid in a given period. For example, a cap of 100% of the contract value means the maximum the client could recover from the development partner is the total amount paid under the agreement.

Caps exist because the potential consequences of a software failure can vastly exceed the value of the contract itself. Lost revenue, reputational damage, and regulatory fines can run to figures many times larger than the fees for building the software. Without a cap, a development partner could face claims worth many multiples of the fees they received, which would make delivering bespoke software commercially unviable. No sensible partner would price a fixed-fee build while carrying unlimited downside, so the cap is what makes the commercial bargain workable for both sides.

The key question for a client is not simply whether there is a cap (there almost always is) but whether it is proportionate. A cap set far below the contract value leaves the client with little meaningful recourse, while a cap that bears a sensible relationship to the fees gives both parties a clear, agreed limit to plan around.

What is an indemnity, and should it be capped?

An indemnity is a promise by one party to compensate the other for specific types of loss. It is a more direct route to recovery than a general breach of contract claim, because the parties have agreed in advance that a defined category of loss will be made good.

In software contracts, the most common indemnities relate to two areas:

• Intellectual property infringement: a promise that the software does not infringe anyone else’s intellectual property. If a third party claims the delivered software copies their protected work, the indemnity covers the resulting loss. This connects closely to how the software’s IP is owned and licensed, covered in our guide on IP licensing and source code handover.
• Data breaches: a promise that negligent handling of personal data will be compensated.

The crucial structural question is whether indemnities sit inside or outside the liability cap. If they sit inside, an indemnity claim counts towards the same overall ceiling as any other claim. If they sit outside, the indemnity is subject to a separate limit, or to no limit at all. An uncapped indemnity means there is no limit on the amount the indemnifying party could be required to pay. This is a significant risk allocation, and whether indemnities should be capped or uncapped is one of the most common areas of negotiation. There is no single correct answer; what matters is that the contract states the position clearly for each indemnity so neither party is surprised when a claim arises.

What losses are usually excluded?

Most contracts exclude certain types of loss from claims altogether. These typically include:

• Loss of profits
• Loss of anticipated savings
• Indirect or consequential losses

The rationale is that these types of loss are difficult to predict and can be disproportionate to the value of the contract. A modest software defect could, in theory, be argued to have cost a business a large amount of speculative future profit, and pricing a build against that kind of open-ended exposure is not realistic.

Where the line is drawn on excluded losses is a commercial negotiation. One item deserves particular attention: reputational damage, sometimes framed as loss of goodwill. For some organisations this is exactly the loss they most fear and most want to be able to recover, yet it is often swept up in the excluded categories. Clients should check specifically whether reputational damage is included or excluded, rather than assuming it falls one way or the other.

How do caps, indemnities, and carve-outs stack together?

It helps to picture liability as a stack. At the base sit ordinary contractual claims, which are limited by the cap. Indemnities may sit inside that cap or be lifted above it. And at the very top sit the carve-outs that cannot legally be limited at all, no matter what the rest of the clause says.

Reading the stack from the bottom up: general contractual claims are limited by the cap, and the excluded losses never enter the calculation at all. Indemnities are the movable layer, sitting inside the cap or above it depending on what the parties agree. And at the top are the carve-outs that the law puts beyond the reach of any cap.

What cannot be limited by law?

Some liabilities cannot be excluded or capped by contract under English law, and well-drafted agreements carve them out of the cap explicitly rather than pretending otherwise. The two most common are:

• Fraud and fraudulent misrepresentation. A party cannot contract out of its own fraud.
• Death or personal injury caused by negligence. Liability for this cannot be limited.

These items sit above any cap and remain unlimited. A liability clause that tried to limit them would simply be ineffective for those items, so reputable contracts name the carve-outs openly. Their presence is a good sign: it shows the clause has been drafted properly rather than copied from a template that overreaches.

Why should liability be mutual?

Liability is a two-way relationship, even though contracts are often drafted as if only the development partner can do anything wrong. The client also has obligations: paying on time, providing accurate and lawful data, and granting the access the partner needs to deliver. The treatment of defects and acceptance, covered in our guide on acceptance testing and UAT clauses, is one area where client and partner responsibilities meet directly.

Provisions that impose caps and exclusions on the development partner alone, while leaving the client’s exposure open-ended, are unbalanced and usually signal a one-sided contract. Mutual liability provisions, where the cap, the excluded losses, and the carve-outs apply to both parties, are fairer and tend to support a more durable working relationship. When you review a liability clause, check that it reads symmetrically and is not simply a list of obligations pointed in one direction.

What to look for in your contract

When you review the liability provisions, work through the following:

• A liability cap that is proportionate to the contract value. The ceiling should bear a sensible relationship to the fees, neither so low that recourse is meaningless nor so high that it makes the engagement unviable.
• Clarity on whether indemnities (IP, data breach) sit inside or outside the cap. Each indemnity should state its position explicitly, and any uncapped indemnity should be a deliberate, understood choice.
• A list of excluded losses that both parties are comfortable with. Check loss of profits, anticipated savings, and indirect or consequential losses, and look specifically at how reputational damage (loss of goodwill) is treated.
• Carve-outs for things that cannot legally be limited. Fraud and personal injury should sit above the cap and remain unlimited.
• Mutual liability provisions, not just obligations on the development partner. The cap, exclusions, and carve-outs should apply to both sides.

Where to go from here

Liability caps and indemnities are one of ten areas covered in our practical guide to software development contracts, which puts this topic alongside capped investment, IP licensing, acceptance testing, exit rights, and the other provisions that shape a bespoke build. Reading the liability clause in the context of the whole agreement is the best way to judge whether the risk allocation is fair.

We believe a balanced, clearly drafted liability clause is one of the strongest signals of a healthy engagement. If you are reviewing a software development contract and want to talk through the liability provisions, book a consultation.

This guide explains how common software development contract terms work in plain English. It is not legal advice. For advice specific to your circumstances, consult a solicitor qualified in technology and commercial contracts. It reflects common UK market practice as at June 2026.