Aggregating Fundamentals
A dispute between Centrica and Accenture over a gas billing system highlights the fact that even the most carefully drafted of contracts have their ambiguities.
Accenture, the IT consultancy group, suffered a defeat on all of the preliminary issues in a judgment handed down on 6 November in GB Gas Holdings Limited v (1) Accenture (UK) Limited, (2) Accenture SCA, (3) Accenture International SARL, (4) Accenture Inc [2009] EWHC 2734 (Comm).
Centrica is claiming nearly £200m in relation to the alleged failure of the IT customer billing system which was to be created and installed by Accenture.
In a complex series of preliminary judgments by Mr Justice Field, one element stands out. The contract stated that once Centrica had provided notice to Accenture of any ‘fundamental’ defect in the system, Accenture was obliged to take reasonable steps to fix the problem. Centrica claimed that it had notified Accenture of a fundamental defect but Accenture had refused to take any steps in response. Accenture argued that no single ‘fundamental’ breach had occurred and they were therefore not liable. Centrica claimed that a series of lesser breaches could be aggregated to form a ‘fundamental’ breach. Mr Justice Field agreed with Centrica.
Commenting on the judgment, Peter Clough, head of disputes at Osborne Clarke, said:
‘One of the important points to note about this case is that IT suppliers can be liable for claims for fundamental breach arising from the cumulative effect of a series of faults, each of which could look relatively minor in isolation. The majority of systems will of course be inter-linked so that a defect in part of the process could affect another part, snowballing into a more serious issue.
Accenture were partly caught out by the use of the words “and/or” in the definition of “fundamental breach”. This judgment reinforces the careful considerations that need to be given when negotiating IT contracts. It will be interesting to see what other issues arise on this matter at the full trial.’
Published: 13/11/2009
Printed from www.scl.org ( (c) The Society for Computers & Law)


Comments
The overall result seems to be that suppliers of financial systems probably have to take an entirely different contractual approach if they are not to accept (whether consciously or not) an excessive degree of risk once the system goes into live use.It will be interesting to see how they react.
Paul Golding
TRG law
Paul Golding, 19/11/2009 17:46
I am not suprised the judge ruled that Centrica were allowed to aggregate breaches to constitute a fundamental breach. I imagine this same approach would be applied to any ERP-type implementation because, as the judge said: (i) systems of this nature involve a lot of inter-related processes and sub-processes; (ii) an error in one process can affect a related process; (iii) it is quite common to have defects in a system which in combination create an aggregated defect; (iv) design errors in different processes can cumulatively impact on other processes.
I was interested in the weight that the judge put on the recitals in the contract as part of the factual matrix against which he interpreted the relevant contract clauses. Don't speed read Recitals they can be important!
Ann Lewin, 25/11/2009 17:01
I have to admit to some insider knowledge here, as I worked at British Gas when these negotiations were going on (I left in 2002), but the whole point of the Jupiter project was to bring all of British Gas' customer-facing systems together as it had different systems for different products, none of which talked to each other and meant that if a customer had queries about 3 products, they had to talk to 3 different people. Accenture were well aware of the importance of the project and what its purpose was. If Centrica then had disgruntled customers as a result of the failure of the system, it seems clear that compensating those disgruntled customers would be a direct loss and falls squarely within the first limb of Hadley v Baxendale.
anonymous, 26/11/2009 16:58
To post a comment, log on (you must be a current member of SCL to post a comment ). Comments are limited to 4096 characters (roughly 500 words). Comments are subject to the SCL standard terms and conditions. Please go to My SCL and log on now.