ERP Selection Process: 10 Steps to Choosing the Right ERP Platform

Choosing an ERP platform is not simply a software purchase. It is a business decision that can affect financial reporting, inventory, procurement, operations, customer service, data quality, internal controls, and employee workflows for years.

That is why a structured ERP selection process matters.

The objective is not to find the ERP with the longest feature list, the lowest subscription price, or the most recognizable brand. It is to identify the platform that fits your business requirements, technology environment, budget, growth plans, users, and implementation capabilities.

A disciplined ERP selection process also protects the company from a costly mistake: choosing a system based on a polished sales presentation and discovering during implementation that critical requirements, integrations, data needs, or commercial assumptions were never properly evaluated.

A sound process starts with documented requirements, narrows the market to a manageable shortlist, uses structured demonstrations, evaluates both the software and implementation partner, compares total cost of ownership, and completes reference and contract due diligence before signing.

This guide walks through 10 steps to choosing the right ERP platform, with practical considerations for U.S. businesses.

Key Takeaways

An effective ERP selection process should:

• Define the business problem and desired outcomes before evaluating software.
• Document current-state processes and translate them into prioritized future-state requirements.
• Use pass/fail gates for non-negotiable requirements before applying a weighted scorecard.
• Narrow the market from a 6–10 vendor longlist to 3–5 shortlisted vendors and 2–3 finalists.
• Give every finalist the same real-world business scenarios during product demos.
• Distinguish between native functionality, configuration, extensions, customization, third-party solutions, and genuine product gaps.
• Evaluate the ERP software and implementation partner separately.
• Compare three- to five-year total cost of ownership (TCO), rather than focusing only on subscription or license prices.
• Validate integrations, data migration, security, U.S. accounting and tax requirements, and contract terms before making the final decision.
• Use customer references and implementation evidence to validate vendor claims and key assumptions.

The goal is not to identify the ERP with the most features. It is to identify the platform that provides the right combination of business fit, technical fit, implementation capability, total cost of ownership, and long-term value.

SAP is a common choice for companies looking for a comprehensive ERP platform. If you are evaluating SAP or have already included it in your shortlist, LeverX can help you assess requirements, solution fit, implementation considerations, integrations, and TCO.

Request a free consultation

What Is the ERP Selection Process?

The ERP selection process is the structured method a company uses to determine whether it needs a new ERP, define what the system must accomplish, identify suitable vendors, evaluate alternatives, and select a platform and implementation approach.

A complete selection process typically follows:

Business case → Requirements → Market scan → Shortlist → RFP → Scripted demos → Technical validation → TCO → References → Contract

The process should answer five fundamental questions:

1. What business problems are we trying to solve?
2. What must the new ERP be able to do?
3. Which platforms can support those requirements now and as the company grows?
4. What will the ERP really cost over its lifecycle?
5. Which vendor and implementation team can deliver the expected outcome?

The important distinction is this: ERP selection should be driven by business requirements, not by software demos.

Before You Start: Confirm That You Actually Need a New ERP

One selection mistake happens before the selection process even begins: assuming that replacing the ERP is the only answer.

A structured ERP assessment can help determine whether the organization actually needs to replace the current platform or whether the problem can be addressed through reconfiguration, reimplementation, a new module, or an integration.

ERP assessment and ERP selection are different exercises. An assessment evaluates the system you have; selection evaluates the systems you could buy. Treating the assessment as a gate can prevent the organization from launching an expensive replacement project when a narrower solution would address the underlying problem.

Ask:

• Is the current ERP fundamentally incapable of supporting the business?
• Are the problems caused by the software or by poor configuration?
• Could a new module solve the problem?
• Could an integration eliminate the need for replacement?
• Is the vendor's roadmap aligned with our requirements?
• Would reimplementation be cheaper and less risky than replacement?

If the conclusion is that replacement is necessary, move into the formal selection process.

The ERP Vendor Funnel

Do not evaluate every ERP product on the market in depth.

A practical selection funnel is:

6–10 vendors → 3–5 shortlisted vendors → 2–3 finalists

The purpose of each stage is different.

Longlist: 6–10 vendors

Identify platforms that appear capable of meeting your basic requirements.

Shortlist: 3–5 vendors

Remove systems that fail important functional, technical, geographic, industry, or commercial requirements.

Finalists: 2–3 vendors

Run detailed demos, technical validation, reference checks, and commercial due diligence.

This is more efficient than inviting ten vendors to present polished product demonstrations while expecting the evaluation team to maintain meaningful comparisons across all of them.

The 10 Steps of an ERP Selection Process

1. Define Your Business Goals and ERP Objectives

Start with the business problem, not the software.

Companies replace or upgrade ERP systems for many reasons, including outdated technology, disconnected systems, manual processes, poor reporting, rapid growth, acquisitions, multiple entities, inventory problems, manufacturing complexity, compliance requirements, or an inability to integrate critical applications.

Before researching ERP vendors, define exactly what the project should accomplish.

For example: “We need better reporting.”

is not specific enough.

A measurable objective would be: “Finance should be able to produce consolidated management reports without manually combining data from five separate systems.”

Other objectives might include reducing the monthly close, improving inventory accuracy, reducing manual order entry, consolidating multiple legal entities, automating procure-to-pay approvals, reducing spreadsheet dependency, improving supply-chain visibility, standardizing processes across locations, or supporting expansion into additional U.S. locations.

Define success metrics

Connect each major ERP objective to a measurable outcome.

This creates a stronger basis for evaluating vendors. A system should receive credit for solving the problems that justified the ERP investment—not simply for having a long feature list.

2. Document Current Processes and Pain Points

Before selecting the future system, understand how the business operates today.

Focus on the processes that matter most, such as lead-to-cash, procure-to-pay, record-to-report, plan-to-produce, and inventory-to-fulfillment.

For each process, identify the systems involved, manual steps, spreadsheet dependencies, approval bottlenecks, integration points, reporting gaps, data-quality problems, workarounds, and compliance risks.

This often reveals that what employees describe as a “software problem” is actually a process problem.

A useful way to assess the current state is to classify processes as:

• Keep - the process works well.

• Improve - the process works but should be automated or streamlined.

• Redesign - the process is inefficient and should change.

• Eliminate - the process exists largely because of limitations in the current environment.

Do not automatically reproduce the old system in the new ERP. The objective is to define the future-state process, not merely document the legacy one.

3. Create and Prioritize ERP Requirements

Your requirements document is one of the most important deliverables in the ERP selection process.

Do not start with a generic list of hundreds of software features. Start with business processes and translate those processes into specific requirements.

Requirements will usually span finance, operations, commercial processes, technology, reporting, and automation. Depending on the organization, this can include general ledger, accounts payable and receivable, fixed assets, budgeting, procurement, inventory, warehouse management, manufacturing, order management, supply-chain planning, projects, APIs, integrations, identity management, data migration, security, dashboards, workflow automation, and analytics.

The important point is not to produce the longest possible list. It is to capture the capabilities that are genuinely important to the future operating model.

Prioritize every requirement

A practical model is:

• Must-have - the project cannot succeed without it.

• Should-have - important, but there may be a reasonable workaround.

• Nice-to-have - useful but not selection-critical.

• Out of scope - explicitly excluded from the project.

The distinction between requirements and selection criteria is important:

Requirements define what the ERP must do.

Selection criteria define how you will compare vendors against those requirements.

4. Establish Selection Criteria, Pass/Fail Gates, and a Scorecard

Once requirements are documented, build the evaluation framework.

Do not rely on a single overall score from day one. Use a two-stage model: eliminate genuine non-negotiable gaps first, then compare the remaining vendors using weighted criteria.

Stage 1: Pass/Fail Gates

Some requirements should be non-negotiable.

Typical gates may cover security and compliance, critical functional capabilities, business-critical integrations, required U.S. accounting and legal-entity capabilities, and commercial viability.

A vendor that fails a genuine non-negotiable requirement should not remain a finalist simply because it scores well elsewhere.

Stage 2: Weighted Scorecard

For the remaining vendors, use weighted criteria.

The exact weights should reflect your organization. A manufacturer may weight manufacturing functionality heavily, while a rapidly growing company may place more emphasis on integrations and scalability.

Use a consistent scoring scale

A simple five-point scale works well:

Base scores on evidence, not impressions.

Score software and implementation partners separately

An ERP can be an excellent product while the proposed implementation partner is a poor fit.

Evaluate ERP software fit and implementation partner fit as separate dimensions, then consider both together during the final decision.

For companies with SAP in their environment, LeverX’s SAP consulting team can help assess the current landscape, plan modernization, and evaluate deployment options.

request a free consultation

5. Research ERP Vendors and Build a Shortlist

Now research the market.

For each candidate, consider industry experience, company size, geographic coverage, U.S. customer base, deployment model, product roadmap, integration capabilities, security posture, implementation ecosystem, support model, customer references, vendor stability, and pricing model.

Do not shortlist a system simply because another company uses it.

The question is: Does this ERP fit our business?

Evaluate vendor viability

Look beyond the sales presentation. Ask how many customers use the specific product, how many are similar to your company, how much relevant industry and U.S. experience the vendor has, what the product roadmap looks like, how frequently the product changes, and how dependent your proposed architecture would be on third-party applications.

The goal is not merely to identify a capable product. It is to establish whether the vendor is likely to remain a suitable partner throughout the ERP lifecycle.

6. Create an ERP RFP and Standardize Vendor Responses

For a larger or more complex project, an ERP RFP can dramatically improve comparability.

A complete RFP typically covers the company and project, scope, functional and technical requirements, integrations, implementation approach, data migration, training and change management, pricing and TCO, security and compliance, vendor information, support and service levels, references, and submission requirements.

Ask every vendor the same questions

This is critical.

You should be able to compare Vendor A with Vendor B without having to interpret completely different sales narratives.

High-value questions include:

• Which of our requirements are supported out of the box?

• Which require configuration?

• Which require customization?

• Which depend on a third-party product?

• Which requirements cannot be met today?

• What implementation activities are excluded from the proposal?

• What ongoing costs should we expect after go-live?

• What is the three- to five-year TCO?

• What happens to our data if we terminate the agreement?

• How are renewal price increases handled?

The RFP should create comparable evidence, not simply generate longer vendor proposals.

7. Run Scripted ERP Demos Using Real Business Scenarios

This should be one of the most heavily weighted parts of the evaluation.

Do not ask vendors: “Can your ERP handle inventory?”

Ask: “Show us what happens when a customer orders a product that is out of stock.”

Then require the vendor to demonstrate the complete flow: Order → availability → replenishment → fulfillment → shipment → invoice → payment

For finance, you might require: Journal entry → close → consolidation → management reporting

For procurement: Requisition → approval → purchase order → receipt → invoice → payment

For manufacturing: Demand → planning → production order → material issue → completion → costing

Give every vendor the same scenarios and assumptions.

Then classify the result:

This distinction is critical.

A vendor saying: “Yes, we support that.” is not enough.

You need to know how it is supported and what it will cost to implement and maintain.

8. Validate Integrations, Data, Security, and U.S. Requirements

ERP software rarely operates alone.

Map every business-critical system that needs to exchange data with the ERP, such as CRM, ecommerce, banking, payroll, tax systems, warehouse management, manufacturing systems, EDI, payment platforms, business intelligence, data warehouses, and customer portals.

For each integration, determine whether a native connector or API is available, whether middleware is required, who owns the integration, how data is synchronized, how errors are handled, how the integration is monitored, and what is included in the implementation quote.

Validate data requirements

Data migration deserves the same scrutiny as functional requirements. Ask what migration tools are provided, which formats are supported, how much historical data can be migrated, who cleanses the data, how many test migrations are included, and how reconciliation will be performed.

Validate security

Evaluate the proposed architecture for role-based access, least privilege, MFA, single sign-on, encryption, audit logging, backup and recovery, incident response, vendor access, data export, and data retention.

U.S.-specific considerations

For a U.S. company, requirements may also include U.S. GAAP reporting, multi-entity consolidation, sales-tax integrations, 1099 workflows, ACH and U.S. banking integrations, EDI, state-level tax processes, industry-specific regulations, and U.S. customer references.

These should be treated as selection requirements where they materially affect the business—not simply added as generic checklist items.

9. Calculate Total Cost of Ownership

The cheapest ERP subscription is not necessarily the cheapest ERP.

Compare total cost of ownership (TCO) over at least three to five years.

Ask every finalist for the same cost model and compare:

Year 1 → Year 2 → Year 3 → Year 4 → Year 5

This is especially important when vendors use different pricing structures. A lower subscription price can be offset by implementation effort, additional modules, integration costs, customization, or higher internal resource requirements.

10. Complete Due Diligence and Make the Final Selection

The final decision should not simply go to the vendor with the highest score.

Scores are evidence - not the decision itself.

Before selecting the ERP, verify the assumptions behind the score.

Conduct customer reference checks

Speak with customers of similar size, industry, complexity, geography, and ERP scope.

Ask:

1. Was the project delivered on time?
2. Did it stay within budget?
3. What went wrong?
4. How much customization was required?
5. How difficult was data migration?
6. How well did integrations perform?
7. How was the implementation partner?
8. What happened during go-live?
9. How responsive is support?
10. What would you do differently?
11. Would you choose the same ERP again?
12. Would you choose the same implementation partner again?

Reference calls are most useful when they test the assumptions that influenced your evaluation rather than simply asking whether the customer is satisfied.

SAP can support complex business processes, financial management, compliance requirements, and integrations across your organization. LeverX can help you evaluate SAP for your business and prepare for implementation.

Request a free consultation

ERP Contract Terms to Validate Before Signing

The contract deserves as much attention as the demo. A strong product fit can still lead to unexpected costs or project risk if important commercial, implementation, data, or service assumptions are not reflected in the agreement.

Before signing, review the contract together with the software agreement, implementation statement of work, pricing proposal, and any related service agreements. Make sure the terms match the assumptions used during the ERP selection process.

Pricing

Look beyond the initial subscription or license price. Confirm how users are defined, what is included in each pricing tier, how additional users and modules are charged, and whether prices can increase at renewal.

Also check for costs that may sit outside the headline price, such as additional environments, storage, integrations, premium support, training, or third-party components. If possible, document price protection and the assumptions behind the three- to five-year TCO model.

Implementation

Make sure the implementation scope is specific enough to measure.

Confirm which services are included, what the implementation partner is responsible for, and what the customer must provide. Review expected deliverables, project milestones, acceptance criteria, resource requirements, travel or other expenses, and change-order rates.

Pay particular attention to assumptions around data migration, integrations, customization, testing, training, and go-live support. A service that was discussed during the sales process but is not included in the statement of work may become an additional cost later.

Data

Confirm who owns the data stored in the ERP and what rights the company has to access and export it.

The agreement should address data export formats, extraction procedures, retention periods, backup responsibilities, and assistance during termination or migration to another system. Also clarify whether there are fees for large-scale data extraction or transition services.

Data terms become especially important when the ERP contains financial records, customer information, supplier data, and operational history that the company may need to retain after the contract ends.

Service

Review how ongoing support will work after implementation.

Check the available support tiers, service-level commitments, response and resolution targets, support hours, escalation procedures, and responsibilities for critical incidents. Confirm whether standard support covers the company's operating hours and locations or whether additional coverage is required.

If the ERP is business-critical, make sure the contractual service commitments are consistent with the operational requirements identified during the selection process.

Security

The contract should reflect the security requirements established during technical due diligence.

Review obligations related to data protection, security controls, incident notification, access management, subprocessors, data residency, business continuity, and disaster recovery. Where applicable, check audit rights and the vendor's responsibilities for security assessments or compliance documentation.

Also clarify how security incidents will be communicated, what information the vendor must provide, and what happens if a security requirement changes during the contract term.

Termination

Understand what happens if the relationship ends.

Confirm termination rights, notice periods, data extraction procedures, transition assistance, and any fees associated with moving away from the platform. Check how long the company will have access to its data and in what format it will be provided.

If the ERP is deeply integrated into finance, operations, ecommerce, or other core systems, transition assistance can be particularly important. The contract should provide a realistic path for retrieving data and maintaining business continuity during a transition.

These terms can materially change the economics and risk of an ERP decision. They should therefore be reviewed as part of the ERP selection process, not treated as an administrative step after the vendor has already been chosen.

ERP Selection Scorecard Example

A practical software scorecard might look like this:

Do not use the scorecard as an automatic winner-selection mechanism.

Review the evidence behind each score and maintain a record of:

Requirement → Evidence → Demo result → Vendor response → Assumptions → Risk

That creates an audit trail for the final decision and makes disagreements easier to resolve.

ERP Selection Criteria Checklist

A strong ERP evaluation should cover five broad areas: business fit, functional fit, technical fit, vendor and implementation fit, and financial fit. The relative importance of each category should reflect the organization's specific priorities, risks, and growth plans.

Business Fit

Start with the business problems that triggered the ERP project. Does the solution address the most important operational, financial, reporting, or control issues? Consider whether it supports the future operating model, organizational structure, geographic footprint, and expected growth.

The ERP should fit not only how the business operates today but also how it expects to operate over the next several years.

Functional Fit

Evaluate the capabilities that are critical to the organization's core processes, including finance, procurement, inventory, supply chain, manufacturing, order management, projects, reporting, and automation.

Do not evaluate functionality based only on whether a vendor answers "yes." Determine whether the capability is available natively, requires configuration, depends on an extension or third-party solution, or requires custom development. These differences can affect implementation effort, cost, and long-term maintainability.

Technical Fit

Assess how well the ERP fits into the existing technology environment.

Review integrations and APIs, data migration, security architecture, identity and access management, reporting and analytics, scalability, environments, backup and recovery, and the ability to exchange data with critical business systems.

Technical fit should also account for future requirements. A solution that works with the current architecture may create limitations as transaction volumes, users, entities, or integrations increase.

Vendor and Implementation Fit

The software is only one part of the ERP decision. Evaluate the vendor and implementation partner separately.

Consider relevant industry experience, similar customer references, implementation methodology, available resources, product roadmap, support model, geographic coverage, and experience with the company's specific business and technical requirements.

The key question is not simply whether the vendor can demonstrate the required functionality, but whether the vendor and implementation team can realistically deliver and support it.

Financial Fit

Compare the full cost of ownership rather than focusing on the initial subscription or license price.

The financial model should account for implementation, data migration, integrations, customization, training, support, upgrades, additional modules or users, internal resources, and other ongoing costs. A three- to five-year TCO model provides a more useful basis for comparing ERP options than the initial software price alone.

The important point is that these categories provide a framework, not a universal scoring formula. Weight them according to the organization's specific priorities, business risks, technical environment, and long-term objectives.

Common ERP Selection Mistakes to Avoid

Starting vendor conversations before defining requirements

This allows vendor demos to shape the requirements instead of the business defining what it needs.

Requirements should be sufficiently developed before vendors are evaluated in depth.

Evaluating too many vendors

Ten product demos may sound thorough, but the evaluation team can struggle to maintain meaningful comparisons across that many platforms.

A structured 6–10 → 3–5 → 2–3 funnel is generally easier to manage.

Letting vendors script the demos

A vendor-controlled demo emphasizes what the vendor wants to demonstrate. Your team should control the scenarios and define what constitutes a satisfactory demonstration.

Comparing only software

The implementation partner, delivery model, support structure, and actual consultants can materially affect the outcome.

Choosing based on price

A lower subscription cost can be offset by greater implementation effort, integrations, customization, support, or internal resource requirements.

Treating all “yes” answers as equal

There is a major difference between native functionality and custom development requiring additional consulting and maintenance.

Ignoring the contract until the end

Pricing protection, renewal terms, user definitions, implementation scope, data rights, and termination terms can materially affect the five-year cost of ownership and should be reviewed before the final selection.

How Long Does ERP Selection Take?

ERP selection timelines vary by company size, complexity, and the number of stakeholders involved.

These are planning ranges, not guarantees. Complex integrations, multiple legal entities, manufacturing or supply chain requirements, strict security and compliance reviews, and a large number of decision-makers can extend the timeline regardless of company size.

The most common causes of delay are unclear requirements, limited stakeholder availability, too many vendors, slow RFP responses, scheduling issues, unresolved technical questions, and prolonged contract negotiations.

The goal is to keep the selection process thorough but focused: long enough to validate the decision, but structured enough to maintain momentum and stakeholder engagement.

How Long Does ERP Implementation Take After Selection?

Selection and implementation are separate timelines.

Implementation can range from several months to multiple years depending on company size, number of entities, integrations, data complexity, customization, process redesign, and organizational readiness.

A useful planning distinction is:

• Small organizations: often several months
• Mid-market organizations: commonly several months to a year or more
• Large or highly complex enterprises: potentially a year or longer

These ranges should be treated as planning assumptions rather than fixed benchmarks.

The important point is that selection is only one stage of the ERP lifecycle. The platform you choose may remain central to the business for many years, so saving a few weeks during selection is not necessarily valuable if it reduces the quality of the decision.

What Is the Best Way to Compare ERP Systems?

The most reliable approach is to evaluate each ERP system against the same requirements, scenarios, and commercial assumptions. This makes differences easier to identify and reduces the influence of sales presentations or unsupported stakeholder preferences.

A practical ERP comparison framework is:

Requirements → Pass/Fail Gates → Shortlist → RFP → Scripted Demos → Technical Validation → TCO → References → Contract Due Diligence → Final Selection

The purpose is not to produce a purely numerical answer, but to create a consistent evidence base for the final decision.

How LeverX Can Help With SAP ERP Selection

If SAP is on your shortlist, the next step is to look beyond product features and assess how the solution fits your business processes, integrations, data, compliance requirements, and growth plans.

LeverX helps companies evaluate SAP solutions against real business requirements and prepare for implementation. Our SAP experts can support requirements assessment, solution evaluation, integration and data planning, TCO analysis, and implementation planning.

This approach helps identify potential gaps and implementation considerations before the final SAP decision is made.

See how SAP can fit your business processes, technology landscape, and growth plans.

Explore SAP with LeverX

Final Thoughts: The Best ERP Is the Best Fit, Not the Best Demo

The right ERP selection process is not about finding the platform with the most features.

It is about finding the platform that can support the business processes that matter, integrate with the systems the company depends on, meet security and compliance requirements, scale with the organization, and deliver acceptable value over its lifecycle.

The strongest ERP selections share a common discipline: requirements are documented before vendors are evaluated, non-negotiable requirements are treated as gates, the vendor list is deliberately narrowed, finalists receive the same demo scenarios, native functionality is distinguished from customization, software and implementation partners are evaluated separately, TCO is compared using the same assumptions, customer references are treated as evidence, and contract terms are part of the selection rather than an administrative step afterward.

A useful final framework is:

Business Case → Requirements → Gates → Shortlist → RFP → Scripted Demos → Scorecard → TCO → References → Contract

That process turns ERP selection from a vendor-driven buying exercise into a structured business decision.

The goal is not to answer: “Which ERP has the most features?”

It is to answer: “Which ERP can reliably support the business we are building, at a cost and risk we are prepared to accept?”

That is the foundation of a successful ERP selection.

ERP Selection FAQ

What are the main steps in ERP selection?

The main steps are to confirm the business case, define goals, document current processes, create requirements, establish selection criteria, build a shortlist, issue an RFP when appropriate, run scripted demos, validate technical and security fit, compare TCO, conduct references and due diligence, and finalize the contract.

How many ERP vendors should we evaluate?

A practical funnel is approximately 6–10 vendors on the longlist, 3–5 on the shortlist, and 2–3 finalists. The exact number depends on project complexity and the number of genuinely relevant products.

What should I look for when choosing an ERP?

Focus on functional fit, technical and integration fit, scalability, security, vendor viability, implementation capabilities, user experience, support, and total cost of ownership. Most importantly, evaluate whether the system solves the specific business problems that triggered the project.

What is an ERP selection scorecard?

An ERP selection scorecard is a weighted evaluation framework used to compare vendors consistently. It typically covers functional fit, technical fit, implementation, TCO, security, scalability, and vendor support.

Software and implementation partners can be scored separately because product fit and delivery capability are different considerations.

Should ERP price be the most important selection criterion?

Price should be evaluated alongside functionality, implementation effort, risk, scalability, and long-term TCO. A cheaper ERP can become more expensive if it requires significant customization, integration work, workarounds, or additional support.

Disclaimer: The ERP selection timelines, evaluation criteria, cost considerations, and recommendations presented in this article are provided for general informational purposes. Actual ERP selection requirements and outcomes vary depending on business size, industry, processes, technical environment, compliance requirements, and implementation scope. Companies should evaluate ERP solutions based on their specific business needs and conduct appropriate technical, financial, security, and contractual due diligence before making a purchasing decision.