I can usually tell an ERP rollout is in trouble before anyone shows me the project plan. Someone says, “Our business is a bit unique, but the system should be straightforward.” Translation: key workflows still live in spreadsheets, half the pricing logic sits in one person’s head, and nobody has agreed who owns item master, customer master, or chart-of-accounts decisions.
That combination causes more ERP pain than the software itself.
For small businesses, especially family-run ones, most ERP implementation mistakes are not technical failures. They’re ownership failures, data failures, and design failures that get disguised as “the vendor didn’t configure it right”. By the time go-live hits, the team is exporting to Excel again, finance doesn’t trust margin reports, warehouse staff are bypassing steps, and the owner is asking why a six-figure project made things slower.
If you’re dealing with NetSuite, Cin7, MYOB Advanced, or another mid-market ERP in Australia, the pattern is remarkably consistent. The names change. The failure modes don’t.
The mistake that starts most of the others
The first big error is trying to preserve old spreadsheet behaviour inside the new ERP.
Family businesses are especially prone to this because the spreadsheet is rarely “just a spreadsheet”. It’s a pricing engine, an approvals workflow, a margin checker, a stock allocation rulebook, and a peace treaty between sales, ops, and finance. It may be ugly, but it works because the people around it know its quirks.
Then the ERP project begins, and the brief becomes: “Make the new system do exactly what the spreadsheet does.”
That is one of the most common ERP mistakes for family businesses. It sounds safe. It is not safe.
Here’s what usually happens at go-live:
- customer-specific pricing rules haven’t been normalised
- units of measure are inconsistent across products
- manual order exceptions were never formally documented
- credit hold decisions still depend on one manager’s judgement
- sales reps keep side files because they don’t trust what the ERP shows
The result is predictable. Orders start failing validation. Pick slips don’t match what the warehouse expects. Finance finds GST treatment inconsistencies. Sales starts taking orders off-system “just for now”. Within two weeks, the business has recreated the old spreadsheet workflow on top of the ERP it just paid to replace.
If your ERP design goal is “don’t change how we work”, you’re probably paying enterprise software prices to preserve small-business chaos.
“It’s a simple project” is usually the warning sign
When a small business calls the ERP project simple, they’re usually skipping process mapping. That skipped step causes more rollout delay than almost anything else.
Not a fluffy workshop. Actual process mapping.
That means documenting, in detail:
- how a quote becomes an order
- how an order becomes a pick, pack, dispatch, and invoice
- where approvals happen
- where exceptions happen
- who makes the call when the process breaks
Most teams only map the happy path. They do not map the Tuesday-afternoon reality:
- partial stock available
- customer wants split delivery
- special pricing expired but sales promised it anyway
- supplier lead time changed
- freight needs to be rebilled
- order needs to ship before a PO is receipted
- item is active in one system and obsolete in another
That’s where ERP rollout challenges actually live.
In a family business, those exceptions are often handled by habit rather than policy. “Ask Karen.” “Dad usually approves that.” “We know which customers can go over terms.” None of that translates cleanly into system rules unless you force it into the open early.
A proper process map does two things. It shows where the ERP can handle the workflow natively, and it shows where you need a deliberate workaround, integration, or custom build. Without that, the project team spends weeks arguing about software fit when the real issue is undocumented operating logic.
The fit problem is often not a fit problem
A lot of supposed ERP fit issues are really bad master data or unclear process ownership.
This matters because businesses waste months blaming the platform for problems it cannot solve.
Here’s a practical way to tell the difference.
Signs you have a real ERP fit issue
| Symptom | More likely a true fit issue? | Example | |---|---:|---| | Core workflow cannot be modelled without breaking compliance or control | Yes | Complex contract pricing or multi-entity fulfilment the platform genuinely does not support well | | Native approvals are too limited for your risk controls | Yes | You need staged approvals by margin threshold, territory, and account class | | The system forces workarounds across multiple departments | Yes | Sales, warehouse, and finance all need duplicate handling for one order type | | Integration architecture is brittle even with clean inputs | Yes | ERP cannot reliably expose or consume the data needed for other core systems |
Signs you have a data or ownership problem
| Symptom | More likely data/ownership? | Example | |---|---:|---| | Reports disagree depending on who exported them | Yes | Different item codes, customer names, or date filters | | Users say “the ERP is wrong” but can’t point to one consistent rule | Yes | Margin is “wrong” because freight, rebates, or discounts are applied inconsistently | | One person keeps manually fixing records after import | Yes | Customer terms, tax codes, or supplier lead times were never standardised | | Same process works for some teams and fails for others | Yes | Branches or business units follow different unofficial rules |
If the issue disappears when data is cleaned and ownership is clarified, it was never really an ERP fit issue.
This is one of the most expensive common ERP mistakes. Businesses buy add-ons, pay for customisation, or even consider replacing the ERP when what they actually need is governance over master data and decisions.
For readers dealing with unreliable reporting after rollout, this is closely related to the warning signs in 7 signs your ERP reports are no longer trustworthy.
Data migration is always worse than people think
Small businesses almost always underestimate pre-migration cleanup. Not by 10 per cent. Usually by a factor of three.
They assume migration means exporting data from the old system, cleaning a few columns, and importing it into the new one. That’s not migration. That’s file transfer.
Real migration means deciding:
- which records are authoritative
- which duplicates will be merged
- which inactive records should stay inactive
- how historical transactions will be represented
- what level of detail is actually needed on day one
The biggest headache is usually master data, not transactions.
The usual trouble spots
Item master
This is often the worst offender.
You’ll find:
- duplicate SKUs
- old codes still used by sales
- inconsistent units of measure
- supplier pack sizes that don’t match warehouse handling
- descriptions that mean one thing to purchasing and another to customers
If you import that mess into a new ERP, you don’t get clean operations. You get cleaner-looking confusion.
Customer master
Family businesses often have years of account sprawl.
One customer may exist as:
- “Acme Pty Ltd”
- “ACME”
- “Acme Sydney”
- “Acme Accounts”
- a cash-sale version used by the warehouse
Then there are pricing tiers, payment terms, ABNs, delivery addresses, and contacts maintained differently by sales and finance. That blows up quickly when order workflows, statements, and credit controls depend on one clean customer record.
Supplier master
Lead times, minimum order quantities, landed cost assumptions, and contacts are often stale. Purchasing teams work around this manually, so the bad data stays hidden until the ERP starts driving replenishment.
Chart of accounts and dimensions
Finance often tries to carry every historical reporting quirk into the new ERP. Too many accounts, inconsistent cost centres, and unclear department coding make month-end harder, not easier.
Key takeaway: Most ERP go-live errors start months earlier, when bad master data is treated as an import task instead of an operating model problem.
Family business dynamics make planning harder than people admit
When the owner or family manager is the main decision-maker, project planning often misses decision rights. That hurts adoption after go-live more than any training deck will fix.
This is one of the defining ERP mistakes for family businesses.
The owner usually knows the business better than anyone. That’s the strength. The weakness is that many decisions remain centralised and informal:
- pricing exceptions
- customer credit calls
- stock allocation priorities
- purchasing overrides
- who gets to bypass the process when a big account complains
During implementation, the team waits for these calls. Workshops stall. Config decisions sit unresolved. The vendor keeps moving because the timeline says it must. So assumptions get made.
After go-live, staff discover the system reflects those assumptions, not the owner’s actual intent. Adoption drops because people feel the process was imposed on them, while the owner feels the system “missed how we really work”.
That’s not a software problem. It’s a governance problem.
What should have been nailed down in project planning
-
Who owns each master data domain
Not “IT”. A named business owner for items, customers, suppliers, pricing, and finance structures. -
Who decides process rules
Especially for exceptions. If a margin is below threshold, who approves? If stock is short, who gets priority? -
Which decisions must be made in the room
Some workshops can gather input. Others need binding decisions, on the spot. -
What cannot be deferred to go-live
Tax treatment, fulfilment rules, approval paths, and reporting definitions should not be “worked out later”.
For ERP project planning, this is the difference between momentum and drift.
The go-live mistakes that do the most damage
Most ERP go-live errors are not dramatic system outages. They’re small operational fractures that compound fast.
A few that show up again and again:
1. Reporting is tested last
Teams test whether transactions post. They do not test whether management can trust the outputs.
So the first board pack after go-live becomes the real UAT. Revenue by channel is off. Gross margin excludes freight or rebates. Stock valuation doesn’t reconcile to what ops sees on the floor. Finance then burns days rebuilding reports in Excel.
If reporting matters, test it before go-live with real scenarios, not sample data.
2. Cutover is treated as a weekend task
The plan says:
- final export Friday
- import Saturday
- validate Sunday
- trade Monday
That only works if the source data is stable, the validation rules are clear, and every exception owner is available. In reality, cutover needs rehearsals, rollback criteria, and explicit sign-off thresholds.
3. Super users are chosen by title, not influence
The best super user is not always the manager. It’s often the person everyone already asks when something goes wrong. If that person hates the design, your adoption problem is already baked in.
4. Integrations are assumed to be “just an API job”
Shopfronts, EDI feeds, freight systems, BI tools, payroll, CRM, and supplier portals all depend on data shape and timing. A field existing in two systems does not mean the process is integrated.
For businesses trying to avoid data lock-in after rollout, this is where an external reporting layer helps. A governed data foundation, like Data Warehouses & Data Lakes, gives you one source of truth above the ERP so reporting and analytics are not trapped inside one vendor’s schema.
That same architecture is explored in more detail in how to build a lakehouse layer above ERP systems.
The list of mistakes I see most often
If you want the short version, these are the common ERP mistakes that keep recurring in small businesses.
- treating ERP selection as a software demo contest
- trying to replicate spreadsheet logic instead of redesigning process
- skipping detailed process mapping because the business is “simple”
- underestimating data cleanup, especially item and customer master
- confusing bad data with poor ERP fit
- leaving exception handling undocumented
- centralising too many decisions with the owner
- failing to assign business ownership for master data
- testing transactions but not reporting
- assuming go-live is the finish line instead of the start of stabilisation
That cluster is the heart of most ERP mistakes for family businesses. Not one of them is solved by buying a “better” system on its own.
What I’d do before touching another ERP configuration screen
Pause the build and run a hard diagnostic on data, process, and ownership. Not for six months. For two focused weeks.
Use this sequence:
-
Map the top 10 revenue-critical workflows
Quote to cash, procure to pay, stock adjustments, returns, credit approvals, and month-end close. -
Identify every off-system dependency
Spreadsheets, shared inboxes, paper forms, side databases, and “ask this person” steps. -
Audit master data quality by domain
Items, customers, suppliers, pricing, tax, chart of accounts. -
Name the real owners
One accountable business owner per domain and per core workflow. -
Test reporting definitions before go-live
Revenue, gross margin, stock, debtor ageing, purchase commitments, and cash forecasts. -
Decide what belongs in ERP and what belongs around it
Not every workflow should be forced into the ERP. Some belong in integrated tools or custom front ends.
That last point matters. We’ve seen Australian businesses get far better results by keeping the ERP as the system of record while moving customer-facing or exception-heavy workflows into purpose-built layers. For wholesale teams, for example, B2B Ordering Portals can handle customer-specific pricing, ordering workflows, and repeat orders cleanly, without forcing sales and customers through clunky ERP screens.
For a broader view of why this “data liberation” approach matters, read ERP Data Liberation: Contrarian Insights and Innovation.
The uncomfortable truth about ERP recovery
If your rollout is already messy, the answer is rarely “train people harder”. Training helps. It does not fix broken process design, bad master data, or unclear authority.
That’s why recovery work needs someone who can do two things at once: make senior architectural and vendor decisions, and get practical enough to sort the workflow, data, and reporting details that staff feel every day. In my experience, that’s where projects either stabilise or keep bleeding.
Artigence does that through Fractional CTO and ERP Data Integration work, with live production systems for Australian businesses, not off-the-shelf SaaS rebadging and vendor talk. If your ERP rollout is stuck, reporting is unreliable, or you need a clean layer above NetSuite, Cin7, or MYOB Advanced, the fastest next step is to book a call with Artigence. We’ll help you identify whether you have a fit problem, a data problem, or an ownership problem, and what to fix first.
