note- 8.1

Risk Based Audit Approach Session 8.1

AUDITING IN EDP ENVIRONMENT

Session Overview

In this session we are not discussing features of the EDP systems such as components of computer system and types of computers etc. presuming that the participants must be aware of this, however, some questions for discussion has been incorporated in exercise 8.1.1. We will have a discussion on characteristics of EDP system followed by basic principles of auditing in an EDP environment and approach to audit of computerized accounts on audit risk consideration.

Learning Objectives

At the end of the session you will be able to understand the basic principles of auditing in EDP environment, Audit approach in EDP environment, CAATs.and one of the generalized audit software IDEA.

CHARACTERISTICS OF AN EDP ENVIRONMENT (Risk identification for the auditor)

An understanding of the major characteristics of an EDP environment, insofar as they differ from those of a manual system, is essential for the auditor as a tool for risk identification and for formulating his general approach and specific techniques for audit of such a system. The following paragraphs discuss the main characteristics of an EDP environment, which have a bearing on the work of the auditor and proper assessment of these

characteristics will help in proper planning and execution of audit.

Organisational Structure

In an EDP environment, the number of persons involved in the processing of information is significantly lower than that in a manual system. Therefore, many conventional controls based on segregation of duties may not exist or may be less effective. Moreover, certain data processing personnel, by virtue of their specialised knowledge, may be intimately connected with the input preparation, processing, and distribution and use of the output. Thus, they may be in a position to alter programs or data during processing or storage.

Absence of Input Documents

In a manual accounting system, a transaction is recorded on the basis of a supporting document, e.g. voucher, invoice, receipt, etc. However, such documentation may not always be available in the case of a computerised system, where some data may be entered directly into the system without supporting documents. For example, sale orders may be fed directly into an on-line system. Similarly, the computer itself without visible authorisation of individual transactions may perform discount and the interest calculations.

Lack of Visible Audit Trail

Note 8.1 RTI, JAIPUR

ote 3.2

1


Where a manual accounting system is in operation, the process of recording transactions generally follows a set pattern. Firstly, a basic document, i.e. voucher, invoice or receipt, etc. is prepared. This is the first recognition of a transaction having taken place. Then an entry is made in a prime book of account, i.e. journal or daybook Finally, a posting is made in the principal book, i.e. ledger. Thus, for each transaction, there is a visible ‘trail’, which the auditor can follow. However, under the computerised system, the above order is not strictly followed. In a computerised system, the auditor may often find that the audit trail is mostly in machine-readable form. Also, it may exist only for a limited period of time.

Lack of Visible Output

In many EDP systems, the results of processing may not be printed or may be printed in a summary form. The data may be retained on the files, which are readable, only by the computer.

Easy Access to Data and Programs

In a computerised system, data and programs may be easily accessed and altered at the computer or through the use of remote terminals. Therefore, unless appropriate controls are instituted, there is an increased potential for unauthorized access, to, and alteration of, data and programs.

Consistent Performance

EDP systems are normally more reliable than manual systems, inasmuch as they perform functions exactly as programmed. On the other hand, a faulty computer program may consistently process transactions or other data erroneously.

Programmed Controls

In a computerised system, many internal control procedures are incorporated in computer programs. These procedures can be designed to provide controls with limited visibility; for example, unauthorized access to data may be prevented by passwords. Many other control procedures can be manual in nature, such as review of reports printed for exception or error reporting, and reasonableness or limit checks of data.

Single Transaction Update of Data-base Computer Files

Under an EDP system, a single input to the system may automatically update all the records associated with the transaction. For example, a goods received note may update the purchase and supplier's accounts files as well as the inventory file. Thus, an erroneous entry in such an accounting system may create errors in various accounts.

Vulnerability of Data and Program Storage Media

Large volumes of data and the computer programs may be stored on portable or fixed storage media such


ote 3.2

2


as magnetic tapes, disks, etc. These media are vulnerable to theft, loss, or intentional or accidental destruction.

Use of Codes

Code numbers are extensively used to represent names and descriptions in a computerised system. The auditor has to familiarise himself with such codes. This may create some problems, especially in the initial stages. The auditor may face another difficulty due to the fact that narratives may be totally absent in the computerised records. Thus, it may become difficult for him to understand the various transactions.

COMPUTER FRAUDS

It should be recognised that while computers can process information with incredible efficiency, they are also very vulnerable to frauds. Computer frauds can be divided into five general categories as below.

1. Financial frauds, e.g. where fund transfers are made to the criminals personal account.

2. Property frauds, e.g. where false orders are placed on the computer for goods which are misappropriated.

3. Information theft including unauthorised access to data base records and computer programs.

4. Theft of services including unauthorised use of computer.

5. Vandalism of equipment and destruction of records.

Five principal facets of computer operations have been found in the USA to be particularly vulnerable to manipulation.

1. Data input, where false data is programmed into the system or the existing data removed.

2. Programming, where theft, destruction or full or partial modification is possible.

3. Central processing, where the system is exposed to wiretaps and interception of the data.

4. Output, where theft of confidential data occurs.

5. Communication of data to another computer or from computer to terminal. There is, therefore, a strong need for adequate controls in all these areas.

INTERNAL CONTROLS IN AN EDP ENVIRONMENT

Maintenance of information on computer channelises the various processes into well-controlled steps. Hence, the internal controls in such systems are well defined and formalised. In its essence, internal controls in an EDP system depend on the same principles as those in the case of manual systems. Thus, the plans of organisation, system of authorisation, distribution of duties,


ote 3.2

3


etc. are to be reviewed. However, there are many special controls applicable in the EDP environment.

Internal controls which are special to an EDP environment include both manual procedures and procedures designed into computer programs. These manual and computer control procedures can be classified into (a) general EDP controls and (b) EDP application controls.

General EDP Controls

The purpose of general EDP controls is to establish a framework of overall control over EDP activities. General EDP controls pertain to division of duties, controls over development and maintenance of software, controls over computer operations, error routine, controls over stationery, data entry and program controls, file controls, and security and standby arrangements.

In a manual system, internal control objectives are achieved, inter alia, through appropriate segregation of incompatible functions. As we have discussed earlier, some of the functions which are usually segregated in a manual system cannot be segregated in an EDP environment. This is because the number of persons involved in processing of information is significantly reduced in an EDP environment and also because the knowledge of functioning of the system may be limited only to a few persons. Nevertheless, while the exact organizational structure of the

EDP function differs from organization to organization depending on the nature and complexity of EDP system and the nature of applications, the following segregation of duties in a large EDP installation illustrates how this can be achieved.

Systems Analyst The systems analyst is responsible for the general design of new systems and modification of the existing systems in accordance with the specific needs of the enterprise.

Programmer The programmer writes and tests the programs based on the system design or modifications therein specified by the systems analyst. It is important that the programmer does not have access to input data or to computer operations since, by virtue of his understanding of the computer programs, he can easily manipulate the data.

Computer Operators The computer operators are responsible for processing the transactions through the system in accordance with the instructions set forth in the ‘program run instructions’ developed by the programmer. It is important that there are adequate controls to ensure that the computer operations are not in a position to modify computer programs; otherwise, they can manipulate the data (e.g., there may be programmed procedures to ensure that a program file cannot be altered without the use of a password).


ote 3.2

4


Librarian The librarian maintains custody of computer programs, transaction files, and other important computer records. The access to programs, transaction files, etc., is permitted only on the basis of proper authority.

EDP Internal Auditor The EDP internal auditor tests the effectiveness of all aspects of the EDP system. He monitors the re-processing of errors and compares input with output on a test basis to determine its reasonableness. Thus, he performs internal verification of the data.

Form the above, it can be seen that organizational controls involve segregation of incompatible functions and a system for independent verification of effectiveness of various aspects of the EDP system. The objective is to minimize the possibility of manipulation of programs and data. A clear-cut segregation of functions acquires special significance in view of the fact that EDP departments usually have a small number of employees; this increases the potential for manipulations in the absence of appropriate controls.

It is important that,the documentation should include the flow charts, program documentation (which should include a description of the purpose of each part of the program and the detailed

program), and program run instructions (which should specify the nature and format of input, the detailed operating instructions, possible errors, and the nature and format out output). The documentation of computer programs. makes it easier for new EDP personnel to familiarize themselves with the system.

For example, the program files may be made ‘read only’ to ensure that the computer operator cannot alter them. If a need for an alteration in a program arises. The documentation should show the reasons for alteration, the details of alteration, the results of test-run of the altered program, and the authorization of the systems analyst for putting the altered program in operation.

Apart from the simple control of use of locks on the doors to the computer rooms, the responsibility for handling program and data files should be entrusted to a librarian who should provide them only to authorized persons and maintain a record of issue of program and data files. Another effective access control (especially in the case of remote terminals) is the use of passwords. A password is a secret code, which is known only to the computer user. Unless the correct password is entered, the computer system does not function.

Some of the more common hardware controls are as follows.


ote 3.2

5


Diagnostic Check In most computer systems, every time the computer is started, it checks whether the various components and peripheral devices are functioning properly. In case any error condition is detected, a message appears on the computer screen.

Parity Check In a computer system, transfers of data between input-output devices (e.g., hard disk) and memory take place at high speeds. Sometimes, a malfunctioning of the computer system (arising from such causes as dirt, improper humidity level, etc.) may take place during such data transfers, thereby corrupting the data. Parity checking is a system, which helps, in timely detection of such errors in data. In computer language, every alphabet, numeral or symbol is denoted by a group of binary digits (often called ‘bits’) of ‘1’ and ‘0’. For example, in one of the popular binary code systems, the capital character ‘A’ is denoted by ‘1000001’ whereas the numeral ‘1’ is denoted by ‘0110001’. An extra or parity bit is added by the computer system automatically to bring the sum of the ‘1’ bits to an odd number (odd parity check) or an even number (even parity check). During the transfer of data, the computer checks whether the number of ‘1’ bits is odd (in case of odd parity) or even (in case of even parity). If not, this signifies that a bit has been lost during transfer, thereby corrupting the data. The computer usually makes another try t transfer the data correctly. If it tails, an error message is flashed. It may, however,

be noted that all computer systems do not use parity checking.

Dual Read and Read-after-write Data are read from an input source (e.g., a floppy disk) twice and the results of the two operations are compared to detect errors. Similarly, data written to storage media are read again to detect any errors in writing.

Echo Check In this case, when a terminal sends data to the central computer, data is transmitted back to the same terminal where it is compared with the original data held in memory to identify whether there has been any error during the transmission of data.

To retain them in such a manner that they can be. These procedures include the following.

(a) Backup and Recovery Procedures These procedures include off-site backup of programs and data (i.e. maintaining copies of programs and data at a place other than the one where the computer system is located), procedures for recovering the program and data files in case of international or accidental destruction, and provision for off-site processing in the event of a disaster/break-down in the system.

Many application programs have an in-built system of retaining two versions of a computer file at any point of time: the current


ote 3.2

6


version which incorporates the changes made during the latest computer processing, and the immediately preceding version, i.e., the version prior to making the latest changes. An enterprise may also establish procedures for retention of more than the last two versions in the case of critical data. Many computer installations maintain three generations of files to enable recreation of the files in the event of loss or destruction. This is known as the ‘son-father-grandfather’ technique. The current version is the son, the previous version is the father, and the previous version of the father is the grandfather. For example, if certain transactions are processed every week, the files retained at the end of the third week would include those for the first and the second week. This would ensure that a file could be reconstructed in case it is accidentally destroyed during processing. Thus, if during the 4th

week, the 3rd week’s file is destroyed; it can be easily reconstructed with the input documents of the 3rd week processed with the 2nd week’s file.

Error Routine

There should be proper procedures for identification and documentation of all errors, whether arising during inputting of data or during processing or as a result of malfunctioning of the computer

system. Similarly, there should be proper procedures for correction of such errors. The corrected data should be resubmitted only under the authority of a responsible officer. The auditor should also review the error corrections, since they provide a useful insight into the effectiveness of internal controls.

EDP application Controls

The general EDP controls discussed above influence the overall EDP environment and, therefore, have an effect on all or most EDP applications. Besides these controls, it is also important to design and operate appropriate controls over each EDP application.

It is obvious that if the data fed into the computer are unauthorized or incomplete or inaccurate, the output will also not be reliable. Some of the common controls over input are as follows.

Authorisation for Processing Input documents should contain authorization by appropriate personnel. For example, in a payroll application, each time card should be signed by the foreman or departmental supervisor before being fed into the computer. Authorisation of input documents can also be ensured by requiring that the slip accompanying the documents (generally called transmittal or route slip) sent to the EDP department should be signed by an authorized official In the case of on-line systems, it may not always be possible for transactions to be authorized before input. For example, orders from


ote 3.2

7


customers may be accepted on telephone and fed into the computer through remote terminals. In such cases, programmed controls are often instituted to compensate for the absence of pre-input authorization. For example, the computer system may be programmed to automatically check that the order is from a valid customer (i.e., there is a master file record of the customer) and within the authorized credit limit.

Batch Numbering The transmittal or route slips should be given a running serial number and should state the number of input documents. Whenever a batch of input documents is received by the EDP department, it should examine the continuity of the batch numbers to ensure that no batch is lost during transmission and also compare the number of accompanying input documents with the number mentioned on the transmittal or route slip. As far as possible, each type of input documents (e.g., sale invoices, copies of cash receipt memos) should also be given a separate running serial number.

Pre-processing Review Before data is fed into the computer, it should be reviewed for completeness and correctness, e.g., whether all the columns are filled in, whether data are in a proper format, etc. (In many cases, this function is performed by the concerned department before sending the input documents to the EDP department. The computer systems are also often so programmed as to verify the completeness of data fields, correctness of data format, etc., before accepting the data for processing.)

Batch Control Totals Batch control totals are used primarily for obtaining assurance about the completeness of the input. Three examples of batch controls totals are: record counts, financial batch totals and hash totals.

Record counts involve manual counting of number of records or transactions before they are fed into the computer; the result is compared with the number of records indicated by the computer after inputting. It may, however, be noted that a record count does not indicate whether the contents of the records have been accurately fed into the computer. Moreover, if a record is fed twice while another records omitted, the record count procedure will not detect this mistake.

Financial batch totals and hash totals involve manual calculation of the total value of a numeric data field in the records. After the data have been fed into the computer, the total for the relevant field is calculated by the computer. The two totals are then compared either manually or through the computer. If they tally, it can be assumed that all the data to be input have been fed as also that the data of the relevant numeric field have been fed correctly (except that compensating errors in different records can possibly exist). Financial batch totals represent totals of a numeric field, which is a part of accounting data, for example, the amount of sale invoices in a sales accounting application. Financial batch totals are sometimes impractical; for example, in a payroll application, the wages payable may not be known before the computer processing is complete.


ote 3.2

8


The hash totals, on the other hand, represent totals of those numeric fields, which are not part of accounting data, for example, invoice number in a sales accounting application, or employee number in a payroll application. Hash totals, therefore, have limited utility for the purpose of determining the accuracy of input.

Check Digit The use of check digit protects against the usual transposition or transcription errors, i.e., errors arising out of an accidental reversal of digits, etc. A check digit is a number calculated through an arithmetical operation on a particular field in the input data, for example, the account number of customer. After the check digit is calculated, it is appended to the number from which it is calculated. The number along with the check digit appended to it is then entered in the computer. The computer is programmed to calculate the check digit in the same manner in which it was calculated manually. If the check digit appended to the number does not tally with the check digit as calculated by the computer, an error message appears.

Edit Tests Examples of common edit tests are validity tests, format tests, completeness tests, and limit (or range) tests.

Validity Tests These involve comparison of the input data with a list of valid data which is already stored in the computer. For example, the employee number fed into the computer in a payroll application for a particular month can be compared with a computerized list of employee code numbers.

Data Format Tests these involve the checking of the contents of specific fields of input data to determine whether they are in prescribed format. For example, the data field for the value of sales in an invoice must contain only numbers and not alphabets.

Completeness Tests These involve checking that all data fields relevant in recording a transaction contain data, e.g., in a payroll application, checking whether the employee number, employee name, number of hours worked, etc., have been input or not.

Limit (or Range) Tests These involve checking a data field to determine whether the quantity or the amount therein is within defined limits. For example, where the maximum basic salary of a worker is Rs. 3,000, the computer program may be so designed as to eject the input data if the basic salary fed into the computer exceeds this limit. It may be noted, however, that incorrect data falling within the limits will not be detected by limit tests.

The following are some of the important processing controls.

1. File Labels For accuracy of processing, it is essential that correct master file, transaction files and program files are used. Experience suggests that in many cases, wrong files or older versions of correct files are used, resulting in erroneous output and wastage of time and effort. A method of ensuring that the correct program and data files are used for processing is the use of file


ote 3.2

9


labels. The file labels can be either external (e.g., a label affixed on a floppy disk) or internal (file description written in the computer file and readable by computer). It is important that file labels are sufficiently descriptive so that the computer operator can readily identify the correct files.

2. Run-to-run Controls In the case of those applications, which consist of more than one computer run, the control totals during each run are accumulated and agreed with input totals or with the totals held on computer file. This ensures that any data lost, added or changed during the intermediate processing runs are detected promptly.

Besides the above, controls similar to those which seek to ensure the accuracy and completeness of input can also be applied in respect of processing. For example, in an organization where different employees are paid house rent allowance ranging between 30%-35% depending upon the basic salary, there may be a limit test to judge whether the figure of house rent fed into the computer in respect of a particular employee is within this limit or not. At the processing stage also, a similar check can be applied by requiring the computer to check whether the total house rent allowance falls within the defined range of 30%-35% of the total basic salary of all employees. Besides this, the accuracy and completeness of

processing can also be assessed by reviewing the results of processing manually as also by re-performing some of the operations manually and cross-checking the results. For example, for a sample of employees, the figure of dearness allowance calculated by the computer can be crosschecked against the results derived manually.

Besides, the responsibility for distributing the output to the appropriate users should be clearly laid down.

1. AUDIT OF EDP-BASED ACCOUNTS

We have already discussed the main characteristics of an EDP environment that have a bearing on the work of an auditor. The various types of controls applicable in an EDP environment have also been discussed. Now, basic principles of auditing in an EDP environment, the approach to the audit of EDP-based accounts and some of the specific techniques of such audit will be dealt with.

Basic Principles of Auditing in an EDP Environment

The basic principles governing an audit in an EDP environment are similar to those in a manual environment. However, some of the auditing procedures to be applied for complying with these basic principles are specific to the EDP environment.


ote 3.2

10


It is a basic principle of auditing that an auditor should have adequate training, experience and competence in auditing. In the context of auditing in an EDP environment, this implies that the auditor should have sufficient understanding of computer hardware, software and processing systems to be able to plan the engagement and to understand how EDP affects the study and evaluation of internal control and the application of auditing procedures.

As in the case of any other audit engagement, the auditor can delegate work to assistants or use work performed by other auditors or experts while auditing in an EDP environment. However, he should have sufficient understanding of EDP to direct, supervise and review the work of assistants who have EDP skills or to obtain reasonable assurance that the work performed by other auditors or experts with EDP skills is adequate for his purpose.

In planning his audit, the auditor should gather sufficient & relevant information about the EDP environment, including the following:

- The manner in which the EDP function is organised.

- The computer hardware and software used by the entity.

- Significant computer applications, the nature of processing, and policies regarding retention of data.

- Plans regarding implementation of new applications or revisions to existing applications.

2. Audit Approach in an EDP Environment

The computerisation of an accounting system does not change the overall objective and scope of audit. However, the use of a computer results in changes in the processing and storage of information and affects the organisation and procedures employed by the entity to achieve adequate internal control. Accordingly, the procedures followed by the auditor in his study and evaluation of the accounting system and related internal controls and the nature, timing and extent of his other audit procedures may be affected by an EDP environment.

The special features of an EDP system make it necessary for the auditor to modify his compliance and substantive procedures for review of internal controls and examination of data. Due to the absence of audit trail and primary records, lack of visible output, and the use of accounting codes, etc. the auditor cannot carry out the traditional vouch-and-post audit of computerised records. He has to lay much more emphasis on the evaluation of internal control and on analytical review procedures and has also to change his verification programme in consonance with the manner in which the records are maintained.


ote 3.2

11


Computerised systems of accounting, however, also offer certain safeguards to the auditor. Firstly, if he is satisfied about the controls, the auditor can place a higher degree of reliance on the arithmetical accuracy of the accounts maintained he need not conduct a detailed verification of the arithmetical accuracy of the records. Further, computerisation automatically implies a constant review of the systems to increase their efficiency in producing reliable data. As a result, the internal controls are normally better designed under computerised systems. Automatic checks are instituted and the responsibilities of various people are clearly stated. Systems analysis and methods study are conducted periodically. Consequently, the movement of papers is smoother and speedier.

Computerisation of accounts, thus, presents special problems and opportunities for the auditor. Instituting special controls can mitigate the problems and the opportunities can be exploited by the auditor to make his audit programme more effective. As in the case of audit of accounts maintained manually, the audit of computerised accounts can be divided into two major phases:

1. Review of internal controls; and

2. Examination of records produced by the data processing system.

Review of Internal ControlsThe review of internal controls

acquires special significance in an EDP environment. This is due to the limitations on the auditor's examination of computerised records arising out of many factors, e.g. absence of audit trail, lack of visible output. Moreover, while well-defined internal controls ensure the arithmetical accuracy of records, weaknesses in the system may lead to frauds and errors.

The auditor's review of internal controls involves ascertaining the system, testing compliance through the performance of compliance procedures, and finally, making an evaluation of the system as a basis for ascertaining the degree of reliance which he can place on the system in determining the nature, timing and extent of his substantive procedures.

The auditor can obtain and document an understanding of the internal controls through the use of organisation charts, internal control questionnaires, inquiries, observation and flowcharts. He should gain an understanding of the general EDP controls and EDP application controls. It must be recognised that general EDP controls have pervasive effect on all facets of the system. Thus, if these controls are not effective, it is possible that material errors might occur and remain undetected. The auditor should review the various general EDP controls as well as the EDP application controls, i.e. controls over input, processing, output, etc.


ote 3.2

12


On the basis of his understanding of the system as above, it should be possible for the auditor to identify those controls on which he may wish to rely in conducting the audit. The next step for the auditor would be to perform the compliance procedures to determine whether the controls on which he intends to rely were functioning properly throughout the period of intended reliance. The objectives of performing compliance procedures in an EDP environment do not differ from those in a situation where accounts are maintained manually.

Compliance procedures are concerned primarily with the following questions:

Were the necessary procedures performed?

How were they performed?Who performed them?

The auditor can perform tests of compliance by obtaining documentary evidence regarding the application of internal controls; he can also make verbal enquiries or actually observe the functioning of the controls. For example, the auditor may scrutinise the rejection records to check whether rejections were promptly dealt with and whether a periodic review was made of the contents of the suspense file. Apart from examination of documentary evidence, enquiry and observation procedures, the auditor may also use computer assisted audit techniques in performing

compliance tests. These techniques are discussed briefly later in this note.

Compliance tests as above enable the auditor to determine whether the controls on which he intends to rely were functioning properly throughout the period of intended reliance. Based on his judgment, the auditor determines the nature, timing and extent of his substantive procedures.

Examination of Records Produced by Data Processing System Having determined the degree of his reliance on the internal control system, the next step for the auditor is to select and examine the records produced by the data processing system with a view to assessing their accuracy, validity and completeness. In doing so, the auditor has to deal with a problem peculiar to EDP systems, namely, lack of a complete and visible audit trail.

The audit trail refers to the links by which an original transaction can be traced forward to its final output or whereby each item of the output can be traced back to the source documents. The vouchers, journal, ledger, and other books of account provide the links in the audit trail. These are important for an auditor since he can trace the final impact of all transactions on the financial statements only through such links. As discussed earlier, in manual accounting, the audit trail is clear. The following chart shows the audit trail in the case of manual records.

Audit Trail under Manual Accounting

Documentation Prime Books Principal Financial(Voucher, invoice of Account Books Statements


ote 3.2

13


etc.) (Daybook, (ledgers, (balance sheet Journal, etc.) Etc.) & Profit and

Entry Posting Loss accounts Etc.)

First Chronological Classification OutputRecognition of Transaction Classification by Nature

The introduction of electronic data processors affects the audit trail. There are direct input devices, which eliminate the source documents. Similarly, the processing references may be missing, making it difficult to observe the sequence of records and transactions. Hence, the auditor has to find out sufficient printed records, listings, etc. to reconstruct and follow the sequence of transactions. In many cases, special printouts may be specifically required to reconstruct the audit trail. This may, however, require retention of data in a machine-readable form for long periods. Alternatively, the printouts required for audit purposes may be prepared when the data are processed initially.

The auditor may trace certain selected transactions from input documents to regular output statements or to error listings. The sampled items so traced provide evidence regarding the actual activities of the period. In this approach, the auditor does not make use of the computer in conducting audit

tests. He merely traces the transactions from the original documents to the statements and compilations produced on the computer.

Such an approach is useful in the case of computer systems, which perform relatively uncomplicated processing and produce detailed output. The auditor ensures that sufficient audit trail will be available to him so that he can conduct his tests in essentially the same manner as in the case of a traditional audit of manual accounting systems. This, however, may not always be the case. In many cases, it may be impracticable for the auditor to perform tests of details of transactions manually, and he may have to use what are commonly known as 'computer-assisted audit techniques'.

3. COMPUTER-ASSISTED AUDIT TECHNIQUES


ote 3.2

14


In an EDP environment, the auditor may perform his compliance procedures as well as tests of details of transactions with or without the help of the computer. Many people have labeled these approaches as 'auditing around the computer' and 'auditing through the computer'. Auditing around the computer has come to imply that the audit is conducted in the traditional manner by examining the computer printouts in the same way as the manual records are checked. Thus, the auditor more or less ignores the computer and verifies the computer output with reference to the source documents. Auditing through the computer implies that the auditor in performing his compliance and substantive procedures uses the computer. If the auditor has a reasonable expertise in electronic data processing, he can make use of the capacities of the computer to improve the effectiveness and efficiency of his audit procedures. Techniques that use the computer itself for audit purposes are known as 'computer-assisted audit techniques' (CAATs).

Uses of CAATs

According to IAG 16, computer-assisted audit techniques may be used in performing various auditing procedures, including the following:

Tests of details of transactions and balances; for example, the auditor may use audit software to test all (or a sample) of the transactions in a computer file.

Analytical review procedures; for example, audit software may be used to identify unusual fluctuations or items.

Compliance tests of EDP controls; for example, the auditor may use test data to test the functioning of a programmed procedure.

Considerations in the use of CAATs

In determining whether or not to use CAATs, the auditor should consider the following factors:

(A) Computer Knowledge, Expertise and Experience of the Auditor

In order to use CAATs, it is necessary that the auditor have sufficient knowledge to plan, execute and use the results of the particular CAAT adopted. The level of knowledge required of the auditor depends on the complexity and nature of the CAAT and of the entity's accounting system. Thus, the use of CAATs in certain circumstances may require significantly more computer knowledge and expertise than in others.

(B) Availability of CAATs and Suitable Computer Facilities

The auditor should consider the availability of CAATs, suitable computer facilities and the necessary computer-based accounting systems and files. The auditor should also ensure that cooperation of the entity's personnel in providing processing facilities and assistance would be available to him.


ote 3.2

15


(C) Timing Certain computer files, such as detailed transaction files, might be retained by the client only for a short time, and may not be available in machine-readable form when required by the auditor. Thus, the auditor can make arrangements for the retention of data required by him, or he may have to alter the timing of his work, which requires such data.

The application of CAATs can be particularly useful in cases where the time available to perform an audit is limited.

(D) Documentation

When an auditor uses CAATs, he should keep adequate working papers relating to the application of such techniques. The working papers should contain sufficient documentation to describe the CAAT application, such as:

Planning

Objectives of CAAT. Specific CAAT to be used. Controls to be exercised. Staffing, timing and cost.

Execution CAAT preparation and

testing procedures and controls.

Details of the tests performed by the CAAT.

Details of input, processing and output.

Relevant technical information about the entity's accounting system, such as computer file layouts.

Audit Evidence Output provided. Description of the audit work

performed on the output. Audit conclusions.

Other Recommendations to entity

management.

7 -Types of CAATsCAATs can be broadly divided into two distinct areas of operation: (A) CAATs used to directly validate the processes in programs, or (B) CAATs used to analyse data files.CAATs can be an independent area of specialization within IT audit, but that is not within the scope of the generalist IT auditor. In this session we will limit our discussions to a few CAATs under each of the two categories (A) and (B) mentioned above.A. CAATs used to validate processes in programsIn validating processes in programs, the questions that the auditor would generally ask include the following:

Is the data being processed correctly?

Are records being processed correctly?

Does a file become altered during processing?

Are the object code and source programs the same?

Is the program / system being misused?

Has the program been altered ?

Is data entry properly verified by the program?


ote 3.2

16


B. CAATs used to analyse data files

These are CAATs, which are primarily used on data files. Of course, results of data analysis can indirectly help the auditor to reach conclusions regarding the quality of programs. However, these CAATs do not directly test validity of programs unlike those discussed earlier.

(i) File interrogation software

File interrogation involves various tests performed on a data file such as to check control totals, duplicate entries, missing entries, abnormal transactions, select samples, etc.. The tests can be performed by using SQL statements, writing programs specific to the system being audited, or by using generalized audit software. There are two types of file interrogation software, Generalized and Industry specific interrogation software

(a) Generalized audit softwareAnalyses of data help the auditor to conclude on the quality of the data maintained by the application system. In turn, the quality of the data reflects the quality of the system processing the data. A variety of specific CAATs can be developed for analyzing data files. The problem is that external auditors must deal with systems having diverse characteristics: different hardware and software environments, different data structures, different record formats, and different processing functions. With resource constraints it is often not feasible to develop specific programs for every system that will extract, manipulate and report data required for audit purposes. For this reason generalized audit software has been

developed that is capable of handling a wide variety of different systems. With the development and marketing of generalised audit software like ACL and IDEA, the auditor has been provided with a powerful tool that can add tremendously to the auditor’s efficiency with minimum IT-skill requirement. Such software usually provide for a wide variety of functions for collecting and analyzing audit evidence, such as:

Totaling is used to prove completeness and reconciliation to the stated account;

Stratification gives the auditor a more complete picture of the ranges of values within the file, allowing a more educated approach to interrogations and quickly highlighting potential problems within the file;

Sampling enables the auditor to extract a representative selection of transactions from the file for audit testing;

Duplicate checks allows the identification of errors in payments or possible fraudulent activity;

Ageing shows a pattern of payments throughout a period. The period between receipt and payment of transactions can be monitored;

Gap detection highlights missing numbers in sequences. A useful tool in highlighting missing transactions or fraudulent activity;

Virtual field creation can be used to re-perform calculations to prove the accuracy of output data;

Data extraction based on auditor-specified parameters. This can help the auditor in a variety of ways such as identifying abnormal transactions, separating high value and key items while performing sampling procedures,


ote 3.2

17


retrieving records of fixed assets for physical verification, etc.

File comparison for a variety of purposes such as testing data consistency, detecting unauthorized and fraudulent transactions, missing values, etc.

Risk identification through IDEA

Can be used for testing data obtained from a wide variety of IT systems.

Can be used by auditors relatively unskilled in IT.

Can be used to test very large samples or even entire population very efficiently.

Provide a wide variety of functions in one place for auditing purposes.

Automatically documents the results of audit tests.

(b) Industry specific interrogation software

Some types of audit software packages are now available that are oriented toward a specific industry in which an auditor works. In a sense, the packages are still generalized audit software packages since they provide auditors with a high-level language that can be used to invoke a wide range of functions. However, they differ from the generalized audit software discussed earlier in two ways. First, since they are oriented toward a particular industry, they provide high-level commands that invoke common audit functions needed within the industry.

Brief History of IDEA

IDEA is an acronym for Interactive Data Extraction and Analysis, which makes it

evident that the focus of the software is on data extraction and analysis functions. The software was initially developed by the Office of the Auditor General of Canada in 1985 in Dbase III. The product has been upgraded many times and the software is now Windows compatible.

Import functions

One of the major challenges confronting an auditor in the use of computers in auditing is the challenge of plethora of database software and platforms in which the auditee applications run. Each database software has its unique way of saving data. This means that data saved in one database software cannot be used in many cases in another database software. The different types of computers like micro, mini, mid, mainframe computers and the different coding pattern ASCII and EBCDIC used in them compound the problem of using the data. So, the IDEA software provides a tool called import, which helps in importing files from different databases, spreadsheet software as well as data stored in other formats.

Some of the files that are commonly imported are Dbase and Access files, Lotus and Excel files, fixed length ASCII files and ASCII delimited files.

Data and Analysis functions

Some of the commonly used data and analysis functions are discussed below:

Checking for Duplicates:

There are certain fields that are unique and cannot have duplicates. For example in a file containing the permanent details of employees, the employee


ote 3.2

18


identification code should be unique, i.e., there cannot be 2 employees with the same identification code. The ‘Duplicate key detection’ function in the software identifies such records that have duplicate entries of a unique field.

Gap Detection:

There are instances in which certain fields are assigned continuous numbers. For example, the file containing invoices should have a continuous number for the invoices. If any invoice numbers are missing it might be because some sales transaction have not been accounted for. The ‘Gap detection’ function helps in finding if there are gaps in numbering within a given range.

Indexing:

Records in a file are stored in the order in which they are fed in the computer. However, the user might like to view the records in a different sequence. This requirement is taken care of by using the “Indices” function in the software. Let us assume that a file contains details of the office employees who have performed air journey in connection with official work. We could view the records in the file according to the date of journey, then the airlines and finally according to the purpose of journey. The records could also be rearranged according to the destination of travel by using the ‘indices’ function.

Key Field Summarization:

There will be instances in which number of records relates to a particular category. For example in the “Travels” file discussed above, number of employees might have used the same airlines or traveled on a particular date.

So, the records can be grouped according to “AIRLINES” or “TRAVELDATE” to get a consolidated picture. This can be achieved by using the “Key field summarization” function

Field Statistics:

For numeric fields, statistical details like minimum value, maximum value, average value, number of positive, negative and zero value items, standard deviation etc., might provide meaningful insight into the data. This can be found out by using the “Field Statistics” function

Numeric Stratification :

When the number of records falling within different range of values is to be ascertained, then numeric stratification function can be used. For example, continuing the example of air travel, if we wish to ascertain the number of instances in which the airfare is less than Rs.500, instances in which airfare is between Rs.501-Rs.1000, between Rs.1001 and Rs.2000 etc., then numeric stratification function will be helpful. The stratification will not only indicate the number of records within each stratum, but also indicate the aggregate value of the stratified field for each stratum. In this instance, the software might indicate that number of employees who performed travel where the airfare is less than Rs.500 as 43 and the total airfare of all such travels put together as Rs.8622.35.

Field Manipulation:

There will be many instances when applying some formulae on the existing data new information could be


ote 3.2

19


generated. This is possible with the help of “Data Manipulation” function. For example, a file contains details of the employees including their basic salary. Let us assume that allowances are computed as a percentage of the basic salary (60%) and you wish to calculate the allowances. Select the “Field Manipulation” function and type the formulae SALARY * 0.6 against the new field to be created. The software will automatically create a new field with this formula.

Record Extraction:

The database files might contain hundreds or thousands of records and the auditor will not be interested in seeing all the records. He might like to focus on records that satisfy certain condition (s) by using the record extraction function. For example continuing the air travel example, we might be interested in seeing records where the airfare is more than Rs.1000 and the purpose of travel is “Attend Meeting”.

Linking Files:

With the Relational Database Management concept becoming very popular, data is not stored in a single table or file. It is stored in different files by creating a link or setting relationship between various files. So when such files are imported into IDEA, the required details might not be available from a single file and linking related files will be necessary. This is achieved by linking files.

For example, the sales file might contain the ACCOUNT_NO of the customers and the master data file of customers might contain the name of

the customers and their credit limit. The auditor will have to link these two files to find out the credit limit for customers and see whether credit sales have been made to customers in excess of the credit limit.

Sampling functions

The three common sampling methods that can be performed with the software are as follows:

Random Sample:

Random sample is a sampling method in which it is decided to select certain number of records out of the total population for detailed test. Once the number of items to be tested is selected, then the computer randomly selects these records and writes them into a random sample file. For example, let us assume that out of the 200 records in a file you wish to select 20 records. With random sample function the software will automatically select randomly 20 records

Systematic Sample:

Systematic sample is a process in which the first record is selected randomly and adding the sampling interval identifies subsequent records. For example in a file containing 200 records, if we assume that 20 records are to be chosen, then the sampling interval will be 200/20 = 10. So, the first record has to be chosen within the first ten records and adding 10 to the number of the first record choose the subsequent records. For example if the first record is 5, then the software will automatically select 20 records and the record number of the first record will be 5, the second –15, third- 25 and so on.


ote 3.2

20


Stratified Random Sample:

Instead of selecting a percentage of the total records, it is desirable to create different stratum and apply different percentage of selection for different stratum according to the value of the stratum. For example, in the air travel file different stratum may be created according to the airfare. The auditor might then decide to choose 1% of the record in the stratum “0-500”, and 100% of records in the stratum “20000-50000”. This is possible by using the stratified random sample function.

Miscellaneous functions

Some commonly used miscellaneous functions are discussed below:

Select Control Amount:

This function helps in finding out the total of some numeric field for the entire file. For example, in the air travel file you might want to choose airfare as the control amount. In this case the sum total of airfare for all the records will be displayed.

View History:

One of the major advantages of the IDEA software is the automatic documentation prepared by the software. This can be viewed on the screen or

printed with the help of “View History” function.

SummaryIt will be observed from the above discussion that approach and techniques to be followed by an auditor in auditing EDP based information (e.g. accounts processed on computers) are in certain respects different from those to be followed in manual environment requiring more skills and knowledge. Audit risks are a fact, following necessary preventing methods must be adopted to estimate and control risks effectively:

Reforming audit techniques and methodology,

Improving preliminary and follow up audit on IT System,

Strengthening audit on internal controls and urging audited entities to establish and improve the internal control system in IT Environment,

Enhancing the training of auditors; and

Speeding up the development of audit specific software.

Better understanding of CAATs and use of IDEA software for data, analysis and sampling


ote 3.2

21