I’ve assisted companies with finding this information for two reasons. Either they haven’t previously required strict audit controls or someone suspects fraud. I explained the first circumstances in my article on ERPsoftwareblog entitled, “Oregon Companies Improve Audit Ability of Microsoft Dynamics GP.” However, the fraud cases are what drew my attention to this functionality in the first place.
I explained the fraud cases in the Case study: It’s Not Brain Surgery, “Don’t Let the Fox in the Henhouse” of Rapid Implementation. A bookkeeper for neurosurgeons had kept two sets of books. The ones she used to create financial statements had countless subsidiary ledger transactions re-created as manual General Ledger transactions. While she was meticulous in the fake company, the district attorney caught her when I pointed out what to look for in an extract of transactions.
Determining Whether an Entry is from a Subledger or has been Created in the General Ledger.
Let’s start in a subledger at SOP Transaction Entry
When that entry is posted in the Sales series, but stopped at the General Ledger, we can see the fields that can be edited at this point, i.e., darn near everything – I marked the editable fields below in yellow.
Now here’s a screen shot of my best effort at emulating that same entry. I stopped at just a few lines for the example. The first three distributions look the same here as the real subledger distribution entry, right?
Even via the standard posting journal, you still can’t see a difference. Remember I edited just the first 3 lines for this example.
It’s not until you use either SmartList or MS-SQL to view ALL fields for the entry that you see the distinguishing characteristics of a subledger distribution posted to the General Ledger versus a General Ledger entry made to look like a subledger transaction. The General ledger entry has no access to various “Originating” fields of information. I highlighted the entries in this graphic; yellow is the subledger entry, pink is the fake General Ledger entry. Originating fields can only be populated by the Subledgers.
- Originating field could be edited in SQL, but that requires access to and knowledge of the SQL Enterprise Manager AND an adept, detail-oriented fraudster
- In addition, when someone attempts to zoom to a subledger entry from the General Ledger, they receive the warning message, “Unable to zoom. The Transaction originated in General Ledger.”
So if your auditors are looking for proof you haven’t fudged by substituting manual general ledger entries for deleted subsidiary ledger entries, you can produce a SmartList report. Of course, if you have fudged for good reasons, document what happened.
If you fudged for the wrong reasons, head for the hills. We can catch you.