The defects that survive cleanup are usually not the obvious ones
The first cleanup pass always catches the loud problems. Blank supplier names. Duplicate customer codes. Materials with no base unit. Those are the easy wins, and they make everyone feel better for a week.
Then month-end lands, or a margin report, or a stock valuation extract, and the same numbers are broken again. That is usually when someone asks the real question: Which master-data defects usually survive the first cleanup pass and keep breaking ERP reporting months later?
The answer is not “bad data” in general. It is a small set of defects that are technically valid, semantically wrong, and wired into more than one ERP process. They survive because they do not look broken in the source system, or because fixing them in one place just recreates the problem somewhere else overnight.
Key takeaway: the defects that survive cleanup are usually the ones that sit at the boundary between master data, ERP logic, and reporting joins, so the fix has to be decided by process, not by whoever found the error first.
The defects that come back after everyone thought they were fixed
There are five patterns I see over and over in ERP data cleanup work.
1. Cross-object mismatches that no single record can reveal
A vendor record can look fine on its own. So can a plant. So can a material. The defect appears only when you join them.
Typical examples:
- supplier assigned to the wrong purchasing org
- material extended to one plant but not the warehouse that actually ships it
- customer master valid in sales, but missing the finance view needed for posting
- valuation class correct in the material master, wrong for the company code
- payment terms set in the customer record, but overridden by hierarchy or contract logic
These are the defects that slip through first-pass data cleanup because no one is looking at the relationship layer. They only surface when the ERP tries to post, price, reserve stock, or summarise by plant and company code.
If you are cleaning master data in NetSuite, Cin7, or MYOB Advanced, this is where the “looks fine in the screen” trap bites hardest. The record can be valid, but the combination is not.
2. Defects recreated every night by the source system
Some master-data defects survive because they are not really defects in the ERP at all. They are being reintroduced by the upstream system, interface, or import job.
You fix the customer group in ERP. The next overnight sync from the CRM writes the old value back. You correct the material description in the warehouse system. The integration job reloads the stale version from a spreadsheet export. You clean a supplier hierarchy manually, then the vendor feed from the procurement platform repopulates the same parent-child structure.
This is why cleanup work often feels like mopping with the tap still running.
If a defect returns within 24 hours, do not keep cleaning the target table. Trace the source-of-truth path, the transformation logic, and the schedule. In Australia, I see this a lot where finance teams are trying to reconcile month-end numbers from ERP while operations are still feeding legacy Excel files into the system. The spreadsheet wins unless you shut the door properly.
3. Fields that are dangerous to “just fix” by hand
Some fields are deceptively small and carry more business logic than they look like they should.
The risky ones are usually:
- tax codes and GST treatment
- account determination fields
- valuation classes
- MRP parameters
- posting periods or default ledgers
- payment terms and dunning rules
- price list or customer hierarchy fields
- unit of measure conversions
A manual correction might make the report look right, but it can break posting, tax calculation, inventory valuation, or integration behaviour elsewhere. That is especially true when the field is used by both transactional processing and reporting.
A classic example is “fixing” a material’s valuation class so stock value ties out in a report. It works until the next goods receipt posts to the wrong inventory account. Another is changing GST classification in the ERP because the sales report is wrong, only to discover the tax engine was relying on a different combination of customer and item attributes.
This is where good cleanup work needs a change log, a rollback plan, and someone who understands the downstream posting logic, not just the report.
4. Defects that are semantically wrong, but technically valid
These are the nastiest ones because they pass validation and still poison reporting.
Examples include:
- duplicate supplier hierarchies that represent the same commercial entity differently
- cross-plant material codes that collapse into one reporting line even though they are operationally distinct
- inconsistent valuation classes across otherwise “valid” materials
- customer duplicates that differ only by trading name, postcode, or payment terms
- plant, warehouse, and company code combinations that are legal in the system but nonsense in the business
The ERP does not care that the data is awkward. It will happily store it. Reporting, however, will aggregate it into misleading totals.
This is why first-pass cleanup often misses the real issue. The record is valid, the code set is valid, the interface is valid, and the business still gets a broken margin report because two commercial entities were collapsed into one reporting bucket.
5. History defects, not current master data defects
A lot of “current” reporting errors are actually historical.
The current master data may be clean. The reporting defect comes from old transactions posted before the cleanup, historical account mappings, archived material snapshots, or a change in hierarchy that altered how prior periods roll up.
Teams usually discover this too late, after they have already compared current master data to current reports and found no obvious mismatch. That is when the search widens to:
- historical price conditions
- archived supplier or customer hierarchies
- old plant extensions
- prior account determination logic
- legacy MRP parameters that affected open orders
- transaction dates that straddle a master-data change
If the report is wrong only for some months, or only after a cutover, assume history before you assume the live master record is at fault.
The ones that keep reappearing because the ERP itself is rebuilding the defect
Some master-data defects are not just surviving cleanup. They are embedded in ERP logic.
That usually happens in three places.
Account determination and tax rules
If account determination is driven by material group, valuation class, plant, and company code, a manual correction in one field may not hold. The next transaction uses the same rule set and recreates the reporting issue in a different account.
Tax is similar. If GST logic depends on customer class, ship-to location, and item tax category, then “fixing” the customer master without checking the rule chain just moves the error.
MRP and planning parameters
MRP parameters are notorious for this. Lot sizes, safety stock, lead times, and reorder points can all look reasonable in a list, but if the planning engine or integration job is resetting them from a template or a BOM feed, the cleanup will not stick.
This is one of the reasons Which Business Processes to Clean Up Before ERP matters before you touch the data. If the process still creates bad defaults, the master data will keep drifting back.
Interface defaults and template-based imports
A lot of ERP data issues are not entered by humans at all. They are cloned from templates, copied forward from old records, or populated by middleware defaults.
That is why a defect can survive the first cleanup pass and keep breaking ERP reporting months later, even when nobody is manually retyping the wrong value. The system is doing it for them.
The defects most likely to be missed in a first pass
When people ask Which master-data defects usually survive the first cleanup pass and keep breaking ERP reporting months later?, I usually point them to the defects that only appear when records are joined across modules.
Those are the ones a simple duplicate check will miss.
Reconciliation checks that catch them early
Use checks that compare across objects, not just within one table:
- customer to ship-to and bill-to consistency
- vendor to purchasing org and company code alignment
- material to plant, warehouse, and valuation area alignment
- tax code to item category and customer class
- account determination to material group and posting history
- open orders to current master extensions
- stock valuation to inventory account postings
- MRP parameters to actual replenishment behaviour
If you are building a lakehouse layer above ERP systems, this is where it earns its keep. A governed data layer can compare current master data, historical transactions, and external reference data without corrupting the ERP itself. That is often a better place to catch drift than trying to force the ERP screen to explain everything.
How to Build a Lakehouse Layer Above ERP Systems covers that pattern well.
Deciding where the fix belongs
Not every recurring defect should be fixed in the same place. If you fix it in the wrong layer, you create a different kind of drift later.
Here is the practical rule I use.
| Where the defect lives | Best fix | When to avoid it | |---|---|---| | Source system creates the defect overnight | Fix upstream validation, mapping, or workflow | If the source is not the true system of record | | ERP posting logic depends on the field | Fix the ERP rule, reference table, or master-data governance | If the field is only used for reporting | | Reporting joins are collapsing distinct records | Fix in the reporting layer or semantic model | If the ERP transaction itself is wrong | | Historical transactions are wrong | Correct via controlled reclassification or adjustment, not live master edits | If the issue is already closed and auditable history must remain intact |
The hard part is knowing when the report is the problem and when the ERP is the problem. If the master data is technically valid but semantically wrong, I usually prefer to fix the source of truth or the ERP rule, not the report. Reporting-layer band-aids are useful, but they should not be the place where business meaning is invented.
That is also where 7 Signs Your ERP Reports Are No Longer Trustworthy becomes a good sanity check. If every report needs a custom exception to make sense, the problem is upstream.
What survives because it looks valid, and why that matters
The defects that survive cleanup are usually the ones that pass a basic validation rule and still fail business logic.
Think:
- duplicate supplier hierarchies that are formally distinct but commercially identical
- valuation classes that are allowed but inconsistent across plants
- cross-plant material codes that merge into one line in finance
- customer records that are valid individually but break when grouped by trading entity
- tax and GST attributes that satisfy the field format but not the posting rule
These are not cosmetic issues. They are the defects that distort margin, inventory, tax, and working capital reporting for months before anyone traces them back.
And because they are often embedded in ERP logic, they do not stay fixed unless the fix is made at the right layer, with the right owner, and the right reconciliation check.
The cleanup pass that actually holds
A good first-pass cleanup is not a one-off scrub. It is a triage exercise.
Start by separating defects into four buckets:
- source-created
- ERP-rule-driven
- reporting-join-driven
- historical
Then test each one against three questions:
- Does the defect reappear overnight?
- Does fixing it in the ERP change posting, tax, or MRP behaviour?
- Does it only appear when data is joined across modules or periods?
If the answer points upstream, fix the source or the interface. If it points to ERP logic, change the rule or the governance. If it only breaks reporting, build the correction into the semantic layer, not the transaction system. If it is historical, treat it as a controlled data correction, not a live master edit.
That is the difference between cleanup that lasts and cleanup that just gives you a quieter inbox for a month.
What to do next
Pick one recurring ERP reporting error and trace it backwards through the chain: report, join, ERP rule, source feed, historical transaction. Do not start by editing the obvious field. Start by asking which layer is recreating the defect, and which layer is only showing it.
If you are dealing with NetSuite, Cin7, or MYOB Advanced and the same master-data defect keeps reappearing, that is usually a sign the fix belongs in the integration path or the governed reporting layer, not in another manual spreadsheet pass. A Data Warehouses & Data Lakes layer can give you one governed model for finance, operations, and external data, so you stop patching the same issue in three different places.
If you want the faster path, bring in an advisor who also builds. That is where our ERP Data Integration work fits, especially when the reporting defect is really a master-data governance problem wearing a dashboard’s clothes.
