Data quality is the degree to which data is fit for the decisions, operations, and models that depend on it. Six dimensions are the standard way to assess that fitness: accuracy, completeness, consistency, timeliness, validity, and uniqueness. Keeping all six healthy over time is the job of data quality management.
Every vendor in the category publishes a definition like that one; the definition is the easy part. At IWConnect we’ve built and repaired enterprise integrations since 2004. In that work, quality only ever became visible when a dimension failed inside a live system. That experience shapes this post: one failure story per dimension, drawn from production.
What does data quality actually mean?
Data quality measures how fit your data is for the decisions and operations that depend on it. The standard framework breaks this into six dimensions: accuracy, completeness, consistency, timeliness, validity, and uniqueness. A dataset can score well on some dimensions and fail others. That’s why single quality scores mislead.
The six dimensions trace back to a 2013 working paper from DAMA UK. The framing that matters most in it is fitness for use. Correct data can still be useless. A phone number formatted perfectly for a market you don’t operate in passes every check and helps nobody.
Fitness for use also means quality is contextual. The same customer table can be good enough for a marketing segment and dangerously wrong for billing. Ask what the data needs to support before you ask whether it’s clean.
Accuracy: when the data doesn’t match reality
Accuracy measures whether a stored value matches the real-world fact it describes. The textbook example is a wrong address or a misspelled name. In production, accuracy failures are quieter and more expensive. Every downstream system treats the wrong value as truth until something forces a reconciliation.
Here’s the pattern we keep meeting in ERP work. A vendor gets registered twice, the second time under a slightly different spelling, and each record carries its own bank details and payment terms. An invoice arrives, matches against one record, and gets paid. A reminder lands three weeks later, matches against the other record, and gets paid again.
At one manufacturer, accounts payable needed eleven days to untangle a duplicate payment like that: confirm it, request the refund, correct the master data, document the fix for audit.
The money came back; the eleven days didn’t. Nothing in the workflow was broken. The record was.
Completeness: when the field is blank at the worst moment
Completeness measures whether all the data required for a task is actually present. Entry-level null checks catch empty mandatory fields. The failures that hurt involve fields that are optional in the source system and required somewhere downstream. That gap stays invisible until the exact moment the value is needed.
Customs clearance is where we’ve watched this play out. A materials record travels from the ERP to a freight forwarder’s system with the commodity code field blank. The code was optional at creation. Nobody needed the code for purchasing, so nobody ever filled it in.
The shipment reaches the border and stops. The fine, where there is one, is the small part. A production line is waiting on that part, and every day at customs means rescheduled orders and overtime on the far side. One empty field, priced at the cost of a standing factory.
Consistency: when two systems disagree
Consistency measures whether the same fact carries the same value everywhere it’s stored. Each copy can look plausible on its own. The failure only appears when two systems answer the same question differently, and the person asking has no way to tell which answer deserves their trust.
A renewal call is a reliable place to find this one. The CRM says the customer runs 40 seats. Billing says 25. The account manager quotes from the CRM, the customer pushes back with their own invoice, and the call turns from a renewal into an apology.
The direct damage is one awkward conversation. The lasting damage lands on reporting.
Once sales and finance have publicly disagreed on a number, every dashboard built on either system picks up a mental asterisk. People quietly go back to their private spreadsheets. Trust leaves in an afternoon and comes back over quarters.
Timeliness: when the data is right but late
Timeliness measures whether data is current enough for the decision it feeds. A value can be perfectly accurate for the moment it was captured and wrong for the moment it’s used. Batch schedules make this failure predictable: the data is always right, just right about yesterday.
Retail inventory shows the shape of it. Stock levels sync from stores to the central platform in a nightly batch. Every morning decision runs on yesterday evening’s counts. Most of the year that’s fine, because stock moves slower than the sync.
Then a promotion lands. Units the system still counts as available sell out by mid-morning, the webshop keeps accepting orders against them, and the afternoon becomes cancellation emails. Nobody entered a wrong number anywhere. The data was accurate the moment it was written and stale the moment it mattered.
Validity and uniqueness: the two everyone merges
Validity measures whether values conform to required formats and rules; uniqueness measures whether each real-world entity appears exactly once. Most explainers fold these two into accuracy or skip them outright. That’s a mistake, because each has a signature failure the other four dimensions never catch.
Validity fails silently. Two regional systems exchange dates, one writing the day first and the other the month first. The 4th of March becomes the 3rd of April, every value passes the null checks, and the schema stays satisfied. Until a delivery date drifts a month out, nothing looks wrong.
Uniqueness is the dedupe problem sitting underneath the accuracy story above. One customer exists as three records, each accumulating its own history and its own credit limit. No single record is false. The customer, in total, carries triple the exposure anyone approved.
How do the six dimensions connect to data quality management?
The six dimensions are the vocabulary of data quality; data quality management is the practice that acts on them. Dimensions tell you what to look at. Management decides who owns a rule, what happens when it fails, and how the fix travels back into the source system.
Measuring dimensions without that loop produces a familiar artifact: a quality dashboard nobody reads. It goes red in a corner while the invoices keep going out. Gartner puts the cost of poor data quality at an average of $12.9 million a year per organization. Much of that spend leaks through the gap between measurement and action.
A working data quality management program closes that gap. Most start with a written quality framework that names owners and thresholds before any tooling arrives.
Frequently asked questions about data quality
Three questions come up in nearly every conversation about data quality: what the six dimensions are, how quality differs from data integrity, and how to measure it. The short answers sit below. The measurement question is large enough that it gets a post of its own.
What are the six dimensions of data quality?
- Accuracy: values match the real-world facts they describe
- Completeness: every required value is present
- Consistency: the same fact matches across systems
- Timeliness: values are current enough for the decision at hand
- Validity: values follow the required formats and rules
- Uniqueness: each real-world entity appears exactly once
What is the difference between data quality and data integrity?
Data integrity is structural. It concerns whether data stays intact, related, and uncorrupted as it’s stored and moved. Data quality is fitness for use. That’s why a database with perfect integrity can still hold data nobody should trust.
How do you measure data quality?
Measure each dimension separately against rules the business has agreed to, then track those scores over time. A single blended score hides which dimension is failing, and the dimension is the part that tells you what to fix.