Key Takeaways
- Tennant Company’s stock fell more than 23 percent in a single day after the manufacturer disclosed that a new ERP system was disrupting order processing, turning an operational problem into a market event.
- An ERP implementation failure now carries consequences that reach past cost overruns and into the territory of securities disclosure and investor litigation.
- ERP implementation risk becomes material the moment a rollout affects revenue recognition or contradicts what leadership has already told the market about project health.
- Independent oversight and a disciplined project audit give boards an accurate view of status before a troubled rollout ever reaches an earnings call.
Most executives picture an ERP implementation failure as a budget problem. The project runs long, and the finance team absorbs a larger bill than anyone planned for. The Tennant Company situation shows a more serious version of that risk. In early 2026, the industrial equipment manufacturer disclosed operational problems tied to a new ERP system, and its shares fell more than 23 percent in a single day. The company is now the subject of a federal securities fraud investigation.
What makes this case instructive is the distance between what investors were told and what was actually happening inside the rollout. As an independent ERP advisor, we regularly see how quickly go-live problems travel from the warehouse floor to the boardroom.
Today, we’ll examine how an ERP rollout becomes an investor disclosure risk, and what leadership can do to keep operational trouble from turning into a legal and reputational event.
Contemplating litigation?
We have multiple software expert witnesses available for provision of reports, depositions, and testimonies.
When an ERP Implementation Failure Becomes a Disclosure Event
An ERP system is the software of record for how a company processes orders and closes its books, which means a serious disruption to it rarely stays inside the IT department. When Tennant brought its new system live, the reported effect included disruption to order processing along with lost sales and higher remediation costs. For a public company, an operational problem of that size crosses an important line once it becomes material to financial results or begins to contradict what the company has already told the market.
Publicly traded companies carry a legal obligation to disclose material risks and results accurately. An ERP implementation failure becomes a disclosure event when its effects reach revenue or when earlier statements about project health no longer match what is actually happening. Tennant had communicated that its project was progressing as anticipated. When the company later disclosed severe operational issues, the gap between those two positions became the foundation for the securities fraud investigation that followed.
Public ERP failures were once remembered mainly as expensive cautionary tales about wasted capital. The Tennant case shows how much the stakes have widened. Panorama has written before about the hidden costs of ERP failure and the lawsuits that follow, and this situation adds a live, unfolding example to that pattern.
Why ERP Implementation Risk Reaches the Boardroom
ERP implementation risk is often treated as a project management concern owned by IT and the systems integrator. In reality, that same risk sits closer to the audit committee than most boards assume, because the failure modes that derail a go-live are frequently the ones that distort financial reporting.
Several recurring conditions turn a routine rollout into a reporting problem:
● Revenue disruption at go-live: When order-to-cash processes break, the company cannot invoice or recognize revenue on its normal schedule, which distorts the numbers leadership reports to the market.
● Optimistic status reporting: Project sponsors under pressure to show progress often relay a healthier status than the evidence supports, which sets up the eventual gap between disclosure and reality.
● Absent independent verification: When the only view of project health comes from the team responsible for delivery, leadership has no reliable way to confirm whether a status of on track is genuinely accurate.
● Data integrity gaps: Master data that migrates in poor condition tends to surface as inventory and financial errors weeks after go-live, well after the risk was reported as resolved.
Case Study
A major Florida city, one of the ten largest municipalities in the state, halted its ERP implementation in late 2019 after leadership questioned whether the vendor software and the team were ready. The organization needed an objective read on whether the investment could still be salvaged.
Panorama conducted an independent assessment that paired a document review with structured interviews and a formal vendor question-and-answer process. The audit confirmed genuine progress while identifying functionality gaps that would require customization before the system could safely go live. Rather than recommend abandoning the investment, Panorama laid out three defensible paths, and leadership moved ahead with an experienced external project manager on the strength of an accurate picture of project health. That visibility is exactly what a troubled program needs long before its status ever reaches a public statement.
Read the full ERP project recovery case study.
What an Independent Audit Catches Before Investors Do
An ERP system audit is an independent review of a project’s health, carried out by a party that has no stake in reporting good news. It examines the same evidence the delivery team sees and then tests whether the reported status actually holds up. The real value of that review is timing. A problem in configuration or data that surfaces during testing gives leadership months to correct course and to calibrate what it tells the market, while the same problem discovered at go-live gives leadership a disclosure to make.
For companies that are already past that point, ERP audit and recovery work stabilizes the operation and rebuilds an accurate status baseline that executives can trust. Independent ERP services of this kind exist precisely because the team delivering a project cannot objectively grade its own work.
Expert Insight
Our ERP project recovery team has found that the gap between reported project status and actual readiness is widest in the final ninety days before go-live, which is exactly when leadership is most likely to reaffirm timelines in public. An independent checkpoint in that window is often the difference between a managed delay and a disclosure event, which is why we advocate independent oversight on large ERP projects.
How to Keep Go-Live Risk Out of Your Disclosures
Boards and executives cannot eliminate ERP implementation risk, but they can govern it so that operational problems are understood and disclosed accurately before they ever reach the market. The steps below help close the gap between project reality and public statement.
1. Commission Independent Status Verification
Bring in a party from outside the delivery team to validate project health at defined milestones. An external reviewer measures readiness against evidence and gives the audit committee a status it can rely on when it drafts disclosures.
2. Tie Go-Live Decisions to Financial Readiness
Treat the go-live decision as a financial control question as much as a technical one. Confirm that order-to-cash and financial-close processes can operate from the first day, because those functions determine whether reported revenue stays accurate.
3. Align Investor Messaging With Project Evidence
Ensure that anything leadership tells the market about an ERP program traces directly back to verified project data. When a rollout slips, disclose the operational impact promptly rather than restating an optimistic timeline the evidence no longer supports.
4. Engage an Independent ERP Implementation Partner
Work with an ERP implementation partner whose incentives are independent of the software vendor and the systems integrator. That independence is what allows a partner to report an inconvenient finding while there is still time to act on it.
5. Build a Recovery Plan Before You Need One
Establish in advance how the organization will stabilize operations if a go-live falters. A recovery approach agreed ahead of time shortens the distance between a problem surfacing and leadership holding an accurate, disclosable picture of it.
Learn More About ERP Implementation Risk
The Tennant case marks a shift in how the market treats ERP implementation risk. A troubled rollout is no longer only an operational and financial setback, because it now carries disclosure and litigation exposure that reaches the board and the shareholder base. The organizations that handle this well are the ones that build independent verification into the program from the very start.
As an independent ERP services company, Panorama helps leadership audit project health and recover troubled implementations so the business can give the market an accurate account of where a program stands. To see how independent oversight applies to your rollout, explore our ERP project recovery services and contact us below to learn more.
FAQs About ERP Implementation Risk
1. What turns an ERP implementation failure into an investor disclosure problem?
An ERP implementation failure becomes a disclosure problem once its effects reach reported financial results or contradict earlier statements about project health. When a rollout disrupts revenue recognition or forces a change in guidance, the operational issue becomes material information that a public company is obligated to disclose accurately and without undue delay.
2. How is ERP implementation risk different from ordinary project risk?
Ordinary project risk affects cost and schedule. ERP implementation risk reaches further, because the systems involved govern financial reporting and revenue. When they falter, the consequences extend to guidance and investor confidence, which is why many boards now treat the health of an ERP project as a governance matter rather than a purely technical one.
3. Can an independent audit prevent this kind of failure?
An independent project audit cannot guarantee a clean go-live, yet it gives leadership an accurate and evidence-based view of status. That visibility lets executives correct course during testing and calibrate what they tell the market, which is frequently the difference between a managed delay and a public disclosure event.
4. What should a board do when it suspects an ERP rollout is in trouble?
The board should commission an independent assessment instead of relying on status reports from the delivery team. An objective review establishes the true state of the project and clarifies whether the program should continue or be reset. That accurate baseline protects both operations and the integrity of the company’s disclosures.
5. Why do public ERP failures increasingly lead to litigation?
Public ERP failures now intersect with securities law because investors rely on what management says about major transformation programs. When a rollout damages results after leadership signaled that everything was on track, shareholders can allege they were misled. The Tennant investigation shows how directly a troubled ERP project can translate into legal exposure.
