Ask an implementation team whether a requirement should be met by configuration or customisation and you will get a technical answer. It is not a technical question. It is a decision about what your system will cost to own for the next decade, and it is almost always made by people who will not be there to pay the bill. By 2009 the industry had enough completed ERP programmes behind it to see the pattern clearly. Two organizations implementing the same product with similar scope could end up with total costs that differed by a factor of three, and the variable that best explained the gap was not the vendor, the integrator or the industry. It was how much custom code they wrote.
The Distinction That Gets Blurred
Configuration means using settings the vendor built for the purpose: chart of accounts structure, approval thresholds, document numbering, tax rules, workflow steps, field labels, report layouts. The vendor tests these settings with every release and guarantees they keep working. Customisation means changing or adding code: modified standard programs, bespoke transactions, custom tables, altered business logic, interface code that reaches into internals. The vendor tests none of this and guarantees nothing about it. Project teams blur the line constantly, usually with the phrase "it's just a small enhancement." There is no such thing. Every line of custom code is an asset that must be tested at every upgrade, understood by every future support team, and documented well enough that someone who has never met its author can maintain it in eight years.
Why the Cost Curve Bends
Customisation cost is not the build. The build is the cheapest part.
- Every upgrade becomes a regression project. The volume of custom code determines the length and cost of upgrade testing, forever. This is the single largest driver of long-run system cost.
- Support becomes ambiguous. When something breaks, the vendor's first question is whether custom code is involved. Diagnosis takes longer and accountability is unclear.
- The knowledge concentrates. Custom logic usually lives in the head of the person who wrote it, and that person leaves. What remains is code nobody dares change, which is how systems become unmodifiable.
- It compounds. One customisation creates the precedent for the next. Organizations rarely have twelve customisations; they have four hundred, added one reasonable exception at a time.
- It forecloses the cloud. The cost of moving to a modern platform is largely the cost of unpicking custom code. Heavy customisation today is the reason a migration will be quoted at three years later. Vendors eventually formalised the response. SAP's clean core approach is the clearest statement of it: rely on standard functionality wherever possible, extend through a separate platform rather than by modifying core objects, govern all custom development, and ensure extensions do not break upgrades. The stated benefits — reduced technical debt, decoupled customer and vendor code, faster adoption of new capability — are exactly the costs that uncontrolled customisation imposes, stated in reverse.
Why Teams Customise Anyway
Understanding the pressure matters more than restating the principle. The business says "this is how we do it here," and nobody wants to be the person telling a department its process is not special. The integrator is paid to deliver requirements, not to argue them away, and custom development is billable. The project is behind schedule, and building the exception is faster than redesigning the process. And the cost of customisation lands in years three through ten, while the cost of the argument lands this week. That asymmetry — immediate pain versus deferred cost — is why customisation governance has to be a policy decided before the project starts, not a judgement made during it.
A Policy That Actually Holds
- Default to standard, and make deviation an approval. Every customisation request goes to a named governance body with the authority to say no, not to a project manager under schedule pressure.
- Require a business case per item. What does this cost to build, test at each upgrade, and support for ten years? What is the quantified benefit? Most requests do not survive the question.
- Apply the differentiation test. Does this process win us customers or is it just familiar? Genuinely differentiating logic deserves investment. Habit does not.
- Separate the layers. Where customisation is justified, build it on the extension platform, not inside core objects. Decoupled code survives upgrades; modified standard code does not.
- Maintain a register. Every customisation with its owner, business justification, and date of last use. Review it annually and remove what is unused — and a surprising proportion will be unused.
- Budget the lifetime cost visibly. Show the board the cumulative upgrade testing cost implied by the current customisation count. Numbers change behaviour where principles do not.
- Re-examine at every major release. Vendors eventually ship standard functionality that replaces your bespoke build. Retiring custom code at that point is the cheapest improvement available to most estates.
The AI Twist
There is a new reason this matters. AI-assisted development has made writing custom code dramatically cheaper, which removes the friction that used to limit it. The build cost was never the problem, so lowering it does not help — it just lets organizations accumulate technical debt faster than they ever could manually. Meanwhile, the AI features being added to enterprise platforms depend on standard data structures and standard process flows. Heavily customised systems get less value from them, and sometimes none, because the vendor's models are trained and tested against the standard object model. The organizations that held the line on customisation between 2009 and now are the ones able to adopt new capability quickly today. That was not the argument anyone made at the time, but it turned out to be the return on the discipline.
Common Questions
What is the difference between ERP configuration and customisation?
Configuration uses settings the vendor designed and tests with every release. Customisation changes or adds code, which the vendor does not test and does not guarantee across upgrades.
Why is ERP customisation so expensive long term?
Because the build is a small fraction of the cost. Each customisation must be regression tested at every upgrade, supported without vendor assistance, and understood by future teams — for as long as the system runs.
What is a clean core approach?
Using standard functionality wherever possible and building any necessary extensions on a separate platform, decoupled from core code, so that upgrades do not break them and technical debt does not accumulate in the core.
How do you control customisation during an ERP project?
Set the policy before the project starts: standard by default, deviation by approval from a governance body with authority, supported by a written business case that includes ten-year support and upgrade costs.
Customization Policy Review — Outpace audits your custom code estate, prices its real lifetime cost, and puts a governance policy in place that survives schedule pressure.