What bad data actually costs your business — and why catching it early is cheaper
A non-technical guide to the business cost of poor data quality — where the money really goes, why an error gets roughly ten times more expensive at every stage it survives, and how to measure your own number instead of borrowing an analyst's.
· 10 min read
Bad data costs money in four places: the hours your team spends fixing it, the decisions made wrongly because of it, the trust it destroys in the reports nobody believes any more, and the customers and regulators who see it before you do. The important part is not the total — it is the shape. An error caught where it enters costs a few minutes. The same error caught in a board pack costs a meeting, a retraction and some portion of your credibility. Catching it early is not a technical preference; it is the entire economics of the problem.
The number you have probably seen
Gartner has estimated the average cost of poor data quality at around $12.9 million per organisation per year. You will find that figure in every data quality vendor's deck, including, now, this one.
Treat it as a conversation starter, not evidence. It is an average across wildly different organisations, it is several years old, and no CFO has ever approved a budget because an analyst firm published a mean. The number that will actually move your finance director is the one you calculate from your own last six months — and that number is usually easier to produce than people expect.
The more useful part of the research is not the total. It is the consistent finding that the cost of an error scales with how long it survives.
The 1-10-100 rule
The widely used rule of thumb in quality management is that costs scale by roughly an order of magnitude at each stage:
- $1 to prevent — validate the record where it is created or loaded.
- $10 to correct — find and fix it later, inside your own systems.
- $100 to fail — do nothing, and pay the cost of the wrong decision, the wrong invoice, the wrong regulatory filing.
The exact multipliers are not the point and were never meant to be precise. The shape is the point, and it holds up against almost anyone's experience: fixing a duplicate customer record at the point of entry is a trivial act, and unpicking six months of duplicated revenue attribution across three downstream systems is a project.
This is why "catch it early" is worth saying out loud. It sounds like a platitude. It is actually a statement about a hundredfold cost difference.
Where the money actually goes
Four buckets, roughly in order of how visible they are:
| Cost | What it looks like | Why it hides |
|---|---|---|
| Rework | Analysts reconciling two numbers that should match; engineers rerunning pipelines; a "data quality week" every quarter | Buried in salaries, never itemised |
| Wrong decisions | Stock ordered against a broken forecast; a campaign aimed at a mis-segmented list; a hire made against inflated pipeline | Attributed to bad judgement, not bad input |
| Lost trust | Teams building private spreadsheets because they don't believe the dashboard | Looks like culture, costs like duplicated infrastructure |
| External failure | Wrong invoices, wrong regulatory returns, a customer told something untrue about their own account | Only counted when it becomes an incident |
The first bucket is the one everybody feels and nobody measures. If your analysts spend a day a week reconciling numbers, that is roughly 20% of your analytics capacity spent proving that yesterday's data was right — a cost that never appears on any line item, and one you could quantify this afternoon.
The fourth bucket is the one that ends up in a board meeting. It is also the one that early detection almost entirely eliminates, because external failures are rarely caused by exotic problems. They are caused by ordinary problems that nobody was watching for.
Why errors get more expensive the further they travel
An error in a source table is a fact about one table. By the time it has been through your transformation layer it is a fact about every model built on that table. By the time it reaches a dashboard it is a fact about every decision someone made while looking at it.
Three things compound:
The blast radius grows. One bad column feeds five models, which feed twenty dashboards. Fixing the column is easy; finding all twenty consumers, telling them, and correcting what they already did is not.
The evidence disappears. A duplicate caught on the day it lands can be traced to the load that caused it. The same duplicate found in a quarterly review has to be reconstructed from logs that may have rotated, by someone who was not there.
Trust does not recover at the same speed it is lost. One retracted report earns months of people quietly double-checking your numbers in their own spreadsheets. That cost is real, permanent, and invisible in every budget you will ever write.
Calculate your own number
You do not need a maturity model or a consultant. Take your last six months and answer five questions:
- How many data incidents did you have? Count anything where someone had to correct, re-run, or apologise for a number.
- How long did each take to detect? Not to fix — to *notice*. This is usually the shocking one.
- How long did each take to resolve, across everyone involved, not just the engineer who wrote the fix.
- How many were found by a consumer rather than by you? A stakeholder finding your error is a different, much more expensive category than you finding it.
- What did the worst one actually cost in decisions made, refunds issued, or filings corrected?
Multiply the hours by a loaded cost, add the worst case, and you have a defensible figure built entirely from your own history. In most teams the answer lands somewhere that makes the tooling conversation very short.
The single most useful metric in that list is time to detection. It is the one you have most control over, it is the one that determines which of the 1-10-100 buckets an error lands in, and it is the one that a monitoring tool moves directly.
What "catching it early" means in practice
Early detection is not a culture of vigilance. It is a small number of concrete, boring habits:
Check data where it enters, not where it is consumed. The validation belongs at the boundary — the point where data arrives from a source system or lands from a load — because that is where the blast radius is still one table wide.
Write down what "correct" means, before you need it. Most data incidents are not exotic. They are a required field that went null, a key that duplicated, a status column that grew a value nobody expected, a table that simply did not update. Those expectations can be stated in advance, in plain terms, by the person who owns the data — and once they are written down they can be checked automatically, forever, for free.
This is what a data contract is. It is an agreement between whoever produces a dataset and everyone who depends on it, written in a format both a person and a machine can read: these columns exist, this one is never empty, this one is unique, this one only ever contains these five values, and this table is never more than a day old. Catalyst uses the Open Data Contract Standard for exactly this, so the agreement lives in a portable open format rather than inside one vendor's product.
Watch freshness, not just correctness. The most common data incident is not wrong data. It is *absent* data — a load that silently did not run, leaving yesterday's numbers looking perfectly valid. A freshness check is the cheapest rule you will ever write and it catches a disproportionate share of real incidents.
Alert on the change, not the state. Tell people when something *starts* failing. Repeating "still failing" every hour is how a channel gets muted, and a muted channel is worse than no channel, because it feels like coverage.
Route the alert to whoever can fix it. A quality failure that reaches a general channel is everyone's problem and therefore nobody's. It should reach the owner named in the contract.
Making the case internally
Three framings that tend to land better than the cost of bad data itself:
Lead with time to detection, not with quality. "We currently find out about data problems when a stakeholder emails us, on average eleven days later" is a sentence that gets budget. "Our data quality is poor" is a sentence that gets a nod.
Scope it to a decision, not to a platform. Pick the three datasets behind your most-used report and cover those first. Nobody approves "monitor everything". Plenty of people approve "make sure the revenue dashboard is never wrong again".
Report coverage, not incidents. Once monitoring is running, the number that shows progress is the share of critical datasets under contract, and the trend in how quickly failures are caught. A falling incident count is ambiguous — it might mean things improved, or it might mean you stopped looking.
Where to start
- List your ten most-used datasets. Not all of them — the ones people actually make decisions with.
- For each, ask the owner what would have to be true for it to be wrong. You will get four or five answers, and they will be simple ones.
- Write those down as a contract and turn them into automated checks.
- Run the checks on the same cadence as the data, right after the job that loads it.
- Send failures to the owner, and only on the transition into failure.
That is a week of work for most teams, and it moves your typical error from the $100 bucket to the $1 bucket. Whatever the real multiplier is in your organisation, that is where the return is.
Frequently asked questions
How much does poor data quality cost a business?
Gartner has estimated an average of around $12.9 million per organisation per year, but averages across an entire economy are not a basis for a business case. Calculate your own from the last six months: count your data incidents, the hours spent detecting and resolving each, and the cost of the worst one. That figure is defensible in a way a borrowed benchmark is not.
What is the 1-10-100 rule in data quality?
A rule of thumb from quality management: it costs roughly $1 to prevent an error, $10 to correct it once it is inside your systems, and $100 to live with the consequences of acting on it. The multipliers were never meant as precise measurements — the point is that cost scales sharply with how long an error survives undetected.
Why is catching data errors early cheaper?
Because an error's cost grows with its blast radius. Caught at the source it affects one table and can be traced to the load that caused it. Left alone, it propagates into every model and dashboard downstream, the evidence needed to diagnose it ages out, and people make decisions on it. Early detection is the difference between a five-minute fix and a multi-week reconciliation.
How do I measure the cost of bad data in my own organisation?
Track four things: number of incidents, time to detection, time to resolution, and how many were reported by a consumer rather than found internally. Multiply the effort by a loaded hourly cost and add the direct consequences of the worst incident. Time to detection is the most actionable of the four, because it determines how expensive every other incident becomes.
Do I need engineers to set up data quality monitoring?
Not for the parts that matter most. The valuable rules are business rules — this field is always filled in, this identifier is unique, this status only takes these values, this table updates daily — and the person who knows them is the data owner, not an engineer. Catalyst reads your table's structure automatically and proposes a starting set of checks, so the job becomes reviewing and adjusting rather than writing code.
Isn't this what our data warehouse already does?
Warehouses enforce structure, not meaning. They will stop you putting text in a number column, but they will happily accept an order with a negative total, a customer duplicated four times, or a table that has not been updated since Thursday. Several popular warehouses do not enforce uniqueness constraints at all — see the notes on Redshift and BigQuery, where declared primary keys are never checked. The gap between "structurally valid" and "actually correct" is where data incidents live.