What ERP Really Costs a Small Business

Why the pricing page does not answer the question

Every vendor publishes a per-user monthly figure. It is a real number and it is close to useless for budgeting, because the subscription is usually between a fifth and a third of what the first year actually costs.

The gap is not vendors being deceptive. It is that most of the cost is yours, not theirs: configuration decisions, data cleanup, training, and the hours your own people spend on all three. None of that appears on a price list because none of it is sold to you.

The five components

Budget each separately. Collapsing them into one number is how projects end up 60% over before anyone notices.

The ranges are wide because the mix shifts with how much you change. A business adopting the system's standard processes lands at the low end of implementation and the high end of training. A business bending the system to its existing processes inverts that, and pays again at every upgrade.

The line everyone omits

Your own people's time, and it is routinely a fifth to a third of the cost.

Somebody has to decide the chart of accounts. Somebody has to say which of the four spellings of a customer name is correct. Somebody has to test that a purchase order actually prints. These are not tasks a vendor can do for you, because they require knowing your business.

In a small business those people are also doing their day jobs. The cost shows up as deferred work, longer month-ends, and slower sales response — real, and invisible in any budget that only counts invoices.

A worked example

A 25-person distributor, 12 of them needing system access. Finance, inventory, purchasing and basic CRM. Mid-market cloud ERP at 85 per user per month.

Year one is about four and a half times the subscription. Year two settles to roughly 1.35 times it. Budgeting from the pricing page alone would have produced 12,240 and a conversation nobody enjoys in month four.

Per-user pricing, and where it bites

Per-user is the dominant model and it has two traps worth pricing before you sign.

First, user tiers. Many vendors separate full users from light or read-only ones at very different prices. A warehouse operative who only confirms picks should not cost what a financial controller costs. If the tiering is not spelled out, your cost scales with headcount rather than with usage.

Second, the module ladder. The quoted price usually covers a core bundle, with manufacturing, project accounting, advanced warehousing or multi-currency sitting above it. Establish which of the things you actually need are in the base price, in writing, before comparing two quotes — the headline figures are rarely measuring the same scope.

What recurs

• Subscription, usually with an annual uplift clause. Ask what it has been for the last three years rather than what the cap is.
• Support tier. The default is often business-hours email; anything faster is priced separately.
• New starters. Training is not a one-off if you are hiring.
• Change work. Reports, integrations, new processes — budget a small annual allowance rather than treating each as an exception.
• Integration maintenance. Anything connected to a payment provider, a marketplace or a bank feed will break when their API changes.

Questions to settle before signing

Each of these has cost a business real money by being left vague. Ask them in writing, and keep the answers with the contract.

1. What is the annual uplift, and what has it actually been for the last three years? A cap of 7% tells you less than a history of 4%.
2. Which modules are in the quoted price, and which are not? Multi-currency, project accounting and advanced warehousing are commonly outside the base.
3. What are the user tiers and what does each allow? Price the real mix, not twelve full seats.
4. What is included in implementation days, and what happens when they run out? A fixed-day quote with hourly overage is a different product from a fixed-price outcome.
5. Who owns the data, and in what format can it be exported? Ask for a sample export rather than a clause.
6. What does support actually cover, and what is the response time at the tier you are buying?
7. What does an upgrade involve, and who pays for retesting customisations?

Cloud and on-premise are different shapes

Not only different totals — differently shaped totals, which matters if cash flow is tight.

Cloud subscription spreads cost evenly and includes hosting, backups and upgrades. There is little capital outlay, and the number is predictable until renewal. The trade is that it never stops, and over seven or eight years it usually exceeds what a licence would have cost.

On-premise front-loads a licence and hardware, then charges annual maintenance at roughly 18–22% of licence value. Cheaper over a long horizon if you keep the system a long time, and it carries costs that rarely make the comparison: server hardware, backups, someone to run it, and an upgrade project every few years rather than a continuous drip.

For a business of 25 people the practical answer is almost always cloud, and not on price. It is that on-premise assumes an internal capability to run infrastructure, and if that capability does not already exist, buying it is far more expensive than the licence difference.

How to budget it

1. Scope the modules you need in the first year, not the ones you might want in year three.
2. Count users honestly by tier, and ask the vendor to confirm the tier split in the quote.
3. Take the vendor's implementation estimate and add 30%. It is quoted against a clean data set and clear decisions, and you have neither yet.
4. Estimate internal hours, then double them.
5. Hold 10–15% contingency outside the project budget, controlled by whoever sponsors the project.

Then run it as a project with a budget and tracked actuals rather than as a purchase. The failure mode is not overspending; it is overspending unnoticed until the money is gone and the system is half-configured.