Choose a decision with a clear owner
Start with something the team can name: a weekly workload decision, a stock review or a report used to decide where to investigate a problem. Identify who uses it, when they use it and what action follows. A folder full of spreadsheets is too broad a starting point for a focused audit.
Write the consequence of an error. A wrong category might distort a summary; an incorrect recipient might send information to the wrong person. The effort spent checking a field should reflect how it is used, rather than how prominent it looks in a spreadsheet.
Follow the information back to its source
List the source, the person or system that supplies it, the transformations applied and the final place where it is read. Include manual copying, lookup rules, merged files and filters. Keep the original unchanged while investigating.
An illustrative chain might be: incoming request, shared register, manually maintained category, weekly report. If nobody can explain what an empty category means, that uncertainty belongs in the audit. It should not disappear when the chart turns the missing values into an attractive bar.
Check different kinds of quality separately
The UK Government Data Quality Framework distinguishes completeness, uniqueness, consistency, timeliness, validity and accuracy. These provide useful prompts for an audit; satisfying one does not establish the others.
For your selected decision, translate the prompts into concrete checks. Are required fields present? Are duplicate records counting the same event twice? Do dates agree across files? Is the information recent enough for the intended action? Does a plausible-looking value match its source? Limit this first pass to checks that matter to the chosen decision.
Keep an issue log with consequences
An issue log connects a finding to its effect and proposed response. Keep uncertainties separate from confirmed errors. The example below is fictional.
Scroll the table sideways to see all columns.
| Finding | Possible effect | Next check |
|---|---|---|
| Same request recorded twice | Workload could be overstated | Compare source identifiers |
| Several dates are missing | Ageing report may omit open work | Check what an empty date means |
| Category rules differ by team | Group totals may not be comparable | Agree a shared definition |
Correct the rule before the rows
If a form allows an ambiguous date, cleaning today’s file will not stop tomorrow’s ambiguity. Decide the accepted format, the meaning of an empty value and who is responsible for resolving an exception. Document changes so that the next report can be interpreted correctly.
Review a small sample of corrections against the original source before applying a wider change. Retain the information needed to explain what changed, and avoid silently replacing an unknown value with a guess. A clean-looking data set can still be unreliable.
Close with a usable audit record
Write down what was checked, the sample or coverage, the confirmed findings, the unresolved questions and the changes made. Say which decisions the data can support and where a limitation remains. The result should help another person use the information appropriately.
If the audit exposes a disagreement about what a number means, define it before building another report. The business metric definition sheet provides a next step. Revisit the checks when the source, collection process or decision changes.
Sources & further reading
Published by Naltyx. Examples are illustrative; any Naltyx product mentioned is our own. How we write.