What Actually Makes an ERP Project Expensive - and It Isn't the Licence

In most ERP projects the licence is the smallest and most predictable component. What moves the budget is the number of interfaces, the state of your data, the volume of customisation and the amount of guidance - and all four can be estimated before signing, if you ask the right questions.

The four cost drivers

The second row is the surprise: every system that keeps running - payments, store, shipping, payroll, warehouse - is an interface, and every interface has a price even when it "only pulls data".

Why interfaces cost more than they look

An interface is not one connection. It is usually:

• Field mapping between two systems that disagree on what a customer is called.
• Deciding who is master for each data type - a business decision, not a technical one.
• Failure handling - what happens when the other side is unavailable.
• Testing in both directions, including edge cases.
• Monitoring that tells you the connection dropped, because otherwise you find out a week later.

Five components per connection, times the number of connections. Four interfaces are often a bigger budget line than a year of licensing. The decision of when to build a connection at all is covered in an ERP module versus custom development.

What does your data cost?

This is the one component you can measure today, before speaking to anyone. Export the customer list and the item list and check:

1. How many rows in total.
2. How many duplicates by name, by company number, by phone.
3. How many free-text fields that should be closed lists.
4. How many items with no category or no unit of measure.
5. How many records nobody has touched in three years.

Row 5 is an opportunity: not all history has to migrate. A deliberate decision about what does not move is the cheapest way to reduce a project.

What inflates the cost quietly?

• Custom reports. Every report someone "must have" is development.
• Screens that need adapting to one specific process.
• Complex permissions where each person sees something different.
• Multiple companies or branches inside one structure.
• Requirements born mid-project because someone saw a feature in a demo.

The last one is responsible for most overruns and is the easiest to prevent: anything requested after the analysis phase is priced separately and decided explicitly.

What to ask before signing

• What is not included in this quotation.
• How many guidance hours are included, and the rate beyond them.
• Who builds each interface, and what happens when it breaks in a year.
• What an extra user costs, and what an extra module costs.
• What happens to cost when document volume doubles.
• Who cleans the data, and if it is us - how many hours that is.

The first question usually returns the most useful information in the entire conversation.

A budget that survives contact

A realistic budget has four lines, not one: annual licensing, one-off implementation, interfaces counted individually, and a reserve for customisations discovered after go-live. A fifth is never written down but always paid: your team's hours. A business that budgets the fifth makes very different decisions about project scope.

How to compare two quotations

ERP quotation comparisons fail for the same reason nearly every time: they do not describe the same scope. The only fix is to send both vendors the same short document - five to ten processes in your own names, the list of systems that stay alive, the user count by role, and an explicit request to price each interface separately.

What comes back is then comparable. Three lines worth looking for in each quotation: the data assumption - does the price assume you supply a clean file; what training includes - hours, roles, and whether there is a follow-up session a month later; and the rate after the project ends, because that is where most of the multi-year spend lives.

A vendor who refuses to break a quotation into those lines is not necessarily hiding anything, but they are making your budget harder to manage later. That in itself is useful information.

What gets cut by mistake

There are three places businesses trim to fit a budget and pay several times over afterwards. Training - looks like a luxury until the team invents its own working methods. Testing - the first line to fall when the date is tight, and the number one cause of a hard month after go-live. Data cleaning - deferred because "we can fix it later", but fixing after loading is far more expensive than fixing before, and in most cases it simply never happens.

The right cut, when a cut is needed, is scope: fewer modules in phase one, fewer interfaces, fewer custom reports. That defers spending instead of creating debt.

The cost that continues after the project

An ERP project ends; the system does not. Three costs continue into year two and three: ongoing licensing that grows with users and modules; interface maintenance, because the other side changes version eventually and a connection that worked for two years breaks on a Tuesday; and changes - a new process, a new branch, a new report.

The cheap way to manage this is not to negotiate each change separately but to agree an annual hours allocation with the partner up front and track it. That produces one conversation a year instead of twenty small negotiations, and it lets you know the real cost of the system - which is almost always higher than the first quotation implied, with every vendor, regardless of quality.

Sources

• Priority Software - modules and solutions
• Hashavshevet H-ERP - modules