databases. This is quite normal. Database anomalies could be the result of missing or unmatched information caused by human error and flaws and limitations in the database. Bugs in the database can occur whenever a record is entered, modified, or deleted.
Insertion anomalies occur when data is being entered into the database. One form of this anomaly is where the information cannot be entered until additional information from another source is entered. A new employee’s shift scheduling cannot be entered until the employee has a payroll number. The payroll number may not be assigned immediately as the new employee’s first pay will not occur until two weeks from starting employment.
Data must be entered in a format that is consistent. The most common insertion errors are missing or incorrectly formatted entries. Well-designed software should have error-checking capabilities that provide an error message and prevent recording of the record if there is a blank entry where data is expected. Error checking or validation should also prevent an entry that does not fall within an acceptable range. For instance, the program would not accept a number outside of 01 to 12 where the field is a numeric month field. It may not accept a single digit for a month if the validation was designed to require a leading zero where the month normally would be a single digit. This helps to reduce errors where the operator meant to enter 12 but entered a 1 instead.
Deletion anomalies occur when the last record for a particular group of information is deleted. Removing that record may remove relevant information associated with the record. The deletion of information or facts about one entity automatically deletes other facts regarding that entity.
Let’s say an employee has left to work for another employer. The former employee shift schedule information is deleted but the associated address information might also be contained in that last record for the employee. Where would the employer send the employee’s last paycheck or accumulated vacation pay?
Modification or update anomalies are where incorrect information needs to be changed that may require many other record changes. This leads to the possibility that some items may be updated incorrectly.
When we analyze data for anomalies for fraud items, we are not interested in insertion, deletion, or modification anomalies caused by the business systems (other than to note poor system designs that lead to internal control problems). What we are interested in are unexpected or strange items, such as outliers or too many inliers. We target suspicious transactions or transactions that are too typical to be natural. We look at the unusual in relationship to the usual.
Anomalies in datasets will be common. Most will be errors and very few, if any, may pertain to fraud. It is unlikely that any fraud can be proven solely based on analyzing data. Analyzing data to identify anomalies or patterns gives the auditor or investigator a starting point of where to do further analyses. One must follow the audit trail to review source documents and supporting factors that lead to the records to review.
It is important to employ professional skepticism at this point by:
• Critically assessing the anomalies without making a conclusion.
• Having no biases caused by being overly suspicious or cynical.
• Not accepting evidence or information gathered at face value.
• Ensuring that all evidence or information is complete.
• Pursuing the facts through the critical review of documents associated with the data anomaly.
• Assessing whether information provided by staff lacks objectivity or there is lack of knowledge.
What is the anomaly for the numbers 1987 and 2013? It took 26 years to pass before the year contained all four different digits again. This anomaly is neither an error nor fraud, but rather just an observation.
Many staff members have access to business systems as part of their duties to update, create, delete, and modify transaction records. Some employees, such as managers, owners, and shareholders, may have additional or higher access rights. Without the proper controls these accesses are vulnerable to errors and potential fraud.
The modification or substitution recording of the proper transaction can be classified as a fraudulent inclusion. Falling under a fraudulent deletion can be failing to record the transaction when it should be entered.
Concealing theft of inventory can be done by altering inventory records to match the physical count. Alternatively, if the fraudster is involved in the physical count, changing the count numbers to match the perpetual inventory records would also conceal the shrinkage. Reclassifying the missing inventory as obsolete would accomplish the same results. More sophisticated fraudsters may create a sale of the inventory to an old existing account that may be due for write-off.
Recharacterizing expenses as capital expenditures increases net income that may constitute financial statement fraud. One of the simplest ways to show higher income is to just omit the recording of liabilities and expenses until another period. While it is easy for management to do, it is hard for the auditors to detect as it leaves no audit trail. Improper recording can be examined but it is far more difficult to look for something that should exist but does not.
True deletion of electronic records is akin to the shredding of paper documents. Most business systems do not allow deletion without it being logged in the audit-trail file. Some systems record a deletion as a reversal of a previous transaction, therefore maintaining the integrity of the system. An excellent example of transaction deletions are “zappers and phantom-ware facilitate the systematic skimming of cash receipts by deleting records of cash sales, re-numbering receipts to disguise the deletion, and the production of conforming financial reports. In some cases, these programs can be so thorough that they reach out beyond the ECR and the sale system itself to bring inventory and employee time records into line with the deletions.”18
Fraud occurs in any organization as it is not possible to invoke the level of control needed to eliminate fraud. If there are too many restrictions or controls in place, those restrictions prevent employees from doing their jobs properly.
As auditors or investigators, we can only test for red flags of fraud. Data analytical software can assist us in sifting through all the transactions to flag anomalies. Being able to recognize fraud may allow us to further refine our tests to reduce the number of anomalies to investigate.
Before we can perform data analytics, we must understand the data analysis cycle and know how to obtain the electronic data files for our audit or analysis. We must ensure that the data is usable, complete, and accurate.
CHAPTER 3
The Data Analysis Cycle
THE DATA ANALYSIS CYCLE is a three-stage cycle that is constantly changing, and which must be adjusted to in order to be effective. The stages are evaluation and analysis, software and technology, and the audit and investigation stage.
To start the cycle one must understand the whole business well and, specifically, the subsidiary, division, or business unit being reviewed. A good understanding of the industry in general, along with the business environment, will give you a baseline for comparison purposes.
This cycle includes evaluating areas of potential fraud and identifying symptoms or red flags for frauds. This knowledge allows you to tailor your evaluation strategies to the organization. You cannot apply all the same steps and procedures universally to every business, as business practices in different industries, as well as within the same industries, differ greatly.
With this knowledge, the next step is to identify weaknesses or areas where potential fraud may exist within the business systems. It would be impossible to perform this task on the business organization as a whole. You need to break down the organization to at least the business-unit level