We Can't Trust Our Own Numbers: Fixing Data Quality for Good

Not with a clean-up project - those buy a quarter of clean data before the same processes dirty it again. Data quality is a system with four working parts: master data management with clear ownership, quality rules enforced automatically in the pipeline, monitoring and lineage so trust becomes checkable, and named stewardship for the data that matters. Built on Microsoft Fabric and Purview, trustworthy data becomes what the platform produces by default - not what diligent individuals achieve against the odds.

There's a phrase that tells you everything about an organisation's data health, and it's said in meetings every day: "Take this with a pinch of salt, but..."

When reports routinely ship with caveats - when managers keep private spreadsheets "just to be sure," when analysts pre-emptively apologise for the figures, when any surprising number is assumed to be an error until proven otherwise - the organisation has a data quality problem. And data quality problems are never just technical. They are trust problems wearing a technical costume.

Poor data quality rarely comes from one dramatic failure. It seeps in through ordinary cracks:

Free-text where there should be structure. Customer names typed five different ways. Product codes improvised when the right one wasn't handy. Every free-form field is an invitation to inconsistency, accepted daily.

No owner for the master data. Who is allowed to create a new customer record? Who decides the product hierarchy? In many businesses the answer is "whoever needed to," which means the same real-world customer exists three times and every report counts them differently.

Systems that disagree by design. The CRM was updated; the ERP wasn't. An integration silently failed in March and nobody noticed until the September numbers looked odd. Without monitored pipelines, drift between systems is not a risk - it's a certainty.

Fixes applied downstream. Analysts patch known errors in the report layer - a manual adjustment here, an exclusion list there. The report looks right, the source stays wrong, and the fix becomes undocumented folklore that leaves when its author does.

None of these is scandalous. All of them compound. Give them a few years and you have an organisation where nobody can say with confidence how many active customers it has.

The verification tax. Every important number gets checked, re-derived, or shadow-tracked before anyone acts on it. Multiply that across every manager and every month; it's one of the largest invisible line items in your business.

Slower, more timid decisions. When data is doubted, decisions escalate - more sign-offs, more meetings, more instinct. The organisation's clock speed drops.

Compliance exposure. If you report to regulators, auditors, or investors from data you privately distrust, you are carrying risk you haven't priced. For businesses under GDPR, POPIA, or industry regulation, data quality isn't hygiene - it's obligation.

A hard ceiling on AI. Every AI ambition - Copilot, agents, forecasting - runs on your data. Models trained on inconsistent data produce confidently wrong answers at scale. Fixing quality isn't a prerequisite you can skip; it's the foundation the whole AI roadmap stands on.

The instinctive response to bad data is a one-off clean-up project. It always fails the same way: the data is clean for a quarter, then the same processes that dirtied it dirty it again. Quality isn't a project. It's a system with four working parts:

1. Master data management. One governed definition of your core entities - customers, products, suppliers, accounts - with clear ownership and controlled creation. This is the single highest-leverage fix, because every report and process inherits it.

2. Quality rules, enforced by the platform. Validation at the point of entry and in the pipeline: required fields, valid ranges, format checks, duplicate detection. In a Microsoft Fabric architecture, data moves through Bronze, Silver, and Gold layers - and the Silver layer is precisely where quality rules live, applied automatically to every record, every refresh.

3. Monitoring and lineage. Quality dashboards that track error rates and completeness over time, alerts when a feed breaks or a metric drifts, and lineage (via tools like Microsoft Purview) that shows exactly where any number came from. When someone asks "can we trust this figure?", the answer becomes checkable instead of rhetorical.

4. Ownership and stewardship. Named owners for key data domains, agreed definitions, and a lightweight forum for resolving disputes. Governance doesn't need to be bureaucratic - it needs to be explicit. Most data chaos is simply the absence of anyone being responsible.

Notice what's missing: heroics. In a working quality system, trustworthy data is what the platform produces by default, not what diligent individuals achieve against the odds.

Start where distrust is most expensive - usually customer or product master data feeding your financial and executive reporting. Profile it honestly (the first quality dashboard is always sobering), fix the highest-impact rules first, and assign ownership as you go. Then extend domain by domain. Delivered iteratively, the first visible trust gains land within weeks - and they build the appetite for the rest.

If your quality problems are compounded by conflicting metric definitions, fix the definitions in the same pass - the two problems share a solution architecture.

Data governance and quality frameworks are a core Solv Systems service. As a Microsoft Partner working across Fabric, Power BI, and Purview, we build the whole system described above: master data management, automated quality rules in the pipeline, monitoring and lineage, and the governance structures that keep it working after we leave.

We're deliberately practical about it. Governance programmes fail when they start with committees and documents; ours start with your most business-critical data, ship enforceable rules early, and grow the framework around demonstrated wins. And because we build on the Microsoft platform you already own, quality and governance become properties of your architecture - not a parallel bureaucracy.

The outcome our clients notice first isn't technical. It's the day a surprising number appears in a dashboard and the room's first question is "what should we do?" rather than "is that right?"

If your organisation pays the verification tax on every report, that's not a fact of life - it's a solvable design problem.

Our data platform consulting team will look at where your data quality issues originate, which fixes would rebuild trust fastest, and what a right-sized governance framework looks like for your organisation.