Most ERP selection processes fail not because companies choose the wrong software, but because they never clearly defined what “right” looked like. Without specific, measurable selection criteria, evaluations devolve into vendor demos, gut feelings, and the preferences of whoever has the most influence in the room. Months later, your team is arguing about which platform felt better rather than which one actually met your requirements.

This guide helps you build selection criteria that are specific enough to be useful, weighted appropriately for your business, and scored consistently across all vendors. The goal is a selection process that produces a defensible decision — one your implementation team and executive sponsors can stand behind even when the going gets hard.

The Four Dimensions of ERP Selection Criteria

Effective ERP selection criteria span four major dimensions: functional, technical, vendor, and cost. Each dimension matters, but not equally for every organization. Your weighting should reflect your business’s specific priorities and risk tolerance.

Functional Criteria

These are the capabilities the ERP needs to provide to support your business operations. Functional criteria are where most teams focus their attention — and rightly so, because an ERP that cannot support your core processes will fail regardless of how technically excellent it is.

Functional criteria should be written as specific capabilities, not vague desires. “Good inventory management” is not a useful criterion. “Ability to manage inventory across five warehouse locations with lot and serial number tracking and automatic reorder points” is a criterion you can test.

Break functional criteria into must-have (eliminators — any vendor that cannot demonstrate this capability is disqualified) and nice-to-have (differentiators — capabilities that add value but are not deal-breakers).

Technical Criteria

Technical criteria cover how the platform is built, deployed, and maintained. These matter because even a functionally excellent ERP can become a long-term liability if it is built on outdated architecture, difficult to integrate, or dependent on skills that are hard to hire.

Technical criteria include deployment model (cloud, on-premises, hybrid), integration mechanisms (API quality, pre-built connectors), development platform (for customizations), security certifications, uptime SLAs, and mobile capabilities.

Vendor Criteria

The ERP vendor is a long-term partner. Vendor criteria assess the health and reliability of that partnership beyond the software itself. A financially unstable vendor, a vendor with poor support practices, or a vendor whose roadmap is moving away from your use case creates risk that the software’s current functionality cannot offset.

Vendor criteria include financial stability, customer retention rate, support tier options and responsiveness, implementation partner ecosystem, product roadmap transparency, and references from similar customers.

Cost Criteria

Cost criteria go beyond comparing sticker prices. Total cost of ownership (TCO) over a multi-year period is what matters — and it includes software licensing, implementation services, training, customization, integration development, ongoing support, and infrastructure.

Vendors are not always forthcoming about full cost implications, so effective cost criteria force them to be specific about what is included and what is not.

How to Weight Your Criteria

Not all criteria matter equally. Weighting your criteria forces your team to make explicit decisions about priorities — which is valuable in itself, because it surfaces disagreements that should be resolved before you evaluate vendors, not after.

A practical approach is to allocate percentage weights across the four dimensions first, then weight criteria within each dimension.

Dimension	Typical Weight Range	Why It Varies
Functional	40–60%	Higher weight for operationally complex businesses
Technical	15–25%	Higher weight for businesses with complex integration needs
Vendor	15–25%	Higher weight for businesses with low internal ERP expertise
Cost	10–20%	Higher weight for budget-constrained organizations

Within the functional dimension, weight individual criteria by business impact. Your most critical processes — the ones that would break your business if they were not supported — should have the highest weights.

Sample Selection Criteria Table

Here is an example criteria table that your team can adapt. Scores are typically 1–5 (1 = does not meet requirement, 5 = fully meets or exceeds requirement).

Criterion	Dimension	Weight	Vendor A Score	Vendor B Score	Vendor C Score
Multi-entity financial consolidation	Functional	8%	5	4	3
Multi-currency transactions	Functional	5%	5	5	4
Inventory management across 5+ locations	Functional	7%	4	5	4
Production scheduling (discrete mfg)	Functional	6%	3	5	4
Native API / REST integration	Technical	5%	5	4	5
Mobile access for warehouse operations	Technical	4%	3	5	4
SOC 2 Type II certification	Technical	4%	5	5	5
Cloud uptime SLA (99.5%+)	Technical	4%	5	5	3
Vendor financial stability	Vendor	5%	5	4	4
Implementation partner ecosystem	Vendor	5%	5	4	3
Customer retention / references	Vendor	4%	4	4	3
3-year TCO within budget	Cost	8%	3	4	5
Implementation cost transparency	Cost	5%	3	4	4
Weighted Total		70%	3.9	4.4	3.8

Weighted scores are calculated by multiplying each criterion score by its weight and summing the results. This table format makes the trade-offs visible and gives your selection committee a shared view of how vendors compare.

Avoiding Criteria That Are Too Vague to Be Useful

Vague criteria produce vague evaluations. Here are common examples of criteria that need sharpening before they are useful:

Too vague: “Good reporting capabilities” Specific: “Real-time financial reporting with drill-down to transaction level, including P&L by entity, location, and department, with role-based access controls on report data”

Too vague: “Easy to use” Specific: “End users with no ERP experience can complete standard transactions (order entry, purchase requisition, expense submission) after one day of training”

Too vague: “Good vendor support” Specific: “Dedicated support contact available for issues rated P1 (system unavailable) with response SLA under 30 minutes; average ticket resolution time for P2 issues under 48 hours”

Too vague: “Integration capabilities” Specific: “Native REST API with documented endpoints for all core modules, rate limit above 10,000 requests per day, and OAuth 2.0 authentication support”

The test for whether a criterion is specific enough: Could you write a scripted demo scenario or a request-for-information question that produces a yes/no or measurable answer? If not, sharpen it further.

Building Your Scoring Methodology

Who Scores?

Involve the right people in scoring — not just IT and finance, but operational department leads who will use the system. A five-person evaluation committee with representatives from operations, finance, IT, and a major end-user group produces better scores than a committee of only IT and finance staff.

When Do You Score?

Score each criterion after each vendor demonstration, not at the end of all demonstrations. Memory is unreliable and recency bias is real — you will remember the last demo most vividly and score earlier vendors less accurately if you wait.

How Do You Handle Disagreement?

When committee members score the same criterion very differently, do not just average the scores — discuss the discrepancy. Differences in scores often reveal different assumptions about how your business will use the feature, or different information about how the vendor presented it. Resolving these disagreements produces more accurate scores and better-aligned expectations.

Must-Have Criteria as Disqualifiers

Apply must-have criteria as gates before weighted scoring. Any vendor that cannot demonstrate a must-have criterion at an acceptable level is disqualified before entering the weighted scoring. This prevents a vendor with a very low total cost from advancing despite missing a critical functional requirement.

Common Mistakes in ERP Selection Criteria

Writing a Wish List Instead of Requirements

Your team will generate many ideas for what would be nice to have in an ERP. Filter the wish list ruthlessly. Ask: “Would the lack of this capability genuinely prevent us from operating effectively?” If the answer is no, it may not warrant a high weight — or even inclusion — in the criteria.

Letting One Stakeholder Dominate the Criteria

When criteria are written primarily by the IT team, the result is often technically sophisticated but functionally thin. When written primarily by a single department head, the criteria reflect that department’s priorities at the expense of others. Criteria-building should be collaborative with structured input from all major functional areas.

Treating All Criteria as Equally Important

If your criteria matrix has thirty items all weighted at equal percentages, the result will not differentiate meaningfully between vendors. Weight criteria to reflect genuine business priorities.

Ignoring the Implementation and Support Experience

The best-scoring software with the worst implementation experience is still a bad outcome. Include vendor support quality, partner ecosystem strength, and implementation methodology as weighted criteria — not afterthoughts.

Frequently Asked Questions

How many criteria should we include in our evaluation? Between twenty and forty criteria is a practical range for most evaluations. Fewer than twenty and you miss important dimensions; more than forty and the process becomes unwieldy and the scores lose precision because no individual criterion has meaningful weight. Focus on criteria that are both important to your business and likely to differentiate between the platforms you are evaluating.

Should we include cost as a criterion or evaluate it separately? Including total cost of ownership as a weighted criterion alongside functional and technical criteria gives you an integrated view of the trade-off between capability and cost. However, some organizations evaluate cost separately to prevent low-cost vendors from masking functional gaps. A hybrid approach — use functional and technical criteria to create a shortlist, then evaluate cost within the shortlist — works well.

What is the right weighting for must-have versus nice-to-have criteria? Must-have criteria function as gates — vendors that cannot meet them are disqualified regardless of weight. Nice-to-have criteria enter the weighted scoring, with weights reflecting how much they would contribute to business value. A useful rule: if missing a capability would require a significant workaround, treat it as a must-have; if it would be inconvenient but manageable, treat it as a weighted differentiator.

Can we use the same criteria framework for both our initial vendor shortlisting and our final evaluation? Yes, and you should. Consistency across the evaluation ensures you are comparing vendors on the same basis throughout. You may refine individual criteria as you learn more during the process — for example, if vendor demonstrations reveal that a criterion you thought was differentiating is actually standard across all platforms, you can adjust its weight. Document any changes and apply them retrospectively to all scored vendors.