This browser is not actively supported anymore. For the best passle experience, we strongly recommend you upgrade your browser.
Digital developments in focus
| 4 minutes read

Capping liability: far from a model of clarity in TCS v DBS

Negotiating and drafting a liability clause is never easy. We’ve seen a number of liability clauses scrutinised in court in recent years, and the judge’s interpretation can have a huge impact on the damages recoverable.

Tata Consultancy Services Ltd v Disclosure and Barring Service [2024] EWHC 1185 (TCC) is a weighty 242-page judgment covering a wide range of issues in a digital transformation contract: notices, conditions precedent, estoppel, termination and (once again) liability caps. This post focusses on the liability clause and the challenges in interpreting it. 


In 2012, DBS retained TCS to take over certain manually intensive processes from its incumbent provider, and to build a new system to modernise DBS processes. The modernisation process didn’t go according to plan and suffered significant delays – when the contract came to an end in 2020, TCS claimed delay damages in excess of £100m, with DBS counterclaiming for losses of a similar amount. 

Issues of construction

The contract was based on the Government’s standard-form Model ICT Contract. It contained a liability clause that capped each party’s liability to the other, excluded liability for indirect loss and certain other heads of loss (including loss of profits), and set out a non-exhaustive list of losses that DBS could recover as direct loss.

The liability clause was, the judge noted, “far from a model of clarity” and gave rise to several issues of construction.

  1. Did the cap on TCS’s liability apply to each of DBS’s counterclaims or was it a single, aggregate cap that applied to all claims under the contract?
  2. Was TCS’s liability for delay payments limited to 10% of implementation Charges (and what were the “implementation Charges”)?
  3. Was TCS’s claim for loss of anticipated costs savings really a claim for loss of profits (and so a head of loss that was expressly excluded by the clause)?

One cap or several?

In previous cases, we’ve seen the significant difficulties that the wording of liability caps can cause. In Royal Devon, the “least bizarre” meaning was that an “aggregate” cap set two separate caps: one for defaults during the first year of the contract and another for defaults thereafter. And in Drax v Wipro – despite some “linguistic quirks” – a cap limiting Wipro’s “total liability” was, indeed, a single cap on liability for all claims.

In TCS v DBS, TCS’s “total aggregate liability” was limited for certain specified losses, including:

in respect of all other claims, losses or damages, shall in no event exceed £10,000,000 (subject to indexation) or, if greater, an amount equivalent to 100% of the Charges paid under this Agreement during the 12 month period immediately preceding the date of the event giving rise to the claim under consideration less in all circumstances any amounts previously paid (as at the date of satisfaction of such liability) by [TCS] to [DBS] in satisfaction of any liability under this Agreement. 

DBS argued the cap of £10,000,000 applied separately to each of its counterclaims. TCS said that the clause provided a single, aggregate cap of £10,000,000 which applied to all claims. The judge considered it a single, aggregate cap. The reference to “aggregate liability” clearly indicated that the clause set out TCS’s total liability, irrespective of how many claims, losses or damages there may be, and the simple language of “per claim” was missing. Although “the claim under consideration” wording suggested that more than one claim could be under consideration, the clause then netted off any amounts previously paid – the capped sums were not intended to be additive. The precise mechanics of the alternative calculation of the cap (by reference to Charges) were unclear, but it wasn’t necessary for the judge to reach a view here.

Defining implementation Charges

Separately, TCS’s total aggregate liability for “Delay Payments” was capped at 10% of “implementation Charges”. “Charges” was defined in the contract, but “implementation Charges” wasn’t. TCS contended this wording should be equated with a defined term describing a delivery milestone and regarded as a reference to a subset of the Charges. The judge disagreed: it wasn’t possible to discern a clear or meaningful intention to identify a particular subset.

Loss of profits or anticipated cost savings?

Under the liability clause, neither party was liable to the other for loss of profits, so TCS sought damages for loss of anticipated cost savings.

DBS argued that, in reality, TCS’s claim was for loss of profits, which was excluded by the clause. TCS accepted its claim could have been articulated as a claim for loss of profit but argued it was free to advance the claim in a way that was not caught by the exclusion.

The judge drew on Soteria Insurance v IBM United Kingdom, which distinguished speculative losses, such as loss of profit and loss of anticipated savings – which are open-ended and difficult to estimate in advance – from claims for actual incurred, but wasted, costs that are easily ascertained (with invoices, contracts, receipts, etc.).

An innocent party can choose whether to claim its loss of profits or its wasted expenditure, but that choice is between two very different substantive claims, rather than a choice about how the claim is articulated. The judge concluded the loss of anticipated savings was the same in substance as a loss of profits claim, and liability was excluded, regardless of what TCS named it.

Aiming for clarity

TCS v DBS, much like Royal Devon and Drax before it, reminds us again of the importance of clear drafting in liability clauses and the challenges poorly worded liability clauses can bring. Clarity is difficult, but not impossible. Make sure defined terms are precise and used consistently in the agreement. Keep the drafting of liability clauses (in particular the description of liability caps) simple where possible and work through the mechanics to check that caps work as intended.


tech procurement and cloud