Data Quality
Data quality describes the degree to which data is fit for its intended purpose – measured across dimensions such as completeness, correctness, timeliness, consistency and uniqueness. In an ERP system, the data quality of master and transactional data directly determines how reliably processes can be automated and how dependable analyses are.
Data quality describes how well data is suited to the purpose for which it is meant to be used. It is measured not as a single figure but across several dimensions: completeness (are all required fields filled?), correctness (do the values match reality?), timeliness (is the data up to date?), consistency (do data points in different places not contradict each other?), uniqueness (does each object exist only once, without duplicates?) as well as conformity and accuracy (do values meet the expected format and required precision?).
In an ERP context, data quality relates above all to master data – article, customer and supplier master records – and to the transactional data generated from it, such as orders, invoices and postings. Because every module of an ERP system accesses the same data pool, poor data quality does not stay local but ripples through the entire process chain: a wrong tax key in the customer master produces incorrect invoices, an empty weight field in the article master blocks shipping-cost calculation, a duplicate distorts revenue analyses. Data quality is therefore not a purely IT question but the fundamental precondition for an ERP system to deliver the promised automation and transparency at all.
At a glance
- Fitness of data for its intended purpose – not a yes/no, but a degree
- Key dimensions: completeness, correctness, timeliness, consistency, uniqueness, conformity
- The biggest lever lies in master data – errors propagate across all documents
- Typical enemies: duplicates, dead records, inconsistent formats, outdated addresses
- Secured through mandatory fields, validation, duplicate checks and clear data ownership
The dimensions of data quality
Data quality is multidimensional: a record can be complete but outdated, or correct but inconsistent with a second system. Quality is therefore measured against several, sometimes conflicting criteria. The most common dimensions are completeness (all required attributes are present), correctness or accuracy (the values match the reality being represented), timeliness (the data reflects the current state), consistency (the same information is identical everywhere), uniqueness or freedom from duplicates (each real object exists exactly once) and conformity (values comply with the defined format, such as a valid IBAN or a standardized country code).
In practice, these dimensions can be condensed into measurable key figures, such as the share of filled mandatory fields, the duplicate rate or the number of faulty VAT IDs. This measurability is the core of professional data quality management: only once quality is checked against rules and quantified can it be improved in a targeted way and monitored over time.
Data quality vs. data integrity
Data quality and data integrity are often confused but mean different things. Integrity is a technical concept: it ensures that data is stored technically intact and free of contradictions – for example through foreign keys, transactions and database validation rules. Data quality is the business concept above it: even technically intact data can be factually wrong, outdated or unfit for its purpose. A correctly stored but substantively wrong delivery address has integrity but poor data quality.
Why data quality is decisive in ERP
The economic value of an ERP system – automation, single-point maintenance, end-to-end processes and dependable reporting – stands or falls with data quality. Because documents draw their values automatically from the master data, every master-data error multiplies across all downstream operations. An incorrectly stored payment term systematically delays incoming payments, a faulty tax status leads to wrongly reported VAT, and an incomplete article master slows down picking and shipping.
Quality defects are especially costly in reporting: analyses, forecasts and planning decisions are only as reliable as the data they rest on. If a key account’s revenue is split across three master records because of duplicates, credit-limit and ABC analyses miss the mark. Good data quality is therefore the precondition both for operational process reliability and for data-driven decisions – and the reason why every data migration should be preceded by a cleansing rather than carrying bad data into a new system.
How data quality is secured
Data quality does not arise on its own but through an interplay of rules, tools and responsibilities. Preventive measures include mandatory fields, format validations (such as check digits for IBAN or VAT ID), selection lists instead of free text, naming conventions and a duplicate check already at record creation. Reactively, cleansing runs are added: profiling reveals anomalies in the data set, deduplication merges duplicate records, and enrichment fills in missing values from reliable sources.
Just as important as the technology is the organizational anchoring. Data governance defines who is responsible for which data objects (data owner and data steward), by which rules data is maintained and how quality is measured. In larger organizations, master data management bundles these tasks and defines a leading system of record for each object, so that several systems do not maintain contradictory truths.
The golden record as target picture
A central outcome of consistent data quality work is the golden record: the single, cleansed and enriched record per real object that serves as the binding reference across all systems. It typically emerges by merging duplicates and fusing the best field values from different sources into one consolidated master record. Without freedom from duplicates and clear rules on which source wins per field, such a golden record cannot be formed.
DACH specifics: GoBD and legally compliant data
In the German-speaking region, data quality also has a regulatory dimension. The GoBD require, for booking-relevant data, among other things traceability, completeness, correctness, timely recording and immutability – all of which are requirements that hinge directly on data quality. Missing or contradictory tax attributes, incomplete document data or non-traceable changes are therefore not just a process problem but a compliance risk during a tax audit.
In practice this means: tax-relevant master data such as VAT ID, tax keys and customer/supplier accounts must be correct, current and checked – the VAT ID ideally verified via the confirmation procedure. For intra-community supplies, e-invoicing and the DATEV-compliant handover to the tax firm, consistent, format-compliant data quality is the fundamental precondition. Here, poor data quality causes not only rework but potentially tax risks.
On top of this comes the GDPR: customer and contact data is almost always personal data, which is why its timeliness and erasability also count towards data quality. Outdated or superfluous personal data is not only a quality but a legal problem. An ERP system should therefore be able to cleanly separate retention periods for booking-relevant data from managed deletion routines for attributes no longer needed – which in turn presupposes clear, well-structured field maintenance.
Example
Example: data quality as the foundation of an ERP rollout
A mid-sized online retailer for sports goods wanted to absorb its growth with a new ERP system. During the stocktaking, the real problem emerged: the article master from shop, marketplace exports and an old inventory management system contained contradictory descriptions, missing weights and customs tariff numbers, inconsistent units and around twelve percent duplicates. Automated shipping costs and customs processing would have been impossible on this basis.
Before the migration, data quality was therefore raised systematically: mandatory fields were defined, formats standardized, duplicates per article merged into a golden record and missing attributes filled in. Only the cleansed data set was checked in test imports and, after business sign-off, moved into production. The result: shipping costs, customs data and inventory management ran automated from the start – the effort lay not in the software but in the data quality beforehand.
Frequently asked questions
Matching ERP systems
Related services
Sources
Questions about Data Quality in your ERP project?
We advise vendor-neutrally – and implement it ourselves on request.