The first ERP quote you receive is almost never the number you end up spending. It’s a license figure, or a per-user-per-month figure, and it covers maybe a third of what actually leavaes the bank account before anyone logs in. The rest hides in implementation hours, data migration, integration work, training time, and the second wave of scope nobody priced at signature.
If you run finance or operations at a company of 50 to 500 people, you need a defensible number before the board meeting, not after it. That means a range you can explain line by line, with the assumptions visible and the risky lines flagged. Here’s how to build one: what to count, what the benchmarks actually say, and which lines have a habit of moving.
Start With Headcount, Not the Software Price
Per-user math is the fastest sanity check available, and it’s the one most finance teams skip in favour of chasing a headline license rate.
Software Path’s ERP research, drawn from 1,384 selection projects, puts the average budget at $9,000 per user across a five-year window, up from $8,295 the year before. That figure spans businesses of every size, so treat it as a band rather than a quote. Still, run it: 60 users lands you near $540,000 over five years, or roughly $108,000 a year all-in.
If the proposal on your desk implies a fraction of that, something is missing from it. If it implies triple, you’re either buying more customization than a mid-size operation typically needs or you’re paying enterprise rates for mid-market complexity.
Per-user works as a check because most ERP cost scales with people, not with revenue. Licenses are per seat. Training is per seat. Support tickets, permission sets, and role configuration all track headcount far more closely than they track your top line.
Budget the selection process too. The same research found companies spend about 17 weeks on average choosing a system. That’s four months of senior finance and operations attention, and it belongs in the plan even though no invoice arrives for it.
What Sits Underneath the License Line
Vendors quote what they sell. Your budget has to cover what you’ll spend, which is a longer list:
- Software subscription or license: the only line most quotes lead with.
- Implementation and configuration: usually the largest single item, billed in consultant hours.
- Data migration: extracting, cleaning, mapping, and reconciling whatever lives in your current system and the spreadsheets around it.
- Integrations: every connection to banking, payroll, e-commerce, CRM, or a warehouse system is separate scoped work.
- Training and internal time: your own team’s hours, which are real money even when they never appear on a purchase order.
- Ongoing support and version upgrades: the line that renews every year and compounds quietly.
Model those categories yourself before you take a vendor call. If open-source platforms are on your shortlist, an Odoo implementation cost calculator breaks the same lines out by module and user count, which is enough to tell whether a proposal you receive is missing a category or simply pricing one differently.
The point isn’t to arrive at a precise figure this early. It’s to walk into vendor conversations already knowing the shape of the spend, so you can ask why a quote has no migration line instead of discovering the gap in month four.
Where the Overruns Actually Come From
Budget overruns in ERP rarely come from the vendor raising the price. They come from the project discovering work that was never in the original scope.
Panorama Consulting’s 2026 ERP research found that more than a quarter of organizations exceeded their project budgets, with additional technology needs the leading cause. Scope expansion and technical problems followed.
That pattern is worth sitting with, because it describes a specific failure mode. A requirement surfaces during user testing. The module doesn’t handle it the way the business does. So somebody buys a bolt-on, or commissions custom development, and a line item appears that no one costed in the original business case. Multiply that across a handful of requirements and you have your overrun.
The defence isn’t a bigger contingency percentage quietly baked into the estimate. It’s earlier discovery. Walk your two or three most awkward processes through a real demo environment before you sign, not after. The odd ones (consignment stock, multi-currency intercompany billing, whatever your business does that competitors don’t) are where the misfits live.
And put contingency on the page as its own named line. A padded estimate gets negotiated down by a CFO who can’t see what the padding is for. A visible contingency line with a stated purpose usually survives.
Three Envelopes That Make the Number Defensible
Boards approve budgets they can interrogate. Splitting the total into three envelopes makes it interrogable:
- Build: one-time spend to get live. Implementation services, migration, integration development, initial training, and the internal hours you’re diverting from other work.
- Run: recurring annual cost once you’re live. Subscriptions or support contracts, hosting, and whatever internal or partner support you need to keep the thing healthy.
- Change: the year-two backlog. Every implementation ships with a list of things deferred to go live on time. That list is not free, and pretending otherwise is how a successful project turns into a disappointing second year.
Most budgets that fall apart do so because Build and Run were merged into one number, or because Change was never funded at all. Three envelopes also gives you somewhere honest to put the trade-offs when the total comes back too high. You can defer Change. You can rarely defer Build.
What to Do Before the Next Budget Cycle
Take the per-user benchmark, multiply by your headcount, and treat the result as your opening range rather than your target. Then split it into Build, Run, and Change, and stress-test the Build envelope against your two strangest business processes.
Three things worth doing this quarter: get your current data cleaned before anyone quotes migration, write down the integrations you actually depend on, and name a contingency line out loud in the business case. The companies that stay on budget are usually the ones that found the awkward requirements early, while changing the plan was still cheap. See More