By Gavan Corry | Softwhere.co | 14 October 2026
When Birmingham City Council introduced a new Oracle financial system, it expected better control over its finances. Instead, the authority was left struggling with accounting problems, unreliable reporting and an expensive recovery programme. Elsewhere, Asda spent more than £1.2 billion separating its technology from Walmart, while Rolls-Royce became involved in a multimillion-euro court dispute over a delayed software project.
These cases have different causes, but they expose a weakness in the enterprise software market. Customers can spend millions on technology, commit years to implementing it and still find themselves paying heavily when the project fails to deliver what was promised.
ERP consultant Eric Kimberling recently challenged the industry’s business model in a LinkedIn post, asking when an enterprise software ecosystem starts behaving like a cartel. He questioned the financial incentives surrounding licence sales, implementation contracts, forced upgrades and supposedly independent consultancy advice. His concern was that customers frequently carry the risks while software suppliers and their partners benefit from continuing revenue.
The comparison is controversial, and there is no evidence here of an illegal cartel. Kimberling also has a commercial interest in the debate. He founded Third Stage Consulting Group, which sells independent advisory services to businesses undertaking technology projects. Nevertheless, his criticism raises a legitimate question about how ERP software is bought, implemented and maintained.
The issue is not whether suppliers should make money. It is whether customers fully understand the financial commitments they are making and retain enough control to challenge suppliers when things go wrong.
Birmingham City Council: An ERP failure that management failed to stop
Birmingham City Council’s implementation of Oracle Fusion has become one of Britain’s most closely examined public-sector software failures. The system went live in April 2022, replacing ageing SAP software that supported the council’s financial operations. It was intended to modernise accounting and provide better information to managers responsible for public spending.
Instead, the council encountered serious problems with financial reporting, accounting processes and the configuration of the software. The difficulties left staff relying on manual workarounds and made it harder to produce reliable financial information. These were not minor inconveniences in an organisation responsible for managing billions of pounds in public expenditure.
The problems were particularly troubling because significant warnings existed before the implementation went live. External auditor Grant Thornton subsequently found fundamental weaknesses in governance, reporting and project oversight. Risks had not been properly understood or communicated to senior decision-makers, while weaknesses in design and testing remained unresolved.
The findings were documented in the council’s public interest report on its Oracle ERP implementation, published in February 2025.
The council had also moved away from the original principle of using Oracle’s standard functionality wherever possible. Its approach, described as adopt, not adapt, was intended to limit unnecessary changes to the software. In practice, substantial customisation created additional technical difficulties and complicated the recovery work.
By 2023, the council was estimating that completing the Oracle implementation would cost around £100 million, compared with an original approved budget of £38.7 million. Subsequent audit reporting identified further financial exposure associated with the failed implementation and recovery.
Birmingham’s wider financial crisis should not be confused with the Oracle failure. The council faced substantial equal-pay liabilities and other financial pressures when it issued a section 114 notice in September 2023. The software problems contributed to the difficulty of managing its finances, but they were not the sole cause of the financial emergency.
What makes Birmingham relevant to private companies is the failure of management oversight. The council had access to warnings about the system’s readiness, yet the implementation proceeded. Grant Thornton’s findings raise questions about who understood the problems, how accurately they were reported and whether the people responsible for approving the launch had enough reliable information.
An implementation partner can recommend a launch date and explain the financial consequences of delaying it. However, the customer must retain responsibility for deciding whether its accounting, purchasing and operational processes are ready to depend on the new system.
A manufacturing business with unreliable stock records or a distributor unable to process invoices could face serious disruption after an unsuccessful launch. Directors should insist on testing actual business processes before approving a go-live date, including month-end reporting, bank reconciliation, order processing and stock movements.
The decision should rest on evidence that the software works, rather than pressure to meet an agreed timetable.
Rolls-Royce v Topalsson: Why software contracts matter when deadlines slip
Rolls-Royce Motor Cars faced a different problem when a software development project failed to meet its delivery timetable. In 2019, the company contracted German developer Topalsson to create digital visualisation software that would allow customers to configure cars and view realistic representations of their chosen specifications.
The development ran into delays, and Rolls-Royce terminated the agreement in April 2020. Topalsson challenged the termination, arguing over the contractual obligations and the consequences of missed deadlines. The dispute eventually reached the High Court, where the wording of the software development agreement became central to the outcome.
In July 2023, the High Court found that Rolls-Royce had been entitled to terminate the contract. Certain milestones had been made binding through provisions specifying that time was of the essence. The court concluded that the relevant delivery obligations had not been met.
The High Court initially awarded Rolls-Royce €5 million plus interest. However, the developer appealed the calculation, and in November 2024 the Court of Appeal reduced the principal amount to approximately €4.2 million while upholding the termination decision.
The Court of Appeal judgment in Topalsson v Rolls-Royce examined how the contractual liability cap applied to competing financial claims. The case demonstrates how the wording of a software agreement can materially affect the amount a customer recovers.
Although this was not an ERP implementation, the contractual issues are relevant to businesses commissioning enterprise systems. A detailed implementation timetable does not necessarily give customers meaningful protection unless the agreement explains which deadlines are binding and what happens if they are missed.
ERP buyers should examine the distinction between an indicative project plan and a contractual commitment. They should understand whether a supplier can extend delivery dates, what circumstances justify additional charges and how much compensation is available if the implementation fails.
A liability cap deserves particular attention. A company could suffer losses exceeding its original software expenditure through interrupted operations, additional staff costs and the need to replace a failed system. Yet its contract may restrict the amount recoverable from the supplier.
These provisions are not automatically unreasonable. Software companies need to manage their own financial exposure, and customers may be able to negotiate different limits. However, directors should understand the consequences before agreeing to them.
The Rolls-Royce dispute shows why legal review should take place before the contract is signed, rather than after a project has failed.
Asda’s £1.22bn technology separation reveals the cost of leaving
Asda provides an example of how dependent a large organisation can become on established technology. When the supermarket changed ownership in 2021, it continued to rely on systems supplied through its former parent company, Walmart. Separating those arrangements required much more than purchasing replacement software.
The retailer launched Project Future to establish its own technology infrastructure. The programme involved separating thousands of legacy systems from Walmart and introducing new arrangements for finance, distribution, human resources, payroll, store operations and other business functions. Part of the work included moving to an independent SAP S/4HANA environment.
Asda initially continued using Walmart’s technology under transitional support arrangements, but the separation took longer than originally envisaged. The retailer extended those arrangements while new systems were developed, tested and introduced across its business.
The scale of the task was considerable. Store checkouts, distribution operations, stock management and online ordering depended on connected systems. Replacing one application could have consequences elsewhere in the organisation, particularly where information needed to move between applications developed over many years.
By 31 December 2025, Project Future had generated cumulative cash outflows of £1.224 billion, according to Asda’s annual accounts as reported by The Register in its investigation of the retailer’s technology separation.
This was expenditure on the wider technology separation rather than the cost of SAP ERP software alone. Treating the figure as a conventional ERP implementation bill would be misleading.
The disruption also affected trading. Asda reported difficulties with stock availability and its online customer experience following the programme’s major migrations. Management acknowledged that technology problems had contributed to difficulties across parts of the business.
Asda’s circumstances were unusual because the company was separating from a former owner rather than simply replacing an ERP product. Nevertheless, the case raises a question that ordinary businesses often fail to consider: how much would it cost to leave an established software environment?
A company may initially choose an ERP platform because its licence fees are competitive and the implementation proposal appears affordable. Five years later, its accounting records, inventory controls, customer information and production processes may all depend on that system. Changing suppliers could require extensive migration, new integrations and retraining.
The practical consequence is a loss of negotiating power. A customer may be dissatisfied with support charges or licence increases but decide that switching would cost even more. This does not necessarily mean the vendor has behaved unfairly; it means the original purchasing decision has created a long-term commercial dependency.
That possibility should be examined when comparing ERP products. Directors need to understand how data can be exported, what technical documentation will be available and whether another implementation partner could support the system without requiring a complete replacement.
The commercial interests of ERP suppliers and customers can diverge
Kimberling’s criticism becomes more persuasive when considered against the financial structure of the ERP industry. Software vendors earn continuing revenue from subscriptions, licences and support contracts. Implementation partners charge for configuration, integration, migration and training, while consultants may receive fees for helping customers select and manage software projects.
These are normal business arrangements, and many suppliers deliver considerable value. Problems can arise, however, when additional work benefits the supplier financially while increasing the customer’s costs without a corresponding improvement in results.
The distinction is particularly important with time-and-materials implementation contracts. Under these agreements, customers generally pay for the work undertaken rather than a fixed overall deliverable. When a project encounters additional requirements, the implementation partner may earn more revenue as the work expands.
Some extra expenditure is entirely justified. Businesses frequently underestimate the condition of their existing data, discover problems with outdated processes or change their requirements during implementation. A supplier cannot reasonably be expected to absorb every cost created by the customer’s decisions.
Other problems may stem from an inadequate initial assessment. An integration that should have been identified before signing may emerge halfway through the project, or the supplier may discover that standard functionality cannot handle a process described during procurement.
This is why directors should scrutinise hidden ERP software costs before approving a supplier’s proposal. Data cleansing, migration, interfaces, testing and additional consultancy can make the final expenditure considerably higher than the initial quotation.
By the time disagreements arise, the customer may already have committed money and staff time. Replacing the implementation partner could introduce further delays, leaving the supplier in a relatively strong position when negotiating additional fees.
Directors should insist on a clear statement of what the original quotation includes and excludes. They should also establish how changes will be approved and how responsibility will be determined when requirements have been overlooked.
For UK businesses preparing an investment proposal, Softwhere’s guide to how much an ERP system costs explains the difference between software subscriptions, implementation expenditure and the wider project budget.
A cheaper initial quotation is not necessarily better value if substantial work has been excluded from the price.
How independent are ERP consultants?
The question of independence is another concern raised by Kimberling. Some ERP consultants operate within vendor partner programmes, receive referral fees or earn reseller margins from products they recommend. Others charge the customer directly and have no commission linked to the eventual software purchase.
Neither arrangement guarantees good advice. A consultant closely associated with one software platform may possess valuable technical and industry knowledge. Equally, an adviser without direct vendor commissions can still favour familiar products or recommend consultancy work that the customer does not need.
The important point is transparency. Businesses commissioning independent software selection advice should understand how the adviser earns money and whether commercial relationships could influence the shortlist.
A credible selection process should explain why competing products were rejected. If a consultant recommends one ERP platform, directors should expect evidence showing how it meets the company’s requirements and where its limitations lie.
This is particularly important for businesses with specialist operational needs. A manufacturer managing complex production schedules may require different functionality from a distributor or professional services company. Product demonstrations can make these differences appear less significant than they are.
Softwhere’s comparison of small business ERP systems examines software across manufacturing, distribution, retail and other industries. It provides a starting point for identifying which products deserve further investigation rather than relying solely on a preferred vendor’s presentation.
Customers should also ask shortlisted suppliers to demonstrate the processes that cause the most difficulty in their own business, using realistic data and scenarios. A reference from a comparable customer who has experienced problems and resolved them may prove more useful than a collection of general testimonials.
UK regulators are examining software switching barriers
Concern about dependence on software suppliers extends beyond the ERP consultancy market. In May 2026, the Competition and Markets Authority opened an investigation into Microsoft’s business software ecosystem under the UK’s digital competition rules.
The regulator is examining whether Microsoft should be designated as having strategic market status. Its investigation covers questions about product bundling, interoperability, default settings and the ability of customers to move to competing software.
The CMA’s investigation into Microsoft’s business software ecosystem is not evidence that Microsoft has breached competition law, nor does it establish that ERP suppliers are acting as a cartel. However, it demonstrates that switching barriers and the commercial power of established technology providers are being examined at a regulatory level.
For ERP customers, those concerns are familiar. A business may have considerable choice during its initial software selection, but much less practical freedom after years of investment in one platform. The cost of moving data, replacing integrations and retraining employees can discourage companies from changing suppliers even when better alternatives become available.
The CMA’s investigation should not be confused with a judgment on the ERP industry’s commercial practices. Its relevance lies in the wider question of whether business software markets give customers enough freedom to choose competing products.
What directors should do before buying ERP software
The three cases demonstrate why ERP procurement should cover more than product functionality and implementation prices. Directors need to understand how their organisation will manage the project, what contractual protection it has and how easily it could change direction later.
The first priority is to establish a realistic budget. Suppliers should explain the work included in their quotation, identify significant exclusions and describe how additional requirements will be priced. Businesses should compare the total expected cost of implementation rather than relying on headline licence fees.
Contractual responsibility is equally important. Delivery milestones should be clear, and the agreement should explain what happens if the supplier fails to meet them. Directors should understand termination provisions, liability limits and the circumstances in which the supplier can charge for additional work.
The customer must also retain control over the decision to go live. Birmingham’s experience shows the danger of allowing schedules and programme pressures to outweigh unresolved problems. Finance, operations and IT managers should provide evidence that critical processes have been properly tested before the organisation commits to its new system.
Buyers should examine their freedom to change implementation partners. Access to documentation, configuration details, integrations and custom developments can make a considerable difference if support deteriorates or a commercial relationship breaks down.
Finally, businesses should consider the eventual cost of leaving the platform. Data export rights, contract renewal terms, termination charges and access to historical records should be understood before the first licence is purchased.
For smaller organisations still weighing up their options, Softwhere’s guide to the best ERP software for small businesses in the UK offers a comparison of the main platforms, their likely costs and the types of company they suit.
These precautions will not eliminate implementation risk. ERP projects involve operational change, and some problems only become apparent during delivery. However, careful procurement gives customers a better chance of identifying costs and responsibilities before disagreements arise.
Is the ERP industry working against its customers?
Kimberling’s comparison with a cartel goes further than the available evidence supports. Birmingham’s Oracle problems were heavily influenced by the council’s own management failures, Rolls-Royce was involved in a contractual dispute over bespoke software, and Asda faced the unusual task of separating technology from its former parent company.
None of these cases demonstrates unlawful cooperation between ERP vendors or a deliberate attempt by the industry to exploit customers. What they show is how costly enterprise software decisions can become when contractual responsibilities, technical dependencies and management oversight are not properly understood.
Suppliers have legitimate commercial objectives. They want to sell products, retain customers and earn revenue from additional services. Buyers have different priorities: reliable systems, predictable expenditure and improvements that justify their investment.
Those interests often overlap, but directors should not assume they are identical. An experienced implementation partner can be an asset, while an adviser who explains difficult choices may save a business substantial money. Both relationships still require scrutiny.
Perhaps the most telling feature of the three UK cases is how different the problems were. Birmingham struggled with governance, Rolls-Royce needed the courts to resolve contractual obligations, and Asda faced the financial and operational consequences of technology separation.
The common issue was not evidence of a cartel. It was the scale of the customer’s exposure when major software arrangements became difficult to manage or unwind.
Businesses considering ERP software should therefore give as much attention to contractual protection, implementation responsibility and exit costs as they do to product demonstrations.
The supplier knows what it wants from the contract. Directors need to be equally clear about what their business is accepting.
About the author
Gavan Corry writes for Softwhere.co about ERP software selection, implementation costs and business technology, focusing on the commercial decisions facing UK businesses.