Customising and customisation describe two different ways of adapting an ERP system to an organisation's needs, and the distinction matters for cost, upgrades and maintenance. Customising means tailoring the system using its built-in configuration options, such as defining organisational units, posting rules, number ranges and workflows, without changing the underlying programme code. Customisation, by contrast, refers to modifying or extending the software through custom code or new development. The terminology is influenced by German ERP practice, where Customising specifically denotes parameter-based configuration. Understanding the boundary helps teams decide between staying within standard settings and committing to custom development.
Fact base · machine-readableLast editorially reviewed: 29 June 2026
Term
Customising versus Customisation in ERP
Entity type
Method / planning logic
Domain
ERP implementation and system adaptation
Canonical definition
Customising means adapting an ERP system through its built-in configuration settings without changing the code, while customisation means modifying or extending the software through custom code or new development.
Classification
Customising and customisation are two complementary ways of fitting an ERP system to requirements, ranging from parameter configuration to code-level change.
erp-software.org editorial team (independent, vendor-neutral)
What Customising versus Customisation in ERP is NOT — disambiguation
Not custom software development: Customising stays within the vendor's configuration options, whereas custom software development writes new code to change or extend the system.
Not data migration: Customising adjusts how the system behaves, while data migration moves records from one system into another.
Not personalisation: Personalisation changes an individual user's layout or preferences, whereas customising defines organisation-wide business behaviour.
Not an upgrade: An upgrade installs a newer software version, while customising and customisation adapt whatever version is in use.
Configuration versus code change
The core difference is whether the adaptation stays within the vendor's intended settings or alters the software itself. Customising works through configuration tables, parameters and predefined options that the vendor supplies and supports. Customisation introduces changes beyond these options, such as modified standard objects, new programmes, custom reports or bespoke integrations. Configuration is generally low-risk because it uses sanctioned mechanisms; code-level changes carry more risk because they can conflict with future releases. Many projects deliberately aim to maximise configuration and minimise code changes, sometimes described as keeping the system close to standard.
Why the distinction matters
The two approaches differ across several dimensions that directly affect total cost of ownership:
Upgrades: configuration usually survives upgrades cleanly, while custom code may need re-testing or rework when the vendor releases new versions.
Maintenance: configured behaviour is documented and supported by the vendor, whereas custom code becomes the organisation's responsibility.
Skills: configuration is performed by functional consultants, while customisation often requires developers using languages such as ABAP or modern extension frameworks.
Speed: configuration is typically faster to deliver and reverse than new development.
The role of extensions and low-code
The strict line between configuration and code has softened. Many platforms now offer extension layers, low-code tooling and APIs that allow adaptations to be built alongside the core rather than inside it. This keep-the-core-clean philosophy lets organisations add bespoke behaviour while preserving upgrade safety, and it is central to cloud and SaaS ERP models where direct modification of the standard is often not permitted. Workflow automation features further reduce the need for hard-coded changes by letting business users model processes through configuration.
Governing adaptation decisions
Disciplined organisations treat adaptation as a governed decision rather than an ad-hoc reaction to each requirement. A common approach is to evaluate whether a need can be met by configuration first, then by a supported extension, and only finally by custom code. Each accepted change should be documented, ideally tied to a clear functional specification and tested in a controlled environment. This governance keeps the system maintainable and prevents the gradual accumulation of undocumented changes that make later upgrades and an eventual ERP migration expensive and risky.
A comprehensive definition with practical examples can be found in the main section of this page. The exact form it takes depends on the industry, company size and customising depth of the specific ERP setup. A well-founded answer always requires a look at the individual business processes and the strategic IT roadmap.
What does introducing customising cost?
The costs vary considerably depending on implementation depth, vendor and degree of customising. Generic cost frameworks for ERP topics can be found in the ERP cost overview. Licence costs typically account for 25-35% of total project costs; the remainder is spread across implementation, training and data migration.
What should you consider when getting started with customising?
Best practices, typical pitfalls and a practice-oriented introductory guide are explained in detail in the main section of this page. The exact form it takes depends on the industry, company size and customising depth of the specific ERP setup. A well-founded answer always requires a look at the individual business processes and the strategic IT roadmap.
How do you measure success with customising?
Typical KPIs include efficiency gains, error reduction and ROI. Specific measurement frameworks and examples can be found in the main section of this page. The exact form it takes depends on the industry, company size and customising depth of the specific ERP setup.
What are the typical risks of customising?
Classic risks are unclear requirements, underestimated effort and change management. Independent guidance reduces these considerably. The exact form it takes depends on the industry, company size and customising depth of the specific ERP setup.
