Improve data quality: Practical checks that deliver measurably better reports in 30 days

Many companies try to obtain better reports through new dashboards, additional KPIs or a different BI tool. In practice, however, the problem often lies earlier: anyone who wants to improve data quality must stabilise the data at the points where it is created, transmitted, aggregated and interpreted. Poor data quality is visible not only in „wrong numbers“, but in everyday operations: business units argue about the source instead of the decision, IT receives tickets stating „report is incorrect“, and every analysis requires manual corrections in Excel.

The good news: noticeable improvements do not require a large program. With a clear 30-day approach – focused on a few, but effective checks – reports can be measurably stabilised. Crucially, checks must not be understood as a one-off cleanup, but as an operational control system: with thresholds, owners, documentation and escalation paths.

This article describes practical data quality checks that you can implement in four weeks without „reinventing“ the system landscape. The focus is on effects for operations, administration, interfaces, data flows and collaboration between IT and the business unit.

Why reports fail despite modern tools: typical causes in enterprise landscapes

In mature environments, data is produced across many stages: ERP, CRM, warehouse, portals, bespoke corporate software, import/export processes, service provider interfaces. Each stage can change the meaning of a field. A classic example is „customer“: in System A it is the invoice recipient, in System B the delivery address, in System C the site. As soon as these terms are combined in an analysis, seemingly „incorrect“ metrics appear – even though everything was technically loaded correctly.

Typical causes that make reports unreliable:

• Unclear semantics: fields share the same name but mean something different in each system. Semantics here refers to the business meaning – not the data format.
• Silent interface breaks: a field is adjusted in a source (e.g. new status values), the target pipeline accepts it „as before“ until analyses break.
• Weak master data: duplicates, outdated addresses, inconsistent product masters – and resulting misassignments.
• ETL/ELT without quality gates: ETL (Extract, Transform, Load) denotes the loading and transformation pipelines into a DWH. Without checks, faulty data is simply loaded along.
• Manual corrections: Excel fixes create shadow logic. The report looks „correct“ but is not reproducible.

The consequence is always similar: there is no reliable mechanism that detects deviations early and makes them traceable before they land in management reports.

Measurable in 30 days: what „better data quality“ concretely means

„Better“ must be measurable, otherwise it remains a feeling. For a 30-day plan it helps to agree on a few indicators that both IT and the business unit accept. Three levels have proven effective:

• Input quality: proportion of valid records at the source (e.g. orders with a complete delivery address).
• Pipeline quality: share of successfully validated load jobs without quality violations (e.g. no outliers, no unexpected null values).
• Report quality: number of report complaints, time to resolution, number of manual corrections.

Start with a small scope: two to three critical reports that are used regularly (e.g. revenue/contribution margin, delivery reliability, inventory metrics). For these reports define „critical fields“ and build checks exactly there. This prevents data quality from becoming an endless construction site.

Improve data quality with 5 check categories that work in any environment

The following check categories are chosen so they work independently of the BI tool in use. They can be implemented in the database, in the ETL pipeline, or as separate control jobs. The important factor is not the tool, but consistent application.

1) Completeness checks: required fields are truly populated

Completeness is the quickest lever because it is usually checkable without complex logic. Typical examples: customer ID, article number, posting date, cost center, status, currency. The practical pitfall: „Not NULL“ is not sufficient. A field can be technically populated but substantively empty (e.g. „0“, „–“, „unknown“).

Practical rules:

• Define 10–20 required fields per report that are truly relevant to the metrics.
• Distinguish hard (report must not be updated) and soft (report updates, but with a warning and a ticket).
• Track the rate: „X% of records meet all required fields“ – this is measurable within 30 days.

2) Validity checks: value ranges, format and business conventions

Validity means: a value is not only present but plausible within an allowed range. This can be technical (date in ISO format) or domain-specific (status is one of the allowed values). Interfaces often introduce new values „unexpectedly“. A validity check acts as an early warning system for such changes.

Examples of robust validity checks:

• Enumerations (value lists): status values, document types, posting types.
• Value ranges: quantities >= 0, discounts between 0 and 100, posting date not in the future (with a defined exception).
• Format rules: postal code length per country, IBAN format, e-mail rules (with tolerance so as not to block legitimate exceptions).

It is important to manage exceptions consciously: an overly strict check otherwise leads to workarounds („then we’ll just enter 999“). Therefore define an exception class with a documented reason and expiry date.

3) Consistency checks: the same thing is identical across all tables

Consistency is the most frequent cause of conflicting reports. Typical cases: an order is „completed“, but open line items still exist. A customer is „inactive“ but has new postings. An article is „blocked“ but is being allocated. Consistency checks verify relationships between fields and tables.

Practical consistency checks that deliver quick results:

• Status logic: a terminal status requires an end date; cancellation requires a cancellation reason.
• Referential integrity: every booking has a valid cost center; every line item has a valid product master. (Even if the database does not enforce foreign keys, the check can monitor it.)
• Sum reconciliation: sum of line items = document total (with tolerance for rounding).

These checks are particularly valuable because they make semantic breaks visible that would otherwise only surface in meetings. For IT operations and project management, consistency checks are a good indicator whether changes in the source system are „taking effect.“

4) Duplicate and identity checks: „A customer“ really is a customer

Duplicates almost always arise at process and system boundaries: new sales channels, portals, manual creation, migrations. The business experiences them as duplicated revenue, incorrect segmentation or unclear responsibility. IT usually only sees different keys.

Pragmatic entry without a Master-Data-Management large-scale project:

• Define one to two matching rules for the most important master domains (e.g., customer: name+postal code+street; supplier: VAT ID or IBAN).
• Introduce a „suspected duplicates“ report: not as automatic deletion, but as a worklist with an owner.
• Establish a takeover rule set: which data source is authoritative (System of Record) for address, payment terms, classification?

The measurable effect after 30 days is not „no more duplicates“, but: duplicates are found faster, responsible parties resolve them, and the most important reports are less distorted by double counting.

5) Outlier and drift checks: when figures behave „oddly“ before it escalates

Many data errors are not „NULL“ but gradual: an interface suddenly delivers 20% fewer records, a status is used differently, a location posts in the wrong currency. Drift checks look at trends and distributions. They are especially useful for operational metrics that run daily or weekly.

Mechanisms that are simple to implement:

• Volume check: record count per day/week within a corridor (e.g., minimum/maximum, moving average).
• Distribution check: the share of certain status values or categories remains within an expected range (e.g., „canceled“ does not suddenly increase tenfold).
• Latency check: time between the event in the source system and availability in the DWH/Report (important for day-to-day control).

For drift checks to be accepted, they need clear alert rules. Otherwise „alert fatigue“ develops: many warnings, little action. Therefore define which deviation is only logged and which one triggers a ticket.

The 30-day plan: how IT and the business implement checks without a mammoth project

The following four weeks represent a practical cadence. It fits both classic DWH/ETL setups and modern data platforms. The goal is not perfection but a functioning quality cycle.

Week 1: Establish focus – scope, data sources, ownership

Start with a joint meeting of IT and the business unit (60–90 minutes). The outcome is not a requirements specification but a work order with clear boundaries.

• Choose 2–3 reports that are business-critical and used regularly.
• Define data sources and the path to the report: source system → interface → staging/ODS → DWH → BI. (ODS stands for Operational Data Store, i.e. a staging area for operational data.)
• Name owners: for each report, a business owner (meaning/rules) and a technical owner (pipeline/operations).
• Measure baselines: current error rates, number of complaints, typical causes.

At this point, a short „data glossary“ is worthwhile: which metric refers to what, and which fields underpin it? That reduces later debates.

Week 2: Build checks – first completeness and validity

In week 2 the first automated checks are created. The goal is to get a quick signal without blocking day-to-day operations.

• Implement completeness checks for required fields of the selected reports.
• Add validity checks for status values, date ranges, basic formats.
• Define check results as events: ‚OK‘, ‚Warning‘, ‚Error‘. This classification is operationally more important than the technical detail text.

Important: store check results historically. Otherwise you cannot say after two weeks whether things are improving. A simple audit log per check (timestamp, affected source, number of violations) is sufficient to start.

Week 3: Consistency and drift – stabilize data flows rather than merely clean up

Now it’s about the causes that make reports „unstable“. Consistency checks reveal breaks between tables/systems; drift checks reveal gradual changes.

• Introduce 3–5 consistency checks that directly affect report metrics (e.g., sum reconciliation, status logic).
• Set up 1–2 drift checks per data source (volume and latency are usually the best starting points).
• Agree on a short weekly review (30 minutes): which violations recur? Which are ‚real‘ errors, and which are rule adjustments?

This is the point where collaboration pays off: many „data problems“ are process problems (e.g., status maintenance, required fields in sales). When the business unit is the owner, concrete measures arise instead of tickets without effect.

Week 4: Operationalize – escalation, tickets, approvals, reporting hygiene

Without operational anchoring, checks fade after the pilot. Week 4 brings routine and clear paths.

• Alert and ticket rules: which check class automatically generates a ticket? Who is the recipient? What reaction time is realistic?
• Release protection: when interfaces or data models change, a minimal set of checks is verified before production roll-out (quality gate).
• Data owner worklists: suspected duplicates, missing classifications, exceptions with expiry dates.
• Report hygiene: Remove manual correction paths or mark them clearly as “temporary”, with an expiration date and a responsible party.

At the end of the 30 days you should have a short result sheet: baseline vs. current state (error rates, complaints, time to resolution). That builds trust — and makes the next expansion plannable.

Where checks make the most technical sense: source, interface, DWH or BI?

A common question in projects is: “Where do we implement the checks?” The answer depends on impact and operations. Rule of thumb: check as early as possible, but as close to the report as necessary.

• In the source system: Ideal for mandatory fields and process rules (e.g., status logic). Advantage: errors do not occur in the first place. Disadvantage: changes require business unit approval and can affect processes.
• In the interface: Good for format and mapping checks. Advantage: protects downstream systems. Disadvantage: hard failures can cause data backlogs.
• In the DWH/staging: Good for consistency checks, reconciliation of totals, volume and drift checks. Advantage: central, well monitorable. Disadvantage: errors have already „arrived“ and must be treated retroactively.
• In the BI: More as a final safety layer (e.g., warning notices). Advantage: quickly visible to users. Disadvantage: too late to properly fix root causes.

For a 30-day start, DWH/staging is often the pragmatic place because IT has control there without intervening in operational processes. Medium to long term, it pays to move selected checks forward into the source system.

Data Governance light: roles that actually sustain data quality in day-to-day operations

“Data Governance” sounds like committees and policies. For rapid improvements, a lean model that clarifies responsibilities is sufficient. Three roles have proven effective in projects:

• Data Owner (business unit): Responsible for meaning, rules and exceptions. Decides whether a value is acceptable from a business perspective.
• Data Steward (operational): Processes task lists (e.g., duplicates, missing classifications) and ensures continuous maintenance.
• Technical Owner (IT): Operates checks, monitoring, interfaces and escalations; ensures traceability (logs, history, reproducibility).

It is important that escalations do not end up in limbo: if a check is repeatedly violated, you need either a process change, a UI adjustment in the business software, or an intentional rule change. “Ignoring” is not an option, otherwise the control system loses credibility.

Typical pitfalls — and how to avoid them

Too many checks at once

If teams define 100 rules but operate none of them consistently, nothing is gained. Start with a few checks that act directly on the selected reports. Expand only once operation is stable.

Checks without an action path

A check that only shows „red“ creates frustration. Every rule needs an owner, a processing form (ticket, worklist, process) and a decision whether the report is blocked or only warned.

„We clean up once“ instead of fixing root causes

A one-off cleanup can help improve baselines. It only becomes sustainable when the cause is addressed: mandatory fields, input masks, interface contracts, status logic, migrations. Otherwise the problem will return.

No traceability of data provenance

For recurring uncertainties a simple data-lineage view pays off: where does a field come from, which transformations occur, who last changed something? Data Lineage means exactly this chain of origin. It does not need to come as a large tool – often a maintained overview per report is sufficient.

How better data quality improves decisions – beyond „prettier dashboards“

The benefit is visible not only in fewer errors, but in faster, more reliable decisions:

• Less coordination overhead: Meetings focus again on actions instead of data sources.
• Faster root-cause analysis: Check histories show when an error began (e.g. after a release or an interface change).
• More stable planning: Forecasts and inventory decisions are less distorted by data artifacts.
• Less shadow IT: When official reports are reliable, the pressure to build ad-hoc Excel workarounds decreases.

Especially for IT leadership and project owners it is crucial: data quality is an operating-system-level issue. It connects architecture (data flows), operations (monitoring, tickets), processes (maintenance obligations) and modernization (interfaces, data models).

Conclusion: In 30 days from disputes over numbers to a controllable quality process

Improving data quality is less a matter of the tool than of discipline: clear terms, a few effective checks, historized metrics and an action path that works in daily operations. If you start with 2–3 critical reports, quickly automate completeness and validity and then add consistency and drift, you will achieve measurable stability in reports within a month – and a foundation to grow Data Governance without overhead.

If you want to assess which checks will produce the fastest effect in your system landscape and how they can be operationally anchored cleanly, you can discuss that in the next step in a structured way:

Improving reporting and master data quality are also important for this topic. The article places these aspects into context and shows what matters in day-to-day operations.

Discuss a project or modernization initiative with Net-Base.