ERP for Beginners: Customisation vs Configuration — the ERP Make-or-Break

If you spend any time around ERP — as a buyer, an implementer, a consultant, or just someone watching a project from the outside — you will, sooner or later, hear two words used almost interchangeably by people who don't work with the software, and very deliberately distinct by people who do. Those words are customisation and configuration.

To a casual observer they sound like synonyms. Both of them describe "changing the software to fit our business." Both of them happen during every ERP implementation. Both of them get written down in long specification documents. And yet the distinction between them is, by a wide margin, the most important mental model in the entire ERP world. Projects that understand it come in on time. Projects that don't, don't.

This is episode one of Season 2 of ERP for Beginners — the Going Deeper season — and we're going to unpack this one idea properly. By the end you'll know what each term really means, why they're not interchangeable, why the industry has strong opinions about which one to prefer, and what the modern answer looks like when "don't customise" collides with "our business really does work differently."

What configuration actually is

Let's start with configuration, because it's the one people tend to underestimate.

Configuration is what happens when you change the behaviour of an ERP system without writing any new code. Every serious ERP ships with thousands — sometimes tens of thousands — of switches, toggles, tables, and parameters that let you shape how it behaves. You configure the system by setting those values.

A partial list of things that are configuration:

• Setting up your chart of accounts — the list of general-ledger accounts your finance team will post to. You pick the account numbers, the account types, the groupings. No code is written; you're populating tables the vendor already built.
• Defining company codes and the currencies, fiscal calendars, and legal entities they belong to. The software already knows what a company code is — you're telling it the specific ones your business has.
• Setting tolerance groups — the rules that say "if a purchase invoice is within 2% of the purchase order amount, auto-approve; otherwise send for review."
• Configuring approval workflows — who has to sign off on a purchase over $5,000, a payment to a new vendor, a journal entry above a certain threshold.
• Picking which payment terms your business uses — Net 30, Net 60, 2/10 Net 30, end-of-month. All those options are already in the software; you're choosing which subset to activate.
• Defining tax codes for the jurisdictions you operate in. The software knows about VAT, sales tax, withholding tax; you're filling in the specific rates.

The thread running through all of these is that the vendor anticipated them. The software was built with the expectation that businesses would need to express these things, and the vendor provided a controlled way to do it. You're using the product the way the product was designed to be used.

A different but equally valid way to say it: configuration is flipping switches the vendor already installed.

Crucially, configuration survives upgrades. When the vendor ships a new release next year, your configuration carries forward largely unchanged. The switches are still where they were; your choices are still your choices. That durability is one of configuration's best properties.

What customisation actually is

Customisation is what happens when you change the behaviour of an ERP by writing new code that didn't exist in the shipped product.

The classic example is an SAP project writing ABAP — SAP's proprietary programming language — to build a new report, a new transaction screen, or a modified version of a standard process. Oracle projects do the same thing with PL/SQL or Java. Salesforce does it with Apex. NetSuite does it with SuiteScript. Every ERP has its in-system programming model, and customisation is what happens when someone sits down and writes code in that model.

Typical customisations:

• A custom report that combines fields from multiple modules in a way the standard reports don't.
• A modified sales-order screen that adds three industry-specific fields your company needs.
• A custom invoice-approval workflow that doesn't fit the workflow templates the system ships with — maybe because your approval chain depends on a field the vendor's workflow engine can't see.
• A user exit — a piece of custom code inserted into the middle of a standard transaction, triggered at a specific point ("when a purchase order is saved, check this custom table first").
• A whole custom module, in extreme cases. Some industries — utility, oil and gas, parts of public sector — have historically had entire functional areas bolted onto standard ERP with tens of thousands of lines of custom code.

Customisation is powerful. If the vendor didn't anticipate what you need, customisation is how you make the software do it anyway. But that power comes with costs, and understanding those costs is the heart of this episode.

Why the industry is terrified of over-customisation

Every senior ERP person you meet will, if given half a chance, tell you a horror story about a customer who customised too much. These stories are industry folklore, and they share a shape.

A company buys an ERP. The vendor's implementation partner arrives, asks the business "how do you do things today?", and rather than pushing back, agrees to replicate exactly how things are done today — in code. Every quirk, every exception, every "well, we've always done it this way." All of it gets coded up as customisation on top of the standard software. The project goes live. Everyone celebrates.

Then three things happen:

The upgrade bill arrives. A year or two later, the vendor ships a new version. The standard software has been improved. But the custom code was written against the old standard software's internals. Every customisation has to be reviewed, tested, and often rewritten, because the thing it was hooking into has moved. Some customers discover that their upgrade is a second implementation — longer and more expensive than the first.

Support becomes impossible. When something goes wrong in a standard system, the vendor's support team can diagnose it because they know the standard system. When something goes wrong in a heavily customised system, the vendor shrugs — that's your code, not ours. The customer is on the hook for supporting code written years ago by consultants who have long since moved on.

The best practices get buried. ERPs aren't generic. They embed specific ways of doing finance, procurement, HR — ways that the vendor has refined across thousands of customers. A new employee joining a company with a heavily customised ERP can't use their industry knowledge from previous jobs, because the system doesn't behave the way the textbook says. It behaves the way your consultants coded it to behave five years ago.

The costs compound. A lightly customised ERP is faster to upgrade, easier to support, cheaper to staff, and — perhaps most importantly — able to absorb the vendor's innovations as they arrive. A heavily customised ERP becomes, over the years, a bespoke piece of software with an ERP pedigree, increasingly disconnected from the product line it started from.

This is why the industry mantra is "vanilla is best." Stay as close to the shipped behaviour as you can. Customise only when you have to. And when you do customise, write it down, isolate it, and keep the list as short as humanly possible.

The line between them is not always clean

In theory, the line between configuration and customisation is sharp: one is flipping switches, the other is writing code. In practice it's fuzzier, because modern ERPs have intermediate mechanisms that sit between pure config and pure code.

User exits and enhancement points are places in standard code where the vendor has deliberately left hooks — "put your custom logic here if you need to." That's code, so technically customisation, but it's sanctioned, isolated, and designed to survive upgrades. It's considered much safer than modifying standard code directly.

Custom fields — adding a new column to a master data record — are config in some systems and code in others. A modern system might let you add a field through an admin screen with no code; an older one might require a developer.

Workflow engines let you wire together approval chains using drag-and-drop tools. That's still configuration by most definitions, but it can encode surprisingly complex business logic.

Form and report designers let power users build new views of existing data without involving IT. Again, configuration in spirit, but the output can be very rich.

The distinction that matters, across all of these, is: does this survive the upgrade? If the answer is yes, and the mechanism was designed by the vendor for this purpose, you're on safe ground regardless of what the label says. If the answer is no, or you're relying on vendor internals staying stable, you're in customisation territory and the costs apply.

When customisation is actually the right call

Despite the industry's preference for vanilla, there are real cases where customisation is the correct answer. It's worth knowing what they look like.

Your business really is different in a specific, valuable way. Every business thinks it's a special snowflake — most aren't. But sometimes the thing that makes your business money is a process that doesn't exist in the standard software. A unique pricing model, an unusual manufacturing step, an industry-specific compliance requirement. If that unique thing is a source of competitive advantage, coding it into the system may be the right call.

Regulatory requirements the vendor hasn't caught up to. A new local regulation drops, your local tax authority mandates a specific document format, and the vendor's next release won't include support for eighteen months. Customisation is how you bridge the gap, ideally with the expectation that you'll rip it out once the standard supports it.

Integration with a legacy system you can't replace yet. The ERP has to talk to a 15-year-old mainframe that won't exist in five years. Standard interfaces don't exist. You code the bridge, knowing it's temporary.

In each of these cases, the right discipline is: customise narrowly, document why, plan the exit. If the customisation exists because the vendor hasn't caught up, schedule its removal for when they do. If it exists because your process is genuinely unique, write down why, so that in ten years someone doesn't delete it thinking it's cruft.

The modern answer: extensions, not modifications

The biggest shift in the last decade is that the ERP industry has largely moved away from in-system customisation entirely, in favour of extensions.

The idea is simple. Instead of writing custom code inside the ERP's core — modifying standard transactions, hooking into user exits, adding ABAP to the main system — you write your custom logic in a separate environment that communicates with the ERP through stable APIs. SAP calls this the clean core approach. Oracle, Microsoft, and Salesforce all have their own versions of the same idea. The custom code lives in a cloud platform next to the ERP, reads and writes via documented interfaces, and is completely insulated from the vendor's internals.

The benefits are significant. Upgrades of the core ERP don't touch the extension. The extension can be written in a modern language by a developer who doesn't need to know the ERP's internal model. The core ERP can be kept vanilla and continue to absorb vendor innovation automatically. And if you ever switch ERPs, your extensions — written against stable APIs — are substantially more portable than on-platform customisation ever was.

This shift is why you'll hear so much current language about clean core, side-by-side extensibility, headless ERP, and API-first architecture. It's all pointing at the same thing: keep the ERP vanilla, put the custom stuff outside.

For a beginner, the takeaway is simple. When someone says "we're doing this as an extension rather than a customisation," they're saying: we're not touching the ERP's core, we're building next to it. That's the modern best practice.

Why this is the most important mental model in ERP

Pull all of this together and you can see why configuration-vs-customisation is the distinction that predicts project outcomes.

Projects that lean hard on configuration — and resist the urge to code around every business quirk — tend to finish on time, come in on budget, and age gracefully. The vendor's product works, the staff trained on the vendor's product feel at home, and each new release delivers value automatically.

Projects that lean hard on customisation — because "we've always done it this way" was allowed to drive design — tend to overrun, blow budgets, create long-lived technical debt, and end up paying for the same implementation twice when the next major upgrade arrives.

For anyone watching an ERP project — whether you're inside it, running it, or buying into it — the single most useful question you can ask is: "is what you just described configuration or customisation?" If the answer is "configuration, using the standard mechanisms," relax. If the answer is "customisation, because the standard didn't fit," ask one more question: "could we change the business process instead?" In most cases — not all, but most — that's the better answer.

What's next

That's the first episode of Season 2. Configuration versus customisation. The vendor's switches versus your own code. Vanilla versus custom. And the modern extensibility story that lets you have it both ways.

Episode two goes to the layer underneath: the data. Every ERP runs on two fundamentally different kinds of data — master data and transactional data — with different rules, different lifecycles, and different failure modes when they go wrong. If configuration-vs-customisation shapes the system, master-vs-transactional shapes the content that flows through it.

See you there.