ERP customisation: what to configure, customise or keep standard

On 4 October 2024, Malaysia’s Inland Revenue Board (HASiL) published version 4.0 of its e-Invoice Guideline, after version 3.1 on 19 July and version 3.2 on 30 July (HASiL, e-Invoice Guideline version 4.0, 4 October 2024). Businesses with annual turnover above RM100 million have had to issue e-invoices through MyInvois since 1 August 2024, and the next group follows on 1 January 2025. Each change like this arrives as a vendor update and a dated setting, or as a developer’s job, depending on where the rule lives in your enterprise resource planning (ERP) system.

Configure an ERP wherever its own settings do the job, and customise it only for processes customers choose you for. Customise by extending the system outside its core. Keep internal steps standard, from ledger posting to stock valuation, and meet tax and other legal must-haves before go-live without custom code.

Teams tend to believe their processes are unique, and some are. Most finance and inventory steps aren’t, and code written for them has to be retested every time the system is updated. That holds whether you’re choosing a system or deciding what to change in one you already run.

1. ERP configuration changes settings, and ERP customisation adds code

ERP configuration changes how the system behaves through settings it already offers, and ERP customisation adds code. Configuration covers fields, approval limits, document numbering and tax codes. Customisation is an extension kept outside the vendor’s core or, as a last resort, a change to the core itself. The further a change moves from settings, the more work each upgrade takes.

Vendors name these levels differently, and their guidance agrees on the two ends: settings first, changes to the vendor’s own code last.

We sort changes into four levels:

Level	Example	What happens at upgrade	When to use it
Configure	Extra fields, print templates, user roles, tax codes	Settings carry over; check they still fit	First, for every requirement
Extend	An add-on module, script or app built on the ERP’s API or extension model, outside the core	Usually survives, but needs retesting	A differentiator customers notice that settings can’t match
Integrate	A ready-made product connected to the ERP, such as a warehouse management system (WMS), a customer relationship management (CRM) system or invoice capture	Each system updates on its own; retest the connection	A must-have such as an e-invoicing link, or an internal step with a large, frequent workaround
Modify the core	Changing the vendor’s own code	Has to be redone or retested at every upgrade, and can hold it up	Last resort, for a differentiator no extension point can reach

Microsoft’s implementation guide puts settings first: “App settings are the safest and least disruptive way to customize your app. You should always try them first before looking for other options” (Microsoft Learn, customise and extend, 24 January 2024).

At the other end, both vendors keep changes out of their own code. SAP calls its approach “clean core”. In that model, “any modification to the ERP functionality offered by SAP is built outside of the core, using extensibility solutions”, as SAP’s chief business officer put it in an interview (SAP News Center, 6 May 2024).

Microsoft goes further in its Dynamics 365 finance and supply chain apps. There, extensibility is “the only customization framework”, and changing Microsoft’s own code, which Microsoft calls overlayering, “isn’t supported”. The extension model is designed “so that updates are less likely to affect custom solutions” (Microsoft Learn, extensibility home page, 14 May 2019).

Extensions still need retesting at each update, so configuration remains the cheaper place to start.

Why is integration third? It adds a second system to run and a connection to retest whenever either side updates. Vendors don’t all see it that way. SAP presents side-by-side development on its own separate platform as part of a clean core: its January 2024 article on the approach cites Hitachi High-Tech, which used “a side-by-side development approach on SAP Business Technology Platform (SAP BTP)” and cut “9,000 custom code developments to 472” (SAP News Center, 22 January 2024).

So placing integration third is this article’s judgement, and the diagram shows order only:

2. The test: a process is worth extending only if customers choose you for it

If customers choose you partly for a process, and settings can’t match it, the process is a differentiator: extend the system. That holds even when its terms sit in customers’ contracts, as negotiated prices do. Everything else falls into two groups:

• Must-haves: any other rule from a contract or regulation (tax, statutory reports, e-invoice formats, obligations you don’t compete on) goes live through configuration, the vendor’s localisation or a standard integration such as an e-invoicing connection.
• Internal steps: everything else stays standard, and only a large, frequent workaround justifies a ready-made product beside the core.

If no setting, localisation or standard integration can meet a must-have, the system doesn’t fit, and that’s a selection finding rather than a customisation request.

“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, and the second is an advantage worth protecting in software. Microsoft’s implementation guidance draws the same line for its own ERP: “adopt wherever possible, adapt only where justified”, and it names the processes worth adapting as those that “add business value and give you a competitive edge in the market” (Microsoft Learn, fit-gap analysis, 30 April 2024).

SAP’s clean core article sorts processes the same way: “Create two categories: one for differentiating elements that deliver value to your business and another for basic functions that don’t create value but keep your business running” (SAP News Center, 22 January 2024).

Six questions sort a change request

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

1. Can configuration do this without code?
2. Would a customer notice if this process changed?
3. If not, is it still required by a contract, a service level or a regulation?
4. Does the standard flow produce a wrong result, or only a different-looking one?
5. How often does this happen: every order, or twice a year?
6. What does the manual workaround cost, in hours per month?

The answers sort the request in that order: configure, then differentiator, then must-have, then internal step. Keep an internal step standard when the result is correct, even if it looks different. If the standard result is wrong, check the configuration and the vendor’s localisation first. If neither fixes it, the system doesn’t fit. Only a large, frequent workaround justifies more, and that means a ready-made product beside the core, never code inside it.

Case: contract prices pass the test, freight postings don’t

Contract pricing is the clearest test case, and our own ERP shows where the line sits: a price list per customer or customer group, with tiered discounts, is a setting there.

Where every quotation has to match the customer’s contract, and customers choose the supplier partly for those terms, the pricing is a differentiator. A business with contract prices has four routes:

• Configure: the standard price lists hold customer-specific rates and volume breaks, if the system’s pricing settings reach that far.
• Extend: a pricing extension outside the core holds the contract rules and feeds the standard quotation.
• Modify the core: the vendor’s pricing code changes, and gets retested at every upgrade.
• Change the process: quotations are priced in a spreadsheet and typed in, a workaround on every order.

If the standard price lists hold the rules, that’s configuration and the case is closed. If a contract goes beyond them, the pricing is still a differentiator even though its terms sit in contracts, so it’s extended before go-live: customers would notice on the first quotation. Modifying the core is the last resort, and the spreadsheet fails question 5, because it happens on every order.

Freight postings fail the test. A request to change how freight costs post to the ledger, to match an old system, is an internal step: no customer would notice, the standard posting is correct, and a report can show the split. That’s a small workaround at most: keep the posting standard and build the report.

3. Most change requests are configuration, and the extend column stays short

Most change requests land in one of three columns, and the middle one should stay short. Where a request lands says who carries it at upgrade:

Configure, including must-haves	Extend, if customers choose you for it and settings can’t hold it	Keep standard
Tax codes and rates	Pricing rules and contract rates	Ledger posting and the chart of accounts structure
Approval limits and user roles	Approval chains tied to your service promise	Stock valuation: pick a supported method, never code your own
Document numbering and print templates	Quotation and order flows customers see	Tax calculation logic and statutory reports
Industry fields your team uses every day	Delivery commitments customers rely on	Bank reconciliation

The middle column is where your business differs in ways customers notice, and the right column is where it shouldn’t. The same SAP article puts the case for the right column plainly: “In terms of finance, accounting, HR, procurement, and many other core business processes, you’re probably very similar to your competitors and others in your industry.”

Accounting standards do allow choices, such as FIFO (first in, first out) or weighted average stock valuation, but ERPs generally offer those as settings, so picking one is configuration. Writing your own valuation or posting logic adds risk without adding an advantage.

The finance core stays standard because its logic is connected

Finance and inventory share one chain of logic, so a change in one place shows up in several others. Change the stock valuation method and the effect reaches:

• Cost of goods: every sale posts a different cost.
• Margins: product and customer margin reports move with it.
• Month-end: the stock ledger has to reconcile to the general ledger under the new rule.

The vendor maintains its standard logic across releases. Custom code gets only the tests your team writes, and only as far as the test plan covers. This is our own view, with no source behind it: a posting rule of your own needs explaining at every audit, and that cost rarely appears in the build estimate.

4. A fit-gap analysis comes before any build

A fit-gap analysis compares how your business runs with the system’s standard flow, before anyone writes code. Microsoft describes it as “a method to identify the gaps between your business needs and the standard processes” in its ERP, and places it after a fit-to-standard pass and the configuration that follows (Microsoft Learn, fit-gap analysis, 30 April 2024). Before building any gap, the same guide weighs four things:

• Cost: the complexity, cost and time of developing and maintaining the customisation.
• Impact: its effect on the usability, functionality and performance of the system and the technologies around it.
• Redundancy: whether the vendor’s next releases may cover the need anyway.
• Alternatives: other ways to build it and, in a separate section, a partner’s product.

These steps work with any vendor:

1. List the processes. Quote to cash, purchase to pay, stock, month-end close, and anything specific to your industry.
2. Walk each one through the standard flow with the people who do it. Use the system itself, loaded with sample data.
3. Mark each step fit, configure or gap. A gap is anything settings can’t cover.
4. Sort each gap into a route. Differentiators customers choose you for get an extension. Must-have gaps go to the vendor’s localisation or a standard integration. Internal steps stay standard.
5. Price the workaround in hours per month. For an internal step, a couple of hours a month rarely justifies anything beyond the standard flow. A large, frequent workaround may justify a ready-made product beside the core.
6. Decide: extend, integrate, or accept the standard. Write the reason next to each decision.

5. Local tax rules belong in configuration with effective dates

Tax rates and e-invoicing rules in Singapore, Malaysia and Indonesia change often, each time from a fixed date, and every one of them is a must-have. They should reach your ERP as vendor updates, “localisation” (the vendor’s country pack of tax rules and formats) or a standard integration, as settings with effective dates. Built as custom code, they cost your own team a change and a retest at every rule change.

The main rules, with the date each one applies from:

• Singapore GST: the goods and services tax (GST) rate has been 9% since 1 January 2024 (Inland Revenue Authority of Singapore (IRAS), current GST rates).
• Singapore InvoiceNow: GST-registered businesses will send invoice data to IRAS through InvoiceNow solutions, in phases: voluntary early adoption from 1 May 2025, newly incorporated companies that register for GST voluntarily from 1 November 2025, and all new voluntary GST registrants from 1 April 2026. IRAS will announce details for the remaining GST-registered businesses later (IRAS media release, 15 April 2024).
• Malaysia service tax: the rate rose from 6% to 8% on 1 March 2024, with food and beverage, telecommunications, parking and logistics services kept at 6% (Service Tax (Rate of Tax) (Amendment) Order 2024, P.U. (A) 64/2024).
• Malaysia e-invoicing through MyInvois: the requirement phases in by annual turnover or revenue. Businesses above RM100 million came into scope on 1 August 2024, those above RM25 million and up to RM100 million follow on 1 January 2025, and all other taxpayers on 1 July 2025 (HASiL, e-Invoice Guideline version 4.0, 4 October 2024).
• Indonesia VAT: the Harmonisation of Tax Regulations Law (Law 7 of 2021) set value added tax (VAT) at 11% from 1 April 2022 and at 12% from no later than 1 January 2025 (JDIH BPK, Law 7 of 2021).
• Indonesia e-Faktur and Coretax: VAT invoices are made in e-Faktur, an application of the Directorate General of Taxes (DJP). Once DJP’s new core tax system, Coretax, goes live, invoices will be made in Coretax itself, and the system will assign their serial numbers (DJP, Coretax and tax returns, archived 10 June 2024). DJP opened a Coretax simulator for taxpayers on 23 September 2024, ahead of its launch (DJP press release, 24 September 2024).

Our own ERP keeps tax rates as settings with effective dates, so a step such as Indonesia’s move from 11% to 12% is a new rate dated from the day it applies.

Who absorbs a rule change depends on who owns the tax logic. When the vendor’s localisation holds the rule, the vendor ships the change and your team sets its date and tests it. When your own code holds it, your team writes the change as well, and each new version of a guideline, such as HASiL’s three between 19 July and 4 October 2024, means checking that code against it.

Microsoft’s guide to Malaysian e-invoicing in Dynamics 365 Finance shows the vendor side. Customers import Microsoft’s feature, set up credentials, certificates and tax-type mapping, and set any extra properties “through configuration only. No coding is required” (Microsoft Learn, Malaysian e-invoicing, 8 August 2024). The limit is on the same page: that invoicing service runs on cloud deployments only.

Ask how your vendor ships these updates before you sign (question 3 of the five vendor questions below), and where a system has no built-in connection to an e-invoicing network, use a standard integration to meet the must-have without custom code.

6. ERP customisation keeps costing after the build

The build is only the first part of a customisation’s cost, and the rest arrives for as long as the customisation exists. Four costs recur:

• Upgrades: every upgrade has to be checked against each customisation, and some need rework.
• Testing: custom code needs its own tests, kept up to date release after release.
• Knowledge: someone has to remember why the customisation was made, and when that person leaves, the reason often leaves too.
• Training: new staff learn a process that doesn’t match any guide or tutorial.

Vendors say the same about their own systems, and they also sell the extension platforms they recommend, so their advice comes with an interest.

SAP’s Hitachi High-Tech case in section 1 puts a number on the upgrade cost: with 472 custom code developments in place of 9,000, the company could “facilitate major upgrades every year and minor updates every six months” (SAP News Center, 22 January 2024). Microsoft’s fit-gap guidance opens with a warning for teams that recreate the processes of their legacy systems in a new one: the approach can lead to “costly and unnecessary customizations that require more design, coding, testing, training, and documentation” (Microsoft Learn, fit-gap analysis, 30 April 2024).

We’d add that those five items (design, coding, testing, training and documentation) come back at every update, so they are running costs, and a build estimate that stops at the build leaves them out. The same page notes that a customisation can become redundant once the vendor ships the feature itself.

An academic study of ERP maintenance takes a more measured view. Customisations can bring real benefits, it finds, but each one needs weighing against its likely effect on future maintenance (Light, 2001, Journal of Software Maintenance and Evolution). So each customisation should be a deliberate choice, with its reason written down.

7. A few full cycles on the standard flow separate real gaps from unfamiliar steps

Use the standard flow for real before deciding what to extend, except for a differentiator customers would miss on day one. Before go-live, change requests tend to recreate the old process. Why wait for full cycles? Our sense is that a step which only feels unfamiliar reads as a gap in the first week and as the standard flow by the third month-end close, and the requests that survive those cycles are the real gaps.

The order from go-live to the first extension

From go-live to the first extension, the order is:

1. Meet the must-haves before go-live: statutory rules and contract terms you don’t compete on, without custom code. Extend before go-live only for a differentiator customers would miss on day one, like contract prices the standard price lists can’t hold.
2. Go live on the standard flow for finance, inventory and core records.
3. Run a few full cycles, such as a month-end close, a purchasing cycle or a payroll run.
4. Collect friction. Keep a simple list of where people needed workarounds and how often.
5. Apply the test to each item on the list, asking whether customers choose you partly for this process.
6. Extend the few that pass, with a short note explaining why each customisation exists. Internal steps with a large, frequent workaround get a ready-made product beside the core instead.

Supplier-invoice capture shows that last route. Customers never see it, so it isn’t a differentiator, but typing in every invoice by hand is a large, frequent workaround. The answer is a ready-made capture product beside the core: it reads emailed or scanned invoices into draft entries by optical character recognition (OCR) and leaves the ledger logic standard. Anything that fails a check waits for a person to review it before it posts.

The same order works beyond ERP. In a CRM system, sales stages often need tailoring, but contact records rarely do. In a warehouse management system, picking rules may be specific to your operation, but stock movements should follow the standard.

8. Six signs show a system carries more custom code than it needs

A system that shows several of these signs is probably carrying more custom code than it needs:

• Upgrades: the team postpones them because no one can say what will break.
• Reports: only one person or one vendor understands how the key numbers are calculated.
• Month-end: the figures need manual adjustment after export.
• Tax: a rate change or a new e-invoicing format needs a developer.
• Training: new staff take much longer to learn the system than they would on a standard one.
• Changes: simple ones take weeks because they touch custom code.

The fix is rarely a full replacement. Often it means moving internal steps back to the standard flow and keeping only the customisations for processes customers choose you for. If the system has stalled altogether, the first two weeks of a software project rescue show how we map what is safe to keep before changing anything.

9. Five questions show how a vendor handles change

Each of these five questions has a good answer to listen for:

1. How are customisations kept separate from the core? A good answer names the mechanism (settings, an extension model or an API) and says the vendor’s own code is never changed.
2. What happens to them at upgrade? A good answer says how often updates arrive, how extensions are retested, and who fixes one that breaks.
3. How do statutory updates ship? A good answer: tax rates and e-invoicing formats arrive as vendor updates or localisation, set with effective dates, without touching your custom code.
4. Who owns the custom code? A good answer: you do, with the source code and documentation handed over.
5. Who applies updates, in the cloud and on-premise? A good answer says who installs each update in each setup, how much notice you get, and who retests your extensions.

Put the same five questions to every vendor you shortlist.

10. Takeaways

Configuration comes first, every time. Settings carry over at upgrade and code doesn’t, so a requirement reaches code only after the settings, the vendor’s localisation and a standard integration have all failed to meet it.

We extend a process only when customers choose you partly for it. Contract pricing passes that test. Freight postings, ledger rules and stock valuation don’t, however different the old system was.

We’d rather connect a ready-made product than write code inside the core. Supplier-invoice capture beside the ledger, or an e-invoicing integration where the vendor has none, keeps the core standard and gives the workaround a product that someone else maintains.

Tax rules belong in settings with effective dates. Malaysia’s MyInvois and Singapore’s InvoiceNow phase in on six dates between 1 August 2024 and 1 April 2026, and Indonesia’s VAT is set to reach 12% by 1 January 2025, so each change should land as a dated setting rather than a developer’s job.

Write the reason next to every customisation. The knowledge cost in section 6 outlives the person who built the change, and a one-line reason is what the next upgrade gets checked against.

If you’re shortlisting systems, put the five questions above to every vendor, including us: the ready-to-use ERP page lists the modules and says who owns the customisations and whether the system can run on your own servers. You can also book an ERP demo and walk your own contract pricing or e-invoicing rules through the standard flow with our technical lead, who replies within 24 hours.