ERP integrations rarely show up as material risks in investment memos, yet they often disrupt merger integrations and operational improvement efforts. Revenue recognition, inventory accuracy, payroll, working capital visibility, and internal controls all depend on them. When ERP implementations go well, they attract little attention. When they go poorly, the effects ripple across the business.

Over the past decade, several mid-market ERP implementations have failed at high cost, despite involving widely used systems, familiar industries, and reasonable transformation goals.
This piece looks at three such failures and the lessons they offer to investors, operating partners, and finance leaders who are accountable for execution, not just system choice.
1. Revlon vs SAP: Integrating Systems Before Operations Were Ready
After acquiring Elizabeth Arden, Revlon consolidated manufacturing, supply chain, and finance onto SAP. The objective was clear: unify operations, simplify reporting, and capture post-merger efficiencies.
The timing, however, proved costly. The ERP transition occurred while processes, teams, and data structures were still in flux. Manufacturing operations were disrupted, production slowed, and customer orders went unfulfilled. Revlon later disclosed substantial lost sales, remediation costs, and internal control weaknesses tied to the rollout.
From an integration standpoint, the challenge was that the system was introduced into an environment without a stable operating baseline. Process definitions were evolving, data standards were inconsistent, and teams were still adapting to a new organizational structure.

In that context, issues that might have been manageable in a steady state cascaded across manufacturing, logistics, and finance. The ERP system amplified existing instability rather than consolidating it.
For mid-market companies, especially those executing acquisitions, this case reinforces a simple reality: ERP integrations assume a degree of organizational stability. When that stability is absent, systems change tends to surface as business disruption rather than controlled implementation risk.
2. Worth & Co. vs Oracle: How Integration Drift Becomes a Sunk-Cost Trap
Worth & Company, a mechanical contracting firm, set out to implement Oracle ERP to support job-based accounting, cost tracking, and operational reporting. Early plans assumed that standard modules could accommodate the business with limited adaptation.
As implementation progressed, gaps appeared between how work was actually performed and how transactions were expected to flow through the system. Job costing logic, revenue recognition timing, and field-driven inputs required repeated adjustment.
Rather than revisiting core design assumptions, these gaps were addressed incrementally. Configuration changes accumulated. Manual workarounds filled gaps. Fixes were deferred to later phases.
Over time, integrations with surrounding systems became increasingly unstable as upstream assumptions shifted. Data structures changed without full downstream validation. Finance teams relied more heavily on reconciliations outside the system to confirm results.
Project governance did not intervene early enough to stop this draft. Milestones advanced despite unresolved workflows. Payments continued based on elapsed time and effort rather than functional completeness. Leadership intervention came only after years of spend and organizational fatigue.
By the time the project was abandoned, the system no longer reflected a coherent operating model. Worth ultimately wrote off the investment and pursued legal action.
This case shows how ERP integration failures often accumulate quietly. When business process definition, data architecture, and system configuration evolve out of sync, projects persist long past the point where recovery is economically rational.
3. Frederick Wildman & Sons vs Microsoft Dynamics: Customization That Undermined Control
Frederick Wildman & Sons implemented Microsoft Dynamics 365 to modernize a distribution business with complex inventory, pricing, and channel requirements. Rather than simplifying processes to align with standard workflows, the implementation aimed to preserve legacy practices through extensive customization.
Business logic became distributed across custom modules, integrations, and interface layers. Core rules governing inventory movement and pricing were embedded in multiple places rather than centralized.
Testing environments struggled to reflect real operating conditions. As a result, issues surfaced after deployment, particularly during high-volume periods and edge cases. Fixes introduced new dependencies, increasing fragility elsewhere in the system.
The finance function absorbed much of the impact. Close cycles lengthened as reconciliations required manual intervention. Confidence in system outputs declined, prompting parallel spreadsheets and shadow reporting simply to validate results.
At that point, the ERP environment no longer functioned as a reliable source of truth. The company incurred additional cost to stabilize and partially redesign the system rather than realizing the intended operational lift.

The lesson here is architectural. When customization fragments business logic across integrations, operational control weakens and recovery becomes expensive.
The Common Thread: Integration as the Failure Point
Across all three cases, integration challenges followed a similar pattern.
Initial system designs were based on incomplete understanding of end-to-end workflows. Exceptions were handled locally rather than through system-level redesign. Data models, process logic, and integrations drifted apart over time.
Testing lagged behind design changes, allowing issues to reach production. Finance teams compensated manually, masking system fragility until operational strain made it visible.
In mid-market environments, where teams lack redundancy, these dynamics surface quickly. Senior leaders spend time validating numbers rather than acting on them. ERP systems intended to compress complexity end up redistributing it across the organization.
What This Means for Investors and Operators
For investors, ERP implementations represent a form of hidden leverage. When executed well, they support scale, visibility, and disciplined execution. When executed poorly, they erode value indirectly through distraction, delayed decision-making, and weakened controls.
Three implications stand out:
ERP risk deserves explicit attention during diligence and post-close planning, particularly in integration-heavy strategies.
Integration governance matters more than vendor selection. The ability to pause, redesign, or exit based on functional outcomes is critical.
Standardization is a strategic choice. Organizations that use ERP implementations to simplify tend to preserve flexibility.
Closing Thought
ERP implementations rarely fail all at once. They deteriorate through small decisions that compound over time. The companies that avoid becoming cautionary examples are not those with the most aggressive timelines, but those with the discipline to align systems change with operational reality.
For mid-market operators and investors focused on durable value creation, that discipline is foundational.
Kenny & Christian