ERP Evaluation Criteria: What to Score Vendors On
Turn this article into takeaways for your work.
Each assistant summarizes the article only for you and suggests best practices for your work.
Updated September 2026.
ERP selection fails differently than most software decisions. A CRM that doesn't fit gets swapped out in six months with limited damage. An ERP that doesn't fit gets customized around for three years, breaks on every version upgrade, and takes the finance close down with it when it finally gives out.
Most evaluation templates hand a committee the same categories used for any SaaS purchase: features, integrations, price, support. That misses what actually separates a good ERP decision from an expensive mistake: whether the data model matches how your entities really work, whether the implementation partner can execute, and whether what you buy today survives the version after next. Our full ERP buying guide covers the end-to-end process; this piece is the scoring checklist to run during evaluation itself.
Key Facts: ERP evaluation
- Panorama Consulting's 2026 ERP Report (170 organizations surveyed, median annual revenue $200.5 million) found a median project timeline of 9 months, with more than a quarter of projects still going over budget and almost a quarter going over schedule.
- Of the projects that went over budget, the most common cause was an unexpected need for additional technology, not scope creep from the buyer. Of the ones that went over schedule, the most common cause was internal organizational resistance, not the software itself (Panorama Consulting, 2026 ERP Report).
- Microsoft openly publishes Business Central list pricing at $80/user/month for Essentials and $110/user/month for Premium, both paid yearly (Microsoft), despite the tier being routinely described as "quote-based" in buyer content. Published list pricing is the exception in this category, not the rule, which is why per-user comparison shopping breaks down here.
What makes ERP evaluation criteria different
A CRM evaluation asks whether reps will use it. An accounting software evaluation asks whether the ledger closes cleanly. An ERP evaluation asks both at once, across every department, entity, and currency, plus whether the data model can hold your business structure without a workaround.
Generic vendor scorecards undersell this risk. A general SaaS vendor evaluation treats implementation as a line item. In ERP, implementation quality often matters more than the software: the same platform can be a smooth 6-month rollout with one partner and an 18-month recovery project with another. Score the partner as rigorously as the platform.
The ERP evaluation criteria checklist
Score each criterion 1-5 during demos, reference calls, and (ideally) a paid discovery workshop with your shortlist. The columns below describe what a strong answer looks like and what should knock a vendor down a tier.
| Criterion | What good looks like | Watch out for |
|---|---|---|
| Functional fit per module | Native modules for your actual workflows (manufacturing, distribution, services, retail) | "Checkbox" modules that need a costly add-on or a partner build to actually function |
| Suite vs. best-of-breed core | A deliberate choice: one vendor for everything, or a strong core plus satellites on clean APIs | Buying a full suite and only using the finance module, at suite-wide pricing |
| Data model fit | Native multi-entity, multi-subsidiary, multi-currency, and multi-book consolidation | "Multi-entity support" that means separate files reconciled by hand in a spreadsheet |
| Implementation partner quality | A certified partner with live reference clients in your industry and revenue band | A reseller who's never implemented your specific module combination |
| Customization vs. configuration | Requirements met through configuration (fields, workflows, approvals) that survives upgrades | Custom code sold as a "simple modification" that breaks on every future upgrade |
| Integration with your stack | Open REST APIs and native connectors to your e-commerce, CRM, payroll, and warehouse tools | An ERP that treats every integration as a separate paid services project |
| Total cost of ownership | Transparent modeling across license, modules, implementation, and support | A quote covering only the license, with implementation left "to be scoped" |
| Industry compliance and reporting | Pre-built workflows for your regulatory world: lot tracking, revenue recognition, grant accounting | Generic reporting that needs a separate BI layer just to pass an audit |
| Change management and adoption | Vendor-provided training, a defined change plan, and a realistic rollout pace | A vendor that treats change management entirely as your problem |
| Vendor viability over a decade | A stable roadmap, an active partner ecosystem, and a track record that outlasts your tenure | Sunsetting the on-premises version you were sold two years ago |
Suite vs. best-of-breed: decide this before you demo anything
This is the fork most CRM-style checklists never have to make, and it changes which criteria matter most. Decide it early, before you waste time on demos that were never going to fit.
| Approach | How it works | Best for | Watch out for |
|---|---|---|---|
| Full suite | One vendor covers finance, inventory, manufacturing, HR, and CRM natively | Teams that want one data model and one support relationship | Paying for modules you'll never fully use; slower to adapt any single module |
| Best-of-breed core plus satellites | A strong financial/operations core (NetSuite, Business Central, Acumatica) connected via API to specialized point solutions (WMS, PLM, CPQ) | One function, like manufacturing or warehousing, that's genuinely more complex than the core ERP handles well | Integration becomes its own ongoing project, with more contracts and more finger-pointing |
| Point-solution patchwork | No true core; separate accounting, inventory, and operations tools stitched together informally | Very early-stage companies not yet ready for a real ERP decision | Usually the problem an ERP purchase is meant to solve, not a durable state |
How to weight the criteria by buying situation
The right weighting depends on your entity structure and regulatory load more than headcount alone.
| Criteria group | Single-entity SMB | Multi-entity mid-market | Complex or regulated enterprise |
|---|---|---|---|
| Functional and module fit | 30% | 20% | 15% |
| Data model and scalability | 10% | 25% | 25% |
| Implementation and partner quality | 25% | 25% | 20% |
| Integration and total cost of ownership | 20% | 15% | 15% |
| Change management and adoption | 15% | 15% | 25% |
Single-entity buyers weight module fit highest because they're solving one clear operational problem. Multi-entity teams shift weight to the data model, since that's what breaks first when a second subsidiary or currency shows up. Enterprises weight change management heaviest because at that scale, the technical implementation is rarely the reason a project fails; the organization's ability to absorb the change is.
The data model test most buyers skip
Ask every finalist to walk through your actual entity structure, not a demo company. If you have, or plan to have, more than one legal entity, currency, or intercompany transaction, this single test disqualifies more vendors than any feature comparison.
Panorama Consulting groups ERP platforms into tiers by the complexity of business they're built to handle, a more useful lens than "SMB vs. enterprise" alone:
| Tier | Typical annual revenue | Example vendors |
|---|---|---|
| Tier I | $750 million+ | SAP S/4HANA, Oracle Fusion Cloud, Infor CloudSuite |
| Upper Tier II | $250 million to $750 million | Microsoft Dynamics 365 Finance and Supply Chain, IFS Cloud, Sage X3, Epicor Kinetic |
| Lower Tier II | $10 million to $250 million | NetSuite, SYSPRO, Acumatica, Priority ERP |
| Tier III | Under $10 million, or point solutions | Hundreds of smaller and niche providers, including Aptean and ECI |
Source: Panorama Consulting, 2026 ERP Report. Business Central, the SMB-focused product most small and mid-size buyers actually price out, sits below Dynamics 365 Finance and Supply Chain here; don't assume every product under a big vendor's umbrella targets the same tier.
Why the implementation partner matters as much as the software
In most software categories, the vendor and the implementer are the same conversation. In ERP, they're often not, and the partner is frequently the bigger risk.
| Partner criterion | What good looks like | Red flag |
|---|---|---|
| Industry reference clients | Two or more live clients in your industry and revenue band, contactable directly without the partner on the call | Only written case studies offered, no live reference calls |
| Delivery methodology | Documented phases, milestones, and formal sign-off gates | "We'll build the plan once the project starts" |
| Team continuity | A named delivery team that stays through go-live, not a handoff after the sales process | The skilled sales engineer disappears the day the contract is signed |
| Fee structure | Fixed-fee or capped time-and-materials with a clear, priced change-order process | Open-ended time-and-materials with no scope document to measure against |
| Post-go-live support | A defined hypercare period and support SLA written into the statement of work | Support model is "we'll figure it out after go-live" |
Customization vs. configuration, and what it does to your upgrade path
Every custom line of code is a future upgrade cost. Configuration (fields, approval workflows, role permissions) generally survives a vendor's version updates; custom code built against a specific version frequently does not. Vendors are increasingly forcing this choice for you: Epicor recently announced that all new features for its Kinetic, Prophet 21, and BisTrack products go to the cloud exclusively, putting heavily customized on-premises deployments of those products on a fixed clock (Panorama Consulting, 2026 ERP Report).
Ask every finalist, module by module, which requirements need custom code, and what happens to that code on the next major version. A vague answer previews an unbudgeted redo down the line.
Phased vs. big-bang: how to choose your rollout
This decision belongs in the evaluation phase, not after signature, because it affects which vendors and partners can realistically support it.
| Approach | How it works | Best for | Real risk |
|---|---|---|---|
| Big bang | All modules and entities go live on a single date | Smaller, single-entity organizations with simple, well-documented processes | One bad cutover disrupts the entire business at once |
| Phased | Modules or business units go live on separate dates over time | Multi-entity or multi-module rollouts that want to de-risk each stage | Longer overall timeline; running old and new systems in parallel for longer |
| Hybrid | Core modules or a pilot entity go live in a big bang, with other locations or functions phased in afterward | Multi-entity and multinational organizations balancing speed and risk | Requires strong governance so the "temporary" hybrid state doesn't quietly become permanent |
More than a quarter of organizations now use a hybrid approach rather than a purely phased or purely big-bang rollout, making it the single most common pattern among multi-entity and multinational implementations, per Panorama's 2026 ERP Report. It wins because it protects revenue-critical operations with an early go-live while giving later entities a slower, lower-risk runway.
Total cost of ownership: what actually gets billed
License is usually the smallest line on the invoice. Model all four layers before comparing vendors on sticker price alone, or you'll rank finalists on the least meaningful number in the deal.
| Cost layer | What it covers | Where buyers get surprised |
|---|---|---|
| License or subscription | Per-user, per-organization, or base-plus-user platform fee | Treating this figure as the whole budget |
| Modules and add-ons | Manufacturing, multi-currency, payroll, and advanced BI, often sold separately | Discovering mid-implementation that a "must-have" module is a separate SKU |
| Implementation and partner fees | Data migration, configuration, integration builds, and training | Underscoping the partner engagement to win the cheapest bid on paper |
| Ongoing support and upgrades | Annual maintenance on-premises, or included support on cloud plans, plus internal admin time | On-premises maintenance running well into double-digit percentages of license cost every year, indefinitely |
Where the category is genuinely quote-only, and where it isn't. Most mid-market and enterprise ERP still hides behind "contact sales," and that opacity is itself worth naming. But two vendors often assumed to be quote-based actually publish list prices:
| Vendor | Verified price | Billing | Source |
|---|---|---|---|
| Microsoft Dynamics 365 Business Central | Essentials $80/user/month, Premium $110/user/month, Team Members $8/user/month | Per user per month, on an annual commitment | Microsoft pricing page |
| Odoo | One App Free at $0 for exactly one app with unlimited users. Paid Standard and Custom tiers are per user per month, but the published rate did not resolve consistently across three fetches of the vendor page (it personalises by region and by a first-year discount), so check it yourself for your own market before budgeting | Per user per month | Odoo pricing page |
| NetSuite, SAP Business One, Acumatica, Sage Intacct, Epicor, Infor | Quote-based; no public list price | n/a | See our full ERP buying guide for indicative quoted ranges |
Two things worth knowing if you have seen different numbers elsewhere. Odoo's free tier ("One App Free") covers exactly one app with unlimited users, not the full suite, so a "free full ERP" claim is a misread of that plan. And Business Central is not quote-based: its top published tier (Premium, $110/user/month paid yearly) runs higher than the "$70-100/user/month" range often repeated in buyer content.
Why so many ERP projects overrun
The failure pattern is more predictable than most buyers expect, which means most of it is preventable during evaluation, not something you discover mid-project. Panorama's 2026 data shows more than a quarter of projects going over budget and almost a quarter going over schedule, and the causes are specific, not vague "ERP is hard" hand-waving.
Budget overruns most often trace back to an unexpected need for additional technology: a system-fit gap surfaced late and got patched with extra tooling instead of caught during selection. Schedule overruns most often trace back to organizational resistance: delayed sign-offs and resistance to standardizing a chart of accounts, not technical delays. Change management is what buyers underinvest in most: fewer than a quarter report an intense focus on it, even though it's the top named cause of schedule slips (Panorama Consulting, 2026 ERP Report). The same report found post-selection services, change management and benefits realization especially, growing faster year over year than pure selection support: the scorecard gets you to a good contract, but what happens after signature is where the project is actually won or lost.
Key questions to ask vendors and their implementation partners
Ask these after the demo, when the sales engineer is off script and the partner's delivery lead is in the room.
- "Walk me through how a new subsidiary or mid-year acquisition would flow through your data model." Exposes a data model that only looks multi-entity in the slide deck.
- "Which requirements need custom code versus configuration, and what happens to that code on your next major version?" Get it in writing, module by module.
- "Introduce us to a same-industry, same-revenue-band client who went live in the last 18 months, without you on the call." A vendor who hesitates is protecting you from hearing something.
- "What's included in your implementation fee, and what triggers a change order?" Ambiguity here is where most budget overruns start.
- "What does your average project look like: on time and on budget, or not, and why?" A partner who can't answer honestly hasn't tracked their own delivery record.
- "If we skip a module today, what does it cost to add later: re-implementation or just activation?" Tells you whether pricing punishes phased adoption.
- "What happens to our data and configuration if we terminate the contract, or if you get acquired?" Get the exit path in writing before you need it.
Our SaaS vendor evaluation scorecard and software shortlisting framework cover the diligence questions that apply beyond ERP.
Frequently asked questions
How is ERP evaluation different from general SaaS evaluation criteria?
General SaaS evaluation asks whether a tool does the job, integrates with what you have, and fits the budget. ERP evaluation adds two layers: whether the data model represents your legal and operational structure, and whether the implementation partner can execute. A great platform with a weak partner routinely underperforms a decent platform with a strong one, rare in lighter categories like help desk software.
How many ERP vendors should we shortlist?
Two to three finalists is realistic. ERP demos and discovery workshops pull real time from finance, operations, and IT staff who also have day jobs, so a longer list just drags the process out. Use the criteria table above to narrow it first.
Should we pick the software or the implementation partner first?
Pick software finalists first, then evaluate partners for each, since partner quality varies within the same platform. Some platforms have one strong regional partner and several weak ones; picking the partner first risks anchoring on the best sales team rather than the best data model fit.
Is it ever fine to buy a full suite and only use one module?
Sometimes, if you genuinely expect to grow into the other modules within a reasonable window. But without a credible plan to use more than one module within two to three years, a focused best-of-breed tool (see how to choose accounting software or inventory management software) is usually the better, cheaper buy.
How do we know if our project is at risk of becoming an overrun statistic?
Watch for two leading indicators: any sign that a "must-have" capability wasn't caught during selection and needs bolt-on technology, and any resistance from process owners to standardizing how work gets done, like a shared chart of accounts or approval flow. Both show up early, often in the first design workshop, if you're watching for them instead of assuming the vendor will flag them.
Score the partner as hard as the platform
Every criterion above matters, but if you only have time to do two things well: pressure-test the data model against your real entity structure, and reference-check the implementation partner as hard as the software. Most ERP projects that go sideways weren't sunk by a missing feature. They were sunk by a data model that didn't fit or a partner that couldn't deliver, both visible during evaluation if you're scoring for them.
Related reading
- How to choose ERP software: a buyer's guide
- How to choose ERP software for small business
- SaaS vendor evaluation scorecard
- How to choose accounting software
- Accounting software evaluation criteria
- How to choose inventory management software
- CRM evaluation criteria checklist
- Best NetSuite alternatives: full ERP roundup

Head of Enterprise Solutions
On this page
- What makes ERP evaluation criteria different
- The ERP evaluation criteria checklist
- Suite vs. best-of-breed: decide this before you demo anything
- How to weight the criteria by buying situation
- The data model test most buyers skip
- Why the implementation partner matters as much as the software
- Customization vs. configuration, and what it does to your upgrade path
- Phased vs. big-bang: how to choose your rollout
- Total cost of ownership: what actually gets billed
- Why so many ERP projects overrun
- Key questions to ask vendors and their implementation partners
- Frequently asked questions
- How is ERP evaluation different from general SaaS evaluation criteria?
- How many ERP vendors should we shortlist?
- Should we pick the software or the implementation partner first?
- Is it ever fine to buy a full suite and only use one module?
- How do we know if our project is at risk of becoming an overrun statistic?
- Score the partner as hard as the platform
- Related reading