A common request: "our reports are wrong, or we do not trust them, can you fix the reporting." It is a reasonable thing to ask and almost always the wrong diagnosis. A report is not a source of information. It is a mirror held up to the data underneath it. When the reflection is wrong, the instinct is to polish the mirror. The problem is rarely the mirror.
A report is downstream of everything
A report does one thing: it reads data that already exists and arranges it. If the report says the wrong thing, there are only two possibilities. Either the report's logic is wrong, a genuine reporting bug, fixable in the report; or the data it read was wrong, and the report is faithfully showing you bad data. In our experience the second case is the overwhelming majority, and it cannot be fixed anywhere in the reporting layer, because the reporting layer is not where the problem is.
Where the problem actually is
Bad data is almost always an entry problem, and entry problems have recognisable shapes:
- Optional fields that should not be. A field that matters for reporting but is not required at entry will be left blank, and every blank is a hole the report either ignores or miscounts.
- Inconsistent values. The same thing entered five ways, free-typed instead of chosen from a list, so the report sees five things where there is one.
- Workarounds. A step skipped, a field repurposed to hold something it was not meant to hold, a status set by hand because the real process is too slow. Each workaround is correct data locally and noise in the report.
- Timing. Data entered late, or in batches, so that a report run at the wrong moment is simply incomplete rather than wrong.
None of these is a reporting fault. All of them surface as a reporting symptom.
Why fixing the report makes it worse
When the response to an input problem is to adjust the report, something quietly bad happens. The report gets logic added to compensate for the bad data: a filter to drop the blanks, a rule to merge the inconsistent values, an assumption to fill the gaps. The report now looks right. But the bad data is still there, the report has become more complex and more fragile, and the compensation is invisible. The next person to build a report from the same data does not inherit the fixes, and gets the wrong answer again. You have not solved the problem; you have hidden one copy of it.
The position, stated plainly
A report you do not trust is a useful thing, because it is a symptom pointing at a cause. The cause is almost always upstream, in how the data gets entered: what is required, what is constrained, what is worked around. Fix it there and every report built on that data gets better at once, including the ones nobody has written yet. Fix it in the report and you have polished one mirror while the thing it reflects stays broken.