Data modelstructure for procurement and master data in industry
Procurement glossary · Updated · 6 min read
Also known as: data structure, data architecture, entity-relationship model, data model, EAM
Short answer
- A data model describes the structure of data: objects, attributes and their relationships.
- In procurement, it mainly covers the material master, supplier master and all procurement documents.
- Its quality determines data quality, automation and reliable evaluations.
A data model describes the structured representation of objects, attributes and relationships in an information system, for example for material master records, suppliers or purchase orders. In technical procurement, it forms the basis for consistent processes from enquiry to invoice verification. Without a cleanly defined data model, data silos, duplicates and faulty reports arise that distort procurement decisions.
Key facts
- A data model defines objects (entities), attributes and relationships between business information.
- In procurement, the material master, supplier master and procurement documents are among the central model areas.
- In practice, a distinction is made between conceptual, logical and physical data models.
- A sound supplier identifier and clear number ranges are prerequisites for a reliable data model.
- Data models are the basis for catalogue buying, tool automation and supplier evaluations.
- Maintenance quality and authorisations determine the benefit of a data model in day-to-day operations.
Contents
Definition: data model
A data model is a formal description of a system's data structures: which objects exist, which characteristics they have and how they are related. It is the blueprint for databases, ERP modules and interfaces. In the procurement context, it defines how materials, suppliers, prices and documents are related.
Conceptual, logical and physical level
The conceptual model describes the business world without technology, for example the entities 'supplier', 'material' and 'purchase order'. The logical model refines these into attributes, keys and cardinalities. The physical model defines tables, field types and indexes in the database. For procurement professionals, the logical level is the most relevant, as it structures processes such as document checking or invoice clearing.
Distinction from data standards
The data model is company- or system-specific, whereas a data standard such as an industry-standard catalogue format is a unified convention beyond that. In supply chains, several models often meet, for example the customer's ERP model and the supplier's vendor portal. Interfaces must map these models, frequently supported by the supplier identifier as a unique reference.
Central objects in the procurement data model
A practical procurement data model represents master data, transaction data and reference data. The quality of these structures determines whether processes such as catalogue buying, changing delivery schedules or creating enquiries can run automatically.
Material master and parts catalogue
The material master describes each part with number, description, unit of measure, drawing reference and classification. A well-maintained parts catalogue prevents duplicates such as 'M8 screw' written in five different ways and is a prerequisite for meaningful spend analyses and supplier consolidation. Classification systems with attribute logic also make it easier to compare across plants and locations.
Supplier master and relationship data
The supplier master contains master data, bank details, certificates, Incoterms EXW or DAP as agreed delivery terms, payment terms and qualification data. Additional objects include inspection reports, framework contracts with expiry dates and references to the contract repository. Unique keys such as a D-U-N-S Number (DUNS) help avoid duplicates across system boundaries and to map KYC in procurement in a structured way.
Transaction data: enquiry to invoice
The transaction objects include enquiry, quotation, purchase order, delivery schedule, goods receipt and invoice. The model must represent statuses and document relationships, for example which line of a delivery schedule belongs to which goods receipt and which invoice. Only then can matching processes such as document checking and automated invoice clearing work without manual follow-up.
Methods and approach for building a data model
Building a data model typically follows a structured approach, from analysing business processes to technical implementation. Industries such as mechanical engineering and the electrical industry often use established modelling methods.
Requirements analysis and modelling
First, the processes and their information needs are surveyed: which data does the cost driver analysis, the specification of services or the technology assessment in procurement require? From this, entity-relationship models or UML class diagrams are developed. Workshops with procurement, engineering and IT prevent business terms from being represented twice or incompletely.
Normalisation and numbering logic
Redundancy-free structures follow the principle of normalisation: every fact is maintained in exactly one place. At the same time, day-to-day operations need pragmatic number ranges, for example for material, supplier and purchase order. In practice, it has proven useful to avoid meaningful keys and to store attributes as fields rather than in the number.
Governance and data maintenance
A data model only lives with governance: defined owners, maintenance processes, quality rules and authorisations. Changes to the model, such as a new mandatory field for sustainability certificates, go through a change procedure. In addition, regular quality checks based on the cycle counting principle ensure ongoing data quality in the inventory.
Key KPIs for data model quality
The quality of a data model can be measured. Data quality metrics show whether master data is reliable and automated processes run without manual rework.
Completeness and correctness
Typical metrics are the completion rate of mandatory fields, the duplicate rate in the supplier master and the proportion of materials without an active source. Practical benchmarks: completeness of mandatory fields often above 95 per cent, duplicate rate well below 2 per cent. Experience shows that low rates correlate with smoother ordering and checking processes.
Measuring process impact
Data quality is also reflected in process metrics: the share of automatically matched invoices in invoice clearing, the share of catalogue orders in catalogue buying, the processing time for changing delivery schedules. Metrics such as Days Inventory Outstanding (DIO) also depend on whether material master data such as lead times is maintained correctly.
Risks and controls
Faulty data models cause concrete damage: incorrect orders, duplicate payments, incomplete compliance checks. Controls and clear responsibilities limit these risks.
Typical weaknesses
Common problems are duplicates caused by decentralised creation, free-text purchasing without a material reference, historically grown custom fields without an owner, and interfaces that silently truncate attributes. Inadequate authorisation concepts also mean that critical master data such as bank details can be changed without review.
Controls in ongoing operations
Effective controls include plausibility rules when creating new records, four-eyes principles for sensitive changes, regular duplicate and completeness reports, and reconciliations between the inventory and accounting. For supplier data, KYC-in-procurement processes and periodic checks of business information provide additional safeguards.
Current developments
Data models are changing as a result of digitalisation, AI and sustainability requirements. Static models are increasingly being supplemented by networked, semantically richer structures.
Networking and semantic standards
Increasingly, enterprise data is being described using shared semantics, for example through digital product passports and industry-oriented classifications. This allows quotation data, certificates and technical attributes to be exchanged in machine-readable form. This facilitates e-auction preparation and comparison processes, because attributes are available in structured form rather than as a PDF attachment.
AI and data quality
AI applications in procurement, from text classification to automated quotation evaluation, are only as good as the underlying model. At the same time, AI supports maintenance, for example through duplicate detection, suggestions for classifications or extraction of data from documents. Sustainability data such as emissions and audit information is being integrated as independent object areas into existing models.
Typical metrics
| Metric | Benchmark | Context |
|---|---|---|
| Completeness of mandatory fields | > 95% | typical benchmark for maintained master fields in practice |
| Duplicate rate in the supplier master | < 2% | a low rate reduces payment and qualification risks |
| Proportion of automated invoice matches | > 80% | indicator of consistent document relationships in the model |
| Materials without an active source | < 5% | indicates gaps in source linking and the parts catalogue |
Typical practical benchmarks – they vary by industry, part and contract.
Practical example
A mid-sized machinery manufacturer with several plants struggled with duplicates in the material master and unstructured supplier data. Enquiries went out with incomplete specifications, and comparisons were hardly possible. The company introduced a uniform procurement data model with classification, clear number ranges and defined mandatory fields.
- Cleansing of the material master with duplicate merging and assignment to parts catalogue classes
- Introduction of a unique supplier identifier including matching against the D-U-N-S Number (DUNS)
- Mandatory field concept for Incoterms, payment terms and qualification data in the supplier master
- Automated matching of goods receipt and invoice to accelerate invoice clearing
Conclusion
In procurement, a data model is not an IT detail but the business map of all procurement data. It determines whether spend analyses are reliable, whether catalogue buying works and whether supplier evaluations rest on clean foundations. Building it requires coordination between procurement, engineering and IT as well as continuous data maintenance with clear responsibilities. Those who invest here create the foundation for automation, compliance and better procurement decisions. A well-maintained data model is therefore a lasting foundation for procurement excellence in the supplier industry.
Frequently asked questions
What is a data model in simple terms?
A data model describes which information a system stores and how it is related. In procurement, this includes material master records, supplier data and purchase orders. It is the blueprint for databases and interfaces. Without a model, duplicates and contradictory entries arise.
Why does procurement need a data model?
Because almost all procurement processes rely on data: spend analyses, supplier evaluations, catalogue orders and invoice matching. A consistent model ensures that the same piece of information is maintained in exactly one place. This reduces errors, accelerates processes and creates reliable reports for management.
Which data objects belong in a procurement data model?
Core objects include the material master, parts catalogue, supplier master, enquiry, quotation, purchase order, delivery schedule, goods receipt and invoice. In addition come contracts, certificates, inspection reports and increasingly sustainability data. Unique keys such as a supplier identifier and clearly defined relationships between documents are essential.
What is the difference between a logical and a physical data model?
The logical model describes objects, attributes and relationships from a business perspective, independent of any specific database. The physical model translates this structure into tables, field types and indexes of a concrete system. Procurement professionals mainly work with the logical view, while IT is responsible for the physical implementation.
How do you measure the quality of a data model?
Using metrics for data quality such as completeness of mandatory fields, duplicate rate, currency of supplier data and the proportion of automatically matched documents. In addition, process metrics such as the lead time for purchase requisitions or the share of catalogue orders show the impact. Regular quality reports make improvements measurable.
How often should a data model be updated?
A data model is not a one-off project but evolves with the business processes. Changes, such as new certificate types or sustainability attributes, should be managed through a change procedure. In practice, an annual fundamental review plus ongoing adjustments for new requirements such as new regulations or systems has proven effective.
