When to Customise an ERP and When to Leave It Alone

Customise an ERP only where the process is part of why customers choose you, such as your pricing rules or approval chains tied to a service promise. Leave routine steps like ledger posting, stock valuation and tax reporting on the standard flow. Every customisation adds cost each time the system is upgraded, so it has to earn its place.

Every company believes its processes are unique. Some are. Most of the finance and inventory steps are not, and customising them adds cost every time the system changes. The trick is telling the two apart before the budget is spent.

The test: does this process win you customers?

Ask whether the process is part of why customers choose you. If it is, customise the system around it. If it is not, adopt the standard flow and spend the budget elsewhere.

It is a simple question, but it cuts through a lot. “We have always done it this way” is not the same as “customers pick us because we do it this way”. The first is habit. The second is an advantage worth protecting in software.

Questions that sharpen the test

When a team asks for a change, we work through these:

1. Would a customer notice if this process changed?
2. Is this rule written into contracts, service levels or regulations?
3. Does the standard flow produce a wrong result, or just a different-looking one?
4. How often does this happen: every order, or twice a year?
5. What does the manual workaround cost, in real hours per month?

If customers would not notice, nothing is wrong with the result, and the workaround is small, keep it standard.

What to customise and what to keep standard

Usually worth customising	Usually keep standard
Pricing rules, discounts and contract rates specific to your customers	Ledger posting and the chart of accounts structure
Approval chains tied to your service promise	Stock valuation methods
Quotation and order flows that customers see	Tax calculations and statutory reports
Industry-specific fields your team uses every day	Bank reconciliation
Integrations with systems unique to your business	User and permission management

The left column is where your business differs from others. The right column is where it should not. Accounting and tax logic in particular follow rules that are the same for everyone in your market. Custom code there adds risk without adding advantage.

Why the finance core should stay standard

Finance and inventory logic is connected. A small change to how stock is valued can ripple into cost of goods, margins and month-end reports. When that logic is standard, it has been used and tested by many companies. When it is custom, your team is the only one testing it.

Auditors and accountants also expect standard behaviour. A non-standard posting rule can mean extra explanation every year.

The hidden cost of customisation

The cost of a customisation is not just the build. It shows up later:

• Upgrades. Every upgrade has to be checked against each custom change, and some need rework.
• Testing. Custom logic needs its own tests, maintained for as long as the change exists.
• Knowledge. Someone has to remember why the change was made. When that person leaves, the reason often leaves too.
• Training. New staff learn a process that does not match any guide or tutorial.

A customisation is a promise to maintain something forever. Make that promise only for processes that set you apart.

None of this means customisation is bad. It means each one should be a deliberate choice with a clear reason, written down.

Start ready, then extend

Our ready-made systems run the standard flow on day one. Custom work starts only after the team has used it and found where it falls short.

This order matters more than it seems. Before using a system, teams tend to ask for customisations based on how the old process worked. After a few weeks of real use, many of those requests disappear, because the standard flow turned out to be fine once people got used to it. The requests that remain are the real gaps.

A practical sequence

1. Go live on the standard flow for finance, inventory and core records.
2. Run full cycles. Let the team complete at least one month-end close, purchasing cycle or payroll run.
3. Collect friction. Keep a simple list of where people needed workarounds and how often.
4. Apply the test. For each item, ask whether it is part of why customers choose you.
5. Customise the few that pass, with a short note explaining why each change exists.

This applies across systems, not just ERP. The same sequence works for a CRM, where sales stages often need tailoring but contact records rarely do, or a warehouse management system, where picking rules may be specific to your operation but stock movements should follow the standard.

Signs you have over-customised

If your current system shows several of these, it may be carrying more custom logic than it needs:

• Upgrades are postponed because nobody is sure what will break
• Only one person or vendor understands how key reports are calculated
• Month-end numbers need manual adjustment after export
• New staff take much longer to train than on a standard system
• Simple changes take weeks because they touch custom code

The fix is rarely a full replacement. Often it is moving routine processes back to standard and keeping only the customisations that pass the test. If the system has stalled altogether, the first two weeks of a project rescue show how we map what is safe to keep before changing anything.

Choosing a starting point

If you are evaluating systems, look for one that runs your core flows on day one and allows extension without changing the finance core. Ask how customisations are kept separate from the standard logic, and what happens to them at upgrade time.

You can see how our ready-made ERP handles standard flows and extensions, and whether cloud or on-premise suits you better. Ready systems can run either way. If you are in Singapore, check how the EDGE grant treats ERP projects before you sign: the support is capped and the order of steps matters.