Not sure it will help, but it might point you at a cause / diagnosis, this is where I would start:
I would run SQL Profiler to see what SQL commands SSRS is issuing. That will also show you the CPU time, number or reads/writes etc and Row Count. You could compare that with the results you see on TEST to see if they are wildly different, for example.
You could also take a snippet of SQL [i.e. the actual SQL that SSRS sends to SQL] and run that on the PRODUCTION server in order to view the Query Plan etc. That might lead you to an index missing (although that won't ... SHOULDN'T??!! ... effect Data Quality), or some dynamic SQL which SSRS is generating differently on Production than it did on Test (and that could well deliver different results).
If you have the least suspicion that the Production Database might be corrupted, particularly if your database housekeeping doesn't routinely include regular data consistency checks, run a DBCC CHECKDB with ALL the options turned on (e.g. including DATA_PURITY(sp??) )