Failed ERP Implementation Claims: Recovering Losses from Your Software Supplier
A failed ERP implementation can affect almost every part of a business at once. ERP stands for enterprise resource planning.
Businesses commonly use ERP systems to manage finance, stock, procurement, manufacturing, orders, logistics, reporting and other core business processes. When an implementation goes wrong, the consequences can be much more serious than a single piece of software not working.
This can result in stock figures becoming unreliable, orders not being processed properly, invoices being incorrect or management not being able to rely on financial reporting.
Where the business has spent substantial sums on the project, management will often want to know two things. First, whether it can hold the ERP supplier or implementation partner responsible. Second, whether the business can recover the losses caused by the failure.
This article looks specifically at failed ERP implementation claims, the issues that commonly arise in ERP projects and the practical steps businesses should consider when assessing responsibility and potential recovery.
What makes ERP implementation disputes different from other software disputes?
ERP systems affect multiple parts of the business
ERP implementation is rarely confined to one department. The system may connect finance, purchasing, inventory, warehousing, manufacturing, sales and reporting. A failure in one part of the implementation can therefore create problems elsewhere.
This interconnected nature can make both the operational consequences and the legal dispute more complex.
Several suppliers may be involved
ERP projects may involve the software vendor, an implementation partner, consultants, integration specialists and other third-party providers.
When the project fails, those parties may blame one another. A claim therefore needs to identify which party assumed responsibility for the particular part of the project that failed.
A claim will generally lie in contract against the party that agreed to perform the relevant work. Claims against a supplier with which the business has no contract, such as a subcontractor of its implementation partner, are much harder to establish, particularly where the loss is purely financial.
When does a troubled ERP implementation become a potential claim?
The system does not support core agreed processes
An ERP project may be in difficulty where important business processes cannot operate in the way the supplier agreed they would. Just because the software is technically live does not necessarily mean the implementation has been successful.
If staff cannot use the system effectively without substantial manual workarounds, the business should consider whether the delivered solution actually meets the agreed requirements.
Repeated delays and failed go-live attempts can be significant
ERP projects often involve extensive testing and preparation before go-live.
Where go-live is repeatedly postponed because significant functionality remains incomplete, data cannot be reconciled or critical defects remain unresolved, management should consider whether the project is still realistically capable of completion.
A history of repeated revised deadlines can also become important evidence when responsibility is later disputed. Agreeing revised dates or recovery plans without reserving the business’s rights may later be argued to amount to a variation or waiver of the original timetable.
What if the ERP system cannot perform the processes you were promised?
The original requirements are critical
ERP suppliers often spend significant time understanding how a prospective customer’s business operates before the parties sign the contract. There may have been workshops and detailed discussions about the customer’s requirements.
If the implemented system cannot support an important process, the first question is whether that capability formed part of the agreed scope.
The relevant evidence may include the statement of work, requirements documentation, supplier proposal and other project documentation. Which of those documents form part of the contract will depend on the contract itself.
Proposals and workshop discussions are not automatically contractual. Many ERP contracts contain entire agreement clauses, and it could be the case that only one document defines the agreed scope. Pre-contract statements can still be legally relevant, for example as a misrepresentation under the Misrepresentation Act 1967 if they were false statements of fact that induced the customer to enter the contract, or in some cases as a collateral warranty. Any attempt to exclude liability for misrepresentation is subject to a statutory reasonableness test.
Does the law imply any obligations if the contract is silent?
Where a supplier provides implementation, configuration or similar services in the course of business, section 13 of the Supply of Goods and Services Act 1982 implies a term that those services will be carried out with reasonable care and skill. The contract may modify or exclude that term, subject to the Unfair Contract Terms Act 1977 (UCTA).
This is not the same as a guarantee that the ERP system will be fit for the customer’s purpose. A fitness-for-purpose obligation will usually need to be an express term, although in some circumstances it may be implied where the customer made its particular purpose known and reasonably relied on the supplier’s skill.
What if the supplier says your business processes need to change?
ERP implementations often require business process change
Implementing an ERP system frequently requires the customer to change some existing processes.
A supplier may therefore argue that the system is working correctly and that the real problem is the customer’s reluctance to adopt the processes for which the software was designed.
If the parties agreed to redesign particular processes as part of the implementation, the supplier may have a strong position.
But process redesign should not become an excuse for missing functionality
There is an important difference between asking a business to adopt an agreed new process and telling it after implementation that an essential requirement cannot be supported.
The project documents should show which business processes the parties expected to change and which requirements the system was supposed to accommodate.
This can be particularly important where the supplier carried out requirements workshops before proposing the final solution.
Can you recover the cost of putting a failed ERP implementation right?
Potentially.
A failed ERP project may require significant remedial work before the business can obtain the system it originally contracted for.
The business may need to bring in specialist consultants, correct data, rebuild integrations or engage another implementation partner.
Whether those costs can be recovered will depend on the supplier’s breach, whether that breach caused the costs, whether they were reasonably incurred and not too remote, whether the business has taken reasonable steps to mitigate its loss, and the contractual liability provisions.
The business should therefore retain invoices, scopes of work and internal records explaining why the remediation became necessary.
The cost of putting the work right is generally recoverable only where it is reasonable to do so. Liability caps and exclusions, particularly exclusions of loss of profit or of indirect or consequential loss, can significantly reduce what is recoverable. Depending on the contract and how it was agreed, they may be subject to UCTA, including a reasonableness test for certain exclusions of liability for negligence (which includes a failure to exercise reasonable care and skill in performing a contract) and for terms in written standard terms of business.
Can you recover the cost of replacing the ERP system entirely?
In some cases, the existing implementation may be beyond reasonable repair.
The business may decide that replacing the system or restarting the implementation with another provider is commercially safer than continuing to invest in the failed project.
Replacement costs can potentially become part of a claim, but the position is fact-sensitive.
The original supplier may argue that the business could have repaired the existing system more cheaply or that the replacement provides additional functionality beyond what was originally contracted for.
For that reason, management should document why replacement was necessary and what alternatives it considered before committing to substantial expenditure.
Damages aim to put the business in the position it would have been in if the supplier had performed the contract properly. A business therefore cannot usually recover both its wasted expenditure on the failed project and the full cost of replacing it, because the two overlap. The business should structure any claim to avoid double recovery. It may also need to give credit for sums not paid or benefits received.
Replacing the system will often mean ending the existing contract. Before doing so, the business should check any contractual termination rights, including notice and remedy requirements. In sufficiently serious cases there may also be a common-law right to accept a repudiatory breach, but terminating without a valid right can itself be a repudiatory breach. The business should also plan termination around access to data, hosting and transition support.
Is there a time limit for bringing a failed ERP implementation claim?
For many claims founded on a simple contract, section 5 of the Limitation Act 1980 sets a six-year limitation period from when the cause of action accrues. Where a deed contains the relevant obligation, the period may be 12 years. Claims for misrepresentation or negligence are also generally subject to a six-year period, but the starting point may differ.
The contract may also contain much shorter notice or time-bar provisions, for example for notifying defects or disputing invoices. Check these early, before negotiations break down.
How the Jonathan Lea Network can help with failed ERP implementation claims
Identifying where responsibility lies
We can review the contracts, project documentation and implementation history to identify what the ERP vendor, implementation partner and any other supplier agreed to provide.
Assessing the strength and value of the claim
We can help establish the alleged breaches, consider contractual liability limits and assess how the losses suffered by the business relate to the supplier’s failures.
Negotiation, mediation and proceedings
We can pursue a commercial resolution through negotiation or mediation, including identifying and appointing an appropriate mediator, and, where necessary, advise on formal proceedings against the responsible supplier or suppliers.
Frequently asked questions: failed ERP implementation claims
A claim may arise where important business processes cannot operate in the way the supplier agreed they would. A system that is technically live is not necessarily a successful implementation. If staff cannot use it without substantial manual workarounds, consider whether the delivered solution meets the agreed requirements. Repeated delays and failed go-live attempts can also be significant, especially where functionality is incomplete, the data will not reconcile or critical defects remain unresolved. In a failed ERP implementation, a claim will generally lie in contract against the party that agreed to perform the relevant work. ERP projects may involve the software vendor, an implementation partner, consultants and integration specialists, and they may blame one another. So identify which party took responsibility for the part of the project that failed. Claims against a supplier you have no contract with, such as a subcontractor of your implementation partner, are much harder to establish. Not automatically. Proposals and workshop discussions are not automatically contractual, and many ERP contracts contain entire agreement clauses. It could be the case that only one document defines the agreed scope. However, pre-contract statements can still be legally relevant. A false statement of fact that induced you to enter the contract may amount to a misrepresentation, or in some cases a collateral warranty. Any attempt to exclude liability for misrepresentation is subject to a statutory reasonableness test. Not automatically. The law implies a term that a supplier providing implementation or configuration services in the course of business will use reasonable care and skill. That is not a guarantee that the ERP system will be fit for your purpose. A fitness-for-purpose obligation will usually need to be an express term. In some circumstances it may be implied, where you made your particular purpose known and reasonably relied on the supplier’s skill. ERP implementations often require some process change. If the parties agreed to redesign particular processes, the supplier may have a strong position. However, process redesign should not become an excuse for missing functionality. Adopting an agreed new process is different from hearing after implementation that the system cannot support an essential requirement. Check the project documents for which processes the parties expected to change and which requirements the system should accommodate. You can, but protect your position. A history of repeated revised deadlines can become important evidence if responsibility is later disputed. However, the supplier may later argue that new dates or recovery plans amounted to a variation or waiver of the timetable. So reserve your business’s rights when you agree new dates. Where go-live keeps slipping, consider whether the project is still realistically capable of completion. Potentially. Remedial costs such as specialist consultants, data correction, rebuilt integrations or a new implementation partner may be recoverable. It depends on the supplier’s breach, whether that breach caused the costs, whether they were reasonable and not too remote, whether you mitigated your loss and the contract’s liability terms. Liability caps and exclusions can significantly reduce what you recover. Keep invoices, scopes of work and records explaining why the remediation became necessary. After a failed ERP implementation, replacement costs can potentially form part of a claim, but the position is fact-sensitive. The original supplier may argue that you could have repaired the existing system more cheaply. It may also argue that the replacement gives you extra functionality beyond the original contract. So document why replacement was necessary and what alternatives you considered before committing to substantial spending. Replacing the system will often also mean ending the existing contract. Not usually. Damages aim to put your business where it would have been if the supplier had performed the contract properly. Your wasted spending on the failed project and the full cost of replacing it overlap, so you cannot usually recover both. Structure any claim to avoid double recovery. You may also need to give credit for sums you have not paid or benefits you have received. Check the contract’s termination rights, including any notice and remedy requirements. In sufficiently serious cases there may also be a common-law right to accept a repudiatory breach. However, terminating without a valid right can itself be a repudiatory breach. Plan the exit around access to your data, hosting and transition support. The contract may also contain much shorter notice or time-bar provisions than the six-year limitation period, so check these early.
Contact us
We provide most enquiries with an indicative scope of work and fee estimate, based on the information you share. We aim to respond within one working day.
In the same email you will be invited to arrange a 20-minute complimentary, no-obligation video consultation, should the proposed scope of work and fee estimate be of interest. This initial discussion is designed to better understand your requirements, refine the scope and ensure our approach is fully aligned with your objectives, at the end of which we will email you a definitive formal fee estimate to consider and approve.
Where you would prefer to receive initial advice and guidance from the outset, or where a short introductory call would not be the most appropriate starting point, we may instead recommend a 2.5-hour fixed-fee appointment, starting from £700 + VAT. This enables us to review the information you provide, discuss your situation with you and provide considered, tailored advice at an early stage.
To make an enquiry, please email us at wewillhelp@jonathanlea.net, complete our contact form, or call us on 01444 708640.
VAT is charged at 20%.
This article is intended for general information only, applies to the law at the time of publication, is not specific to the facts of your case and is not intended to be a replacement for legal advice. It is recommended that specific professional advice is sought before relying on any of the information given. © Jonathan Lea Limited.