Key takeaway
A data quality score is useful only when the team understands what was tested, how failures affect the decision, and who owns the response.
Reporting trust breaks on specific questions: which records are missing, why a total changed, or whether departments mean the same thing by active. A single quality percentage cannot answer all three. A better starting point is a small register of checks tied to reporting decisions. Each check needs a definition, an owner, and an agreed response when it fails.
Choose checks with a clear operating consequence
Completeness asks whether required information is present. Uniqueness asks whether an intended identifier repeats. Validity asks whether a value follows an approved format or allowed set. Relationship checks find records that cannot be matched to their required parent or reporting category.
Freshness and reconciliation answer different questions: whether the expected business period has arrived, and whether source and published totals agree. Choose checks that expose meaningful failures. A missing optional field should not carry the same weight as an unmatched identifier that removes a record from leadership reporting.
Write a quality register, not just a score
| Check | Expected result | Response |
|---|---|---|
| CaseID uniqueness | No duplicate case keys | Block affected batch; investigate |
| Team relationship | Every case maps or is explicitly unassigned | Route unmatched records to owner |
| Reporting period | Required cutoff is represented | Show stale-data notice; escalate |
| Reconciliation | Agreed totals match | Explain discrepancy before release |
Add the owner, test location, last result, affected record count, and resolution evidence. Approve thresholds for the actual use case. A convenient percentage is not a universal definition of acceptable data.
Profile the data before assuming its shape
Review values, nulls, distributions, and identifier patterns before committing to transformations. Microsoft's Power Query profiling documentation describes column quality, distribution, and profile tools. It notes that profiling uses the first 1,000 rows by default unless changed to the entire dataset.
A clean sample can miss problems in older records or rare categories. Decide what sample or full-data coverage is appropriate, record the choice, and do not present a sample check as proof that every record passed.
Keep failed records explainable
Separate invalid records from approved output without losing why they failed. Preserve a stable identifier, rule name, source reference, and processing version in the exception record. Limit access to detail according to the environment's requirements.
Do not replace an invalid date with today's date or silently merge duplicate people to make a test pass. Some rules belong in ingestion or transformation; others can be enforced through database constraints. Business meaning still needs an owner to resolve the exception.
Make quality part of the release decision
Show which checks ran, their scope, affected record counts, unresolved exceptions, and the decision about whether reporting may proceed. Keep approved exceptions separate from uninvestigated failures. Acceptance should be repeatable rather than a message that the data looks fine.
Re-run relevant checks after source or model changes. AVIZ DATA's Data Governance & KPI Architecture and migration services can help define a scoped register. The refresh guide connects those checks to the operating cadence.
Project checklist
- Rules tied to specific business consequences
- Owners and thresholds approved
- Sample versus full-data coverage recorded
- Exceptions preserved with clear reasons
- Release decision supported by check evidence
References
AI-assisted guide checked against the linked platform documentation. Examples are illustrative and are not client results. Platform capabilities can change; confirm the requirements for your environment.