The short answer: clean up the processes that create bad master data, not the ones that merely look untidy
If you only have time to fix a few things before ERP, start with the workflows that write to customer, product, supplier, pricing, and approval data. Those are the ones that poison the new system on day one.
I’ve seen teams spend weeks “standardising” low-risk admin steps, then go live with messy item codes, duplicate customers, inconsistent tax treatment, and approval paths nobody can explain. That is how an ERP rollout turns into a very expensive spreadsheet with better branding.
So if you’re asking, which business processes should I clean up before implementing ERP?, the answer is not “everything”. It’s the processes that create rework, corrupt records, or depend on human memory to function.
Clean these up first, in this order
1. Master data creation and maintenance
This is the first place ERP projects get hurt. Customer records, supplier records, item masters, units of measure, price lists, tax codes, GL mappings, and warehouse locations all need one owner and one rule set.
If your current process allows three people to create the same customer in different ways, the ERP will not fix that. It will just preserve the confusion faster.
For Australia businesses, this is where GST errors, ABN issues, and inconsistent trading terms show up. If a customer can exist as “ABC Pty Ltd”, “ABC Pty. Ltd.” and “ABC” across systems, your reporting, invoicing, and credit control are already compromised.
2. Order-to-cash and quote-to-order
This is usually the first process that breaks when teams try to standardise for ERP. Sales wants flexibility, finance wants control, operations wants clean handover, and customer service just wants the order to ship.
The workaround is usually not to perfect the process before go-live. It’s to define the minimum viable order path, then lock the exceptions into a separate queue or approval rule. That might mean standard terms for most customers, with a controlled override path for key accounts.
If the business runs B2B ordering, this is where a B2B Ordering Portal can remove a lot of manual pricing and repeat-order noise before it reaches ERP. That matters because every manual order correction becomes data cleanup later.
3. Purchasing and supplier onboarding
Supplier setup looks boring until it isn’t. If bank details, payment terms, ABN validation, remittance contacts, and tax treatment are handled differently by different teams, you will create payment errors and duplicate vendors.
Fix the intake process first. One form. One approval path. One place where supplier master data is checked before it enters ERP.
That is especially important if procurement is still using email threads or side-channel approvals in Outlook or Teams. Those approvals do not survive ERP migration unless you force them into a defined workflow.
4. Inventory, units of measure, and location logic
If you stock physical goods, this is one of the highest-risk areas in ERP implementation readiness. Item conversions, pack sizes, catch weights, bins, warehouses, and transfer rules need to be consistent before you migrate.
I’ve seen businesses carry three different unit conventions in the same operation, then wonder why stock on hand is wrong after go-live. The ERP is not the cause. It is just the first system strict enough to expose the mess.
5. Approval workflows with financial impact
Anything that affects spend, credit, pricing, or write-offs needs to be explicit before ERP. If approvals live in tribal knowledge, the project will stall the moment someone asks, “Who signs off on this?”
Map the actual decision rights, not the org chart. Who approves a discount? Who can override credit hold? Who can change a supplier bank account? If the answer is “it depends”, the process is not ready.
Key takeaway: Clean up the processes that create or approve data, not the ones that merely generate noise. ERP punishes ambiguity fastest where master data and money meet.
The hidden failure mode nobody budgets for
The biggest risk in ERP process cleanup is not complexity. It is hidden dependency.
A process that looks simple on paper can rely on one person’s memory, a spreadsheet no one admits owns, and a side-channel approval in Slack or email. Once you migrate that into ERP, the process does not just change shape, it loses the informal shortcuts that kept it alive.
That is the failure mode: the old process was never really documented, so the new one inherits only the visible steps and drops the invisible ones. Then the team starts creating exceptions to make the ERP behave like the old system, and you end up with workflow cleanup before ERP turning into workflow clutter after ERP.
If you want a sharper way to spot this, look for processes where:
- only one person knows the sequence
- exceptions are handled in email, not the system
- spreadsheets decide pricing, allocations, or approvals
- the “real process” differs from the SOP
That is exactly the kind of issue that shows up later as untrustworthy reporting. If you’re already seeing that, this pairs closely with 7 Signs Your ERP Reports Are No Longer Trustworthy.
Which process should you standardise first, and which one should wait?
If you want the honest answer, standardise the process that crosses the most departments and has the most data handoffs. Usually that is order-to-cash, procure-to-pay, or inventory movement.
Those workflows are fragile because they depend on sales, operations, finance, and sometimes the warehouse all doing their part in sequence. If one handoff is loose, the ERP will record the wrong thing or block the transaction entirely.
But do not force standardisation everywhere at once. Some legacy process variations should be preserved for now if they are tied to genuine commercial differences.
Keep these variations, at least initially
| Variation | Why it may be worth keeping | What to do instead | |---|---|---| | Customer-specific pricing for major accounts | Often tied to contracted terms or volume commitments | Move it into governed price lists or customer rules, not ad hoc overrides | | Warehouse-specific picking rules | Different sites may have different physical constraints | Standardise the data model, keep operational logic local where needed | | Project-based billing flows | Construction, services, and make-to-order businesses often need exceptions | Separate project billing from standard sales order flow | | Regulatory or tax-specific treatment | Some products or jurisdictions need special handling | Encode the rule explicitly, do not flatten it away | | Legacy credit exceptions for strategic accounts | Sometimes commercially necessary | Put guardrails around who can approve them |
The point is not to preserve chaos. It is to avoid creating more exceptions by forcing a false standard too early.
This is where a proper pre-ERP process audit pays off. You are not asking, “Can we make every process the same?” You are asking, “Which variation is commercial, and which variation is just habit?”
The processes that usually look important but can wait
Some cleanup items are real, but they are not the first fire to put out. If time is tight, do not spend your best people on these before go-live:
- minor report formatting differences
- low-value internal request forms
- edge-case expense approval paths
- non-critical document templates
- cosmetic SOP rewrites that do not change system behaviour
These can absolutely be cleaned up later. They do not usually corrupt ERP data or block implementation.
What does matter is whether the process feeds the system of record. If it does, it needs governance. If it just adds admin friction, it can wait.
For teams thinking about the reporting side of this, a Data Warehouses & Data Lakes layer can help keep finance and operations reporting consistent while the ERP itself is being stabilised. That is often a better move than trying to make the ERP report on every operational nuance from day one.
A practical pre-ERP process audit that does not waste six weeks
If you are trying to answer which business processes should I clean up before implementing ERP?, use this test on every workflow:
- Does this process create or change master data?
- Does it touch money, stock, or customer commitments?
- Does it rely on spreadsheets or email to finish?
- Does more than one team hand the work off?
- Would a bad version of this process damage reporting or cash flow?
If you answer yes to two or more, it belongs in the cleanup scope.
Then score each process on three things:
- data risk: can it create duplicates, bad codes, or wrong balances?
- handoff risk: how many teams need to do their part?
- exception risk: how often does someone bypass the normal path?
That gives you a cleaner prioritisation than a generic business process optimisation workshop ever will.
What to do before the ERP project starts moving fast
The best ERP implementation readiness work is not a giant documentation exercise. It is a short, ruthless audit of the few processes that can break the system.
Focus on:
- master data governance
- order, purchase, and inventory workflows
- approval rules with financial impact
- any process that depends on tribal knowledge
- any variation that is commercially necessary and should be preserved
If you fix those, you reduce rework, migration pain, and post-go-live chaos. If you ignore them, no amount of implementation discipline will save you from dirty data and manual workarounds.
For more context on where projects usually go wrong, read What Are the Most Common ERP Implementation Mistakes? and ERP Data Liberation: Contrarian Insights and Innovation.
If you want the cleaner path, do the audit before you configure the ERP
You can run this process cleanup yourself, and many teams should start there. Map the workflows, identify the handoffs, find the spreadsheets hiding the real rules, and decide what must be standardised versus what should be preserved.
If the process is core, messy, or deeply tied to reporting and operations, that is usually the point where an advisor who also builds is worth more than a purely advisory review. Artigence does this work in Australia for systems like NetSuite, Cin7, and MYOB Advanced, including ERP data integration and workflow cleanup before the implementation hardens the wrong habits.
If you want help with the pre-ERP process audit and the build work that follows it, book a conversation with Artigence.
