Six Data Quality Checks Before You Decide
A team has a list of customer addresses and is ready to send an important notice. The spreadsheet opens, every row has an address, and the count matches last month’s report. Yet some customers have moved, some appear twice, and a few recent changes have not reached the list. The file looks orderly. Whether it is good enough depends on what the team needs to do with it, when the notice must arrive, and what happens if it reaches the wrong person or no one at all.
That is the practical meaning of data quality: information is good quality when it is fit for its intended use. A dataset does not earn that description simply because it is large, tidy, or free of blank cells. The UK Government Data Quality Hub defines good quality in terms of whether data is good enough to support the outcome for which it is used, and notes that different uses require different standards. Its explanation of data quality is a useful starting point because it makes the decision, rather than the file, the reference point.
If the address list is meant to show roughly where customers live, a small number of old addresses may have little effect on the conclusion. If it is meant to deliver a time-sensitive notice to each person, those same records may be unacceptable. Neither judgment can be made from a generic label such as “clean data.” Someone must say which customers belong on the list, which address counts as current, when the list was last updated, and how much error the task can tolerate.
Start with the decision the data must support
The first useful question is not “Is this dataset accurate?” It is “What would someone do differently after reading it?” A manager deciding how much stock to order, an employee contacting a customer, and an analyst describing last quarter’s orders may all draw from the same systems. Their quality needs diverge. The stock decision depends on a recent count of available items. The contact task depends on reaching the right person. The quarterly report depends on a defined reporting period and a consistent way to count orders. The UK government framework makes the same broader point: required quality varies with purpose, and a dataset is unlikely to suit all users equally.
Write the use in a sentence before choosing checks: “We will use these order records to calculate the number of completed orders placed during September, for a report issued in October.” That sentence creates useful boundaries. “Completed” needs a definition. September needs a time zone and a rule for orders changed after month end. If one order can contain several items, the report must count orders rather than item rows. Without those decisions, a polished dashboard may display a precise number whose meaning shifts whenever its inputs change.
Then identify the consequence of being wrong. A rough directional estimate may tolerate missing records that would make an individual customer decision unsafe. A high-stakes use calls for a stronger reference, closer review of exceptions, and a clear way to hold a decision when a critical value is uncertain. This is a judgment about the task, not a universal numerical threshold. A claim that “95% quality is enough” has no practical meaning until the missing 5%, the denominator, and the resulting decision are known.
The reporting period also matters. A record can have been correct when collected and be wrong for today’s action. The name of an item may remain useful for years while its stock count can change within a day. Calling both fields “current” because they share an update date conceals the difference. Specify the period each value describes and the latest acceptable arrival time for the decision.
Six questions reveal different kinds of trouble
The common dimensions of data quality are accuracy, completeness, consistency, timeliness, validity, and uniqueness. They are questions to ask of data, not a required order of work or six equal parts of a single score. The UK Government Data Quality Framework identifies these six dimensions and says the relevant set can change with users’ needs. A contact list, a transaction report, and an inventory feed will put different weight on each one.
Accuracy asks whether the value matches reality
If a record says a parcel was delivered on Tuesday but the delivery took place on Wednesday, the date is inaccurate. The format may be valid and the field may be filled in, but the value is wrong. Accuracy requires a suitable reference: perhaps the recorded event at the source, a confirmation from the person concerned, or another record whose authority for that fact is understood. IBM’s explanation of accuracy centers on how well data represents the real-world entity or event.
The reference must be appropriate for the particular field. Copying an address from one internal system to another can make the systems agree without establishing where the customer lives now. If both systems inherited the same old entry, an agreement check finds consistency while missing the accuracy problem. For decisions about individuals, the useful question is often which source can actually establish the fact at the time it matters.
Accuracy is also more difficult to estimate than a blank-cell count. If there is no independent reference, a team can identify suspicious values but cannot honestly report the fraction that matches reality. A proposed quality measure should state what was compared, how many records were checked, and which kinds of error could escape that comparison. Otherwise the word “accurate” becomes a confidence claim unsupported by a meaningful check.
Completeness asks what should be present
A file may have no empty cells and still omit entire customers, orders, or reporting sites. Conversely, a record may exist while the one field needed for a decision is blank. Both are completeness problems, but they need different denominators. The UK framework’s definition of completeness covers both the records that should exist and the essential values within those records. The World Health Organization’s data-quality guide also treats completeness and accuracy as separate questions; a present value is not necessarily a correct one.
Consider an illustrative booking service expecting one record for each of 1,000 completed appointments during a week. If 970 appointments appear in the reporting table, record completeness is 970 out of 1,000, or 97%, assuming the expected count itself is reliable. If all 970 records exist but only 900 have the location needed for a location report, the location field is populated for 900 out of 970 recorded appointments, about 92.8%. Those figures answer different questions. The first points to missing appointments; the second points to missing detail among appointments already captured.
A useful completeness rule names what is required, for whom, and when. A shipping address may be required for a physical delivery and irrelevant for a digital download. Treating every optional field as a defect rewards unnecessary collection and makes the actual missing values harder to see. The denominator should include eligible records for the stated use, rather than every row in a database.
Consistency asks whether related records agree
Suppose a customer’s account page shows one service tier and the billing system shows another. Both values may fit the allowed format, but they disagree about the same customer at the same point in time. Consistency asks whether data agrees across records, systems, and stated rules. IBM describes consistency in terms of agreement across sources and records.
The disagreement needs context before it is “fixed.” Perhaps billing records the tier that applied when an invoice was issued, while the account page shows the current tier. Those fields can legitimately differ if their dates and meanings differ. A rule that forces them to match might erase history. First establish whether the two values claim to describe the same thing at the same time. When they do, decide which source has authority for that fact and how corrections flow to the other system.
Agreement is not proof of truth. Two reports derived from the same mistaken source can be perfectly consistent. For important fields, consistency checks should sit beside a way to compare selected values with reality, rather than stand in for that comparison.
Timeliness asks whether the data arrives in time
A monthly report assembled after the month closes may be timely for a quarterly planning meeting. The same delay would be poor for a decision about today’s available stock. Timeliness concerns whether information reflects the needed period and becomes available soon enough to act. The UK framework’s account of timeliness explicitly ties an acceptable lag to intended use.
For an illustrative daily stock decision, imagine the agreed rule is to receive each store’s closing count by 7 a.m. the next day. A count arriving at 8 a.m. is late under that rule, even if every item value is eventually correct. The remedy is not necessarily to demand live updates from every store. It may be to change the decision time, use a clearly marked last-known count, or ensure that a late store is excluded from the automated order until its data arrives. The right choice depends on the cost of delay versus the cost of using an older count.
Timeliness should be measured from a meaningful event, such as a customer change or completed transaction, to the point at which the user can rely on the updated value. A file’s recent export timestamp cannot make old underlying records fresh. Record both the period the data describes and the time it became available.
Validity asks whether a value follows the rule
A date stored as text in an unexpected format, a quantity outside the permitted range, or a product code absent from the accepted catalog can fail a validity rule. Validity concerns conformity with defined formats, types, ranges, and logical rules; IBM’s definition of validity includes those checks. A clear rule helps a system reject a value it cannot safely interpret.
Validity is valuable because it can often be checked as data enters a system. Yet a valid date can still be the wrong date, and a well-formed address can still belong to someone else. Before tightening a form, ask whether the rule reflects the actual cases the service must handle. A narrow rule that rejects legitimate values creates a different quality problem: the missing or altered records never enter the dataset. For each rule, keep an explicit path for an exception that deserves human review.
Uniqueness asks what one record represents
Two rows with the same name are not automatically duplicates. They may be two people, two orders from one person, or two versions of one account. Uniqueness asks whether an entity is represented once at the intended grain: one row per customer, per order, per order item, or per event. The UK framework’s discussion of uniqueness defines it by the absence of duplicate records for the entity represented.
Imagine a report that counts customers from an order table. One customer who placed three orders appears in three rows. Removing two rows to make customer names unique would damage the order history. The right operation for the report is to count distinct customer identifiers, after deciding what makes an identifier trustworthy. In a separate customer table meant to hold one current row per customer, three rows for that same person may be a genuine defect. Until the grain is named, a duplicate rate is easy to calculate and hard to interpret.
A good score needs a population, a period, and a rule
Once a quality question is chosen, turn it into a measure someone else could reproduce. State the population, the reporting period, the rule, the denominator, and the treatment of exceptions. For example: “Of completed September orders eligible for shipment, what share had a usable destination address by the dispatch cutoff?” That is much more informative than “address completeness.” It specifies which orders count, what “usable” means, and when the address has to be available.
An illustrative calculation shows why the details matter. Suppose 2,000 completed orders were eligible for shipment in a week. Of these, 1,900 had an address filled in at the dispatch cutoff. The field-population rate is 1,900 ÷ 2,000, or 95%. If a check finds that 80 of those 1,900 addresses fail the stated format rule, then 1,820 of the 2,000 eligible orders have a populated address that passes that rule: 91%. Neither number tells us how many parcels would reach the intended recipient. For that, we would need a suitable reference or outcome linked to the same orders. The calculation is illustrative, and the difference between the measures is the point.
The denominator deserves as much attention as the numerator. If cancelled orders are excluded, that exclusion must be visible. If some orders have not yet reached their dispatch cutoff, including them can make a process look worse merely because it is still underway. If missing records have no row to inspect, a check run only on the reporting table cannot find them. Comparing expected activity with received records may reveal a gap that a field-level check cannot.
One overall percentage can also hide a local failure. Imagine, illustratively, that 9,900 of 10,000 records meet a rule. That is 99% across the dataset. If all 100 failures come from a single small source system that contributed only 100 records, that source is unusable for a decision about its own population. Break results down by the source, time, or group that matters to the decision, while retaining the full denominator so a small subgroup is not confused with the whole.
Do not add the six dimensions into a single average unless there is a defensible reason for each weight and a clear interpretation of the result. A high score for filled-in fields cannot compensate for an incorrect account number when payment depends on that number. A near-perfect uniqueness rate does not repair a stock feed that arrives after purchasing decisions are made. The dimensions are more useful as separate explanations of whether the data can serve a named task.
The right trade-off depends on the cost of waiting
Quality is often constrained by time and effort. Waiting for every late source can make a report more complete, but it can also make the report arrive after the decision. Publishing promptly can serve an urgent need, but the missing records must be visible so readers do not treat the early total as final. This is a trade-off between timely information and a more complete picture, and readers need to know which version they have.
Consider an illustrative morning staffing decision based on yesterday’s service requests. If one location has not sent its counts, a provisional total with that location clearly marked as missing may still help assign spare staff. A later final report can replace it. If the decision is to judge that location’s performance, the provisional total is a poor basis: the missing location is exactly the one under consideration. The same dataset can therefore be acceptable for one action and unacceptable for another, even on the same day.
The practical choice is to set a rule for each use. Decide when to wait, when to publish a provisional result, when to exclude a value, and when to stop an automated action. Those rules should be driven by what a wrong decision would cost, not by a wish to display a perfect quality score. A team may deliberately accept slower delivery to establish a correct individual record, or accept an early estimate to support a reversible planning choice. The cost of the preferred path should be stated alongside the benefit.
That judgment also applies to correction. Replacing a suspect value with a plausible default can make a field appear complete while hiding uncertainty. If an address cannot be confirmed, marking it unknown and holding the dispatch may be more useful than copying an old address into the new record. If an estimate is appropriate for a summary, label the estimate and preserve the original value so the reader can see what was observed and what was inferred.
Improve the source before polishing the report
When a quality problem recurs, start where the information is created or changed. If dates arrive in conflicting formats, agree on a date rule at entry and at transfer between systems. If customer updates routinely miss a downstream list, trace the update path and find the step that fails. If people create multiple customer accounts because they cannot find an existing record, make the search and correction path workable. Cleaning an export every month may rescue one report, but the next export will carry the same fault if its source remains unchanged.
The choice of check should match the failure. A required-field check is suitable for a missing value. A format rule can catch an impossible code before it enters a dataset. A comparison between systems can show conflicting versions of a shared field. A review against a trusted source can address accuracy. A count of expected versus received records can expose an omitted batch. No single check covers all six dimensions, and a dashboard full of checks is useful only if someone can act on the failures it finds.
Write down who can correct a value and which record should win when sources disagree. For a current contact detail, the answer might differ from the answer for a past invoice address: one describes where to reach a person now, while the other records what was used for a completed transaction. A blanket “latest value wins” rule can corrupt history. The correction process needs to preserve the meaning and date of each field, then pass the appropriate change to the systems that depend on it.
Some errors can be prevented when a person enters a value; others become visible only after records from different sources meet. An input form can require a product code to exist in its catalog, but it cannot establish that a physical item was counted correctly. A report can compare totals across systems, but matching totals can conceal offsetting errors in individual records. Put each check where the information needed to perform it is available, and leave a way to resolve exceptions rather than merely flagging them.
Document the small set of facts a future user needs: what the dataset contains, the period it covers, the grain of each row, its important definitions, when it was last refreshed, and known gaps. That description cannot repair faulty records, but it can prevent a well-intentioned reader from using a limited dataset for the wrong decision.
Keep the checks tied to changing use
Data quality is not a one-time cleanup project because uses, source systems, and acceptable delays change. A field that was optional for a summary may become necessary for an individual action. A new sales channel may add records that an old report never expected. A system change may alter the meaning of “completed.” Review the quality rules when any of those conditions changes, especially when a dataset begins to support a new decision.
An effective routine can be small. For each important use, keep a short description of the population and period, the critical fields, the few failure rates that could change the decision, and the person who can resolve exceptions. Review a sample of actual failures, including records that a rule rejected and records that were expected but never arrived. Look for whether the same source, step, or definition produces the trouble repeatedly. Then change that part of the process and check whether the relevant failure falls.
Treat reported rates as observations, not guarantees. A lower missing-field rate may follow a better collection process, or it may follow a new default value that hides missing information. A drop in duplicate records may reflect real corrections, or an altered matching rule. When a measure changes sharply, inspect the rule and the underlying records before treating the trend as improvement.
The lasting test is simple: can the person making the decision understand which records are included, how current and dependable the crucial values are, and what uncertainty remains? If so, the data can be used with an informed judgment. If those answers are missing, a neat table and a precise total offer less confidence than they appear to.
Common questions
Is data quality the same as data cleaning?
Cleaning can correct or remove particular problems, such as invalid codes or duplicate customer rows. Data quality is the broader question of whether the resulting information is suitable for a named use. A clean-looking file can still omit eligible records or arrive too late. A recurring defect also calls for a change in collection or transfer, not only another cleanup pass.
Can a dataset be high quality without being perfect?
Yes, if the remaining limitations do not prevent the stated use and the user can see them. The UK Data Quality Hub explicitly says that good quality does not require every value to be perfect. The important condition is that the acceptable error and its consequences are judged for the particular task. A dataset may support a broad trend while remaining unsuitable for contacting a specific person.
What is the first data quality measure to track?
Start with the failure that could most change the decision you actually make. For a contact task, that may be whether the current destination can be confirmed. For a report, it may be whether all eligible records from the reporting period arrived. Name the population and period, define the rule, and count failures against a visible denominator. Add other measures when they reveal a distinct risk, rather than because a generic checklist includes them.