Standard vs customised ERP: when to configure or script

Somewhere in most ERP implementations, a workshop reaches a moment where the standard system does something differently from how the business currently does it, and someone reasonably asks whether it can be changed to match. The answer is almost always yes — modern ERPs are flexible, and a capable developer can make the system do nearly anything. The question worth asking is not whether it can be done. It is what you are committing to by doing it.

A customisation is not a one-time cost. It is a recurring one: it must be retested with every upgrade, understood by every new team member, documented or it becomes a mystery, and maintained for as long as the system is in use. Mid-market companies that accumulate customisations without a consistent framework for deciding among them end up with an ERP instance that is expensive to touch, slow to upgrade, and effectively unique — which sounds like flexibility and functions as fragility.

This article sets out a framework for making that decision consistently, because the individual decisions are usually reasonable and the aggregate is usually not.

Why this matters

The direct cost of a customisation is visible at build time and easy to budget for. The costs that accumulate afterward are the ones that actually determine whether it was worth it.

Every customisation increases testing scope at every future upgrade — the vendor's release notes do not know about your script, so someone has to check it manually, every time. Every customisation is a piece of institutional knowledge that lives with whoever built it, and mid-market companies do not retain that person indefinitely; when they leave, the customisation becomes either a black box or a rebuild. And every customisation makes the next implementation partner's job harder, because they are now supporting a system that diverges from the one they trained on and the one the vendor's own documentation describes.

There is a compounding effect specific to ERP: a heavily customised instance becomes progressively harder to change, at exactly the point when the business most needs it to change, because customisation debt accumulates fastest in growing, evolving companies — the ones for whom flexibility matters most.

At a glance: the decision framework

The last row is the discipline that matters most and the one most often skipped. Every customisation request should be required to answer it explicitly, in writing, before approval.

What works, and what to be honest about

What works:

Requiring a written answer to "what breaks if we don't do this." Not a preference, a consequence. "The warehouse team finds the standard picking screen less convenient" is a preference. "We cannot legally invoice under Spanish requirements without this field" is a consequence. Making this distinction explicit and requiring it in writing changes the conversation from advocacy to evidence.

A customisation register, reviewed periodically. Every customisation logged with its owner, its business justification, and a review date. Most mid-market companies have no such register, which means nobody can answer "why does the system do this" for a meaningful share of what has been built, and nobody ever revisits whether a justification still holds.

Preferring configuration to scripting, and scripting to core modification. These carry different maintenance costs and different upgrade risk. A configuration change is usually safe across upgrades. A script needs testing. A core modification is the highest-risk category and should require the highest bar of justification.

Isolating what must be customised. Where customisation is genuinely justified, build it as a discrete, well-documented, loosely coupled addition rather than embedding it through the core configuration. This materially reduces the cost of the next upgrade and the cost of eventually removing it if the justification stops holding.

Revisiting old customisations, not just gating new ones. A justification that was correct three years ago may not be correct now — the regulation may have changed, the competitive differentiator may have become table stakes, the team that needed the workaround may have moved on. Periodic review catches this; most companies never look back.

What to be honest about:

Rejecting a customisation request is a harder conversation than approving one. The person asking usually has a genuine, immediate frustration, and "adopt the standard process" can feel dismissive even when it is the right answer. This is a governance and communication skill as much as a technical one, and it needs a decision-maker willing to have the uncomfortable conversation.

Some customisation is genuinely necessary, and refusing all of it is its own failure mode. Statutory requirements, genuine competitive differentiators, and integration necessities are real categories. The goal is a consistent, defensible framework, not a blanket refusal.

The framework requires someone with authority to say no. Without an empowered decision-maker — the same requirement discussed in the NetSuite implementation failure patterns elsewhere in this series — this framework is a document nobody follows, because every individual request will find an advocate and no request will find a consistent evaluator.

Legacy customisations are harder to remove than new ones are to prevent. Once a process has been built around a customisation, removing it has a change-management cost independent of its technical cost. This is an argument for rigour at the point of creation, since prevention is cheaper than a later removal by a wide margin.

This is not a one-time decision. A framework applied once at implementation and then abandoned produces the same accumulation it was meant to prevent. It needs to be a standing governance process, with an owner, for the life of the system.

Decision framework recap: applying it in practice

The table above is the framework. In practice, apply it as a standing process:

1. Every customisation request enters a register before any development begins, with the requester required to answer the written justification question.

2. A named decision-maker evaluates against the framework, not a committee — see the NetSuite implementation article in this series for why this matters generally.

3. Approved customisations are built isolated and documented, with an owner and a review date recorded.

4. The register is reviewed at a fixed interval — annually is reasonable for most mid-market companies — and every entry's justification is re-tested against current circumstances, not just its original approval.

5. Rejected requests are logged too, with the standard-process alternative documented, so the same request does not resurface without institutional memory of why it was declined.

Indicative cost and effort

Get a quote for a scoped customisation audit against your existing instance.

Frequently asked questions

How do we retrofit this framework onto a system that already has years of undocumented customisation?
Start with the register — inventory what exists, even without full justification initially, because the inventory alone is valuable. Prioritise review by what is riskiest to upgrade or least understood, rather than attempting to justify everything at once.

What proportion of customisation requests should we expect to reject?
There is no universal figure worth citing, and treating rejection rate as a target distorts the process — the goal is a consistent framework honestly applied, not a quota. In our experience a framework applied with real rigour rejects a meaningful minority of requests that would otherwise have been approved by default, but this varies enormously by company and industry.

Does this framework apply the same way to reporting customisation as to process customisation?
The principle is the same but the risk profile differs — a custom report is generally lower-risk than a change to core transactional logic, because it does not affect how transactions are processed, only how they are presented. Weight your evaluation accordingly; the bar for a report customisation can reasonably be lower than for a workflow customisation.

Who should be the decision-maker for this framework?
The same person with authority over cross-functional ERP design decisions generally — see the implementation article in this series. If no such person exists, establishing that role is a prerequisite to this framework working at all.

How does this relate to a NetSuite implementation specifically?
It is the ongoing governance discipline that prevents the "customisation as the default answer to every gap" failure pattern discussed in the implementation article. That article addresses it during a project; this one addresses it as a permanent operating discipline afterward.

Closing — Next steps

Customisation decisions are made one at a time, by different people, under time pressure, and the aggregate is rarely what anyone intended. A consistent framework — applied by a named decision-maker, requiring a written justification, and reviewed periodically — does not eliminate customisation. It ensures that what exists is there because it earned its place, and that someone would notice if it stopped earning it.

If you want to know where you stand today: attempt to build the customisation register for your existing instance. The exercise alone — discovering what has been built, by whom, and why — is usually the most informative afternoon available to a team wondering why their system has become expensive to change.

About the author

Bruno Galo is the founder of Atypical Tech, a NetSuite consultancy serving mid-market clients across Iberia. He specializes in connecting CRM and ERP systems for seamless order-to-cash workflows, building automated order management pipelines that eliminate manual data entry between sales and finance teams. As an official Stacksync implementation partner, Bruno designs and deploys AI agents on integration platforms to handle exception routing, document processing, and reconciliation — turning fragmented order flows into reliable, self-monitoring systems.

LinkedIn: https://www.linkedin.com/in/brunogd

Sources

URLs are publisher-level and should be verified before publication.

• Oracle NetSuite, customisation and SuiteScript documentation — https://docs.oracle.com/en/cloud/saas/netsuite/
• Panorama Consulting Group, annual ERP Report — customisation and total cost of ownership data — https://www.panorama-consulting.com
• Atypical Tech engagement experience, mid-market NetSuite implementations across Iberia