Customising versus Customisation in ERP

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.

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.

Related Topics

• ERP
• Low-code platforms
• Sandbox