10 Implementation
10.1 Architecture of continuous auditing
Continuous auditing requires an information technology structure for data processing and storage. Additionally, a type of analytic monitoring methodology to support continuous assurance (Brown et al., 2007). There are two types of the architectural structure of continuous auditing: internal within organizational systems and external of the organizational systems.
• Internal of the system (EAM)
Embedded audit modules (EAM) are developed and implemented within the organizational system. Groomer and Murthy (1989) introduced the EAM approach. Firstly, EAM is embedded within the application walls using the programming language of the application (Kuhn & Sutton, 2010). The application which EAM is implemented within is also known as an enterprise resource planning (ERP). Which are highly complex information systems designed for an overview of the organization including all functions and departments and a database where all business transactions are entered, recorded, processed, and monitored (Umble et al., 2003).
Secondly, EAM evaluates transactions against pre- programmed audit criteria, due to the fact that these occur in the ERP system. Thirdly, EAM is able to report violations of transactions to pre-programmed audit criteria, due to continuous monitoring of transactions. Finally, the storage of the violations also called alarms (Kuhn & Sutton, 2010). Nevertheless, the EAM approach is rarely used in practice (Alles et al., 2008). To protect the organizational ERP systems from excessive interference from auditors. To visualize the EAM procedure, refer to figure 7.
Figure 7 Embedded audit module, within ERP
ERP System •Storage of alarms EAM Evaluate
•Evaluate against pre- programmed audit criteria
EAM Report
•Reporting of violations, of pre- programmed audit criteria
EAM Storage
• External of the system (EAM Ghosting, Audit Data Warehouse, & MCL)
An external variant of EAM is EAM ghosting. EAM ghosting is a variant which benefits from the advantages of an EAM, yet is implemented outside the ERP system of an organization (Kuhn & Sutton, 2010). Ghosting entails operating in a ‘copy’ of the ERP system, in a real-time fashion. An advantage of EAM ghosting is that the organizational ERP systems are protected from excessive interference from auditors on the organizational ERP systems.
Furthermore, an external continuous auditing architecture is an audit data warehouse. Rezaee et al. (2002) described this architecture as an optimal continuous auditing model because it combines the power of the client architecture and data will be delivered to audit workstations. The distinction with EAM ghosting is that an ERP system is not a necessary condition for an audit data warehouse (Rezaee et al., 2002). First, data is extracted from organizational corporate systems. Second, the extracted data is conversed, in standardized data. Chan and Vasarhelyi (2011), point out that extracted data should be standardized to conduct continuous auditing. Data standardization requires the development of data standards, for storing in the audit data warehouse (Rezaee et al., 2002). Third, standardized audit procedures and audit standards are stored in the audit data warehouse, to conduct continuous auditing. Furthermore, the audit data in the warehouse can be transformed into audit data marts. Data marts provide efficient sources of audit evidence for further analysis, for specific departments. Finally, the end-users are conducting tests and reports of the data on the audit workstations. In order to provide an overview of the architecture of an audit data warehouse, refer to figure 8.
Moreover, an external continuous auditing architecture is a management control layer (MCL). A MCL is an external architecture that operates independently of the organizational ERP systems to be monitored but is linked into the system and/or its underlying database to provide a similar level of monitoring (Kuhn & Sutton, 2010; Vasarhelyi et al., 2004). The management control layer is subdivided in: data provisioning, filtering layer, relational storage, measurement-standards layer, inference engine, analytic layer, alarms and alerting layer, and reporting layer. Essentially, the continuous auditing systems are implemented external of the organizational ERP system (Kuhn & Sutton, 2010). The management control layer is similar to the audit data warehouse, while the difference is that MCL is built outside, upon an organizational ERP system. Additionally, the MCL is characterized by its exception-detection capability, which is provided by the inference, analytic, alarms and alerting layers (Vasarhelyi et al., 2004). In order to provide an overview of the architecture of MCL, refer to figure 9.
In order to provide an overview of the several forms of architectures of continuous auditing, refer to table 2. Which is developed based on several characteristics which are described per architecture. Importantly to note, organizations are able to develop their own architecture, which supports their individual goals and desires (Kuhn & Sutton, 2010). For example, a hybrid approach, both internal and external, or some new architecture that has yet to evolve.
Intern Extern
Characteristic EAM EAM
Ghosting
MCL Audit Data
Warehouse Pre-programmed audit
procedures
Yes Yes Yes Yes
Location of audit procedures Inside organizational system (ERP) External hardware & software External hardware & software External hardware & software Location of data and
alarms Inside organizational system (ERP) External database External database External database
Continuous monitoring Yes Yes No No
ERP Build within Interlinked Interlinked No
Table 2 Overview architecture continuous auditing
Furthermore, these continuous auditing architectures and systems, or in other words continuous auditing environment, should be highly reliable for the auditor. Woodroof and Searcy (2001) describe the four principles of a highly reliable continuous auditing environment as integrity, security, availability, and maintainability. Moreover, the continuous auditing environment must be secured, which is characterized by authorization, confidentiality, integrity, and authentication (Woodroof & Searcy, 2001). The reliability and security of the continuous auditing environment are somewhat of an overlap, due to the fact these requirements serve the same objective, which is to provide assurance of the continuous auditing environment. Therefore, it is important for auditors to develop a continuous auditing architecture which meets these requirements.