Accuracy is one of those words that's easy to understand in a semantic sense (we all know what you mean when you say it) but harder to define across an array of discrete reports. The best thing you can do is to give some guidance on how your colleagues can check their work themselves.
In practice that might include something like a validation checklist, which can be as general or specific as suits the types of products they are creating. Something that helps me check my own work is to define, in advance, what a valid report will look like, and then check to make sure those elements are in place as I work. Depending on the specifics of your issue, this might be something you can help your direct reports put into place before they tackle a new project.
So, for a simple example, if I'm summarizing data by some grouping category A, at the start of my work I'll pull a basic count of elements that are in category A. Once I've actually done the summarizing, I'll count the number of entries to make sure that it matches the count from that first step.
In cases where the work is very complex I'll randomly pull entries from my report and then manually check them over, typically both re-compiling the output manually (to make sure my intermediate steps were executed correctly) and also applying smell-test checks (like making sure all values are valid).
The combination of thinking through what an accurate product would be, doing basic validity checks on output, and randomly spot-checking output has been very useful for me in helping save my boss from your situation.