A data audit sounds like a technical exercise. In practice, most of what it turns up is not technical at all. The dashboards are usually fine. The pipeline is usually fine. What is broken is that nobody has written down what the words mean.
The finding that comes up almost every time
Two teams report different revenue for the same month, and both are correct. Sales counts an order when it is confirmed. Finance counts it when the invoice is paid. Neither definition is wrong; they answer different questions. But because nobody ever wrote them down side by side, the monthly meeting becomes an argument about whose number is real instead of a discussion about what to do next.
Most “data quality problems” are definition problems that have been escalated to the engineering team because they arrived in a spreadsheet.
The fix is not a new tool. It is a one-page document listing each metric, its exact definition, its source, and the person who owns it. Getting three departments to sign that page is harder than any dashboard, and worth more than most of them.
What else an audit finds
- Silent truncation. A field that was sized for twenty characters receiving thirty. Nobody sees an error; the data is simply shorter than it should be, and has been for two years.
- Duplicate entities. The same customer existing three times because the name was entered slightly differently. Every per-customer metric is quietly wrong, and usually in the direction that flatters.
- Timezone drift. Timestamps stored in mixed zones. Daily figures near the boundary land in the wrong bucket, which matters enormously for anything reported daily and not at all for anything reported quarterly.
- Reports nobody reads. Frequently a third of scheduled reports have not been opened in months. They still consume compute, attention and maintenance.
- Manual steps presented as automation. A pipeline described as automated that has one person pasting a file in on Monday mornings. It works right up until they are unavailable.
How we run one
The order matters. Start with the questions the business actually asks, then work backwards to the data, rather than starting with the warehouse and looking for something interesting.
- Interview the readers, not the writers. Talk to the people who make decisions from the numbers. Ask which figure they check first, and which one they secretly do not believe.
- Trace three metrics end to end. Follow them from the interface where they were created to the report where they were consumed. Three is enough to surface every structural problem in the chain.
- Write the definitions down and get them agreed. This is the deliverable that keeps paying after the engagement ends.
- Fix validation at the point of entry. Cleaning data downstream is endless work. Preventing bad entries upstream is finite work.
What good looks like afterwards
The measurable outcome is not usually a prettier dashboard. It is that the monthly review starts with what to do rather than whether the numbers are right, and that reporting which used to take days of assembly now arrives on its own. When we rebuilt KPI reporting on exactly this method, accuracy improved by around a quarter and manual effort fell by about a third — and almost none of that came from clever code.