How to Fix Bad Data Quality: 5 Steps to Cut Its Cost (2026)

Key Takeaways

• Bad data quality means data that is not fit for the decision or process that uses it, rather than just data with typos.
• The first warning signs are business symptoms, so look for reports that disagree, manual reconciliations, failed loads and stale AI answers.
• You can also price the problem with one formula: defective records times minutes to fix, divided by 60, times a loaded hourly rate.
• The fix runs in five steps: prioritize critical data, profile it, trace root causes, remediate, then prevent recurrence.
• Prevention at the point of entry and in the pipeline saves more than repeated cleanup, because each cleanup only treats the symptom.
• Every critical data element needs a named owner and steward, or the same defects return within months.

The Report That Counted the Same Customer Three Times

Picture a Monday revenue review at a mid-sized distributor. Marketing shows 48,000 active customers. Finance shows 41,000. Nobody in the room can say which number is right.

The cause turns out to be one buyer stored three ways. The CRM knows her as “J. Smith”, billing has “John Smith”, and the support desk logged “Jon Smith” with a different email. So marketing mails her three catalogs, and the dashboard spreads her spending across three accounts. Revenue per customer looks lower than it is, and the growth plan built on that figure aims at the wrong target.

Nothing in that story is a dramatic failure. No system crashed, and no alert fired, so nobody looked. That silence is exactly why bad data is so expensive: the damage hides inside normal reports until someone acts on them.

This guide covers what bad data looks like, how to spot it and how to put a dollar figure on it. It then walks through a five-step fix, shows which method fits which problem, and explains who should own the result.

What Is Bad Data Quality?

Bad data quality is data that is not fit for the decision or process that depends on it. A customer address can be perfectly valid for a marketing list and still be wrong for a tax filing. Quality is always judged against a use, which is why two teams can disagree about the same table.

Standards bodies describe that fitness through dimensions. The UK Government Data Quality Framework lists the six core dimensions from DAMA UK: accuracy, completeness, consistency, timeliness, uniqueness and validity. It also notes that this is not a prescriptive list, so teams can add dimensions that matter to them. The ISO/IEC 25012 data quality model goes further, with 15 characteristics split between inherent qualities and system-dependent ones.

You do not need to memorize either list, though. What matters is that each dimension turns a vague complaint into something you can measure. For example, “the customer data is bad” becomes “12% of customer records have no email.” Those numbers can be owned, tracked and fixed.

Seven Types of Bad Data

Defects tend to fall into seven recognizable types. The table below shows how each one appears in daily work, and also where it usually starts. If you want the boundary between this topic and data integrity, our guide to data integrity vs data quality draws that line in detail.

Warning Signs Your Data Has a Quality Problem

Bad data rarely announces itself in a data team’s tools first. Instead, it shows up as friction in the business, where people work around numbers they no longer trust. So if several of the signs below sound familiar, the problem is already costing you time.

• Two reports answer the same question with different numbers, and meetings start with an argument about which is right.
• Analysts keep spreadsheets that reconcile one system against another before every month-end close.
• Campaign emails bounce, while invoices or parcels go to old addresses.
• Nightly loads fail because a field arrived in a new format or a column was renamed upstream.
• An AI assistant or chatbot cites a policy, price or contact that changed months ago.
• Customers call more than once to correct the same details, because the first fix never stuck.

Symptoms tell you where to look, while a few quick checks tell you how big the problem is. Run these on one critical table before you plan any fix, because the numbers will set your priorities.

1. Measure the null rate on fields the business needs, such as email or tax ID.
2. Count rows that share a key that should be unique.
3. Count values outside a valid range, for example negative quantities or future dates.
4. Compare a total, such as open orders, between two systems that should agree.

None of these checks needs a new tool, so you can start right away. A few SQL queries or a profiling run will show whether you have a minor cleanup or a structural problem.

What Bad Data Quality Costs, and How to Calculate Yours

Cost is the argument that gets a data quality program funded. Without a number, the work competes with every other request, so it usually loses. With a number, however, it becomes a business case that a finance leader can check.

What the Research Says

The clearest published figures come from an IBM analysis. In a January 2026 analysis of poor data quality, IBM cites its Institute for Business Value 2025 research. That study found 43% of chief operations officers name data quality issues as their most significant data priority.

The same analysis cites Forrester research on losses: over a quarter of organizations estimate they lose more than USD 5 million a year to poor data quality. At the top end, 7% report losses of USD 25 million or more.

Those losses rarely appear as one line item, because they spread across rework hours, missed sales, write-offs, delayed decisions and audit findings. That spread is why a team needs its own estimate rather than an industry average.

A Worked Cost Example

The simplest useful formula counts the labor spent fixing defects by hand. It ignores lost revenue and fines, so it gives a floor, not a ceiling.

1. First, count defective records per month, which is records processed times the defect rate.
2. Then multiply by the average minutes a person spends finding and fixing each one.
3. After that, divide by 60 to get hours.
4. Finally, multiply by the loaded hourly rate of the people doing the fixing.

Here is an illustrative case with stated assumptions, not a benchmark. Say a company processes 1,000,000 customer and order records a month, and 3% are defective. That gives 30,000 bad records.

If each takes 10 minutes to research and correct, the team spends 300,000 minutes, or 5,000 hours. So at a loaded rate of $60 an hour, that is $300,000 a month, or $3.6 million a year.

Now assume prevention removes 70% of that rework. That is an assumption to test, not a promise. The saving would still be about $2.52 million a year, before counting a single recovered sale. Then swap in your own volumes, rates and minutes, and you have a defensible first estimate.

Where Bad Data Comes From: Seven Root Causes

Every defect has a birthplace, and it is usually a process rather than a person. So fixing records without fixing that process guarantees the same defects next month. These seven causes account for most of what data teams find.

1. Manual entry. People type fast and skip optional fields, so a sales rep enters “Acme Corp” while a colleague enters “ACME Corporation.”
2. Integration and migration breakdowns. Field mappings drop or truncate values when data integration tools are set up in a hurry. A data migration can also carry old defects into a new platform at full speed.
3. No shared standards. Each team defines “active customer” or “region” its own way, so joins and totals disagree.
4. No owner. When nobody is accountable for a data element, nobody fixes it at the source.
5. Data decay. People move, change jobs and switch phone numbers, so a correct record becomes wrong with time.
6. Upstream schema drift. When a source team renames a column or changes a type, downstream loads break or fill with nulls.
7. Unvalidated AI and unstructured inputs. Text extracted from PDFs, emails or model outputs enters tables without the checks that form data gets, so errors slip through.

Migrations deserve special attention, because they concentrate several causes at once. Mappings change, old rules disappear, and deadlines push data migration testing aside. Step 4 covers the reconciliation check that catches that damage.

How Bad Data Spreads From Source to Decision

A defect does not stay where it starts. It travels from a source system through ETL pipelines into a warehouse, then into reports, models and finally decisions. At each hop it gets harder to trace and more expensive to correct.

A short, dated example shows how far one bad input can reach. In August 2023, a single flight plan that UK air traffic systems could not process caused widespread disruption, and thousands of passengers were stranded. So one record at the source became a national travel problem.

The lesson for data teams is about where checks belong. Validate at the source, then test in the pipeline, reconcile in the warehouse, and monitor what reports and models consume. To see how each hop connects, our explainer on data lineage shows how teams map that path end to end.

How to Fix Bad Data Quality in 5 Steps

A lasting fix follows the same order every time: decide what matters, measure it, find the cause, repair the data and then block the cause. Skipping straight to cleanup is a common reason programs stall. Each step below builds on the one before it.

Step 1: Pick Your Critical Data Elements and Price Their Defects

Start small and specific, because a short list is easier to fund. A critical data element is a field that drives revenue, compliance or a key model. Customer ID, billing address, product price and claim amount are typical examples. A short workshop with finance, operations and data leads usually produces a first list.

Then, for each element, estimate the defect cost with the formula above. A billing address that causes failed invoices outranks a marketing preference field, even if the preference field has more errors. Rank by business impact rather than error count, so effort goes where it returns money.

A quick ranking shows why. The figures below are illustrative assumptions, priced with the labor formula alone at $60 an hour:

The preference field has 15 times more errors, yet the billing address costs three times as much. That is before counting a single failed invoice, so the address goes first.

Step 2: Profile the Data and Set a Baseline

Profiling measures what the data actually holds before anyone changes it. For each critical element, record completeness, uniqueness and validity rates. That baseline is how you will prove the program worked, so capture it before the first fix.

A baseline can start with a query this simple, run against one critical table:

-- Baseline profile for one critical table
SELECT
  COUNT(*) AS total_rows,
  100.0 * SUM(CASE WHEN customer_email IS NULL THEN 1 ELSE 0 END) / COUNT(*) AS email_null_pct,
  COUNT(*) - COUNT(DISTINCT order_id) AS duplicate_order_ids,
  SUM(CASE WHEN order_total < 0 THEN 1 ELSE 0 END) AS negative_totals,
  SUM(CASE WHEN order_date > CURRENT_DATE THEN 1 ELSE 0 END) AS future_dates
FROM sales.orders;

Turn each result into a written rule with a threshold, so everyone measures the same thing. Our guide to data profiling also covers column statistics, pattern checks and tooling in more depth.

Step 3: Trace Each Defect to Its Root Cause

A failed rule tells you what is wrong, but not why. Root-cause work asks “why” until the answer is a process you can change. The five-whys method works well here because it stops teams from blaming the last person who touched the record.

Take duplicate customers, for example. Why are there duplicates? Because support creates new records. Agreeing one format for names, addresses and codes through data standardization removes many of these duplicates.

Why does support create them? Because the support tool cannot search the CRM. Why not? Because the tool was bought with no CRM integration in scope, and nobody owns the cross-system customer lookup. That is the process cause, so the real fix is an owned integration or lookup, not a weekly merge job. To find the producing system quickly, trace the defect back through data lineage from the report to its first source.

Then record each cause next to its rule. Over a few cycles, patterns appear, such as one intake form or one integration behind half your defects.

Step 4: Remediate With Cleansing, Matching and Master Data

Remediation repairs the records you already have. Cleansing corrects formats and obvious errors, while standardization applies one convention for names, addresses, units and codes. Deduplication then finds records that describe the same real-world entity.

Matching needs explicit rules. A rule might treat two customers as one when tax ID matches, or when name and postal code match closely. Machine learning can suggest likely matches, as our guide to AI in data management describes, but a steward still approves the rule. Survivorship rules then decide which value wins, for example the most recent verified address. For entities shared across many systems, such as customers, products and suppliers, master data management keeps one golden record that every system references.

After any migration or bulk fix, reconcile counts and totals between source and target, a step every data migration checklist should include. Purpose-built data reconciliation tools automate those comparisons, so a missing batch shows up before a user finds it.

Step 5: Prevent Recurrence With Validation, Contracts and Monitoring

Prevention is where the money comes back. Every rule from Step 2 should move as close to the source as possible. That way a bad value is rejected at entry instead of cleaned later.

Start with controls the database already offers. Foreign keys enforce referential integrity, check constraints block impossible values, while unique constraints stop duplicate keys:

ALTER TABLE sales.orders
  ADD CONSTRAINT fk_orders_customer
  FOREIGN KEY (customer_id) REFERENCES crm.customers (customer_id);

ALTER TABLE sales.orders
  ADD CONSTRAINT chk_order_total CHECK (order_total >= 0);

ALTER TABLE crm.customers
  ADD CONSTRAINT uq_customer_email UNIQUE (customer_email);

Beyond the database, three habits close the remaining gaps. Data contracts are written agreements between a producing team and its consumers on schema, meaning and freshness. Pipeline tests run those rules on every load and stop a bad batch before it publishes, which is the core of data reliability. Monitoring then watches volume, freshness and distribution, and alerts the owner when something drifts.

In a dbt project, for example, a pipeline test takes only a few lines of YAML. dbt ships four generic data tests (unique, not_null, accepted_values and relationships), and each one returns the rows that fail it. A test with zero failing rows passes, as the dbt data tests documentation explains:

models:
  - name: orders
    columns:
      - name: order_id
        data_tests:
          - unique
          - not_null
      - name: customer_id
        data_tests:
          - not_null

Monitoring and quality checks overlap but are not the same discipline. Our comparison of data observability vs data quality explains where each one fits.

Which Fix Fits Which Problem

Each defect type has a method that works best for it, so using the wrong one wastes months. A team that buys a deduplication tool to solve schema drift will still have broken loads. Match the problem to the method first, then choose a tool category and an owner.

The table also shows why tooling should come last. Every method depends on rules and owners that a tool cannot invent for you.

Why Bad Data Hurts AI More Than Dashboards

A wrong number on a dashboard is visible, so a person can question it. A model trained or grounded on bad data, however, repeats the error quietly, at scale and with confidence. That difference raises the stakes for every AI project.

Recall the warning sign from earlier, an AI assistant citing a policy, price or contact that changed months ago. Say a retrieval assistant quotes an expired price list because the old PDF was never retired. The model worked as designed, and the source data failed it.

IBM’s analysis notes that data quality problems can cause hallucinated AI outputs or make models drift over time. Gartner’s February 2025 press release predicted that through 2026 organizations will abandon 60% of AI projects unsupported by AI-ready data. The same release reported that 63% of organizations either lack or are unsure whether they have the right data management practices for AI.

Regulators also write data quality into AI rules. Article 10(3) of the EU AI Act covers training, validation and testing data for high-risk systems. That data shall be “relevant, sufficiently representative, and to the best extent possible, free of errors and complete in view of the intended purpose.” In the US, the NIST AI Risk Management Framework, released in January 2023, provides a voluntary way to manage AI risk.

For a data team, AI changes three things in practice:

• Unstructured inputs, such as documents and chat logs, need quality checks inside the AI data pipeline, not just in tables.
• Bias becomes a quality dimension, so training sets need representation checks during data preprocessing, alongside null and duplicate checks.
• Freshness matters more, because a retrieval system will answer from whatever version it finds.

Who Owns Data Quality

Data quality fails without clear ownership, and it fails slowly. Everyone assumes another team will fix the problem, so nobody does. That gap is one of the classic data governance challenges. A simple responsibility map ends that loop.

The model below fits a typical enterprise. The business owns the meaning of the data, stewards run the day-to-day rules, while engineers build the controls. If you are designing the wider program, our guide to building a data quality framework covers scope, metrics and tooling choices.

Ownership also sits inside a broader governance model. The data governance framework guide explains how policies, roles and councils fit together.

Standards and Regulations That Set the Bar

Setting quality targets is the data owner’s job, and outside standards make those targets defensible. Several standards and rules define what good enough means. You do not need all of them, but knowing which ones apply helps you set targets that auditors and partners will accept.

BCBS 239 has an instructive origin. The Basel Committee published the principles in January 2013. The 2007 crisis had shown that many banks could not aggregate their risk exposures quickly or accurately. Covered banks must show risk data that is accurate, complete and reconciled, which is Steps 2 to 4 applied under a regulator.

Common Mistakes That Bring Bad Data Back

Many stalled programs did fix their data once. It simply went bad again because the fix never reached the cause. These mistakes show up again and again, and each one has a simple counter.

• One-off cleanup projects. A big cleanup with no prevention decays within months. In the worked example above, a cleanup clears 30,000 bad records, and the next month brings 30,000 more. Fund rules and owners instead of a single sprint.
• Cleaning only downstream. Fixing data in the warehouse leaves the source broken, so push each rule back toward entry.
• Fixing records without telling the producer. A steward who quietly corrects bad rows hides the defect from the team that creates it. Log each fix and send it back to the source owner.
• Tooling before rules. A platform with no agreed rules only measures confusion. Write rules first, then automate them.
• No baseline. Without a starting measure, nobody can show progress. Profile before you change anything.
• Alert fatigue. Hundreds of low-value alerts teach people to ignore all of them. Instead, alert only on critical elements and tune thresholds monthly.

Avoiding these is less about effort than about order. Teams that follow the five steps in sequence rarely fall into more than one of them.

How Kanerika Fixes Data Quality at the Source

Kanerika treats poor data as a process problem with a data symptom. Our work follows the same five steps described above, adapted to each client’s systems and regulators.

We start by assessing and profiling the critical data that drives revenue and reporting. Business owners sign off on the rules, so quality targets reflect real decisions. Our data engineering team fixes root causes inside pipelines and source integrations, not just in the warehouse.

Automated controls, monitoring and governance policies from our data governance services, which include KANGovern, KANGuard and KANComply, keep those fixes in place. Once the first set of critical elements holds steady, we expand to the next.

A pharmaceutical client shows why data consolidation can be the root-cause fix. Its data sat across Model N, SQL Server, SAP and SAP Vistex, with no central warehouse. With four systems and no shared source, teams duplicated effort and reported inconsistent numbers.

That split was the process cause Step 3 looks for, so cleaning reports alone could not fix it. Kanerika removed the split by unifying those sources into a Microsoft Fabric lakehouse, with Power BI reporting on one source of truth. The pharma data platform case study records a 78% reduction in data-related errors and 41% faster data processing.

Bottom Line: How to Fix Bad Data Quality and Keep the Savings

To fix bad data quality, price the critical defects, profile them, trace their causes, remediate the backlog and prevent recurrence at the source. Forrester research cited by IBM finds that over a quarter of organizations lose more than USD 5 million a year to poor data quality. The worked example shows a mid-sized operation losing $3.6 million a year in rework labor alone.

The savings come from prevention, not from one-off cleanup, because prevention removes the rework that cleanup keeps paying for. Clear the backlog once, then block each cause where it starts, and you fix bad data quality and cut its cost for good.

Frequently Asked Questions