The mistake most teams make with ERP customisation
The first bad decision usually happens before anyone writes code. A team looks at a clunky order process, sees a gap in the ERP, and decides to “just customise it” because the exception feels rare. Six months later, that “rare” exception is in every second order, and now the ERP is carrying logic that nobody wants to touch.
I’ve seen this in wholesalers, distributors, and manufacturers across Australia. The pattern is familiar: pricing rules live in one place, warehouse rules in another, and someone has glued the whole thing together with custom approval logic inside the ERP because it looked faster than changing the process.
That is the real question behind What customisation is worth doing in an ERP system, and what should I avoid customising? Not “can we do it?” Almost anything can be done. The better question is whether the customisation will still make sense after the first reorganisation, the first acquisition, or the first upgrade.
Start with what the ERP should own
A good ERP should own the things that are stable, auditable, and close to the financial truth.
That usually means:
- item masters
- customer masters
- tax and GST treatment
- inventory balances
- credit control
- invoice generation
- standard order status flow
- core warehouse allocation rules
If you’re asking what to customise in ERP, start by protecting the parts that affect money, stock, and audit trail. Those are the places where a custom ERP system gets expensive fastest if you make them too clever.
The safest customisation is usually not deep code. It is ERP software configuration, because configuration survives upgrades far better than bespoke logic. If the ERP can already handle the rule through settings, approval matrices, item classes, customer groups, or warehouse parameters, use that first.
What is worth customising, and what should you avoid customising?
There is a clean dividing line I use.
Worth customising
Customisation is worth doing when the rule is:
-
Material
It affects revenue, margin, stock accuracy, SLA performance, or compliance. -
Stable
The rule is unlikely to change every quarter. -
Cross-functional
It touches more than one team, and manual work creates real cost or error. -
Hard to train around
If staff keep making the same mistakes because the system allows them to, the system should probably help.
For B2B order processing, that often includes:
- customer-specific pricing logic that is truly contractual
- freight rules tied to postcode, lane, pallet count, or carrier contract
- credit holds with clear thresholds and overrides
- inventory reservation rules for allocated stock
- approval paths for large or unusual orders
- compliance checks for regulated products
- invoice timing where dispatch and billing are genuinely different
Avoid customising
Avoid customising anything that is:
- a one-off exception for one customer
- a workaround for poor master data
- a temporary process during a transition
- a preference from one team that the next team will not inherit
- a rule that changes often and is already painful to explain
That includes a lot of “small” order-processing exceptions. A small pilot can make them look harmless. Once order volume rises, those same rules become maintenance debt.
If you want the blunt version of what not to customise in ERP, it is anything that exists because the business has not yet decided how it wants to operate.
The customisations that look harmless in phase one
The biggest upgrade pain usually comes from customising the exact places that seem easiest to explain in a workshop.
1. Order routing by customer or product type
This looks simple. If order comes from Customer A, send it to Team X. If it contains hazmat, send it to Team Y. If it is over a threshold, split it.
The hidden problem is that routing logic rarely stays simple. Once it is in the ERP, it starts accumulating exceptions. Then someone adds “unless it is a Friday” or “unless the warehouse is Melbourne” or “unless the order is for a new account.”
The first thing that breaks is usually approval logic, because routing and approval become tangled. One rule changes and suddenly orders are stuck waiting for the wrong person, or bypassing review entirely.
2. Customer-specific pricing inside transaction logic
This is the classic trap. A team wants pricing to “just work” at order entry, so they hard-code special pricing logic into the ERP transaction flow.
That feels efficient until pricing needs a new effective date, a new rebate structure, or a different treatment for GST-inclusive versus GST-exclusive customers. Then the pricing engine becomes a brittle knot.
If pricing is complex, keep the source of truth clear. The ERP can still apply it, but the logic should not be buried inside order entry screens where nobody can see how it is working.
3. Approval rules that depend on too many variables
Approval logic is one of the first things to customise, and one of the first things to regret.
A simple threshold approval can survive. A rule set that checks margin, stock cover, customer category, payment status, and product family often turns into hidden operational damage. Orders sit in limbo. The warehouse waits. The customer rings twice. Someone manually overrides the rule because the business cannot afford to wait.
4. Warehouse-specific exceptions
This one gets expensive fast in multi-warehouse environments. A custom rule that works in one site often fails when you add another DC, a third-party warehouse, or a new fulfilment model.
The issue is not just routing stock. It is reservation, pick priority, split shipments, backorders, and freight allocation. A rule that looked harmless in a small pilot can become a daily reconciliation problem once order volume and exception handling rise.
Where the hidden damage shows up first
If you customise order processing inside the ERP, the first place the damage usually appears is not where people expect.
| Area | What breaks first | What it looks like in practice | |---|---|---| | Credit holds | Orders release when they should not, or block when they should not | Sales overrides become routine, finance loses confidence | | Inventory reservation | Stock is reserved too early or too late | Available stock is wrong, backorders multiply | | Pricing | Wrong price at order entry or invoice | Margin leakage, customer disputes, manual credits | | Shipping | Orders split badly or freight rules misfire | Warehouse rework, missed cut-offs, higher freight cost | | Invoicing | Invoice timing no longer matches dispatch or service delivery | Revenue recognition and debtor reporting become messy |
If you want to spot this before go-live, trace one order end to end. Not a happy-path order. A messy one.
Use a real scenario with:
- a customer-specific price
- a low-stock item
- a credit limit edge case
- a split shipment
- a partial dispatch
- a backorder
- GST treatment that is not identical to every other order
If the custom rule creates confusion in any of those handoffs, it is not ready. This is where ERP implementation guidance gets practical. The test is not whether the screen works. It is whether finance, warehouse, and customer service all agree on what just happened.
Key takeaway: If a custom rule cannot survive a messy real order, it does not belong in the ERP yet.
What usually survives the first year
The customisations that survive are the ones that reduce repeat work without tying the business to one team’s habits.
Usually worth keeping
- customer-specific pricing tables, if governed centrally
- credit limit rules with clear override paths
- automated order validation for mandatory fields
- shipment hold logic tied to compliance or stock availability
- standard integration points to WMS, CRM, or eCommerce systems
- reporting extracts that do not change transaction behaviour
These survive because they are about control and consistency, not personality.
Usually ripped out later
- rules built around one manager’s approval style
- one-off customer workarounds turned into permanent logic
- workflow branches that only one team understands
- custom screens that duplicate standard ERP functions
- hard-coded exceptions for a single warehouse, branch, or rep
Those are the first things to go after a reorg or acquisition. Why? Because they are tied to the way one team worked at one point in time. The new structure does not need them, and the maintenance cost starts to look silly.
That is the practical answer to What customisation is worth doing in an ERP system, and what should I avoid customising? Keep the rules that express business policy. Avoid the ones that merely preserve old habits.
When to change the process instead of the ERP
There is a threshold I use with clients. If the requested customisation affects less than about 10 to 15 percent of orders, and the exception is not strategic, it is usually cheaper to change the process.
That threshold is not a law. It is a pressure test.
Ask three questions:
- How often does this exception happen today?
- Will it still matter after the next growth phase or acquisition?
- Can we train people to handle it manually without creating a bottleneck?
If the answer to all three is “rare, temporary, and yes,” do not build it into the ERP.
A manual workflow or bolt-on tool is often better for:
- special approvals on a small number of high-value orders
- temporary allocation rules during stock shortages
- customer onboarding exceptions
- one-off freight arrangements
- internal review steps that do not affect the transaction itself
This is where a B2B Ordering Portal can be a cleaner fit than pushing every exception into the ERP. For wholesale businesses, a portal can handle customer-specific pricing, repeat ordering, and approval-style workflows without forcing the ERP to become a front-end maze. If you want to see the difference, read How Custom B2B Portals Streamline Order Processing Efficiency.
The customisations that age well in Australia
For Australian B2B businesses, the customisations that tend to last are the ones that reflect local operating reality, not local preference.
That includes GST handling, freight zones across states, warehouse cut-off times, and customer terms that vary by account type. In agriculture, for example, order processing often has to deal with seasonality, bulk quantities, split deliveries, and delivery windows that are tied to transport availability, not just stock. If that sounds familiar, Streamline B2B Order Processing in Agriculture is worth a look.
The point is not that Australia needs special ERP logic everywhere. It is that the business rules that survive here are usually grounded in distribution, compliance, and freight, not in cosmetic workflow preferences.
A practical rule for deciding what to customise
If you are staring at a process map and wondering what customisation is worth doing in an ERP system, and what should I avoid customising?, use this filter:
- Customise when the rule is stable, financially material, and needed across the business.
- Configure when the ERP already supports the behaviour through settings.
- Bolt on when the workflow is important but not core to the ledger.
- Change the process when the request exists mainly to preserve old habits.
That is the real line between ERP best practices and expensive improvisation.
What to do next
Pick one order type that causes the most manual work. Trace it from quote or portal entry through credit check, allocation, picking, dispatch, invoicing, and reporting. Mark every step that depends on a human remembering a rule.
Then sort each rule into one of four buckets: configure, customise, bolt on, or change the process. If a rule exists only to protect a legacy habit, cut it. If it protects revenue, stock accuracy, or compliance, keep it, but keep it visible.
If you want help doing that without turning the ERP into a maintenance trap, book a call about B2B Ordering Portal Development. We build ordering workflows that reduce manual processing without making the ERP harder to maintain.
