A user brought a situation to my attention. The Payables Historical Aged Trial Balance he ran at 12:09.05 PM was off by $6,000. When he ran the report again at 1:08 PM it was correct.

It looks like an invoice from Feb 2019, an invoice that is in history, was left off the report. With the invoice in history for over a year, it's not possible that someone made a change in between the report runs.

I recovered a backup using transaction log backups to bring a test instance to the exact time stamped on his report sample (12:09.05 PM). I ran the Payables Historical Aged Trial Balance report and got the correct result. For the user, it looks like a transient error caused GP to generate an incorrect result. I looked into the stored procedure behind the report and it is littered with "nolock" hints. It's well-documented that nolock can cause issues like this. I suggest that nolock be removed from all of the reports, and to avoid locking problems, use of SNAPSHOT ISOLATION be implemented. Based on GP's legacy design it would not be be wise to enable READ COMMITTED ISOLATION on the database for all of the activity. But enabling the database for SNAPSHOT ISOLATION and then configuring the reports to opt in to it would be safe to do and avoid the reporting errors that can occur with NOLOCK hints.