Key Takeaways
- Reliable master data is the foundation for stable and increasingly automated ERP processes.
- Errors in master data propagate through operational processes and create rework, poor planning and unreliable decisions.
- Automation and AI depend on trustworthy data. Better algorithms cannot compensate for missing or structurally weak master data.
- Master data ownership belongs primarily with the business functions that understand the data—not with IT alone.
- Master data quality is not a one-time cleansing exercise. It requires clear processes, ownership and ongoing measurement.
Companies introduce ERP systems to automate work, improve transparency and reduce manual effort.
Then reality intervenes.
Material planning produces recommendations that nobody trusts. Production dates do not match what the factory can actually deliver. Pricing generates unexpected results. Employees begin correcting system proposals manually and rebuilding calculations in spreadsheets.
The ERP itself may be working exactly as designed.
The data behind it is not.
This is why master data has such a direct influence on ERP performance. A planning engine cannot produce useful results from unrealistic lead times. Automated pricing cannot be reliable when pricing rules are incomplete. Capacity planning becomes theoretical if routings and setup times do not reflect actual production.
And the same issue becomes even more important as companies introduce AI.
Better models can analyse data more effectively. They cannot manufacture business context that is missing from the source.
Master data is therefore not administrative housekeeping.
It determines how much of the ERP’s functionality a company can actually use.
What Is Master Data in ERP?
Master data consists of relatively stable business information that is reused across transactions and processes.
Typical examples are customers, suppliers, materials, products, accounts, assets, bills of material and production routings.
Gabler Wirtschaftslexikon describes master data as fundamental business data that remains comparatively stable over time and is updated periodically [1].
Transactional data is different.
Sales orders, purchase orders, deliveries, invoices and financial postings are created continuously through daily operations. These transactions depend on master data.
A sales order refers to a customer.
A purchase order refers to a supplier.
A production order depends on products, bills of material, work centres and routings.
A transaction can therefore be technically correct while still producing a poor business result because the underlying master data is wrong.
That distinction matters.
If an incorrect supplier lead time generates a poor purchase proposal, the problem is not necessarily the purchasing transaction.
The ERP used the information it was given.
Typical ERP Master Data Domains
| Domain | Typical Information | What It Influences |
|---|---|---|
| Customer master | Addresses, tax information, payment terms, roles | Order processing, invoicing, dunning |
| Supplier master | Addresses, payment terms, procurement information | Purchasing, payments, supplier processes |
| Material and product master | Dimensions, classifications, planning parameters, safety stock | Procurement, inventory, production and sales |
| Pricing and conditions | Price lists, discounts, surcharges, validity periods | Quotations, orders and invoices |
| Bills of material | Components, quantities and versions | Production, planning and costing |
| Routings | Operations, work centres, setup and processing times | Scheduling, capacity planning and costing |
| Resource data | Machines, shifts, calendars and capacities | Production planning and utilisation |
Technical master data is often particularly important in manufacturing.
A company may have implemented sophisticated production planning functionality, but if setup times are rough estimates and routings no longer reflect reality, the planning system is optimising a model of the factory that does not actually exist.
This illustrates the difference between having an ERP system and being able to use it effectively.
Master Data Turns ERP Rules Into Automation
ERP automation is sometimes described as though the software itself were making intelligent decisions.
In most cases, something more basic is happening.
The system follows defined rules based on parameters and master data.
Consider material requirements planning.
The ERP can calculate purchase proposals automatically. But it needs planning procedures, minimum stock levels, lot sizes and realistic supplier lead times.
If a supplier is stored with a 14-day lead time when delivery normally takes six weeks, the calculation may be technically flawless and operationally useless.
Production planning works the same way.
Scheduling depends on routings, work centres, calendars, setup times and processing times.
If the data says an operation requires 30 minutes but reality requires two hours, no scheduling algorithm can produce a reliable production plan.
Pricing provides another example.
Automated price determination relies on price lists, discounts, customer groups, scales and validity periods. Incorrect master data does not stop automation.
It causes automation to produce the wrong result faster.
Research examining the relationship between master-data quality and process quality supports the underlying connection: process performance depends materially on the quality of the master data used by the process [3].
That is the practical meaning of data quality in ERP.
It determines how much control can safely be delegated to the system.
When Users Stop Trusting ERP Automation
The failure pattern is often gradual.
At first, the ERP generates an incorrect proposal.
An experienced employee corrects it.
The next proposal is wrong as well.
Eventually, employees stop treating the system recommendation as a useful decision and begin checking everything manually.
Automation still exists technically.
Operationally, it has disappeared.
This can happen in purchasing when planners continuously override proposed quantities and dates. It happens in production when planners manually adjust schedules because routings and times are unreliable. It happens in pricing when employees maintain separate spreadsheets because they do not trust the conditions stored in ERP.
The organisation then develops a second control layer around the system.
ERP generates the result.
People check it.
Excel corrects it.
The corrected result is re-entered.
At that point the company has paid for automation while continuing to perform much of the work manually.
Master data quality therefore affects more than individual errors.
It determines whether employees are willing to let the system perform standard decisions without constant supervision.
AI Raises the Requirement for Reliable Master Data
The same principle applies to AI.
Many ERP vendors now use AI or machine learning for forecasting, classification, anomaly detection, recommendations and user assistance.
These functions can create substantial value.
But they add a dependency rather than removing one.
They need reliable business data.
A forecasting model can identify patterns in sales or demand. If product categories, customer segments or seasonal attributes are inconsistent, the model learns from inconsistent classifications.
An anomaly-detection system can identify unusual inventory movements or purchase prices. To do that reliably, it needs a meaningful baseline for what constitutes normal behaviour.
AI-supported production planning may identify better patterns in cycle times or resource utilisation. If the underlying routing data is already inaccurate, better analytical methods do not fix the original problem.
This is why current Master Data Management strategies increasingly connect trusted master data directly with automation and enterprise AI. SAP, for example, describes master data management as the discipline of maintaining a trusted view of critical business entities across systems and explicitly links this foundation to reliable AI.
The point is not that AI requires perfect data.
Very little enterprise data is perfect.
It requires data that is sufficiently structured, consistent and governed for the decision being made.
Master Data Quality Matters Before an ERP Change
ERP implementations expose data problems particularly clearly.
Legacy data has often grown over many years.
Different naming conventions coexist. Customer and supplier duplicates accumulate. Planning parameters have been copied from older products. Routings have been updated inconsistently. Some information is maintained in ERP, while other values exist only in spreadsheets.
The existing organisation learns to live with these weaknesses.
A system replacement removes many of the informal workarounds.
The project suddenly has to decide which records will move into the new ERP and which values should become authoritative.
Common issues include duplicate customers and suppliers, materials with incomplete planning parameters, bills of material that no longer reflect production, and routings based on estimated rather than measured processing times.
A new ERP does not clean these records automatically.
It often makes the inconsistencies more visible.
Master-data cleansing should therefore begin before migration becomes a cutover problem.
This does not mean cleaning every historical record.
The focus should be on the data required for the future process.
Does the ERP Data Model Fit the Business?
ERP selection usually focuses heavily on features.
Does the system support production planning?
Does it provide CRM functionality?
Does it handle warehouse management?
Can it create the required reports?
Those are necessary questions.
There is another one that is easier to overlook:
Can the ERP represent the company’s master data in a way that supports its actual processes?
A variant manufacturer may need flexible classifications and bills of material.
A production company may depend on detailed routings, shift calendars and capacity structures.
A trading company may need sophisticated pricing and condition models.
A service organisation may require serial numbers, service objects, installed-base information or contract structures.
This changes the way ERP requirements should be discussed.
Instead of asking only whether the system provides a feature, ask whether the data model can represent the information that feature requires.
That distinction can expose significant differences between apparently similar ERP products.
A function may exist in both systems.
The underlying structures may fit one company far better than the other.
If you are still evaluating potential ERP systems, ERP matching can provide an initial shortlist based on your organisation and requirements.
Master Data Is a Critical Path to Go-Live
During implementation, master-data quality becomes operationally visible.
Migration may technically succeed while the new system still cannot support the business properly.
The data exists.
The required information does not.
Typical examples include products without planning parameters, customers with inconsistent tax information, obsolete records that were migrated unnecessarily, free-text values that should have been structured, or routings that do not reflect the actual production sequence.
A stable go-live therefore needs more than a successful import.
| Go-Live Requirement | Purpose |
|---|---|
| Clear migration scope | Decide what is transferred and what deliberately stays behind |
| Mandatory-field rules | Ensure the future process has the minimum required information |
| Consistent numbering and structures | Prevent ambiguity and duplicate logic |
| Test migrations | Expose structural and quality problems before cutover |
| Domain-specific validation | Check customers, suppliers, materials, pricing and technical data |
| Named data owners | Ensure somebody can make business decisions about each data domain |
Many ERP implementation issues that appear to be system problems are actually data problems.
Incorrect lead times create poor delivery dates.
Incomplete materials generate planning problems.
Weak routing data makes capacity planning unreliable.
If users begin overriding the new ERP immediately after go-live, the company should not assume first that the software is wrong.
The underlying master data deserves the same scrutiny.
Master Data Management Needs Business Ownership
Long-term master-data quality cannot be delegated entirely to IT.
IT owns the technical environment.
The business owns the meaning of the data.
Procurement understands whether a supplier should remain active.
Sales knows which customer relationships are valid.
Production understands how a bill of material should be structured.
Controlling knows which pricing or cost structures are meaningful.
Reference models for master-data quality management likewise emphasise the importance of defined responsibilities and governance [2].
A practical ownership model depends on company size.
| Company Context | Possible Model |
|---|---|
| Smaller organisation | Named owner for each critical master-data domain |
| Mid-sized company | Data Owners for business responsibility and Data Stewards for operational maintenance |
| Larger organisation | Formal data governance, quality gates and potentially a central Data Office |
The job title is secondary.
The critical question is whether somebody has explicit authority to make decisions.
Without ownership, data-quality issues remain open because everyone can identify the problem but nobody is responsible for resolving it.
Manage Master Data as a Lifecycle
Master Data Management is not simply the act of creating records correctly.
Data changes.
Customers move.
Suppliers change banking information.
Products are discontinued.
Prices change.
Production structures evolve.
Master data therefore needs lifecycle processes from creation to retirement.
Creation
A new customer, supplier or material should be created through a defined process.
That process should specify the required information and the responsible roles.
For a material, mandatory information may include units of measure, product group, dimensions, planning method, lead times and relevant technical data.
Critical information may require approval before the record becomes productive.
Changes
Not every user should be able to change every value.
Changes to routing times, bills of material, prices or financial assignments can directly alter planning, costing or reporting.
Companies therefore need clear responsibilities and appropriate documentation for significant changes.
Retirement
Old master data should not remain active indefinitely.
Inactive products, outdated bills of material and obsolete customer or supplier records make search results harder to interpret and increase the risk that the wrong record is used.
Retirement rules keep the operational dataset manageable without necessarily deleting information that needs to be retained.
A simple process can already make a substantial difference.
For example, requiring every new material to go through one structured request containing product group, dimensions, unit of measure, planning parameters and routing information prevents many issues that would otherwise appear later in purchasing and production.
Measure Master Data Quality Without Trying to Measure Everything
Data quality should be measurable.
That does not mean building a large reporting programme before anything can improve.
A few operational metrics often reveal where the real problems are.
| Metric | What It Reveals |
|---|---|
| Completeness of critical fields | Whether processes have the data required to run |
| Duplicate rate | Whether master records remain unique and interpretable |
| Automation without manual correction | Whether users trust system-driven processes |
| Override rate | Where ERP proposals are repeatedly corrected |
| Time required to create or change a record | Whether the maintenance process itself is efficient |
The relationship between data quality and automation is particularly useful.
A technically complete material master may still be poor if planners override every proposal generated from it.
Conversely, data does not need to be perfect in every field if the information critical to the process is stable and trusted.
Master-data quality is therefore better treated as an operating capability than as a one-time score.
Five Practical Steps to Improve ERP Master Data
Companies do not need to begin with a large Master Data Management platform.
A pragmatic improvement programme can start with five steps.
1. Map the Master Data Landscape
Identify the major data domains, where they are maintained and who currently changes them.
The first objective is visibility.
Where do customer records originate?
Who maintains material planning values?
Which spreadsheets supplement ERP?
Which domains generate repeated questions or corrections?
2. Look for Manual Overrides
Repeated manual intervention is often one of the best indicators of weak master data.
If buyers constantly change ERP purchase proposals, investigate planning parameters.
If production planners repeatedly move dates, look at routings and capacity data.
If sales frequently corrects prices, investigate pricing and condition records.
Instead of beginning with a generic data-quality project, start where unreliable data is already producing operational friction.
3. Define Minimum Standards
Do not attempt to standardise everything immediately.
Define a binding minimum.
That may include mandatory fields per data domain, agreed planning methods, realistic routing times, clear pricing rules and consistent numbering conventions.
The value comes from consistency, not from creating the largest possible rulebook.
4. Deliver Visible Quick Wins
Some master-data problems can be improved quickly.
Duplicate customers or suppliers can be reviewed.
A new-material creation process can be standardised.
Critical routing times can be updated.
Obsolete products can be deactivated.
Pricing approvals can be clarified.
Visible improvements increase confidence and make a broader governance programme easier to justify.
5. Make Ownership Permanent
Data quality will deteriorate again if responsibility ends with the project.
Assign Data Owners.
Define operational Data Steward responsibilities where appropriate.
Review quality periodically.
Monitor a small number of relevant KPIs.
Maintain defined processes for creation, change and retirement.
Master Data Management then becomes part of normal operations rather than a recurring clean-up project.
The Management Perspective
The value of an ERP system is not determined only by how many modules it contains.
The system creates value when the information inside it is reliable enough to support decisions and automate routine work.
Master data sits at the centre of that relationship.
It influences planning.
It influences pricing.
It influences inventory.
It influences reporting.
And increasingly, it determines whether AI can work with meaningful company context.
That makes master data a management issue.
IT can provide validation rules, workflows and technical controls.
The organisation still has to decide who owns the information, which standards matter and which level of quality is required for each process.
The objective is not perfect data.
It is data that the business can trust enough to operate.
Conclusion: Better ERP Starts With Better Master Data
Master data is not a secondary ERP topic.
It determines how effectively the system can plan, automate and support decisions.
A new ERP cannot compensate for unreliable planning parameters, duplicate business partners or technical structures that no longer reflect reality.
AI does not change this principle.
It makes it more important.
Companies that want more automation should therefore begin by asking where employees still override system proposals and why.
Companies preparing an ERP project should ask whether their existing master data is good enough to support the future processes.
And companies that want sustainable data quality need clear business ownership rather than recurring clean-up projects.
The goal is not a perfect database.
It is a data foundation that the organisation can trust.
Deeper dive: For more on how AI actually gets access to ERP data, the four access patterns available, and why direct database access usually fails in production, see ERP Data for AI: Which Data Access Actually Works (in German).
How Find-Your-ERP Can Help
Master-data questions also belong in ERP selection and project preparation.
The target ERP determines which structures, classifications, planning parameters and governance mechanisms will be available later.
A system can have the right module and still be a poor fit for the company’s data model.
If you are preparing an ERP replacement, implementation or optimisation, it can therefore be useful to assess both process requirements and the existing data landscape early.
Discuss Your ERP and Data Readiness
Use an expert call to review your ERP project, current system landscape and key preparation risks before they become implementation problems.
FAQ
What is master data in ERP?
ERP master data consists of relatively stable business information used repeatedly across processes. Typical examples include customers, suppliers, materials, products, accounts, bills of material and production routings. Transactions such as orders and invoices refer to this master data.
What is the difference between master data and transactional data?
Master data describes the relatively stable entities and structures used by the business. Transactional data is created by daily activity, such as sales orders, purchase orders, deliveries or postings. Transactional processes depend on master data, so errors in the underlying records can affect large numbers of transactions.
Which master data has the greatest impact on ERP automation?
Planning parameters, lead times, safety stock, routings, bills of material, pricing rules and condition data have a particularly direct influence on automated ERP decisions. If these values are unreliable, employees frequently override system recommendations.
Why do ERP projects struggle with master data?
A new ERP does not automatically repair legacy data. Duplicates, inconsistent numbering, weak planning parameters and inaccurate technical structures become particularly visible during migration and testing. Many apparent implementation problems are therefore data-quality problems.
How can a company measure master-data quality?
Useful measures include completeness of critical fields, duplicate rates, the percentage of automated processes that run without manual intervention, the rate at which users override ERP proposals and the effort required to create or maintain records.
Who should own ERP master data?
Business functions should own the meaning and quality of their data. IT provides the technical system and controls, but sales, procurement, production, finance and other functions are better positioned to determine whether individual records are correct and relevant.
Is master-data management a one-time ERP project?
No. Master data changes continuously as products, suppliers, customers, prices and processes evolve. Sustainable Master Data Management therefore requires defined creation, change and retirement processes as well as ongoing ownership and quality monitoring.
Sources
[1] Gabler Wirtschaftslexikon. (n.d.). Stammdaten [Master data]. Gabler Wirtschaftslexikon Online (in German).
[2] Otto, B., Hüner, K. M., & Österle, H. (2012). Toward a functional reference model for master data quality management. Information Systems and e-Business Management, 10(3), 395–425.
[3] Vetter, S. N., Zettl, A., Mützel, M. M., & Tafreschi, O. (2024). Quantitative analysis of the relationship between master data quality and process quality. Proceedings of the 26th International Conference on Enterprise Information Systems, Volume 1, 50–60.
[4] Addagada, T. C. (2023). Corporate data governance, an evolutionary framework, and its influence on financial performance. Global Journal of Business and Integral Security, 6(1).
[5] Bitkom e. V. (2025). Digitalisierung der Wirtschaft 2025 [Digitalization of the economy 2025] (in German).
