How do you handle BI reporting when your data quality is poor?
Poor data quality doesn't have to stop reporting — but it does change how you build and present it. The goal is to surface trustworthy insights while making data quality problems visible enough that someone actually fixes them.
The temptation to clean everything quietly
When data arrives messy, the instinct is to fix it in the pipeline and deliver a polished report. That approach feels professional. It also creates a slow-moving disaster.
If your BI layer silently patches duplicate records, fills missing values with estimates, and excludes bad timestamps without comment, stakeholders see clean numbers and assume the underlying data is clean too. Source teams never see the cost of their bad data entry. Nothing changes upstream. And you end up maintaining an increasingly complex set of workarounds that only your team understands.
Quiet cleanup is a short-term fix that makes the long-term problem worse.
Make data quality visible in the report itself
A more sustainable approach is to expose quality issues near the metrics they affect. This doesn't mean burying stakeholders in technical debt — it means giving them enough signal to understand what they're looking at.
Practical ways to do this:
- Show exclusion counts. If 340 records were dropped from a revenue calculation because of missing account IDs, say so. A small callout next to the metric is enough.
- Flag stale data. If a feed hasn't refreshed in 18 hours and the dashboard promises daily updates, surface that clearly rather than letting people assume the numbers are current.
- Display confidence levels. For metrics built on incomplete data, a simple label — "Based on 73% of expected records" — gives stakeholders the context to calibrate their decisions.
- Separate verified from estimated figures. Where you've filled gaps with modelled or estimated values, distinguish those from actuals.
The goal isn't to undermine confidence in the report. It's to make the report honest enough that people trust it when it matters.
Build data quality monitoring as its own layer
Treating data quality as a reporting concern rather than a pipeline concern is where most teams get stuck. A more durable approach separates the two.
Before data reaches any presentation layer, run quality checks that flag:
- Duplicate records above a defined threshold
- Missing values in fields required for key metrics
- Referential integrity failures — for example, transaction records with no matching customer ID
- Timestamp misalignment across systems feeding the same metric
- Out-of-range values that suggest entry errors rather than real outliers
These checks don't have to be complex. Even a simple monitoring table that tracks daily record counts, null rates, and duplicate percentages per source gives you an early warning system. When a KPI moves unexpectedly, you check the quality layer first rather than spending two hours in the data.
Teams that build this layer separately find it easier to show source owners what their process is producing — and easier to have the conversation about fixing it.
Getting stakeholders to care about upstream quality
This is where most technical approaches stall. You can build perfect monitoring, document every anomaly, and still watch nothing change because the people who own the source data don't feel the problem.
What actually shifts behaviour:
Tie quality failures to KPIs people already care about. Abstract data quality metrics don't motivate action. A chart showing that 12% of last month's pipeline was excluded from the forecast because of missing close dates — and what that means for the revenue number — does. A clear metrics definition for each KPI makes it much easier to trace which source fields are responsible when numbers go wrong.
Build department-level audit dashboards. Rather than one global data quality report that everyone ignores, build targeted views for each team showing only the records they own with missing or invalid data. When a sales manager sees their team's open opportunities flagged for incomplete fields, it becomes a management conversation, not a data team complaint.
Show the same issue repeatedly. One mention of a data problem gets forgotten. A recurring weekly view that shows the same source issue persisting creates pressure. When a stakeholder sees their KPI tracking affected by the same upstream problem three weeks in a row, the fix becomes easier to justify.
Get leadership aligned early. Department-level audit dashboards work when leadership expects teams to own their data quality. Without that top-down expectation, individual contributors have no incentive to prioritize it. If you can get one executive to treat data quality as a team accountability — not just a data team problem — the cultural shift follows.
When to push back on building before fixing
There are situations where building reports on top of dirty data isn't just impractical — it's actively harmful. If core business decisions hinge on a metric and the underlying data is unreliable enough to produce materially wrong answers, shipping the report creates risk.
A reasonable threshold: if the data quality issues would change the decision a stakeholder makes, fix the source before building the report. If the issues are visible, documented, and don't change the directional answer, report with appropriate caveats and fix the source in parallel.
Pushing back doesn't mean refusing to build. It means being explicit about what the report can and can't support — and getting agreement on that before anyone starts acting on the numbers.
A practical starting point
If you're dealing with poor data quality today and need to move forward:
- Identify the three or four metrics stakeholders trust most. Start data quality monitoring there, not everywhere.
- Add visible quality indicators to those metrics. Record counts, exclusions, freshness — whatever is most relevant.
- Pick one recurring source issue and surface it weekly in a format the source team's manager will see.
- Build the quality monitoring layer before expanding the report. More dashboards on bad data compounds the problem.
The teams that get this right don't treat data quality as a pre-condition for reporting. They treat reporting as the mechanism that makes data quality problems impossible to ignore.