Every ERP quote you receive will be wrong, and not because anyone is being dishonest. It is wrong because the largest cost in the project is not on the quote, cannot be put on the quote, and is paid in your own people's time.
This is an attempt to lay out the whole cost structure — the parts a vendor quotes, the parts they cannot, and which ones you can actually control. We are an ERP vendor, so read it with that in mind; what we would rather not do is sell somebody a platform they will abandon in month seven because nobody warned them what the real work was.
The five parts of the number
Only the first is usually on the proposal. The last two are the ones that decide whether the project works.
| Cost | Who bears it | Roughly how it scales | Can you control it? |
|---|---|---|---|
| Licence or subscription | Vendor invoice | Users and modules | Yes — buy fewer modules |
| Implementation and configuration | Vendor invoice | Process complexity, not company size | Partly — by simplifying first |
| Customisation | Vendor invoice | How far you are from the default | Yes — and this is the big lever |
| Data preparation | Your people | How messy your masters are | Yes — start before you buy |
| Internal time and disruption | Your people | Number of teams affected | Partly — by sequencing |
A useful planning assumption: for a small or mid-sized Indian business, the vendor invoice is rarely the largest figure in the first year. The internal time usually is, and it is almost never budgeted, which is why projects that look affordable on paper come to feel expensive in practice.
What actually drives the number up
Company size is a poor predictor. These five things are much better ones, and four of them are within your control.
1. How many modules you switch on at once
Each module affects a different team, and each team needs its process agreed, its data cleaned and its people trained. Six modules at once is not six times one module — it is six simultaneous change projects with one set of attention to share between them. The cheapest ERP projects we see switch on two things, get them working, and add the third a quarter later.
This is also why it matters whether modules are sold individually. If the platform is a bundle, the decision gets made for you and you pay for a scope you did not choose. With Orbis modules are sold and switched on per client, so a workshop running leads, inventory and accounts is not paying for a kitchen display.
2. How far your process is from the software's default
This is the single biggest driver of cost, and the one businesses are least willing to look at honestly. Every genuinely unusual thing your business does is configuration at best and custom development at worst.
Some of those differences are your competitive advantage and are worth paying to keep. Many are historical — a step that exists because of a system you replaced in 2014, or a person who preferred it that way. The exercise worth doing before you take a single quote is listing your processes and marking each one “this is how we win” or “this is how we have always done it”. The second list is your discount.
What reduces this cost dramatically is whether the ordinary cases need code at all. In Orbis every module form is editable — fields, sections, order, defaults, help text — and renaming something makes it stay renamed, so a large share of what would be customisation elsewhere is configuration here. Worth testing on your own awkward form rather than taking on trust.
3. The state of your master data
The duplicate customer records. The three product codes for one product. The chart of accounts that grew by accretion. The customer whose GSTIN nobody ever validated. None of this is the vendor's to fix, because they cannot know which of your two “Valve 40mm” entries is the real one.
This is the most controllable cost on the list and the most frequently ignored. Cleaning masters before you buy, in the spreadsheets you already have, costs you nothing but attention and takes a visible chunk out of the implementation. Doing it during implementation doubles the pressure and delays everything behind it.
4. Integrations
Every connection to something you are keeping — a bank, a payment gateway, a marketplace, a logistics provider, a government portal — is a build, a test and a thing that will need maintaining when the other side changes. Two-way integrations cost several times what one-way ones do, because somebody has to decide what happens when both sides changed the same record, and that decision is almost never written down until it has already gone wrong.
Compliance filing is the exception worth paying for rather than building. E-invoicing and e-way bills through a GSP absorb the certificate handling, the authentication lifecycle and the portals' periodic changes. Building that yourself is a maintenance commitment, not a one-off cost.
5. How many people have to change what they do
Training cost is not really training cost. It is the productivity dip while a team that was fast at the old way becomes slow at the new way, and it is real for a few weeks whatever anyone promises. It scales with the number of people affected, which is another argument for switching on two modules rather than six.
Where ERP money is genuinely wasted
Having argued that the cost is mostly legitimate, here is where it is not. These are the four patterns that turn a sensible budget into a bad one:
- Automating a broken process. If approval takes four days because it waits for one person, software will make a four-day wait happen reliably. The process was the problem.
- Buying users you do not need. Per-user pricing invites a headcount-shaped order. Count the people who will actually create or approve records, not everyone who might want to look at a report.
- Customising before living with the default. A surprising amount of what feels essential in month one turns out not to matter by month four. Changes made after a quarter of real use are better specified and fewer.
- Paying for reports instead of data. If you need the vendor to build each new report, every future question has a price. Being able to get your own rows out — not just the reports — is what makes the system cheap to ask questions of later.
Questions that reveal the real cost of a quote
Ask these of any vendor, including us. The answers tell you more than the number does.
- What is in the implementation fee, and what is the day rate for everything that is not? The gap between those two is where overruns live.
- Which of the things I have described will need custom development rather than configuration? A vendor who says “none” has not listened.
- What does it cost to add a module in a year, and does doing so need a new implementation?
- What exactly do I have to prepare, and in what format, and by when?
- What happens to my data if I leave? Can I export the rows myself, or do I have to ask?
- What does support cost after go-live, what is the response time, and who pays when something is broken rather than merely unfamiliar?
A sequence that keeps the number down
- Clean your masters now, before any vendor conversation. Customers, suppliers, products, chart of accounts. It costs attention and saves money in every later step.
- Mark each unusual process “how we win” or “how we have always done it”, and be willing to drop the second list.
- Start with the two modules whose pain you can put a number on — usually billing and stock.
- Run a quarter on the default. Keep a list of what genuinely does not work rather than what feels unfamiliar.
- Then customise, from that list, and add the third module.
Businesses that follow roughly that order spend less in total and go live sooner, which sounds like a trade-off and is not. Most of the saving comes from the two steps that happen before anyone is paid.
The honest summary
An ERP is not expensive because software is expensive. It is expensive because it is the first time most businesses have had to write down what they actually do, and that work was always going to cost something. The vendor's invoice is the part you can compare between quotes. The rest is yours to manage, and managing it well is most of the difference between a project that pays for itself in a year and one that is still being argued about.
If you want a realistic figure for your own situation rather than a brochure range, book a walkthrough. Tell us which two modules hurt, how many states you employ people in, and how clean your product master really is — those three answers move an estimate more than anything else you could tell us.
Frequently asked questions
What is the biggest hidden cost of an ERP implementation?
Your own people's time, and specifically master-data cleaning and process decisions. Two or three people will spend a meaningful part of a month on duplicate customers, competing product codes, numbering series and deciding who approves what. It is not optional, it is not the vendor's to do — they cannot know which of your two near-identical product records is real — and it is almost never in the budget. Projects that account for it land; projects that assume it is free slip and blame the software.
Should we pay for customisation?
Only after living with the default for a quarter, and only for the differences that are genuinely how you win rather than how you have always done it. A surprising share of what feels essential in month one does not matter by month four, and changes specified after real use are fewer and better defined. Before paying for code, check how much is configuration: if module forms are editable — fields, sections, order, defaults — much of what would be custom work elsewhere is a setting.
Is it cheaper to buy all modules at once or add them later?
Adding them later is almost always cheaper in total, because each module is a change project for a different team and attention is the scarce resource, not licence fees. The thing to check is whether adding one later means a second implementation. On a platform where every module shares one engine — same forms, permissions, audit trail, import, reporting, numbering and API — switching one on inherits all of that and is a setting rather than a project.
How many users should we actually pay for?
Count the people who will create or approve records, not everyone who might want to see a report. Per-user pricing quietly invites an order shaped like your headcount, and read-only interest is the easiest thing to over-buy. Also ask how customer and supplier access is priced: if your customers viewing their own invoices and statements counts as users, the arithmetic changes considerably.
What should we do before asking for quotes?
Three things, all free. Clean your master data in the spreadsheets you already have. List your unusual processes and mark each one as competitive advantage or inherited habit. And put a number on the pain in the two areas that hurt most — month-end hours, credit notes per month, days from delivery to invoice. Arriving with those three makes every quote you receive more accurate and makes it obvious which vendor is listening.
