Last updated: August 11, 2026
Choosing an ERP for a mid-market business comes down to four checks: run your volume arithmetic against the licensed limits, price the platform question honestly, read the assumptions page, and name one person who can say no. The feature comparison is the part everyone spends five weeks on. It is almost never the part that decides how this goes.
The winning ERP scored 4.31.
Second place scored 4.29. Both numbers came off a weighted requirements matrix, 214 rows deep, built across five weeks by a committee of nine people who mostly did not enjoy it. The gap between first and second came down to one scorer’s rating on a row about multi-currency consolidation, typed in at some point on a Thursday evening by somebody nobody could later identify.
Nice spreadsheet, though. Genuinely. Color coded and everything.
Eleven months later the project was five months late, and multi-currency consolidation had nothing to do with it. Two departments had disagreed about how an order gets priced since roughly 2019, quietly, in a way that never had to be resolved because each side kept its own version in its own system. Selection was the first time both versions had to sit on one page. The software didn’t cause that fight. It just booked the room.
Two disclosures before any advice, stacked so you can weigh the rest properly. I run an ERP and business systems consulting group, so a company that decides it needs help choosing is a company that might call me, and I would absolutely take that call. You’re also reading this on a staffing firm’s site, which I’ll come back to at the end for a reason that isn’t advertising. What follows is the checklist I run when I’m sitting on the buyer’s side of the table, and most of it costs you a morning and no money at all. It’s also the before picture of an argument I’ve already made about getting more out of the ERP you already own, which is worth ruling out first.
The Scorecard Is Measuring the Wrong Variable
Choosing an ERP is the work of matching a system’s real limits, real total cost, and real implementation demands against what your business can actually supply in people, decisions, and clean data. Feature comparison is a small slice of that. Most mid-market platforms already cover the same ninety percent.
Put NetSuite, Microsoft Dynamics 365 Business Central, Acumatica, and Sage Intacct side by side on a requirements grid and you will produce four scores within a rounding error of each other, because a grid rewards breadth and all four are broad. The genuine differences are narrower than the vendors admit and narrower than the analysts imply. Manufacturing depth, multi-entity consolidation, how ugly the warehouse module gets at volume. Real distinctions. Rarely fatal ones.
What is fatal shows up elsewhere. Gartner’s figure here is bleak enough that I’ve stopped putting it on slides in front of prospects, because it reads as scaremongering right up until you check it. By 2027, they expect more than 70% of recently implemented ERP initiatives to fall short of their original business case goals, with as many as a quarter failing catastrophically. Seventy percent. On software that demonstrably works, chosen by companies that ran a process, produced a scorecard, and felt pretty good about themselves on signing day.
Those aren’t feature failures. Not one. Nobody’s business case ever collapsed because the AP module was missing a field.
Do the Arithmetic Before You Book the Demo
Every ERP is sold to you as a platform and delivered to you as a set of contracted ceilings. API calls per year. Records. Concurrent sessions. Full-access users versus the cheap self-service tier. Those numbers live in an order form nobody on the selection committee reads, and each one is checkable against your own volumes on the back of an envelope, weeks before anybody schedules a demo.
Here’s the shape of how that goes wrong. A regulated manufacturer I worked with this year had a subscription allowing one million serialized identifiers a year, against roughly 837,000 units actually shipped. Twenty percent headroom. Looks comfortable, right?
It wasn’t, and the reason is the kind of detail that only surfaces after you’ve signed. Their design allocated blocks of identifiers to suppliers in advance, and a block allocated to a supplier who only uses two-thirds of it still draws down the full allowance. The paper headroom was twenty percent. The real headroom, once allocation patterns were accounted for, was thin enough to matter inside two years of growth. Nobody had checked.
No demo catches that. You catch it by multiplying your own numbers before you go shopping.
| Ceiling to check | Where the number actually lives | What it costs when you hit it |
|---|---|---|
| Annual API call allowance | Order form, not the datasheet | A subscription uplift, or an integration redesign in month nine |
| Concurrent integration sessions | Service tier, buried | Nightly jobs colliding and failing silently |
| Full-access user count | The quote, usually as a line you skimmed | The renewal conversation you didn’t budget for |
| Sandbox environments included | Often zero by default | Testing against production, which is how you learn humility |
| Identifier or serial allowances | A third-party module contract | A ceiling you share with your own suppliers |
| Script and workflow governance limits | Platform documentation | Customizations that work in test and time out at month end |
The other half of this is grain. Whether your integration touches the platform once per unit or once per document changes your call volume by a factor of ten, and that decision gets made by a developer in week three of a build unless somebody raises it during selection. I’ve written up what that arithmetic looks like on a real project elsewhere, so I won’t repeat the numbers here.
Twenty minutes with a calculator. That’s the whole ask.
The Platform Question, and Why the Saving Is Smaller Than the Slide Says
Somewhere in every mid-market selection, usually around week six, a vendor suggests running your integrations through an integration platform instead of building them natively in the ERP. Mapping becomes configuration. A future administrator can see the logic in a picture rather than reading somebody’s code. The pitch is good. Often right, too.
It’s also priced misleadingly. I’ve quoted both.
On the engagement I keep referring to, the native build came in at about $312,500. The integration-platform alternative for the same scope priced at $265,900, which reads as a saving of roughly $47,000 until you notice the words “excluding platform license” underneath it. Add the license. Add a second vendor your team now has to qualify, contract with, and chase when something breaks at 6 a.m.. The delta closes, and on a three-year view it usually inverts.
There’s a technical half to this too, and it’s the part that gets waved past. A realistic integration-platform build is not pure configuration. It contains scripted transformation steps, because real data is messy and no drag-and-drop mapper handles the exception cases. So the thing you were told is configuration turns out to contain code, and the code is exactly the part that breaks when either vendor ships an update. GAMP 5 Second Edition makes this explicit for regulated work: software categories are a continuum assessed per component, not one label stamped across a whole system.
You’re probably not regulated. The logic survives translation anyway. Ask which specific steps in the proposed design are configuration and which are code, get the answer in writing, and price your upgrade risk against the second list rather than the first.
One system boundary. One supplier. One change control process. Those three things never appear as rows on a scorecard, and they’re worth more than most of the rows that do.
Read the Assumptions Page, Not Just the Exclusions
Everyone tells you to read the exclusions. Fine advice. I’ve made it myself, at length. The exclusions list is what the vendor won’t do.
The assumptions list is more interesting. That’s what they’re expecting you to do, and it’s usually printed two pages later in a smaller font with no dollar figures attached, which makes it feel like boilerplate rather than a bill.
A proposal I wrote in July carried twelve assumptions against eleven exclusions. Twelve. The client would deliver an approved requirements document. Their people would turn documents around in ten business days, and test protocols in five. Subject matter experts would be free for workshops and user acceptance testing. A sandbox refreshed from production would sit available the whole way through. And a third-party vendor, one my client doesn’t employ and can’t discipline, would answer technical questions inside five business days.
Read that list again as a staffing plan. Because it is one. Every line is work on your side of the table, with no owner and no date, written by somebody who will be entirely within their rights to invoice you when it slips.
The reason this matters more than it sounds is what happens in the tail. Bent Flyvbjerg and Alexander Budzier studied 1,471 IT projects for Harvard Business Review and found the average cost overrun was a survivable 27%, but that one in six projects was a black swan, running 200% over budget and nearly 70% over schedule. The average is a rounding error you can absorb. The tail ends careers. And the projects I’ve watched fall into that tail did not get there through one dramatic event. They got there because eight assumptions had no name next to them and all eight slipped at once.
So do this before you sign, and it takes an afternoon:
- Print the assumptions page. Write a person’s name next to every line. Not a department. A person, who knows their name is there.
- Any line you can’t staff, raise during selection while it’s still a negotiation rather than during build when it’s a change order.
- Turnaround commitments are the sneaky ones. Ten business days to review a document sounds generous until you count how many documents there are and realize your controller is also closing the month.
- Then compare assumption counts across bidders. A proposal with three assumptions isn’t simpler. It’s less honest, and you’ll meet the missing nine in month four.
Make Them Prove the Testing, and Ask What Writes Their Code
Two questions here. Both are cheap and both change the answers you get.
First, separation. The engineer who builds a function should not be the person who authors or executes the test proving that function works, and on a serious engagement those roles get assigned by name in the test plan before anybody writes a line. Ask for that in your RFP. Then ask for the harder thing, which is the right to select up to five executed test protocols and have them re-executed while your people watch, at no cost. We put that offer in writing on a proposal this summer, unprompted, and a vendor genuinely confident in its own testing will agree in one sentence.
The failure mode you’re guarding against isn’t fabricated results. The real one is duller. It’s unconsciously gentle test design, where the person who built the thing writes tests that exercise the paths they were already thinking about and never touch the ones they weren’t.
Second question, and this one is new enough that most selection committees haven’t thought to ask it. What is your policy on AI-generated code?
Every ERP shop is using it now. Mine included. Almost none of them have written down how, which means the honest answer to “who wrote this customization” is often nobody’s quite sure. A real policy says four things. A named qualified person is the author of record and has to be able to explain any part of the deliverable without opening the tool that produced it. Generation runs against an approved design specification rather than a prose description, so the trace from requirement to code survives. Review before merge is mandatory and performed by somebody other than the author. And the tests that prove the code are written by a person, because generating the code and the proof from the same source defeats the entire purpose of testing.
Ours is written down as a section in our change control document. So ask to see theirs. If a vendor tells you they don’t use AI at all, they’re either behind or being careful with you, and neither one is the answer you were hoping for.
The Spec You’re Evaluating Against Might Be Three Years Stale
Quick one. It’s my favorite, because checking costs nothing.
A buyer sent out an RFP this year instructing every bidder to design against a specific revision of a third-party interface specification. Dated 2023. A 2026 revision existed and had been sitting in their own document folder for weeks, and it contained endpoints the older one didn’t, including one that solved a design problem the buyer had listed on their own open-items table as unresolved.
Three of their open questions were already answered in a document they owned.
Nobody was careless here, which is the point. Documents get superseded quietly and the person who filed the new one wasn’t on the selection committee. Ask every vendor, in writing, to confirm which revision of every relevant specification they priced against and the effective date of that revision. Two lines in an email. It has caught something for me three times.
What a Rentable CIO Actually Does During a Selection
Here’s the framework I use for describing my own job, and it explains why mid-market ERP selections go wrong more often than enterprise ones.
A company doing between $50 million and $1 billion in revenue generally cannot afford a full-time CIO who has personally survived three ERP selections. That person costs what they cost and there isn’t enough work to keep them busy. So mostly it doesn’t happen. Selection gets run by whoever has capacity instead, which usually means a controller who has never done this, or an IT director whose actual expertise is infrastructure, or a committee of nine and a spreadsheet with 214 rows.
You don’t need that CIO full time. You need them for about four months.
That’s the rentable CIO idea, and the work inside those four months is narrower and less glamorous than people expect. Kill the weighted scorecard before it eats five weeks. Do the volume arithmetic in week one. Read the assumptions page out loud in a room containing the people whose names will end up on it. Name the single person who can end a disagreement between two departments, and confirm that person knows they’ve been named. Then sit in the demos and ask the four questions the vendor was hoping to get through the afternoon without.
Four months of somebody who has done this before, against a decision you’ll live inside for a decade. That math isn’t close. If you want the shape of what that engagement looks like, KORE1 runs it as ERP vendor selection and RFP advisory and as a fractional CIO engagement for companies that want the whole transformation covered rather than just the buying decision.
Now the part where I’m supposed to be selling you consulting and instead I’m going to talk about a hire.
The seat that determines whether this works isn’t the advisor. It’s the internal person who owns the system after everybody external goes home, and almost nobody hires that person until the pain shows up eighteen months later. KORE1 has been placing that role since 2005, across more than 30 U.S. metros, and 92% of their placements are still in the seat twelve months on. That number matters here specifically, because twelve months post-go-live is roughly when an unowned ERP starts drifting away from the process it was built for. Their ERP recruiters can tell you what the role costs in your market. And if you can’t justify a permanent hire before go-live, which almost nobody can, run the seat on contract staffing through the first release cycle and let the actual work write the job description instead of guessing at it in advance.
Where Selection Committees Get Stuck
Seven months into selection and still no decision. Normal?
Four months is plenty for a mid-market selection, and seven almost always means the blocker is a decision nobody wants to make rather than information nobody has. Test it directly. Ask what specific fact, if you had it tomorrow, would let you sign. If nobody can name one, you don’t have a research problem. You have a person who needs to be told to choose, and every additional month of evaluation is a way of not doing that.
Do we need someone to run the selection, or is that just billable theater?
Bad person to ask. So here’s a test you can run without me. You don’t need help if someone internal has implemented an ERP before, still works here, and has the authority to overrule a department head. That person exists in maybe a third of the companies I talk to. If they don’t exist, the money you’d spend on four months of guidance is roughly one month of the overrun you’re otherwise buying. If they do exist, hand them the checklist above and save your budget for the implementation, which is where it will actually be needed.
NetSuite, Dynamics 365, Acumatica, Sage Intacct. Does the shortlist order matter?
The implementation partner attached to each option matters considerably more than the option itself. Not a dodge, either. I’ve seen the same platform go beautifully at one company and horribly at another six miles away. Pick two finalists on genuine functional fit, then evaluate the partners as hard as you evaluated the software, because the partner is who you’ll actually be working with for the next nine months. Our ERP comparison tool is a reasonable place to build the first cut.
Two departments want different systems. Now what?
Happens on maybe a third of the selections I sit in on, and it is never really about the systems. Dig one layer and you’ll find a process both departments have run their own way for years, and buying either platform forces one of them to stop. That’s the actual decision. Make it explicitly, in a room, with the executive who can make it stick, before you pick software. Buy first and you’ve simply moved the argument into a requirements workshop with a consulting meter running.
Should we build our own demo script or just watch theirs?
Short answer: build yours, and make it deliberately boring. Take three real transactions from last month, including the ugly one with the partial shipment and the credit memo, and hand the same three to every finalist a week ahead. Vendor demo scripts are engineered to avoid friction, which is their job. Yours should go looking for it. Deliberately. The finalist who says “that one is genuinely awkward in our system. Here is how we would handle it” has told you more than the one who glides through.
What should this actually cost us in year one?
Services usually land somewhere between one and two times your first-year software license, and that multiplier deserves far more scrutiny than the license does. A bidder coming in well under the others is rarely more efficient at the same work. Something has been left out. It always is, and it comes back later at change-order rates you never negotiated. We publish implementation cost and timeline benchmarks if you’re building the budget from nothing.
Name the Person Who Can Say No
Open whatever version of the scorecard you’re building right now.
Find the row where two departments scored the same requirement differently. There’s always one. Usually pricing, order entry, or how a return gets handled. That row is not a scoring discrepancy. It’s the argument you’re about to spend nine months and several hundred thousand dollars having in public, with a vendor watching and billing.
Go resolve it now. Free today. Expensive in March.
Then go find your ceilings, do the multiplication, and print the assumptions page. None of that requires a vendor, a consultant, or a budget approval. It requires a morning and a person willing to be unpopular for one meeting, and it will tell you more about how this project ends than five weeks of feature scoring ever will.
The tech is not the hard part. It hasn’t been for years. Your people are the hard part, and I mean that with affection, mostly.
Got a shortlist in front of you and a nagging feeling about one of the quotes? Hit me up on LinkedIn and send me the assumptions page. I’ll tell you which line is going to move your date and roughly by how much. Free, takes me ten minutes, and I’m right often enough that it’s worth your ten.
The hiring half I’m no use on, so put that question to KORE1. They’ll tell you what the owner seat costs before you’ve picked the software, which is the correct order to find out.
