OVERVIEW
Objective
¾
To explain the use of computer-assisted audit techniques (CAATs) in the context of an audit.CAATs
AUDIT SOFTWARE TEST DATA
AUDIT APPROACH
¾ Possible use
¾ Considerations
¾ Advantages
¾ Difficulties
¾ Description
¾ Uses
¾ Precautions
¾ Description
¾ Uses
¾ Precautions
¾ “Black box”
¾ “Systems-based”
1
AUDIT APPROACHES
1.1 Around (“black-box”
approach)
v 1.2 Through
¾ Examine preparation and control of source documents.
¾ Compare with a sample of (expected) outputs.
INPUT
¾ Normal procedures on
authorisation and collection of input documents and relevant external (general) controls.
¾ Ignore except for tracing input through control/batch details and compare to (expected) output.
COMPUTER
¾ Examine controls over
development, organisation and security.
¾ Test input, processing and output controls as a whole.
¾ Use the computer to interrogate files and test system.
¾ Substantive testing alone will often provide sufficient assurance on the basis that the computer is effectively an electronic
bookkeeping system.
OUTPUT
¾ Substantive procedures on output alone (output may not be
automatically generated) will provide insuffient assurance. Control effectiveness is essential to provide sufficient assurance.
1.3
Small installations
1.3.1 Features
1.3.2 Consequences
¾
Lower level of general (IT)controls ⇒⇒
⇒
Less reliance on system of internal control
Greater emphasis on tests of details of transactions and balances and analytical procedures
Increase effectiveness of audit software
¾
Smaller volumes of data ⇒ Manual methods may be more cost effective¾
Lack of technical assistancein entity ⇒ Use of CAATs may be impracticable
¾
Certain package programs2
COMPUTER-ASSISTED AUDIT TECHNIQUES
CAATs are computer programs and data (e.g. transactions data) used as part of the auditor’s procedures to process data of audit significance contained in an entity’s information
systems. CAATs may consist of package programs, purpose-written programs, utility programs or system management programs.
2.1
Possible use
Controls
IT Application
Manual e.g. safe custody of
back-up
Programmed e.g. password to
system
Programmed e.g. check digits,
sequence check
Manual e.g. authorisation, batch control totals
CAATs may be used
2.2
Considerations affecting use
2.2.1 Matters
2.2.2 Consequences
¾
Computer knowledge, expertise and experience of auditor⇒ Must be sufficient to plan, execute and use results of CAAT adopted.
¾
Availability of CAATs and suitable computer facilities ⇒⇒ ⇒
Use of CAATs may be uneconomical or impractical (e.g. if auditor’s package program and entity’s computer are incompatible). Auditor may use own laptop.
Entity personnel may be required to co-operate with and assist. Internal audit may use 24/7 facilities
¾
Impracticability of manual tests when no visible evidence is available⇒ See Example 1 below
¾
Effectiveness and efficiency ⇒⇒
Execution (e.g. selecting a sample, analytical procedure) is quicker than manual equivalent. Design and printing of forms (e.g. for
confirmations), mail merge facilities, etc.
Example 1
Suggest an example of lack of visible evidence concerning each of the following.
Solution
¾
Input/initiation−
−
¾
Processing−
−
¾
Output−
−
2.3
Advantages
9
Enable the auditor to test program controls – if CAATs were not used then those controls would not be testable.9
Enable the auditor to test a greater number of items (eg 100%) quickly and accurately. This will also increase the overall confidence for the audit opinion.9
Allow the auditor to test the actual accounting system and records rather than printouts which are only a copy of those records and could be incorrect.9
Are cost effective after they have been setup as long as the company does not change its systems.9
Allow the results from using CAATs to be compared with “traditional” testing – if the two sources of evidence agree then this will increase overall audit confidence.2.4
Difficulties
8
Substantial setup costs in developing the CAAT programs and testing them. However, once established, providing the client’s system does not change, they can be used as many times as necessary with only the parameters being changed. However, in most cases specific bespoke interrogation programmes will have been
written as part of the system. This will certainly be the case where an internal audit function is operating and may well have been designed for the specific use of internal audit. The external auditor will need to access the usefulness of such systems for their own use.
In addition provided the data held within the system can be exported, eg into Excel,
Access or ASCII format, it can be interrogated by the auditor on their own laptops (for example).
8
The software may produce too much output either due to poor design or usinginappropriate parameters on a test. The auditor may waste considerable time checking what appear to be transactions with errors in them when the fault is actually in the audit software.
8
Checking the client’s files in a live situation. There is the danger that the client’s systems are disrupted by the audit program. The data files can be used offline, but this will mean ensuring that the files are true copies of the live files.3
TEST DATA
3.1
Description
Data generated by the auditor which is then processed using the client’s systems. The objective of test data is to ensure that the controls within the system are operating properly. If this is the case, then erroneous items should be rejected. Consequently, test data should contain data of both a valid and an invalid nature.
Test data
Test of programmed controls
“Live” “Dead”
¾
Audit test data consists of data submitted by the auditor for processing by the enterprise’s CIS. It may be: selected from previously processed transactions; or created specifically by the auditor.
¾
It may be processed during a normal production run (“live” test data) or
¾
An integrated test facility requires the establishment of a “dummy” unit (e.g. department or employee) against which the auditor’s test data transactions are processed during the normal production cycle.3.2
Process
¾
A full understanding of how the system operates and the programmed control environment is required by the auditor.3.2.1
Use of accurate data
¾
Initially, the auditor must test that the system processes data as intended. Data entered into the system correctly flows through the system, updating controls and balances.¾
Using a sales system as an example, procedure may be: Establish a dummy customer profile (eg name, address, discounts, credit limit,
current balance) on the system or select a live client for testing. Ensure that the system being used is the actual client system and not a copy.
Identify the current control balances, eg receivables control, sales, VAT, customer
ledger balance.
Prepare test data (eg place an order through the entity’s website) and establish the
expected impact on the process (eg changes in receivables control, sales, VAT, ledger balance).
Enter the test data and compare the results with what was expected. If agreed, the
system is operating as expected. If not agreed, the reason(s) why must be established.
Review reports that are necessarily produced by the system to ensure the test data
is reflected within them.
Remove test data from the system including the dummy customer and details.
¾
This test could be incorporated into the auditor’s walk through procedure in order to understand the system (plus the design of and implementation of controls – see next).3.2.2
Use of false data
¾
If correct data is input and processed by the system, many of the application controls that are designed to prevent errors will not have been tested.¾
In understanding the system, the auditor must establish what application controls should be in operation and what they are designed to do. Each control must be tested for “error trapping”, ie input false data such that the control will identify incorrect data and reject it. Examples of such data would include: Data outside of a specified accepted range (eg age, units ordered, delivery date). Incorrect customer codes, product codes (incorrect format and non-existent) etc. Incorrect dates (eg 31 February)
Incorrect payment details (e.g. VISA code when payment is required on-line before
delivery)
Invalid user names and passwords
¾
All of the above examples should result in error messages plus error reports. The system should not be able to “go to the nearest” and complete the process, eg the nearest product code or a default substitute.¾
Again, as the auditor must assess the design of the controls and that they have been implemented, using CAAT test data is an effective (and usually the only) way of doing so.3.3
Precautions
¾
Test data should be run “live” if possible. If not possible it is necessary to ensure that programs used are identical to or are the actual programs used by the client.¾
Any fictitious items included as test data must be retrieved/eliminated from files before the client uses those files in normal processing.¾
If test data is to be run “dead”, there must be adequate computer time available and the special run required must not prove unduly expensive.¾
Since controls are being tested, all discrepancies between predicted and actual results must be fully resolved and documented, irrespective of financial amounts involved.4
AUDIT SOFTWARE
4.1
Description
Software specially designed for audit purposes. It is used to process the client’s data in order to check that the figures themselves are correct. Typically, audit software is used for reperformance tests and re–analysis of information.
¾
Can be an off the shelf package program designed to: read computer files select information perform calculations create data files
print reports in a format specified by the auditor; or
¾
Embedded audit routines built into an entity’s computer system to provide data for later use by the auditor: Snapshots – i.e. taking a picture of a transaction as it flows through the computer
systems. Routines are embedded at different points in the processing logic to capture images of the transaction as it goes through the various stages of the processing. The technique allows the auditor to track data and evaluate the computer processes applied to it.
System control audit review file – provides continuous monitoring of the system’s
transactions using audit software modules embedded within an application system. Information is collected into a special computer file for the auditor to examine.
¾
Note that: Utility programs are used by the entity to perform common functions (e.g. sorting,
creating and printing files). They are not specifically designed for audit purposes; and
System management programs are typically part of a sophisticated operating
systems environment (e.g. data retrieval software or code comparison software). As with utility programs, they are not specifically designed for auditing use.
4.2
Uses (not exhaustive)
¾
Basically: what you can do with data within a database management system (eg Access) you
can do with audit software;
everything you do within a manual audit in selecting, analysing and sorting data,
can be done using audit software.
¾
Examples include: Selecting a sample of records from a file (e.g. random selection of goods despatched
notes or selection of all inventory items valued over a certain amount).
Printing out transactions or balances over a specified amount (e.g. of invoices,
inventory items or accounts receivable) for investigation.
Checking computations and calculations by reperformance e.g.:
−
verifying the accuracy of an aged receivables listing or stratification of an inventory file;−
recalculating depreciation charges;−
recalculating interest charges. Confirming application controls (e.g. when testing input controls over
completeness, a computer audit program can identify any missing items from a sequence).
Reorganising data into a form for audit use (e.g. sorting a file of purchases grouped
Comparing two or more different files (e.g. comparing sales invoices with the sales
ledger to ensure that all invoices have been posted, or comparing inventory held at two different dates).
Recalculating closing balances, extracting balances (eg receivables listing). Re-performing allocation of invoices, payments, journals etc.
Identifying duplicate suppliers and/or employees (and/or duplicate addresses)
which may be a source of possible error or fraud.
Selecting exceptions (e.g. invoices approved on a national holiday, credit limits
exceeded, excess overtime, payments above a set limit).
Identifying fields missing data (e.g. references not obtained for new customers
and/or employees).
Conducting analytical review
4.3
Precautions
¾
Client’s files must not be corrupted or damaged.¾
Files used for testing must be complete and accurate and identical to, if not the same as, files currently used by the client.¾
Computer audit programs must be amended to account for developments in the client’s applications.FOCUS
You should now be able to:
EXAMPLE SOLUTION
Solution 1 — No visible evidence
¾
Input/initiation sales orders entered on-line or voiceactivated input
discounts and interest calculations
generated by computer program
¾
Processing delivery notes and suppliers’ invoicesmatched by computer program
checking customer credit limits
¾
Output output reports not produced printed report only contains summary
