ERP customisation cost is high and vague when the change request is vague. Suppliers price the risk they cannot see: unknown data, effects on other modules, regression testing and future upgrades. Scope the change precisely (trigger, inputs, outputs, edge cases, volumes, test scenarios and upgrade impact) and the quote can shrink and tighten, because less of it is contingency.
Most finance and operations leaders have had the experience: a change that sounds like "add a field and a check" comes back as weeks of effort, with a wide range and a list of assumptions. That is not always padding. It is usually a supplier telling you, in money, how little they know about what you want.
Why do ERP customisation quotes come back so large?
A short request hides a lot of questions. "Block dispatch when a customer is over their credit limit" sounds like one rule. To price it properly a developer needs to know which credit limit, including or excluding unshipped orders, whether it applies to all order types, who can override it, what the warehouse sees, and what happens to orders already picked.
When those answers are missing, the supplier either asks (slow) or assumes the worst case (expensive). Four drivers sit behind most large quotes.
Unknown data
The developer has not seen your data. They do not know how many customers have no credit limit set, whether order types are used consistently, or whether there are 400 orders a day or 40,000. Every unknown becomes contingency.
Testing across modules
An ERP is a web of shared tables and posting rules. A change to sales order release can touch stock allocation, warehouse picking, invoicing and reporting. Regression testing across those areas is real work, and it is often the largest part of a quote.
Upgrade risk
Modifying core behaviour means the change may break, or need reworking, at every version upgrade. Responsible suppliers price that in, or exclude it and leave you with the bill later. Ask which they have done.
The supplier's risk margin
Fixed-price quotes carry the supplier's risk. If the scope is loose, the margin is wide. A tight scope moves risk back to where it can be measured, and the number comes down.
What is the difference between configuration, customisation and extension?
These three words get used loosely, which is half the reason quotes are hard to compare. The table sets out how we use them.
| Approach | What it means | Typical examples | Cost and risk profile | Upgrade impact |
|---|---|---|---|---|
| Configuration | Using settings the ERP already provides | Approval workflows, user roles, document layouts, new fields via admin tools, posting rules | Lowest. Done by consultants, minimal testing | Usually survives upgrades |
| Customisation | Changing or adding code inside the ERP, altering standard behaviour | Modified posting logic, custom screens inside core modules, changed standard reports | Highest. Needs developers, broad regression testing | May break or need rework at each upgrade |
| Extension | Adding functionality alongside the ERP through its supported extension points | Extension apps, event hooks, custom tables in a separate layer | Moderate. Isolated, but still inside the platform | Usually survives if built on supported points |
| Integration / side app | A separate application that reads and writes ERP data through APIs | Quoting tool, mobile app for the shop floor, customer portal, reconciliation service | Moderate up front, contained risk | Only affected if the API changes |
Always ask a supplier which of these they are proposing. Two quotes for "the same change" are often one configuration and one customisation, and the cheaper one may not do what you need.
How do you scope an ERP change request so it can be priced tightly?
A good change request reads like a test plan, not a wish. Here is what we ask for before we price anything.
The current process
Describe what happens today, step by step, including workarounds. "Credit control checks a report each morning and emails the warehouse a list of accounts on stop" tells a developer more than any requirement statement.
The exact trigger
What event starts the new behaviour? An order being saved, released, picked, or invoiced? A nightly job? A user pressing a button? Ambiguity here causes the most rework.
Inputs and outputs
Which fields does the logic read, and what does it produce: a block, a warning, a new record, an email, a status change? Name the actual fields if you can.
Edge cases
List the awkward ones: part-shipped orders, credit notes, intercompany customers, foreign currency, orders created by integration rather than by a person. Edge cases are where estimates go wrong.
Volumes
How many records, how often, at what peak? Logic that runs fine on 50 orders can time out on 50,000.
Who signs off
Name the person who will accept the change, and the one who can approve an override. If nobody owns acceptance, testing never finishes.
Test scenarios
Write five to fifteen scenarios with expected results, using real examples from your data. The GOV.UK Service Manual on user stories puts it simply: acceptance criteria read as "it's done when…". Scenarios like these give a supplier something concrete to estimate against, and give you a fair way to accept the work.
Upgrade impact
Ask the supplier to state whether the change modifies standard objects, how it will be handled at the next upgrade, and what that will cost. Make it a line in the quote, not a footnote.
How can you reduce long-term ERP customisation cost?
The cheapest customisation is the one you do not make inside the core. Three principles keep long-term costs down.
Configure first. Before approving any development, ask whether a standard setting or a small process change gets you 90% of the way. Sometimes the right answer is to change the process, not the system.
Extend beside the core, not inside it. Where the ERP offers supported extension points or APIs, build there. Logic that lives in a separate service or app can be tested on its own, upgraded on its own timetable, and replaced without touching the ledger. This is the same idea as the strangler fig pattern: add new capability around the old system rather than rewriting it. Our ERP integration work is mostly this kind of change.
Keep a register of every change. Record what was changed, why, who owns it and whether it touches standard objects. At upgrade time this list is the difference between a planned project and an expensive surprise.
Side apps are not always the answer. If the logic must run inside a posting transaction, such as a validation that blocks an invoice from posting, it may need to sit inside the ERP. And a side app needs hosting, monitoring and an owner. Be honest about those costs too.
When does a separate app beat customising the ERP?
A separate application usually wins when the process is specialist, changes often, or is used by people who do not otherwise need ERP licences: estimators, drivers, shop-floor staff, customers.
Quoting is a common example. When we built a quoting engine for a steel fabricator, we backtested it on past quotes before anyone relied on it, and quote turnaround went from 2 days to 4 minutes. That kind of rules-heavy, frequently tuned logic is expensive to maintain inside a core ERP module and much easier to change in its own application.
If you find yourself requesting a long series of customisations to make an ERP fit a process it was not designed for, step back. It may be cheaper to build that part as its own system, or in some cases to consider custom ERP development for the core. Data migration then becomes part of the scope; our ERP data migration checklist covers that side.
Frequently asked questions
Why is ERP customisation so expensive?
ERP customisation cost reflects more than coding time. Suppliers must allow for unknown data, regression testing across connected modules, and rework at future upgrades, and they add a risk margin when scope is unclear. A precise change request reduces the unknowns, so less of the price is contingency.
What is the difference between ERP configuration and customisation?
Configuration uses settings the ERP already provides, such as workflows, roles and layouts, and usually survives upgrades. Customisation changes or adds code that alters the ERP's standard behaviour, which needs developers, broader testing and often rework at each upgrade. Configuration should always be ruled out before customisation is approved.
How do I write an ERP change request that gets an accurate quote?
Describe the current process, the exact trigger for the new behaviour, the inputs and outputs, edge cases, volumes, who signs off, and a set of test scenarios with expected results. Ask the supplier to state the upgrade impact as a separate line. The more the request reads like a test plan, the tighter the quote.
Should we customise our ERP or build a separate application?
Customise inside the ERP when the logic must run within its transactions, such as a posting validation. Build a separate application, connected through APIs, when the process is specialist, changes often, or is used by people who do not need ERP licences. Separate apps are easier to upgrade but need their own hosting and owner.
How can we compare two ERP customisation quotes fairly?
Check whether both suppliers are proposing the same approach: configuration, customisation, extension or a side app. Compare their assumptions, the testing they include, and how they handle upgrades. A lower quote that excludes regression testing or upgrade rework is not cheaper in the long run.
Talk it through with us
If you have a change request that came back with a number you do not trust, send us the request and the quote. We will tell you which parts are uncertain and how to tighten the scope. Our ERP customisation team can then price it properly, or show you where a configuration change does the job.
