Data Quality Debt: The Compounding Liability on Your Balance Sheet Nobody Audits
- Matt Lazarus
- Jul 13
- 5 min read
Every balance sheet records the liabilities the organisation has admitted to. None records the duplicate customer master, the three competing product hierarchies, or the four thousand records whose owner left in 2021.
Those things cost real money every week - in rework, reconciliation labour, failed integrations and quietly wrong decisions. But because no ledger line captures the cost, the remediation never competes for budget against the liabilities that do.
The reframing that fixes the funding problem: data quality is debt. It accrues interest, it compounds - and AI deployment is the margin call.
Key Takeaways
Quality debt compounds like technical debt: every workaround adds interest in labour, brittleness and risk.
AI converts the debt from chronic to acute: models execute on bad records at volume, instantly and visibly.
A quality register gets it funded: score critical domains, cost the interest, rank remediation like any capital programme.
What Is Data Quality Debt?
Data quality debt is the accumulated gap between the data your processes assume and the data you actually hold - duplicates, conflicts, gaps and unowned records - plus all the workarounds built to live with that gap. Like technical debt, the principal is the defect and the interest is everything you pay to operate around it.
The interest payments hide inside ordinary operations: the analyst who reconciles two customer lists before every campaign; the finance team's bridging spreadsheet between systems that disagree; the integration project that ran six months over because the source data was nothing like its documentation. None of those line items says "data quality" - which is exactly how the debt stays invisible.
And like all debt, it compounds. Each workaround becomes load-bearing; each new system inherits the duplicates of the last; each departed employee takes another field's meaning with them.
The compounding has a quiet accelerant: staff turnover. Every workaround lives partly in someone's head - which record to trust, which field to ignore - and each departure converts documented-nowhere knowledge into fresh defects. Quality debt is the only liability on the books that grows when people resign.
Why Does AI Turn Quality Debt Into an Acute Problem?
Because AI removes the human shock absorbers. People who work with bad data learn its quirks - they know which customer record is the real one, which field to ignore, which total to distrust. A model knows none of that folklore: it executes on the records as they stand, at volume, with confidence, in front of stakeholders.
The conversion from chronic to acute follows a predictable script. The pilot launches; the assistant merges two customers who were one, quotes the abandoned product hierarchy, or calculates from the field everyone knows is wrong. The folklore that protected manual processes protects nothing - and the debt that cost a steady drip of labour now costs executive trust, which is far more expensive to rebuild.
This is also why "we will fix the data as part of the AI project" reliably fails: the project inherits an unsized liability with no register, no owner and no budget line. The debt has to be measured before it can be retired.
How Do You Audit Data Quality Like a Liability?
Build a quality register: identify the critical data domains (customer, product, finance, asset), score each against four dimensions - completeness, uniqueness, consistency and ownership - and cost the interest each defect class currently charges. The output reads like any capital programme: ranked remediation items with measured returns.
The method, kept deliberately lean:
Scope to critical domains. Five domains drive most decisions; audit those, not everything.
Score with evidence: duplicate rates, conflict counts between systems, null rates on decision-critical fields, and the percentage of records with a living owner.
Cost the interest: hours of reconciliation labour, error remediation incidents, and integration overruns traceable to each defect class - conservative numbers beat impressive ones.
Rank and fund: remediation items ordered by interest saved per dollar, exactly like any other investment case.
This register is a core artefact of an AI Data Readiness Audit - the same exercise that scores AI readiness produces the liability schedule that gets quality funded.
What Does Retiring the Debt Actually Involve?
Targeted remediation plus prevention: deduplicate and master the critical domains, settle the conflicting definitions, assign ownership - then install the controls that stop re-accrual: validation at entry, automated quality monitoring, and stewardship with teeth. Retirement without prevention is a diet without a habit; the debt returns.
The sequencing mirrors the triage logic that governs all good data work: fix the slice your highest-value decisions and AI use cases depend on first, bank the visible win, and let it fund the next slice. That bounded, domain-by-domain remediation is the operating model of preparing your data for AI - quality work scoped by what the business is about to ask of the data, not by perfectionism.
Who Should Own Data Quality - IT or the Business?
The business owns the meaning; IT owns the machinery. Every durable quality programme splits stewardship that way: a named business owner per critical domain who adjudicates definitions and disputes, and a platform team that builds the validation, monitoring and mastering the stewards rely on. Programmes fail when either half tries to carry both.
The reason is structural. Only the business can answer the questions that create quality - is this customer record the same entity as that one, which hierarchy is correct, what does "active" mean? IT enforcing rules it cannot adjudicate produces technically valid nonsense; the business adjudicating without enforcement machinery produces meeting minutes that change no records.
The operating model that works at mid-market scale is deliberately small: one steward per domain (a role, not a hire - typically a senior operator who already fields the disputes informally), a monthly exception review where the monitoring surfaces what broke, and an escalation path for the genuinely contested calls. The register gives the stewards their agenda; the dashboards give them their evidence; the mandate gives their decisions teeth.
One governance rule prevents most relapses: no new system, integration or AI use case ships without naming which steward owns its data domain and which quality gates it must pass. Debt prevention, priced into every project at the moment it is cheapest - the start.
Which Data Domains Should You Remediate First?
Rank by AI exposure multiplied by reuse. Customer data almost always tops the list: it feeds the most use cases, carries privacy obligations, and its duplicates are the ones AI will confidently merge into fiction. Financial reference data follows - the definitions and hierarchies every numeric answer depends on - then product and supplier domains in whatever order your priority use cases dictate.
The discipline is to remediate against a named consumer, not against an abstract standard. "Customer data good enough for the service-agent pilot" is a fundable, finishable scope with a measurable acceptance test; "fix customer data" is a permanent programme. Each remediated domain then serves every subsequent use case that touches it - which is how the debt repayment starts compounding in your favour.
Put It on the Register
Boards fund what appears on a register and starve what does not. Data quality has spent two decades in the second category, and the bill has now arrived wearing an AI badge.
Audit the debt, cost the interest, rank the retirement - and the conversation changes from "should we spend on data clean-up?" to the only question a board actually enjoys: "which of these returns do we want first?"
