7 ERP Selection Mistakes That Cost CFOs Time, Money, and Momentum
Mike Turner is an ERP Growth Advisor and a contributor to Brainz Magazine. He works with Chief Financial Officers (CFOs), Controllers, private equity firms, family offices, and growth-oriented organizations on finance infrastructure, operational scalability, and Enterprise Resource Planning (ERP) strategy.
An Enterprise Resource Planning (ERP) decision can begin with a familiar frustration. Reporting takes too long, spreadsheets keep multiplying, or the finance team spends too much time moving information between systems. The temptation is to start scheduling demonstrations. Seeing new software feels like progress. But before evaluating platforms, finance leaders need a clear understanding of what must change and whether a new ERP is the right way to achieve it.
A successful selection process connects business priorities, day-to-day workflows, implementation capacity, and measurable outcomes. These seven mistakes provide a useful starting point for Chief Financial Officers (CFOs) preparing to evaluate their options.
1. Starting with demonstrations before defining requirements
A polished demonstration shows what a platform can do. It does not necessarily show how well it will handle your organization’s work.
Without clear requirements, an evaluation can become a comparison of attractive dashboards and individual preferences. The team may leave impressed while still lacking answers to its most important questions.
Before meeting with vendors, document the workflows that create the greatest difficulty. Where does information get reentered? Which reports require manual reconstruction? Where do approvals stall? What becomes harder when another entity or location is added?
Separate essential requirements from preferences. Then ask each vendor to demonstrate the same business scenarios. For example, “better reporting” is too broad to evaluate consistently.
“Produce a consolidated monthly report across our entities without manually combining separate spreadsheets” gives everyone a more useful objective.
2. Expecting new software to fix unclear processes
A system change is an opportunity to examine how work gets done. If approval responsibilities are unclear, account definitions are inconsistent, or departments disagree about who owns information, those issues need attention during the project. Otherwise, the implementation may reproduce existing confusion in a different platform.
Map the current process and decide what should change. Identify who enters information, who reviews it, who approves it, and who uses the result.
Some improvements may be possible before implementation begins. Others will depend on the capabilities of the selected platform. Making that distinction helps establish a realistic scope. The goal is to give the new system a well-defined process to support.
3. Overlooking integrations and data movement
Accounting rarely operates in isolation. Billing, payroll, expenses, banking, customer management, and industry-specific applications may all supply information that finance needs.
Ask how those connections would work in your environment:
Which information moves between systems?
In which direction?
How frequently?
Who resolves an error?
What happens when a transaction changes after it has already transferred?
A statement that two systems “integrate” leaves many practical questions unanswered. Confirm what the proposed connection includes, what requires additional configuration, and who is responsible for maintaining it.
Consider a billing process that still requires finance to export, modify, and upload a file every week. If removing that work is part of the business case, the evaluation should demonstrate how the proposed solution addresses it.
4. Leaving daily users out of the evaluation
The CFO brings the strategic priorities. Controllers, accounting managers, and other daily users bring the details needed to test whether the proposed approach will work.
They know which reconciliations are difficult, which exceptions recur, and which spreadsheet contains a step that never appears in the official process documentation.
Include those people early, with clear responsibilities. Ask them to supply real scenarios and evaluate how each option handles their work. Their involvement also helps expose trade-offs.
A workflow that improves executive visibility may require changes in how another team captures information. Those changes deserve discussion before a purchase decision. Leadership should remain accountable for the decision while ensuring that operational knowledge shapes it.
5. Comparing license prices without comparing total costs
The subscription or license price is one part of the commitment. A useful comparison should also consider implementation, data preparation, integrations, training, internal staff time, ongoing support, and any additional capabilities required for the intended scope.
Ask vendors and implementation partners to make their assumptions explicit. What is included? What is excluded? Which responsibilities belong to your team? What circumstances could change the estimate?
Evaluate costs over a consistent period and against a consistent set of requirements. Then connect the investment to specific outcomes. Those might include fewer manual handoffs, more timely reporting, or the ability to manage additional entities with the existing team. Establish a baseline so that expectations can be assessed after implementation.
6. Underestimating internal workload and readiness
An implementation partner can provide expertise and execution support, but your organization still has decisions to make.
Someone must validate data, resolve process questions, test workflows, approve configurations, and help users prepare. That work competes with month-end close, audits, budgeting, and daily operations.
Before agreeing to a timeline, identify an internal owner and the people who will support the project. Discuss their availability and the periods when their capacity will be limited.
Clarify what information must be cleaned up or prepared. Decide how much historical data is needed and how the team will verify that the new environment is ready.
A target go-live date becomes more useful when it is supported by a workable plan, named responsibilities, and sufficient time for testing.
7. Choosing an implementation partner without testing the fit
The implementation team will help translate business requirements into working processes. Evaluate that team with the same care you apply to the software.
Ask about experience with organizations that share your relevant complexities, such as multiple entities, specific reporting requirements, difficult integrations, or a small internal finance team.
Understand who will perform the work. Discuss how scope changes are handled, how issues are escalated, and what support looks like after go-live.
References are most useful when the conversations address comparable challenges. Ask what required more work than expected, how problems were handled, and what the client would do differently. Look for a partner who asks detailed questions, explains trade-offs clearly, and makes responsibilities visible.
Before you replace, confirm what needs to change
A thorough evaluation may lead to an ERP investment. It may also show that the current platform can support the business longer with better processes, configuration, or connected applications.
Revenue alone should not determine the answer. Consider operational complexity, reporting requirements, control needs, and the work required to keep the current environment functioning.
For some organizations, postponing replacement while addressing specific weaknesses is a sound decision. For others, the accumulated workarounds make a broader change increasingly necessary.
Before scheduling the next demonstration, write down:
The three most important workflow problems.
Their effect on time, accuracy, visibility, or business decisions.
What a successful change would accomplish.
Who needs to participate in evaluating and implementing that change.
Those answers give the selection process direction. They also help the CFO explain why the investment matters, what the organization is committing to, and how success will be judged.
Read more from Mike Turner
Mike Turner, Finance Leadership & ERP Strategy
Mike Turner is a finance leadership advisor, ERP strategist, and enterprise account executive who helps CFOs, Controllers, Private Equity firms, Family Offices, and executive leadership teams navigate growth, operational complexity, and financial transformation. With a background in enterprise SaaS, finance technology, and strategic business development, he specializes in helping organizations improve financial visibility, operational efficiency, and scalability through modern finance infrastructure and business technology solutions.
