You have a data quality problem if any of these are true: two reports give different answers to the same question, somebody applies manual corrections during month-end, or people quietly check a figure against their own spreadsheet before they act on it.
None of those require a diagnostic tool to spot. They are behaviours, and they are the most reliable evidence available, because people work around bad data long before anyone formally reports it. By the time a data quality problem is written down in a project document, the business has usually been routing around it for years.
What are the observable symptoms?
| What you notice | What it usually means | Where to look first |
|---|---|---|
| Two reports show different revenue | Different definitions, or different filters on the same source | The definitions, not the data |
| Month-end needs manual adjustments | Something arrives wrong every month and nobody fixed the source | Whatever the adjustment corrects |
| People keep a private spreadsheet | They've lost trust and built their own version | Ask them what the official one gets wrong |
| Totals change when you drill down | Rows that don't join properly, or blanks falling out of filters | Joins between tables, and blank keys |
| The same customer appears several times | No single agreed identifier across systems | Customer master data |
| A figure looks fine but feels wrong | Often a genuine signal from someone who knows the business | Take it seriously, then verify |
| Reports break when someone adds a product | Hard-coded lists that don't grow with the business | How categories are handled in the model |
| Nobody can say where a number comes from | Undocumented logic, often in one person's head | Documentation, and who owns it |
That table is a diagnostic aid built from patterns I see repeatedly, not a statistic. There are no honest published figures for how common each of these is, and I would rather give you something checkable than something impressive.
The three questions that reveal the depth
Can anyone tell you where a number comes from, end to end? Pick a figure from a report someone relies on. Ask which system it originates in, what happens to it on the way, and who decided the rule. If nobody can answer without opening a file and reverse-engineering it, the problem is not really data quality, it is that the logic is undocumented and therefore unverifiable. Undocumented logic is not necessarily wrong, but nobody can prove it right either.
What happens when the answer is wrong? If a wrong number means an awkward meeting, that is one level of risk. If it means a wrong price to a customer, a wrong figure to a bank, or a wrong return to HMRC, that is another entirely. The same underlying flaw carries wildly different costs depending on what depends on it, and this is the question that should drive how much you spend fixing things.
How long has everyone known? Data quality problems are rarely discoveries. Ask the people doing the manual corrections how long they have been doing them. When the answer is three years, you are not looking at a technical fault, you are looking at a process that has quietly absorbed one, which means fixing it involves changing how people work as well as changing data.
The difference between bad data and bad definitions
This distinction saves a lot of money, and it gets missed constantly.
Bad data is when the values themselves are wrong or missing: a customer record with no region, a date field with text in it, duplicate rows from a failed import. It is fixed at source, or with cleaning rules, and it is genuinely a data problem.
Bad definitions are when the values are all correct and two reports still disagree, because one counts an order when it is placed and the other when it is invoiced. Both numbers are right. They answer different questions that happen to share a name.
Most disagreements I am asked to investigate turn out to be the second kind. That is good news, because the fix is a decision rather than a data cleaning project. Somebody with authority says what "revenue" means for reporting, it gets built into the model once, and every report inherits it. The mechanics of why that fixes things are in six reports, six different numbers.
Spending three months cleaning data to fix a definitions problem is one of the more expensive mistakes available, and it is common, because cleaning feels like progress and deciding feels like a meeting.
What to check first, in order
Start with the disagreements people already know about. Ask around for the two reports that never match. That argument is free diagnostic work somebody has already done for you.
Then look for the manual steps. Every spreadsheet in the process that someone edits by hand before the numbers are usable is a place where the automated data was not good enough. Each one is a specific, documented failure with a person attached who can tell you exactly what goes wrong.
Then check the joins. Where two systems have to agree about the same thing (customers, products, cost centres), check whether they use the same identifier. If matching is done on names rather than codes, expect duplicates and orphans, and expect totals to shift when you filter.
Then check for blanks in things you filter or group by. A blank region, a missing category, a null date. These are dangerous because they often silently disappear from a filtered view, so the total on one page and the sum of the breakdown on another do not agree, with no error anywhere.
Only after those four is it worth looking at anything more sophisticated.
How bad does it have to be before it's worth spending money?
Two thresholds worth using.
The time threshold: add up the hours per month spent on manual correction, reconciliation and answering "which number is right". If it is more than a couple of days a month, that is 24 days a year and rising, and it will never shrink on its own.
The decision threshold: if a decision has been delayed or made badly because nobody trusted the number, the cost is no longer measured in hours. This is the one that justifies real spend, and it is also the one people underreport, because "we went round in circles on that" does not get logged anywhere.
If neither threshold is met, a data quality problem can be a known irritation you live with. Not every flaw needs a project.
What does a proper assessment involve?
Profiling the data (counting blanks, duplicates, orphaned rows, values that break the rules they should follow), tracing key figures back to source, and comparing definitions across reports that ought to agree. The output should be a prioritised list where each item says what is wrong, what it affects, and what it costs to fix, because that is what lets you choose rather than just worry.
My data quality health check does that as a fixed-price exercise, and there is a free data quality dashboard if you want to run the profiling yourself first. Whichever route you take, insist that the output is prioritised by business impact rather than by count of issues. A list of 4,000 problems sorted by severity is useless if the top item affects a field nobody reports on.
Common questions
What are the signs of poor data quality?
The behavioural ones are the most reliable: two reports disagreeing, manual corrections during month-end, people keeping private spreadsheets, and totals that change when you drill into them. Duplicate customer records and blank values in fields you filter on are the most common technical causes underneath.
How do I know if my data is accurate?
Trace a specific number end to end, from the report back to the system it originated in, and see whether the rule that produced it is written down anywhere. If the logic exists only in one person's head or inside an undocumented file, you cannot demonstrate accuracy, which is a different problem from being inaccurate but often just as costly.
Why do two reports show different numbers?
Usually because they define the thing differently: order date against invoice date, gross against net of credit notes, including or excluding internal transactions. Both reports are typically correct for their own definition. The fix is agreeing one definition and building it into a shared model rather than into each report separately.
Should I fix the data or fix the reports?
Fix whichever is actually wrong, and check which that is before spending. If values are genuinely incorrect or missing, fix them at source. If the values are fine and only the interpretations differ, that is a definitions decision and no amount of data cleaning will resolve it.
How much does a data quality assessment cost?
Mine is a fixed-price exercise, and there is a free dashboard you can run yourself to profile your data first. The variable that moves the cost is the number of systems involved, because tracing a figure across four systems is considerably more work than checking one.
Can't I just buy a data quality tool?
Tools are good at finding technical faults: duplicates, blanks, format violations, broken relationships. They cannot tell you that your sales team and your finance team mean different things by "customer". Since that second category causes most of the disagreements that damage trust, a tool on its own tends to produce a long list of findings and no resolution.