Every organisation already knows bad data is a problem in the abstract. Far fewer can say what it actually costs them, because the cost of bad data almost never appears as a line item. It shows up as a finance team quietly re-running a report before a board meeting, an analyst spending an afternoon reconciling two numbers that should already match, or a sales forecast that leadership stopped trusting months ago and nobody ever said so out loud. The expense is real, it is just spread across a hundred small delays instead of one obvious failure.

This article is written for CDOs, data directors, and IT leaders who need to make the business case for investing in data quality, not to a technical audience but to whoever holds the budget. We walk through where the cost of bad data actually hides, then look at two concrete scenarios, a data quality failure inside an Oracle ERP system and one moving through a Microsoft Fabric medallion architecture, before covering what a governed data quality framework changes about that cost curve.

The Real Cost of Bad Data Is Rarely Where You Expect

When leadership asks what bad data costs, the instinct is to point at a single dramatic incident, a wrong number that reached a board deck, a duplicate customer record that triggered two invoices. Those incidents happen, but they are the visible tip of a much larger pattern. The bulk of the cost sits in the everyday friction of not trusting your own numbers, teams building parallel spreadsheets to double check a dashboard, analysts spending a meaningful share of their week on reconciliation instead of analysis, and decisions getting delayed a day or a week while someone confirms a figure is real.

None of that shows up on an invoice. All of it shows up in slower decisions, lower confidence in reporting, and analysts spending their time validating data instead of interpreting it.

Where the Cost Actually Hides

Four places consistently absorb the cost of bad data, and none of them are the data itself. The first is analyst time, every hour spent manually checking a number is an hour not spent generating insight. The second is decision risk, a forecast built on unverified data either gets used and turns out wrong, or gets second guessed and delays the decision anyway. The third is compliance and audit exposure, when a regulator or auditor asks who owns a data rule and when it last changed, and there is no clear answer. The fourth is trust itself, once a stakeholder catches one wrong number in a dashboard, they quietly stop trusting all the others, and rebuilding that trust takes far longer than the original error did to create.

Scenario One: Bad Data Inside an Oracle ERP

Consider a manufacturing business running its finance and supply chain on an Oracle ERP. A supplier record gets updated with an incorrect tax jurisdiction, a handful of purchase orders carry a stale unit of measure, and one warehouse location code was mistyped during a data migration two years ago and never caught. Individually these look like small clerical issues. Collectively, they quietly distort landed cost calculations, understate inventory valuation at one site, and cause a reconciliation mismatch that finance discovers only at quarter close, when the fix has to happen under deadline pressure instead of calmly, weeks earlier.

The Oracle ERP itself has no mechanism that flags any of this on its own. Nothing in the transactional system is checking whether a tax jurisdiction code is valid, whether a unit of measure matches what the item master expects, or whether a location code actually exists in the warehouse hierarchy. Those checks have to be defined and run independently of the ERP, against extracted or replicated data, on a governed schedule with clear ownership, exactly the kind of registry-based check that a data quality framework is built to run.

Scenario Two: Bad Data Moving Through a Fabric Medallion Architecture

Now consider an organisation that has modernised onto Microsoft Fabric, with a medallion architecture moving data through bronze, silver, and gold layers on its way to Power BI. The danger here is different but just as costly, a bad record that enters at the bronze layer does not stay contained, it gets transformed, joined, and aggregated as it moves through silver and into gold, and by the time it reaches a semantic model and a dashboard, the original source of the error is several transformation steps removed from where anyone is looking.

A null customer key that should have been rejected at bronze instead flows into a silver fact table, gets joined against a dimension, and quietly inflates a revenue aggregate in gold. Nobody sees a bad record, they see a KPI card that looks slightly high, with no obvious link back to the single row that caused it. Catching this requires checks placed at each layer of the medallion, not just a final sanity check on the gold layer output, because by the gold layer the specific failing record is already several joins deep and effectively invisible.

Reactive Cleanup vs a Governed Framework

Both scenarios share the same underlying pattern, small, individually plausible errors compound quietly until they surface somewhere expensive, at quarter close, in a board report, or in a KPI nobody can explain. The difference between organisations is not whether bad data exists, every environment has some, the difference is whether there is a governed, always-on way to catch it before it compounds.

What Actually Changes the Cost Curve

A registry-based data quality framework does not eliminate bad data, no framework does. What it changes is when the issue surfaces and who is accountable for it. Every check is defined once, with a category, a severity, and an owner attached, and runs against the source data every day, whether that source is an Oracle ERP extract, a SQL Server table, or a Fabric lakehouse layer. Failing records are captured the moment a check runs, not weeks later during a reconciliation, and every check that fires above its threshold generates an alert routed to the person responsible for that data, rather than surfacing as a mystery in a board deck.

The result is that the cost of bad data stops concentrating into rare, expensive, disruptive incidents and instead gets absorbed as routine, low-cost monitoring, exactly the kind of shift finance leaders recognise as good risk management in any other part of the business.

Getting Started

Most organisations do not need to instrument every table on day one. The typical starting point is registering the handful of checks a team already knows matter, a tax jurisdiction validation on the Oracle side, a null key check at the bronze layer on the Fabric side, and letting the registry model expand from there, table by table and source by source, without re-architecting anything already in place.

If your organisation is absorbing the cost of bad data as recurring rework rather than catching it early, speak with a Numlytics data quality consultant. We help data engineering and BI teams put a governed data quality framework in place across Oracle, SQL Server, and Microsoft Fabric environments, so issues get caught at the source instead of at the board meeting.