📉 ERP Customisation Cost Calculator
The quote prices the build. The build is the smaller half. Every customisation is retested and often reworked at every upgrade, for as long as you own the system — so price the annuity, not the invoice.
A customisation is an annuity
The business case for a change request shows a build cost. It is a real number, it is usually accurate, and it is the smaller half of what you have just committed to. What it leaves out is that the thing you have built now has to be carried: regression-tested at every upgrade, and reworked whenever the vendor changes something underneath it.
That cost recurs for the life of the system, and it is almost never attributed. It arrives as upgrade project invoices, two and four and six years later, against a different budget line, approved by different people. Nobody traces it back to the change request, so the organisation never learns what its customisations cost — and approves the next one on the same incomplete figure.
The counter-intuitive part is what the cloud does to it. On-premise, an upgrade can be deferred: you pay in security exposure and in a larger jump when you finally move, but you choose the year. SaaS upgrades are scheduled by the vendor and cannot be deferred, so the rework becomes an operating cost with a date on it. Moving to SaaS lowers the infrastructure bill and raises this one.
None of which means never customise. Some customisations are the reason the business wins, and standardising them away to save upgrade cost is a bad trade. The point of putting a lifetime number on them is to tell those apart from the ones built because a department preferred the old screen — and that conversation gets much shorter once the change request carries its real figure.
❓ Frequently Asked Questions
Why do ERP customisations cost so much more than the quote?
Because the quote prices the build and nothing else, and the build is the smaller half. Every customisation has to be regression-tested at every upgrade, and anything that touches behaviour the vendor also changes has to be reworked rather than merely checked. That cost recurs for as long as you own the system, and it arrives as upgrade invoices years later against a different budget line — by which point nobody connects it back to the change request that caused it. The build is a one-off; the customisation is an annuity.
Doesn't moving to SaaS solve this?
It usually makes it worse, which surprises people. On-premise you can defer an upgrade: you pay in security exposure and accumulated technical debt, but the timing is yours. SaaS upgrades are vendor-scheduled and frequent, so the same customisation gets retested several times a year whether the budget exists or not. Cloud lowers the infrastructure bill and raises the customisation bill. "We moved to SaaS and kept all our modifications" is one of the most expensive sentences in enterprise software.
What counts as a deep customisation?
The useful line is whether the vendor also changes that code. Configuration, layouts and reports use tools the vendor supports and expects you to use, so an upgrade normally just needs them tested. Workflows, integrations and custom fields sit on published APIs, which change often enough that something usually needs adjusting. Modifying core behaviour is the expensive category: every upgrade becomes a merge conflict with a supplier who has never heard of you, and that is what turns a routine upgrade into a project with its own budget.
Is it always wrong to customise?
No, and a tool that concluded that would be useless. Some customisations encode the thing your business is actually better at than its competitors, and standardising them away to save upgrade cost is a bad trade. The point of pricing the annuity is to tell those apart from the ones built because a department preferred the old screen layout. Once a change request carries its lifetime cost rather than its build cost, that conversation becomes much shorter.
Where do the rework percentages come from?
They are industry rules of thumb rather than measured constants, and the range people quote is genuinely wide — which is why they are shown, explained, and adjustable rather than buried. Your integrator's estimate for your system beats any default here, and if you have upgrade invoices from the last few years you have something better than either. The model exists to show the shape: a recurring cost compounding against a one-off number in the business case. The shape is robust; the third digit is not.
How does this relate to the TCO calculator?
It covers what that one cannot see. The TCO calculator adds licence, implementation and training to a flat annual maintenance figure, which is the structure of the quote you will be given. Customisation rework appears in none of those lines — it is not licence, it is not implementation, and it is not the maintenance contract. For a typical estate it can add a substantial fraction of the whole TCO again, which is why it is worth pricing separately rather than hoping the maintenance line absorbs it.