Manufacturing
Data quality problems in manufacturing ERP: the usual suspects
By SourceX Editorial · Updated
Short answer
The usual ERP data quality issues in manufacturing are orphaned orders and jobs, stale routings and BOMs, reused part numbers, catch-all reason codes, duplicate customers and history cut off at migrations. For AI use, broken links matter more than typos: a buyer can live with messy fields, but not a job that no longer connects to its order or NCR.
Key takeaways
- Most ERP data problems fall into two kinds: wrong values, which can be documented, and broken links, which usually cannot be repaired later.
- Overwritten dates and backflushed actuals hide the variance and judgment that make manufacturing history useful.
- Data quality is the condition of records; quality-control data, such as inspections, CMM reports and defect images, is a type of record.
- A licensing buyer needs long, linked, documented history and can accept known flaws that would stop an internal AI rollout.
- Document problems in a known-issues note before cleaning anything, and keep crosswalks whenever records are merged.
What counts as an ERP data quality problem in a plant?#
An ERP data quality problem in a plant is any gap between what the records say and what actually happened on the floor, in purchasing or with the customer. Some gaps are wrong values, such as a routing that still lists a machine the plant sold. Others are missing links, such as a job that no longer points to the sales order it was built for.
The mess is rarely spread evenly. Master data such as parts, routings and bills of materials decays slowly as the plant changes around it. Transaction history decays in jumps, usually at a migration, an acquisition or a change in how a module was used.
The two kinds call for different responses. Wrong values can often be documented and lived with. Broken links usually cannot be rebuilt after the fact, so they set the limits of what any analysis or AI project can do with the history.
This is not only a licensing concern. In RSM's 2026 middle-market AI survey, data quality and availability issues were the most cited inhibitor to AI deployment, named by 34% of respondents, ahead of security and privacy concerns and legacy systems integration. The same ERP problems that slow an internal AI project also shape what a plant can license.
The ten usual suspects#
The ten problems below turn up again and again in mid-sized manufacturing ERPs, whatever the brand. Each one has a different effect depending on whether the data is used internally or licensed to an AI developer, so the last column focuses on AI use.
| Problem | What it looks like | Effect on AI use |
|---|---|---|
| Orphaned orders and jobs | Jobs with no sales order, shipments with no invoice, NCRs with no job number | Breaks the chain from request to outcome, the part buyers value most |
| Stale routings | Standard setup and run times never updated from actual labor | Plans look precise but mislead any model that treats standards as reality |
| BOMs that differ from what was built | Floor substitutions never recorded; phantom assemblies left in place | Material history disagrees with the bill, weakening cost and quality links |
| Reused part numbers | A retired part number assigned to a new, unrelated item | Merges two products' histories and corrupts failure patterns |
| Duplicate customers and vendors | One customer entered under several names after acquisitions or typos | Splits one relationship's history and inflates counts |
| Catch-all reason codes | Scrap, downtime or return reasons coded as other or miscellaneous | Removes the label a model would learn from; notes become the only clue |
| Backflushed labor and material | Consumption posted at standard when the job closes | Actuals mirror the plan, hiding the variance that carries signal |
| Overwritten dates | Promise and due dates replaced on each change with no history | Loses every reschedule, the record of planner judgment |
| Migration cut-offs | Closed jobs, old quotes or NCRs left behind at go-live | History looks short, and older years sit in a system nobody opens |
| Work kept outside the ERP | Expedite lists, schedule boards and inspection logs in spreadsheets | Key decisions are missing from the system of record unless the files are kept |
- 01Your work records
- 02Personal details removed
- 03You approve the release
- 04Licensed to AI developers
Which problems a buyer can live with, and which end the conversation#
Broken links and lost history matter most for AI use; cosmetic errors matter least. An AI developer licensing manufacturing records wants to see how a request turned into a decision and an outcome. Typos, odd descriptions and inconsistent capitalization rarely change that story.
Problems in the middle tier are survivable if they are written down. Catch-all codes, backflushing and stale standards each distort part of the picture, and a buyer can work around the distortion once it knows where it sits. Undisclosed distortion is worse than known distortion.
- Usually disqualifying for the affected years: orphaned records across the main chain, reused part numbers with no way to separate histories, and history that survives only as printed reports.
- Workable with a note: catch-all codes, backflushed actuals, stale standards and duplicate customers that can be mapped to one ID.
- Mostly cosmetic: description typos, inconsistent abbreviations and unit labels that are at least consistent within each part.
Data quality is not the same as quality-control data#
Data quality describes the condition of records, while quality-control data is a type of record, and the two get confused in planning meetings. Quality-control data includes inspection results, NCRs, CAPAs, CMM reports, SPC charts and the images saved at inspection stations.
Much of that material lives outside the ERP, in a QMS, in CMM software, in SPC tools or in folders written by a vision inspection camera. It can be among the most distinctive records a plant holds. Model builders working on visual inspection need labeled examples of defects, and a defect library with disposition decisions attached is exactly that.
The caution is ownership. Many inspection images and CMM reports show a customer's part made to a customer's print, so they need a rights review before anyone treats them as licensable.
What AI-ready means for a licensing buyer versus internal use#
AI-ready means something different for a licensing buyer than for an internal project. An internal project needs current, correct data because its output drives decisions in your plant. A licensing buyer needs long, linked, well-documented history with outcomes, and it can accept known flaws that would stop an internal rollout.
| Question | Internal AI project | Licensing buyer |
|---|---|---|
| How much history? | Enough recent data to reflect today's products and processes | Several years, because variety and outcomes matter as much as recency |
| How clean? | Correct values, since output drives daily decisions | Consistent and documented; known errors described, not hidden |
| Real names? | Yes, users need real customers and parts | No, identities replaced with consistent tokens |
| What documentation? | Team knowledge is often enough | A data dictionary, field notes and a known-issues list |
| What rights? | Internal use is usually covered by existing terms | A right to license each record family, with customer carve-outs |
How to check your ERP without starting a cleanup project#
The fastest check of ERP data quality is a short set of counts by year, run by whoever administers the system. The goal is to find where the chain breaks, not to fix it, because rewriting closed history to make it tidy can destroy the signal an analyst or a buyer would use.
Write the results into a one-page known-issues note. When duplicates are merged later, keep a crosswalk from old IDs to new ones so older transactions still connect.
- Count jobs without a linked sales order or stock reason, by year.
- Count NCRs and returns that carry no job, lot or serial number.
- Compare standard and actual labor on a sample of routings at the busiest work centers.
- List part numbers whose description changed completely at some point, a sign of reuse.
- Show reason-code distributions for scrap and downtime, and how often the catch-all code appears.
- Record each migration and go-live date, and what history came across.
- Ask planners and quality staff which spreadsheets they keep beside the ERP.
Illustrative: a valve manufacturer finds where its chain breaks#
Illustrative: a fictional maker of industrial ball valves runs a mid-market ERP adopted after it outgrew an older system, plus a separate QMS for NCRs and CAPAs. Leadership assumes the history is sound because month-end closes on time.
The counts tell a different story. Jobs from before the go-live have no sales-order links, because only open orders were converted. A block of retired valve-body part numbers was reassigned to a new product line. Scrap on two cells is coded almost entirely as other, though operators wrote useful notes in the comment field.
The COO decides not to clean anything yet. The team writes a known-issues note, builds a crosswalk for the reused part numbers using creation dates, and limits any outside review to the years after the go-live plus the QMS history, which links to lots throughout.
How SourceX looks at ERP data quality#
SourceX treats data cleanliness as one driver in the SourceX Enterprise Data Value Framework, weighed alongside uniqueness, domain expertise, human-generated signal, scale, recency, rights and AI utility. Messy but linked history can outrank tidy history that lost its outcomes.
The fit check collects metadata only: systems, years, record families and the known-issues note. If a package moves forward, the Preparation step of the SourceX five-step transaction handles consistent masking and documentation, and the manufacturer approves what is released.
What are the most common data quality issues in any business system?#
The most common data quality issues in any business system fall into six dimensions: completeness, uniqueness, consistency, timeliness, validity and accuracy. The UK Government Data Quality Framework uses these six, adapted from DAMA UK, and treats the list as guidance rather than a fixed standard.
Sorting problems by dimension rather than by system lets you compare an ERP, a CRM and a helpdesk with one vocabulary. The same defect, such as a duplicate account, looks different in each tool but is detected the same way. The table maps each dimension to examples outside manufacturing and to the check that finds it.
| Dimension | What goes wrong | Example in CRM or helpdesk | Detection check |
|---|---|---|---|
| Completeness | Records or required values are missing for the intended use | Closed deals with no close reason; tickets with no product field | Count nulls or blanks in each required field, by year |
| Uniqueness | One real entity is stored as several records | The same company entered as three accounts after an import | Group by the natural key and count rows per key greater than one |
| Validity | Values fall outside the expected format, type or range | Phone numbers in the email field; negative quantities; dates in 1900 | Compare each value against the allowed list, pattern or range |
| Accuracy | Values do not match what happened in reality | Opportunity amount never updated after the contract changed | Sample records and compare against a trusted document, such as an invoice |
| Consistency | Two records or systems disagree about the same fact | Ticket says resolved while the linked bug is still open | Join the two sources on a shared ID and count disagreements |
| Timeliness | Data arrives too late or is too old for the use | Activity logged days after the call; stale contact titles | Compare event time with entry time and with the last-modified date |
How do you write a detection query for a data quality issue?#
Write each detection query so it returns the failing rows; zero rows means the check passed. This is how dbt, a widely used data transformation tool, defines its data tests: a select statement that looks for records that disprove an assertion, such as selecting duplicates to test that a column is unique.
dbt ships with four built-in generic tests, and they cover several of the checks above in any SQL warehouse or a database copy of the system. Many other checks are a variation of one of these four patterns.
- Run each query by import batch as well as by year, so a spike points to a migration or a process change rather than a general mess.
- Store the failing-row counts, not only pass or fail, so you can see whether a problem is shrinking.
| Pattern | Asserts | Query returns | Dimension it covers |
|---|---|---|---|
| not_null | A required column always has a value | Rows where the column is null | Completeness |
| unique | A key column has no repeated values | Key values that appear more than once | Uniqueness |
| accepted_values | A column holds only values from a set list | Rows with values outside the list | Validity |
| relationships | Every foreign key exists in the parent table | Child rows whose key has no parent | Consistency, and orphaned records |
Which data quality issues matter most in data analytics?#
In data analytics, the issues that matter most are the ones that change a count or a join: duplicates, orphaned records and silent gaps in history. A typo in a description rarely moves a dashboard, but a duplicated customer doubles a count and an orphaned record drops out of every joined report without warning.
A simple decision rule helps rank what to fix or disclose first. Ask whether the defect changes a total, breaks a join, or hides a period of history. If it does any of the three, measure it with a detection query and record the result before anyone builds on the data; if it does none, note it and move on.
Sources for this section
- The UK Government Data Quality Framework uses six data quality dimensions adapted from DAMA UK and presents them as guidance, not a prescriptive list. Source
- GOV.UK's Data Quality Hub describes the six dimensions, including uniqueness as no duplication of records, validity as data in the expected format, type and range, and accuracy as data that mirrors reality. Source
- dbt data tests are select statements that return failing records, and dbt ships with four generic tests: unique, not_null, accepted_values and relationships. Source
Frequently asked questions
Should we clean ERP data before or after a migration?
Clean the master data the new system depends on, such as active parts, routings and customers, before cutover. Leave closed transaction history as it is, documented, and keep a full copy of the old database. Cleanup that rewrites closed history often breaks links the migration needs and erases evidence of how the business actually ran.
Does messy ERP data rule out licensing?
Not usually. Buyers expect operational records to be imperfect. What hurts is missing links between records, missing outcomes and problems nobody disclosed. A clear known-issues note and consistent identifiers often matter more than how tidy individual fields look.
Can AI tools clean our ERP data for us?
They can help find duplicates, suggest reason codes from free text and flag outliers, but they should not silently rewrite history. Treat each suggestion as a proposal that a planner or quality lead confirms, and keep original values alongside corrections so every change stays traceable.
Who should own the known-issues list?
The ERP administrator usually keeps it, with input from the controller on cost data, the quality manager on NCR and inspection records, and production planning on routings and schedules. A single owner stops the list from scattering across email threads and meeting notes.
Do spreadsheets kept outside the ERP count as records?
Yes, when they hold decisions the ERP does not, such as expedite lists, schedule boards or inspection logs. Inventory them with the system they supplement, note who keeps them and how far back they go, and check them for customer names before anyone shares them.
Sources
- In RSM's 2026 middle-market survey, data quality and availability issues were the top inhibitor to AI deployment (34%), followed by security and privacy concerns (30%) and legacy systems integration (28%). Source
Related resources
See if your company qualifies
A short company assessment. No data uploads are needed.