3 The Data Analysis Cycle

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 to be able to focus on a more detailed level. Each area has different elements and risks. For instance, one area may be dealing with cash or payments and another with access controls and authorities. The risk assessments discussed earlier need to be tailored specifically to the function under review.

The audit team should employ the requirements of the Statement on Auditing Standards No. 99 (SAS 99) from the American Institute of Certified Public Accountants. As all transactions contribute toward the financial statements, team members should participate in “an exchange of ideas or ‘brainstorming’ among the audit team members, including the auditor with final responsibility for the audit, about how and where they believe the entity’s financial statements might be susceptible to material misstatement due to fraud” as outlined in the AU 316.14 section of the professional standards.1 The brainstorming exercise combines the experiences and thoughts of team members to identify risk areas.

The collaboration will also assist with the third step of listing red flags and symptoms of possible fraud in the functional or business unit being audited. Once completed as discussed in “Recognizing Fraud” in Chapter 2, you can move on to the Software and Technology segment of the data analysis cycle.

Software and Technology

Utilizing the identified red flags or symptoms, various software and hardware tools can be deployed to source information and data. Analysis can then be done against the data and information obtained. If issues are identified, automated technology can be used to minimize or prevent future occurrences.

With a list of symptoms in hand, one can decide what data is needed to perform meaningful analysis to conform to the audit objectives. With data in hand, analytical software such as IDEA can do tests to target the selected areas. It should be noted that some general tests, such as Benford’s Law, highlight anomalies and can be used to compliment the specific testing.

The audit plan needs to be expanded to review and investigate suspicious items or anomalies. Most of the anomalies will be false positives that can be explained after additional investigation. Actual fraudulent transactions are normally few and far apart. If actual issues are determined, automated procedures and processes, such as continuous monitoring, can be implemented to immediately flag the issue to mitigate the risk of reoccurrence. Continuous monitoring can be both proactive and detective. This may come after the audit and investigative stage.

Audit and Investigative

No amount of technology can confirm a fraud. Technology can merely provide a starting point or identify potential transactions that may or may not indicate fraud. Technology reduces the amount of daily routine transactions to those that are high risk and require further review. Risk analysis is used to dictate whether further resources should be allocated to expand the audit or to investigate specific transactions. The audit trail must be followed and source documents should be reviewed. It may also be necessary to interview staff to obtain additional information, clarification, or reasoning behind the transaction. This may cycle back to the need for better understanding the business in more detail in the evaluation and analysis stage.

Once a fraudulent transaction is identified, technology may be able to assist in quantifying or for rooting out additional fraudulent transactions of the same type. The result of the audit or investigation determines additional procedures necessary to be implemented or included in the automated monitoring procedures.

The three stages of the cycle are ever evolving and continuous. They need to be proactive as new methods of fraud are constantly arising, especially with the rapid changes in technology. While technology may assist the auditor or investigator with new detection methods, technology also provides new tools for the fraudster to attack systems and perpetrate fraud. Where one area may be secured by various controls today, it may be compromised tomorrow. An auditor must include routine checks, like a night watchman on patrol who checks that doors are locked properly several times during the routine patrol. Have a plan but constantly adjust the plan accordingly!


In order to proceed with any data analytical tests, you have to be able to obtain data in a usable format that includes the record fields that you might need for your analysis. In addition to getting the data, the data must be scrubbed or cleansed to correct it from inherent errors to be useful. At times, even perfectly good data must be reorganized in order to perform certain calculations for tests.

Sometimes obtaining useful data requires high-tech knowledge and significant preplanning. For example, SAP,2 enterprise resource-planning software from SAP AG, has more than 70,000 tables—and each table has many fields. The Accounting Document Header table (BKPF) has more than 100 fields.

The information under the subhead Audit Objectives to the end of the subhead Documenting the Results has been extracted and slightly modified (to remove references to appendices not reproduced) from A Practical Guide to Obtaining Data for Auditors,3 published by CaseWare IDEA Inc. IDEA data analytical software is produced by CaseWare IDEA Inc. The author wrote the guide for CaseWare IDEA and the publisher granted permission to include these segments. The reproduced information is generic and can generally be applied in conjunction with other data analytical software.

IDEA licensees can access the full guide at http://ideasupport.caseware.com/media/viewpost.aspx?postid=1418.

Audit Objectives*

Data exists in various formats, maybe in a single file, possibly within a database, or perhaps even spread over a number of business systems that are not linked to one another. The audit objectives should be the determining factor of the data requirements.

For example, a routine financial audit using IDEA—whether it be to verify mechanical accuracy, valuation, existence, validity, completeness, cut-off, and analysis for other audit steps—may only require data from the accounting system. Files may include the general ledger, detail transactions, accounts payable, inventory, and sales.

For a fraud audit, in conjunction with the accounting system files, data both from access logs and from human resources may be needed. Computer or physical entry log date and times may be compared with accounting postings or authorizations. Personnel records of addresses may be matched to vendor records.

Additional electronic data may be required for forensic and other specific-purpose audits and reviews.

Determine Whether IDEA Is Appropriate

IDEA is most useful when there is a problem to solve on an audit or used for substantive testing. IDEA should always be used subject to consideration of data volume and the cost of obtaining the required electronic data.

Data analysis techniques are necessary where there is a large volume of transactions. The greater the number of records, the more valuable IDEA is. When the number of records is low, using IDEA may not provide much benefit over a manual audit.

Consideration must also be given to the costs incurred in obtaining the data. Costs may be direct monetary cost in using outside services or cost in time for both the auditors and IT specialists. There may be major costs involved in determining the files and fields needed, writing queries, processing, and transferring the resulting data from the host computer to the auditor’s computer or IDEA server. Time needs to be budgeted to examine the resulting files to ensure completeness and accuracy. Additional time may be required to investigate and correct data issues.

Data Requirements

Once the audit objectives have been well defined and it is determined that IDEA is the appropriate tool, the next step is to determine the data requirements. In order to do so, you must first identify the business or computer system, the business software used, and the files and fields needed to meet the audit objectives.

Hardware and Operating System

Identifying the computer system hardware and operating system will allow the auditor to determine whether IT support is needed. Computer hardware may be of entry level, business class, workstations and servers, mainframe, or supercomputers.

Operating systems include Windows, Mac OS, iOS, UNIX, Linux, and IBM OS.


Software can include off-the-shelf, add-ons, ERP, and custom-designed packages.


Though it may be simpler with off-the-shelf packages, you must still decide whether to obtain the raw data files and use your own copy of the package to convert the data to be readable by IDEA or to accept an export. The simplest types of export that most packages can handle are Microsoft Excel and print/pdf reports. Though there are disadvantages to both, no specialized skills are required.

For ERP and customized packages from large systems, IT support is required. At times, the expertise lies outside of the organization and third parties or consultants may be required.

Data Dictionary

For small packages, getting everything is simpler.

For large data packages, you need to determine which fields are relevant to the audit objectives. Files may be too large if everything is obtained. Also, many fields may not be relevant to the audit, such as budget, statistical, and nonfinancial fields. Consideration should also be given to the time and cost related to queries and processing.

Data Requirements