Unit 6: Module

Computers

LESSON 1

INTRODUCTION TO COMPUTER CONTROLS

In a computerised environment you get two types of controls namely:

• General computer controls; and
• Application controls.

GENERAL COMPUTER CONTROLS

General Computer Controls are those which establish an overall framework of control for computer activities. They
are controls which should be in place before any processing of transactions gets underway and they span across all
applications.

The following framework is an outline of the controls to be covered in this module. These controls will be discussed
in detail throughout the module.

Seven General Computer Controls Objective

System Development and Implementation Controls To ensure self-developed/purchased system is
properly developed, authorised and meet user’s
needs.
System maintenance Controls (Change Controls) To ensure changes to the system are authorised, meet
user’s needs and made effectively.
Organisational and Management Controls To ensure an organisational framework is created.
Access Controls to Data and Programs To prevent unauthorised changes to programs, data,
terminals & files.
Computer Operating Controls Ensuring procedures are applied correctly and
consistently during processing.
System Software Controls To ensure installation, development, and maintenance
of software packages are authorised and effective.
Business Continuity Controls Prevent/Limit system interruption (Downtime).

APPLICATION CONTROLS

Application controls are controls over input, processing and output of information relating to a specific application
to ensure that such information is valid, accurate and complete.

Application controls include two types of controls, user controls and programmed controls. User (manual controls)
are the controls that the entity has in place over the actual user of the computer system. Programmed controls the
controls that are actually programmed into the system code of the operating system that the entity is using.

These controls will be discussed through the module. The following framework is an outline of the controls to be
covered in this module:
 •Valid - ensure that the transactions captured are valid (i.e. all necessary
information authorised).

Input •Accurate - ensure that the information captured is accurate and no

errors exist.
•Complete - ensure that all information has been captured / recorded.

•Valid - ensure that the transactions captured are valid (i.e. all necessary
information authorised).

Processing •Accurate - ensure that the information captured is accurate and no

errors exist.
•Complete - ensure that all information has been captured / recorded.

•Valid - ensure that the transactions captured are valid (i.e. all necessary
information authorised).

Output •Accurate - ensure that the information captured is accurate and no

errors exist.
•Complete - ensure that all information has been captured / recorded.

LESSON 2

GENERAL COMPUTER CONTROLS

Lesson two will explain the controls that should be in place for the seven general computer controls.

1. SYSTEM DEVELOPMENT AND IMPLEMENTATION CONTROLS

These are the controls in place over the actual development of a new system the entity intends on using. This could
be a purchased package, or a system developed in-house.

CONTROLS OVER A SELF-DEVELOPED SYSTEM

There are four controls that should be in place:

a) Project Authorisation and management;
b) System specification and user needs;
c) System design and programming standards; and
d) Testing

a) Project Authorisation and Management

• Development plan authorised

• A steering committee should be appointed:
o Made up of senior management from both user and computer departments
• The steering committee must ensure that:
o Project authorised;
o Timetables are adhered to;
o Budgets are achieved; and
o Quality requirements.
• Involvement from:
• User department
o Departmental requirements
o Internal / external auditors
 • Data processing department
o Technical soundness
o Compatibility with other systems
o Operational aspects
• Quality control department
o Standard of design
o Testing
o Documentation
• Perform a feasibility study
o Buy / self-developed; and
o Cost / benefit analysis.
• Project team should be appointed, and they will be responsible for:
o Day-to-day management of project
o Ensure project is developed in stages
o Prepare timetables for each stage
• Project authorised after feasibility study/analysis before commencing

b) System Specification and User Needs

• Definition:
o Defining the way the system must work to meet the specifications of users and business
• Two methods of specifying systems:
o Traditional method:
▪ Written systems specification by means of discussions between the data processing
department and users
o Prototype systems:
▪ Design prototype
▪ User department try out
▪ Refine the design through a series of prototypes

c) System Design and Programming Standards

System design and programming standards needed to:

• Ensure the system interacts properly with existing systems and system software;
• Ensure that appropriate control-related programmed procedures are built in;
• Ensure there is supervision over system design;
• Comply with predetermined standards;
• Done on program library not live data.

d) Testing

Testing of in-house systems should be carried out in 3 stages

1. Program testing:
a. Checking the logic of the program to their specs
b. Methods used:
i. Test data
ii. Desk checking (program code analysis)
2. System testing:
a. Ensure the logic of various individual programs links together to form a system in line with the
detailed system description
b. Methods used:
i. Test data
ii. User testing
 3. Live testing:
a. Tested under operational conditions:
i. Parallel running; and
ii. Pilot running.
iii. Parallel running
1. New system in parallel with old system
2. Problem: cost of double processing, difficulty of comparison (e.g. additional info)
iv. Pilot running:
1. Introducing system for only small portions

CONTROLS OVER PURCHASED PACKAGE

Important information to consider when purchasing a package:

• Package must meet user requirements:
o Prepare statement of requirements
o Measure available packages against requirements
• Keep in mind:
o Minimum changes should be made to package
o If modifications is necessary, use normal rules i.r.o system development
o Possibility of future amendments (e.g. tax updates)
o Quality of maintenance service from supplier

The above information must be applied to the selection of a package and the implementation of a package. This can
be done as follows:

1. Specification and selection of package

o Discussions with other users

o Observing operation of package
o Questioning other users of package re:
▪ Facilities offered by program
▪ Freedom from program errors
▪ Speed & efficiency
▪ Ease of use
▪ Quality of support

2. Implementation and testing of package

o Testing
o Independent testing
o Review of experiences of other users

o Implementation
o Involvement of:
▪ User departments
▪ Data processing
▪ Management
▪ Quality assurance
▪
Advantages of purchased systems:

o Less implementation time (immediate implementation)

o Lower cost and cost are predetermined
o Tested thoroughly – thus very reliable
Disadvantages of purchased systems:

o Dependent on vendors for maintenance

o Too general /inflexible to cater for needs
o Change maintenance difficult/impossible
o Written overseas (Vat and Tax differs)

CONTROLS OVER CONVERSION FROM OLD SYSTEM TO NEW SYSTEM

Controls during conversion to the new system (self-developed / purchased).

There are six controls that should be in place here:

1. Planning and preparation;
2. Control over data by the data control group;
3. Update the system documentation;
4. Testing;
5. Back up of the new system; and
6. Posy-implementation review.

1. Planning and preparation:

• Prepare timetables for conversion
• Define methods used (e.g. parallel / pilot)
• Determine cut-off dates
• Prepare data files for conversion (e.g. Standing data)
• Training of staff
• Balance files on old system
• Prepare premises (constant power / air-con)

2. Control over conversion of data by data control group:

• Supervision by senior management
• Auditor involvement

3. Update system documentation:

• System flowcharts
• System descriptions
• Operating manuals

4. Testing:
• Balancing old files with new files
• Third party confirmations
• Follow up of exception reports
• Comparison with data run on old system (parallel)
• Manual comparison of data
• Approval by users

2. SYSTEM MAINTENANCE CONTROLS

These controls exist to ensure that any maintenance that takes place on the newly developed system is done
accurately and in accordance with the requisite level of authority. The changes should be made to ensure that the
system meets the needs of the users. Some examples of these types of controls are:

• Change forms are to be pre-numbered and locked away when not required;
• Any change requests made by the users of the system must be approved by the Line Manager of the user
and a reason as to why the change is necessary must be provided;
 • All change forms need to be signed by Management or the Computer Steering Committee prior to the
change being effected;
• After the change has been made, an IT expert is to test the change to determine if it has been made as per
the approved change request and is working effectively.

• Completeness of changes
o To ensure all approved requests for changes are processed
o Achieved by:
▪ Pre-numbered change request forms
▪ Do regular sequence checks; or
▪ Enter change forms in a register
▪ Outstanding requests reviewed by senior official
• Validity of changes
o Requests should be approved by correct level of authority depending on importance
o User requirements
o Reviewed by data processing department
o Documented

3. ORGANISATIONAL AND MANAGEMENT CONTROLS

These controls would be implemented to ensure that an organisational framework over the computerised
information system (CIS) activities is in place, and to ensure that the basic principles of segregation of duties, review
and virus protection are met. Examples of these types of controls include, but are not limited to the following:

• Computer department is to be represented on the Board of Directors;

• CIS manager should report to senior management;
• Top Management should be committed to controls and to implement management controls such as
establishing an Internal Audit department.
• Computer steering committee set IT policies and exercise control over IT activities
• Staff practices/ processing
o the rotation of operator duties
o system development staff not assigned to operator duties
o at least two operators per shift(scheduling of staff)
o staff take regular leave
• Employment practices
o training of staff and career development
o supervision and review
• Segregation of duties
o Functional
▪ Separate CIS Department
o Operational
▪ SOD between:
▪ System analysts
▪ Programmers
▪ Operators
o Normal SOD between:
▪ Transaction initiation
▪ Authorisation
▪ Processing
▪ Safeguarding
o Independent person must correct errors
• Controls against computer viruses
o Software protection
▪ Software purchases from reputable suppliers
▪ Take care with use of “free” of “public domain” programs
 ▪ Do not lend out program disks
▪ Do not boot up from a disk
▪ Do not use illegal copies
o Data file protection
▪ Install virus detection software
▪ Test data files for viruses before use
▪ Regular backups
▪ Keep disks on write protect
o Staff
▪ Inform staff members against dangers
▪ Train users of microcomputers
▪ Reporting procedures in case of infection
▪ Limit the use of microcomputers to authorized staff
• Supervision and review
o By CIS manager, divisional managers, section heads
o System investigations by internal and external audit

4. ACCESS CONTROLS TO DATA AND PROGRAMMES

As the name suggests, these controls would ensure that access to and editing of data and programs should be
restricted to only those users who have the authority to use the data. Examples of these types of controls include:

• Passwords are to be changed regularly and must be alphanumeric;

• Passwords are to be kept confidential;
• User matrixes must exist in order to restrict database information to the users on a least privileges basis;
• The terminal should shut down after 3 unsuccessful log-in attempts and generate an exception report for
management to review & investigate.

Programmed controls

• Terminals
o TINS (Terminal identification numbers)
o Limited access to system (to specific applications)
o Automatic log off after 5 minutes of non-use
o Shut down after 3 unsuccessful login attempts
o Limited to 1 workstation log onInvestigation into each disconnection
o Simultaneous login prohibited

• Identification of users
o User ID’s & passwords
o Verify IP address
o Magnetic cards
o Voice recognition / fingerprints (use of biometric data)

• Authorisation of users
o Logon ID’s
o Passwords
o Multilevel passwords
o User matrixes
o Passwords for specific authorised levels

• Monitor access and processing

o Audit trails reviewed for daily activities
o Console logs and activity registers
o Application software (unauthorized access)
 o Firewalls

• Communication lines & networks

o Passwords
o Dial & dial back
o Identification data
o Different routes for sensitive data
o Encryption of data

• Password control
o Password strength
▪ Minimum 6 characters (Minimum length)
▪ Alpha /numerical
▪ CAPITAL LETTERS AND small caps
▪ and other - ! @ # *
o Not easily guessed not shown on screen
o Changed regularly
▪ Automatic system request
▪ Re-use of password prohibited
o Confidentiality emphasised
o Cancelled on resignation/ dismissal
o Cancelled after period of inactivity
o Use for authorisation
▪ Limit access to part of system
▪ Limit access to certain times of day
▪ Authorisation levels linked

o Program libraries
o Access to backup programs controlled by access software
o Passwords
o Updating authorised
o Utilities
o Stored separately
o Use logged and reviewed

Physical controls

• Terminals
o Physically locked
o Located in visible area
o Situated in lockable room
• Computer hardware
o Lockable room
o Supervision & review
o Removable mediums secure
• Manual logs

• Program libraries
o Register (REGULAR REVIEW)
o Access controlled

• Distributable processing
o Only executable programs (instead of production programs) at branches
o Independent comparison of exec. Programs to source programs (e.g. internal auditor)
• Logs reviewed
 • Screening & training of staff
• Emergency access controls

5. COMPUTER OPERATING CONTROLS

These are those controls that actually deal with how the user of the computer operates the computer and ensure
that programmed procedures are applied correctly and consistently during the processing of data. Examples of these
types of controls include, but are not limited to the following:

• There must be continuous monitoring and review of the functioning of the computer hardware;
• There must be standardised procedures and operating procedures for the users of the system to follow;
• The must be adequate user manuals in place.
• Scheduling of processing
• Set-up and execution of programs:
o Competent person
o Procedure manuals
o Test against processing log
o Supervision & review
• Use correct programs & data files
• Operating procedures:
o Hardware checks
o Operating instructions & manuals
o Segregation of duties
o Rotation of duties
o Logs
o Supervision and review
• Recovery procedure:
o Emergency plan & instructions
o Backup of data & hardware

6. SYSTEM SOFTWARE CONTROLS

The controls are put in place for programs that process data to ensure that they are installed or developed and
maintained in an authorised and effective manner, and that access to the system software is limited. Examples of
these types of control include:

• In the processing by users on personal(micro) computers, there must be:

o Control over the software on the PC to ensure that it is not copied or pirated;
o Programs which are written internally should be documented and tested to ensure that the program
has the integrity required by management.
• Acquisition & development controls
o See previous notes
• Security over system software
o Integrity of staff
o Division of duties
o Employment policies
o Supervision & review
• Database systems
o Access control
o Documentation
o Supervision & review
• Networks
o Support department
o Access controls
o Disaster recovery plan
 • Processing on microcomputers
o Control of software
o Programs written internally tested & documented

7. BUSINESS CONTINUITY CONTROLS

These are the controls that the entity would put in place to ensure that it would be able to continue as a going
concern, even in the event of a disaster that the company might experience. Examples of these types of controls
include:

• Data is backed up regularly and kept off-site in a fireproof safe;

• The entity has UPS (Uninterrupted Power Supply) to ensure that it can continue doing business in the event
of a power failure;
• The entity’s server room is air-conditioned to ensure that the servers do not overheat resulting in the loss of
vital data;
• Plan, document and test the disaster recovery plan to ensure that it will be effective in the event of a disaster.

• Physical environment:
o Protection against the elements:
▪ Fire: extinguishers etc
▪ Water: away from water pipes
▪ Power: backup supply
▪ Environment: air con etc

• Emergency plan & disaster recovery procedures:

o Establish procedures/Responsibilities
o Prepare list of files & data to be recovered
o Provide alternative processing facilities
o Plan, document & test the disaster recovery plan

• Backups
o Regular backups on rotational basis
o On-line/ Real time backups
o Store back-up files on separate premises
o Hardware backup facilities
o Store in fireproof safe
o Retention of files / records for required times

• Other controls
o Adequate insurance
o No overreliance on staff
o Virus protection / prevention
o Physical security
o Cable protection

• Personnel Controls
o Segregation of duties
o Job rotation
o Hiring/firing procedures
o Employment contracts
o Use of hardware/software
o Confidentiality
 LESSON 3

APPLICATION CONTROLS

INPUT

Controls for Validity

Access Controls – See general control number 4
Segregation of duties – There needs to be different people performing different tasks
Authorisation – This can be obtained in two ways:
1. User of the programme:
a. Via a signature (if there is a hardcopy); or
b. On-line using a password.
2. Computer:
a. Verify the data against the codes/data on the Masterfile.
Override of system generated information:
• Specific authorisation – senior management;
• Should be printed on exception report and followed up by senior management; and
• Review of authorisation procedures by internal auditor.
Changes in data:
• Authorisation by senior management;
• Should be done by an independent senior person;
• Under supervision;
• The changes should be tested and documented after they have been corrected; and
• Should be printed on exception report and followed up by senior management.

Controls for Accuracy

Matching by the computer:
• Input transactions with data on file e.g. goods recorded in purchase journal with purchase orders;
• Info generated by computer e.g. prices originates from codes against suppliers; and
• Any unmatched items should be printed on an exception report and should be followed up by senior
management.
Review by users or senior staff:
• Info that has been entered on screen; and
• Input reports to source documents e.g. Client order to purchase order.
Edit checks - These are controls that have been built into the system and will be performed by the computer. The
different types of edit checks will be discussed below.
Staff training:
• All the users need to be given training on how to use the system.
• Operating and instruction manuals should also be provided.
Controls over documents and forms:
• There needs to be well designed documents; and
• This will minimize errors.
Controls over screens:
• There needs to be user-friendly screens; and
• This will minimize errors.

Edit Checks
Types of Edit checks Definition of edit checks
Field presence checks Ensures all the mandatory fields have been completed before moving to next step.
Formatting check Ensures the fields have been completed in the correct format.
 For example: prices should be numerical and Names of suppliers alphabetical and
supplier codes should be alphanumerical.
Screen check (only check that Checking the info on the screen by the user to ensure accuracy on screen.
is a manual check)
Validity or existence check Ensures that the codes or files on the database does exist.
For example: stock codes checked to inventory master file
Limit or reasonableness Ensures that the information captured in the fields falls below a pre-set boundary
check or limit.
For example: Date entered months cannot be more than 12
Dependency check Ensures that there is interdependency of input with other fields.
For example: Sufficient stock is available before accepting the sale
Field size check Ensure that the number of characters enter into the required fields are correct.
For example: Telephone number is 10 digits and ID number is 13 digits
Screen prompts Ensures a message will “pop up” and ask the user whether he wants to submit the
on-line form.
Logic check Ensures that the totals has been added up correctly.
Sign check Ensures that the field has the corrective sign
Either positive/negative amount
Specific character check Ensure that should the field require a specific character that it will be entered.
For example: spaces in the right place or a #
Arithmetic check Ensures that the journal does balance.

Controls for Completeness

Stationary controls:
• Form design should be easily understandable; and
• Pre-numbered documents.
Matching by the computer:
• Transactions entered compared to info on master files, e.g. Invoice to GRN; and
• Any unmatched items should be printed on an exception report and followed up by senior management.
Sequential testing by the computer:
• Numeric sequence; and
• Any missing numbers should be printed on an exception report and followed up by senior management.
Review of output reports by user:
• To ensure there is numeric sequence;
• Follow up on missing numbers; and
• Balancing inputs with outputs.
Examining processing logs:
• For missing entries; and
• Any missing entries should be printed on an exception report and should be followed up by senior
management.
Control totals – these controls are built into a system. There are three types:
1. Financial Totals – Ensures that the totals of the fields that hold monetary value is equal to the total that
has been entered.
2. Hash Totals – Ensures that the totals of the fields that are numeric is equal to all the numeric fields that
have been entered.
3. Record counts – Ensures that the total number of records are equal to the total number of records you
have submitted.
 PROCESSING

Controls for Validity

Access Controls – see the validity of input
Librarian Function – ensure the correct program or file is used.
Files, labels and version numbers - To ensure that the correct version of file is in use
Overrides:
• Authorisation by senior management; and
• Printed on an exception report and followed up by senior management.
Manual intervention:
• Should obtain authorisation by senior management should the system break down; and
• The disaster recovery plan and business continuity plan should be in place.
Matching by the computer – see the accuracy of input.
Manual logs:
• Review unscheduled processing/unauthorised use; and
• Any unscheduled processing/ unauthorised use should be printed on an exception report and should be
followed up by senior management.
Supervision and review – by senior management
Segregation of duties – see the validity of input.

Controls for Accuracy

Operator manuals and instructions – should be in place.
Controls over your hardware - To ensure accurate operating of the hardware.
Edit checks – see the accuracy of input.
Physical checking of accuracy by users
Review and follow up on exception reports
Recons and balancing – through control totals, see the completeness of input.
Scrutiny by users of processed info for accuracy
Checking postings by users – To ensure that the transactions have been posted to the correct accounting
document.
Supervision and review – By senior management

Controls for Completeness

Control totals – see the completeness of input.
Reconciliations of accounts and balances – To ensure the subsidiary ledgers recons with the GL
Sequential testing by the computer:
• Numeric sequence; and
• Any missing or duplicate number should be printed on an exception report and should be followed up by
senior management.
Processing logs – Should be reviewed by senior management if there are any interruptions.
Breakpoint re-runs – If processing stop or is interrupted this function will ensure that it will restart at the correct
point.
Adequate back up procedures:
• Regular backups on a rotational basis;
• On-line/ Real time backups;
• Store back-up files on separate premises;
• Store in fireproof safe; and
• Retention of files / records for required times.
 OUTPUT

Controls for Validity

Distribution should be controlled – CIS department is responsible to control distribution of output.
Distribution list – That specifies who the authorised users are that can receive output reports.
Distribution schedule – To determine which output will be received and when they will be received.
Distribution register – Users should sign for the output they have received.
Output logs – Be reviewed for unauthorised output.
Online output:
• Should be controlled by the CIS department; and
• Terminals located in secure area.
Access controls – See validity of input

Controls for Accuracy

Reconciliations – Input to output
Review of outputs:
• By CIS users
• Check for obvious errors
• Accuracy of calculations
• Postings from sub ledgers to GL

Controls for Completeness

Reports:
• Should be sequentially numbered;
• Contain end of report messages; and
• Have page counts.
Reconciliations – Input to output
Sequence checks – On page numbers or document numbers
Review of reports:
• By users
• They should inspect for:
o Numerical sequence
o Missing items
o Follow up with senior management

MATERFILES

Masterfile: Files which are used to store only standing information (e.g. name, address and credit limits of debtors)
and latest balances (e.g. outstanding balances of debtors). Changes to standing data on Masterfile are referred to as
Masterfile amendments. The biggest risk regarding the master files is that any changes to the master file might not
be valid, accurate and complete.

Validity for processing changes

• Authorisation of changes in writing by senior management on a master file amendment form;
• All the master file amendments forms should be captured in a register;
• Checking the changes of the MF to the logs of changes; and
• Follow-up of unauthorised changes.

Accuracy for processing changes

• Recon of MF with amendment forms and 3rd party confirmation; and
• Edit checks over data capture.
 Completeness for processing changes
• Sequential numbered audit trail of MF changes; and
• Recon of master file amendment forms with changes register.

LESSON 4

RISKS WITHIN A COMPUTERISED ENVIROMENT

The CIS environment has various threats and risks. Some of them will be listed below but this is not an exhaustive
list.

Potential threats:
• Natural disasters:
o Floods, Fire, Storms, Heat waves.
• Man made disasters:
o Terrorism, war.
• Intentional damage:
o Fraud, Hacking.
• Unintentional error:
o Human Error.

Computer crime:

Definitions:
• The act of using a computer to commit an illegal act.
• “…any criminal activity involving the copy of, use of, removal of, interference with, access to, manipulation
of computer systems, and/or their related functions, data or programs.”
• "crimes where the computer is a major factor in committing the criminal offense" ["FBI Computer" ]

Computer crime can take the form of:

• Theft of money, i.e. the transfer of payments to the wrong account;
• Theft of information, i.e. tapping into data transmission lines or databases;
• Theft of goods by their diversion to the wrong destination;
• Theft of computer time etc.

Possible errors over the input of data:

• Unauthorised data entered
• Errors in creation of data
• Errors in capture/input of data
• Data lost during input
• Data added/altered
• Errors in correction/re-entering rejected data
• Corruption during capture/transfer

Possible errors over the processing of data:

• Data lost during processing
• Data added/altered during processing
• Calculative/accounting errors during processing
• Logic, precision or rounding errors in program
• Incorrect program or data file
• Incorrect values or internal tables in program
• Corruption during transmission
• Equipment malfunctions
 LESSON 5

AUDITING IN AN INFORMATION TECHNOLOGY ENVIRONMENT

As an auditor, whether internal or external, junior or senior, you will be exposed to computerised financial reporting
systems at your audit clients. You will also make use of laptop computers to assist you in carrying out your audit
work. The vast majority of businesses you will visit to perform audits will use computers to capture, process and
record transactions, produce the accounting records and lots of other information. However, the extent to which
business entities use computers will vary considerably. A small company may have one or two stand-alone personal
computers onto which simple bookkeeping programmes are loaded. A large company will have a far more complex
arrangement, using micro-computers as servers and workstations. Such companies will have data centres and lots of
highly qualified personnel.

For example, even very small businesses these days pay salaries and creditors via electronic funds transfer, so some
knowledge of how this is controlled will be important if you are auditing the payroll or acquisitions and payments
cycles. An overview of IT general controls, automated application controls and other key critical IT trends, such as
interface management and mobile applications, will provide you with a good understanding of how IT impacts the
audit. You also need to get used to the fact that every business has different information needs. To illustrate:
• The strategy adopted to audit a bank will call for the inclusion of computer audit experts on the team due to
the complexity and importance of the computerised systems. The fact that banks process millions of
transactions will require that the strategy focus on tests of controls which in turn will affect the audit plan.
• The strategy for the audit of a small company with a bookkeeper or two and a number of PCs will not require
specialist computer skills and will probably be focused on substantive testing.
• The software used by a large company is likely to be far more sophisticated, highly integrated (simplistically
this means that applications work together, for example a credit sale automatically updates the inventory
records, and the debtor ledger and general ledger), and have many more control features for input,
processing and output. At the other end of the scale, a small business may use simple software for each
application which is not linked to any other application, for example a simple computerised perpetual
inventory application may require that all movements of inventory, for example receipts, issues of inventory
items will be entered onto the system by keying in the information from hard copy goods received notes
(GRNs) and delivery notes. The difference in the capabilities of the software will directly affect the validity,
accuracy and completeness of the information it produces as well as the way in which the information is
audited.
• As a final illustrative example, the use of audit software (i.e. software which helps the auditor conduct the
audit or carry out what are termed “computer assisted audit techniques”) will be absolutely critical on some
audits, and hardly critical at all on others. For example, the efficient and effective audit of debtors for a large
company with, say, 5 000 debtors, will not be possible without using audit software to interrogate the
debtors master file, extract samples from it, re-perform calculations, analyse it, etc. In a small business with,
say, 200 debtors, this may not be necessary or even possible.

DATA ANALYTICS

Data analytics, and more specifically computer assisted audit techniques are exactly what the phrase says: making
use of a computer to assist in carrying out the audit. Although there is some extremely powerful and complex
software available to assist in performing audits, the concept is simple: wherever it is economical and efficient to do
so, the power, speed and versatility of the computer should be harnessed to assist with the audit. For many audit
clients it would simply be impossible to perform an audit without using CAATs.

Consider a very simple example:

A branch of a major bank has 22 371 accountholders who have call account deposits with the bank, which earn
interest on daily balances. At the year-end audit, we need to confirm that total interest paid on these call accounts
(as well as various other savings accounts, fixed deposits, etc.) has been correctly calculated, as reflected in the
financial statements at R71 587 200.
• Imagine trying to obtain printouts of all 22 371 account holders and each of their daily balances for 365 days
and then trying to test enough of these on our calculator, to form a representative sample of interest
 calculations - clearly impractical, tedious, inefficient, very expensive and a high probability that our audit
staff would make many mistakes themselves along the way!
• Instead, we are able to use audit software, which can re-perform all of these daily balance calculations and
provide an independently calculated total for interest payable by the bank for the year. Powerful CAATs
packages are able to perform a 100% of the population incredibly quickly thus providing huge benefits to
auditors by significantly reducing audit risk (100% testing rather than sample testing), providing more reliable
evidence (no human errors) and increasing audit efficiencies (millions of calculations can be re-performed in
a matter of minutes and hours rather than days and months).

When applying data analytics in the audit, use processes of inspection, extraction, transformation, loading and
modelling data to discover information and to enhance problem solving and decision-making. Data extraction allows
for:
• Data to be refined.
• Data transferred from source to destination.
• Data to be extracted from unstructured data sets, that aren’t stored in a structured database format.

There are three main types of data extraction in ETL (extract, transform, load): full extraction, incremental stream
extraction and incremental batch extraction.

COMPUTER AUDIT ASSIST TECHNIQUES (CAATs)

How do data analytics/Computer Audit Assist Techniques (CAATs) fit into the audit process

Auditors should perform basic data modelling or where necessary request advanced data modelling by experts, and
then interpret the results, concluding on reporting/presenting/communicating as applicable.

The auditor decides whether or not to use CAATs when considering the audit strategy (scope, timing and direction)
and the audit plan (nature, timing and extent of testing) which is necessary to reduce audit risk to an acceptable
level. The decision made will result in the auditor taking one or more of the following approaches:
• Auditing around the computer;
• Auditing through the computer; and
• Auditing with the computer.
The auditor is not restricted to selecting just one of thee approaches.

Auditing around the computer

This approach treats the computer system and programmes as a black box and relies on review and comparison of
the input and output documents. The rationale behind this approach is that if the source documents are valid,
accurate and complete, and the output produced by the computer system as a result of processing these source
documents, is correct, then the processing functions of the computer system are being performed correctly. The
manner in which these processing functions are performed is deemed to be of little consequence. This approach
assumes that the computer-generated output can be traced back and compared to the input.

The audit is performed by selecting a sample of transactions that have already been processed and then tracing these
transactions from their point of origin as source documents to the output documents or records produced by the
computer system.

This approach is only feasible if the computer system under consideration is a simple, batch-oriented system with no
significant controls or automated/integrated functions built into the system.

Additional requirements for the adoption of this approach are that control is maintained by segregation of duties,
independent checks and management supervision together with the maintenance of a clear audit trail.

The main advantages of auditing around the computer may be summarised as follows:
• There is no risk of manipulation of the client’s data by the auditor.
 • The auditor requires little or no knowledge of computer technology.
• There is minimal disruption of the client's IT function.
• The costs associated with technology and computer expertise may be reduced.

The disadvantages of auditing around the computer may be summarised as follows:

• Apart from the more trivial applications, computer systems generally involve volumes of data and
transactions which render manual testing ineffective.
• System controls and potential errors within the system are ignored.
• No use is made of the most powerful and valuable audit tool, namely the computer.

Auditing through the computer

This approach is concerned with testing the computer system and controls which are built into the system.
Simplistically this is achieved by the auditor sending transactions (test data), some of which will contain errors which
the system’s programme controls should detect, through the system. In this way the auditor tests whether controls
are working as expected, for example if a transaction which the auditor knows is incorrect is picked up by the system,
the auditor has some evidence that the system is working (and vice versa). Thus, auditing through the computer is
primarily a “test of controls” approach.

The main advantage of “auditing through the computer” is that it can be used effectively and efficiently to audit a
highly sophisticated computer system which processes huge volumes of data and relies extensively on computerised
controls, for example banks.

The disadvantages of “auditing through the computer” include the following:

• The auditor is required to have a high level of technical computer knowledge.
• Audit costs may increase due to the level of investment in technology and expertise required.
• The auditor is required to take stricter precautions due to the increased risk of corruption of the client’s data
and master files.
• A high level of client co-operation is necessary, which may impinge upon audit independence.

Auditing with the computer

There are two aspects to “auditing with the computer”:

• using the computer to assist in the performance of audit procedures (mainly substantive testing); and
• using the computer to produce electronic/automated work papers, audit programmes and financial
statements.

Using this approach for substantive testing, involves gaining access to a client’s files and using audit software
(programmes which help the auditor to do what he has to do) to read, sort, compare and analyse data on the file,
very quickly and extensively.

The idea behind using the computer to automate the audit is to make it a more effective and efficient audit by
harnessing the power of the computer.

The main advantage of auditing with the computer is that use is made of the power, speed and versatility of the
computer, which results in a more economical and efficient audit.

The disadvantages are:

• costs/license fees of audit hardware and software;
• the audit team requires training on how to use the software; and
• there may be a tendency for the audit team to audit without thinking about what they are testing.

Combination of the above approaches

The auditor is in no way restricted to one of the three approaches. In probably 99% of reasonably sized audits, where
the client has a computerised accounting system, the audit approach will be a mixture of the above approaches.
Auditing is about getting the mix of tests of controls and substantive testing right, based on the strength of the
organisation’s controls and the ease/efficiency with which substantive testing may be achieved. Also remember that
some of the procedures which the auditor carries out, may be unaffected by whether the client is computerised or
not, for example scrutiny of minutes, or inspection of non-current assets. The overriding objective is to achieve the
most effective and efficient way of getting the audit done.

SYSTEM ORIENTATED CAATs

As suggested by their description, these CAATs concentrate on the accounting system and related control procedures
and are used predominantly to perform tests of controls, although some substantive evidence may also be produced.
The use of systems-orientated CAATs is regarded as “auditing through the computer.”

Because system CAATs are typically run periodically, reliance on general controls is a prerequisite because of the risk
that programs could be changed in between the dates when the software is run. It may be preferable for these to be
run by the internal audit, in which case the external audit would evaluate the work of the internal auditors.

Test data

This type of CAAT requires the auditor to create a set of transactions (let us assume clock cards) to be keyed in and
processed. The transactions will include both correct data and incorrect data, i.e. a clock card with an invalid
employee number and another with 55 hours of normal time, will be entered. What the auditor expects is that the
invalid employee number will be identified by the computer and written to an error report, and that the 55 hours
normal time will be identified by the programmed input limit check and the error highlighted immediately for
correction. Obviously, if entry and processing go ahead as normal, the controls are not working!

• Using the test data, the auditor can design transactions to test any controls which the client claims are in the
system but designing suitable transactions that contain the error conditions which the auditor wants to be
prevented or detected, can be time consuming.
• For the “test data” approach to be effective, the auditor must be fully aware of the controls that are in the
system and must know what the theoretical output should be so that he can compare it to the actual output
for the transactions he has processed.
• As with manual tests of controls, the test data approach only tells the auditor that the control was working
when tested and not that it worked throughout the whole period under audit.
• The auditor will also need to confirm that the programme tested is the one that is used in live runs.
• The test data should be run against a “copy” of the live (production) programme to prevent corruption of
the client’s data.
• Test data is used to test:
o Controls, such as input validation, online password and data access controls; and
o The processing of data by computer system.

Integrated test facility

This is really an extension of the “test data” approach. In this method, an artificial (dummy) unit is created on the
client’s system. For example, Company “X” or Cost Centre “Y”. The auditor can then feed test transactions through
the system for processing along with normal transactions. The test transactions will, however, all be coded for
processing to the fictitious Company “X”, which is simply excluded for purposes of the client’s normal accounting
purposes.

This type of CAAT therefore reduces the risk of corrupting the client’s information. For example, the auditor could
enter two fictitious (dummy) employees on the employee master file, in the proper manner, for example employee
number, cost centre, grade, pay rate. He would then create fictitious clock cards with error conditions for the dummy
employees and would have them processed at the same time and in the same manner as the client’s genuine clock
cards when the “live” payroll run is being performed. As long as they are coded to a fictitious cost centre (e.g. Cost
Centre “Y”), they can easily be excluded from the client’s normal financial reporting records.

Again, the auditor will need to have a clear knowledge of the controls in the system and the results which should be
achieved (output). Once the “dummy records” have been created in the client’s files, the auditor can visit the client
on a number of occasions during the year under audit to perform the test; this helps to gather evidence that the
controls were working throughout the year.

The major disadvantage of this technique is that fictitious transactions may be muddled in with the client’s data if
not correctly coded or if the dummy unit is not separated out before reports are sent to users. For example, the
foreman might be a little surprised and confused to see two additional employees and an extra cost centre in his
factory! It is also conceivable that client staff could manipulate ITF facilities for fraudulent purposes.

Parallel simulation

This type of CAAT involves running the client’s transaction data and master file information through a “trusted”
system set up by the auditor, as well as through the client’s normal system. The results of the two processing runs
are then compared and any discrepancies are followed up. These results can provide evidence relating to controls
(e.g. the auditor’s system may make effective use of a limit check which identifies invalid data while the client’s
system may not have such a check in place), as well as evidence of a substantive nature (e.g. daily transaction totals
can be compared to verify accuracy of client figures).

Embedded audit facility

For this type of CAAT to operate, the auditor arranges to have an audit module inserted into the client’s application
programme. The module is designed to either identify transactions which might be of particular interest to the
auditor, or to re-perform certain validation controls and report thereon, while the client is actually running the
normal application programmes. For example, the auditor may wish to identify all payments to creditors exceeding
R500 000. The audit module would identify these and write them to a file. Another example is that the audit module
could be programmed to perform reasonableness tests when salaries are processed and report on any items outside
of given reasonableness ranges. These embedded files would have strict access controls in place and the auditor
could appear at any time to audit/follow up on recorded transactions or exceptions written to the files.

DATA-ORIENTATED CAATs

These CAATs are concerned mainly with substantive testing, i.e. obtaining evidence to support the assertions relating
to balances in the statement of financial position and totals of transactions that underlie the statement of
comprehensive income. Use of these CAATs can be thought of mainly as “auditing with the computer”.

Generalized/customized audit software

These are programmes that are used to extract/analyse/reformat data extracted from client systems, for example
the auditor may extract a report of all debtors’ amounts outstanding over 90 days. Common features and facilities:
• Versions are generally available for use on a wide range of hardware and systems software.
• They are generally easily programmable to access various file formats and data fields thereby enhancing the
ease of use for the generalist auditor.
• They are menu driven, which adds to their user-friendliness.
• Special security features are generally included, such as restricting certain features of the software to special
classes of users.

Where generalised software (GAS) is not available to suit the needs of a particular set of circumstances, customised
audit software (CAS) may be specially developed.
System utilities and report writers

Many clients will have utilities and report writer’s resident on their computers. Utility programmes can be used to
manipulate and analyse data and test whether programmes function correctly. Report writing programmes enable
users, including the auditor, to design and extract various reports, which may be particularly useful in performing
substantive tests.

Advantages:
• The software has already been loaded on the client's hardware.
• They are relatively simple to use.
• They perform many of the tests which GAS packages offer.
• The cost of using these packages is generally lower than using GAS.

Disadvantages:
• Many utility and report writers are available that may cause time delays seeing that the auditor will have to
assess how unfamiliar clients’ utilities and report writers’ function.
• These forms of CAAT may not be as well documented as GAS packages and may not quite meet the auditor’s
requirements.

Data orientated audit software can be used to:

• Re-perform calculations:
o Test casts and cross-casts of files
o Test casts of balances within the files
o Test calculations (depreciation, interest, inventory value)
o Calculate ratios for use in analytical procedures.
• Perform investigations and analysis:
o Detailed analyses of account balances (debtors and inventory age analysis etc.)
o Examine files for unusual items (long outstanding items, high value items etc.)
o Examine records for quantity, completeness and consistency in order identify exceptional items.
Examples would include sequence checks, alpha/numeric checks, checks for missing fields, checks
for negative items, matching the underlying records etc.
o Compare transaction data with standing data (prices on invoice with price list).
• Select samples:
o Items for testing/confirmation.
o Items which meet certain criteria.
o Exceptions (debtors which exceed credit terms/no terms)
• Extract summaries:
o Items per category (debtors per day outstanding).
o Stratification of balances.
o Printout of master file.
• Perform comparisons:
o Computer files with each other.
o Amounts (e.g. cost prices of inventory against net realizable value).
o Previous years’ files with current year.

Audit functions that can be performed using data-orientated CAAT’s:

• Sorting and file re-organisation;
• Summarisation, stratification and frequency analysis;
• Extracting samples;
• Exception reporting;
• File comparison, for example current master file to prior year’s master file;
• Analytical review, for example extraction of ratios;
• Casting and recalculation; and
• Examining records for inconsistencies, inaccuracies and missing data including sequential numbers and
duplicates (and creating reports thereon).
 FACTORS THAT WILL INFLUENCE THE DECSION TO USE CAATs

The following factors will be taken into account in making the decision as to whether CAATs should be used:

• Complexity of the client’s system – Where a client’s accounting systems are extensively computerised and
of a high level of complexity or sophistication, the auditor cannot rely on manual audit procedures alone.
• Volume of transactions/output – The size of the business will usually govern the number of transactions that
flow through the accounting system. As the volume increases, so do the sizes of files which result from
processing the transactions, making it impractical/impossible to perform manual extraction, sorting,
analysing, summarising of data, etc., due to normal audit time constraints.
• Data stored in electronic form – The client will usually store data in electronic form, for example debtors
master file, inventory master file. In such cases:
o it will not be feasible/efficient to audit the data manually, and
o Normal audit trails may not exist so alternatives to normal manual procedures have to be sought,
for example using CAATS.
• Availability of skills in the audit team – Particular skills, sometimes of a high level, are required when using
some types of CAATs.
• Potential loss of independence – The use of CAATs requires the co-operation of the client and where system-
orientated CAATs are used, the auditor may have to rely quite heavily on client personnel to run the CAAT.
• The attitude of the client – Professionally run companies expect professional auditors and hence will expect
their auditor to be up to date with, and capable of, using advanced audit techniques.
• Compatibility of the firm’s hardware and software with the client’s hardware and software – The audit firm’s
hardware and software is unlikely to suit every single client’s hardware and software so it will need some
adaptation, for example additional software may be required (cost) in order to run audit programmes on
client systems/files.
• The utilities available at the client which can assist – Utilities are programmes that can frequently perform
tasks which are useful to the auditor, such as sorting/ re-organising files, copying, printing parts of a file, etc.
They do many things that generalised audit software does, so if the auditor has no suitable generalised audit
software, he may consider using the client’s utilities. Note that the completeness of the data set is all the
more important in this instance.
• The use of data analytic software tools to analyse data – there are many data analytic software tools
available, such as ACL, IDEA and advanced Excel functions, which can be used to analyse data. These tools
enable auditors to effectively analyse large volumes of data, identify patterns, anomalies and trends, and
gain valuable insights into financial transactions and business operations.

AUDIT FUNCTIONS THAT CAN BE PERFORMED USING DATA-ORIENTATED CAATs

• Sorting and file re-organising

• Summarization, stratification and frequency analysis
• Extracting samples
• Exception reporting
• File comparison, for example, current Masterfile to prior year’s Masterfile
• Analytical review, for example, extraction of ratios
• Casting and recalculation
• Examining records for inconsistencies, inaccuracies and missing data including sequential numbers and
duplicates (and creating reports thereon)

Illustration of what a data-orientated CAAT (audit software) can do

A chart of what the inventory masterfile at 30 June 0002 of an electrical supply company might look like when
printed appears below. Of course this is a tiny part of the file, showing only seven- li ne items or records.
The actual masterfile may have 5 000-line items, which, if printed, would produce a 160-page printout!
 Item Description Location Category Quantity Unit Cost Value S Price Last Sale Last
no. Purchase
A 123 Fuse Box WH2 A 20 710.00 14 690.00 5/0001 3/0002
200.00
P492 Regulator WH3 B -6 42.50 -255.00 56.50 2/0002 4/0002

1671 Plugs WH4 A 410 8.00 3 14.00 11/000 10/000

280.00 1 1
G893 WH2 C 91 44.00 4 52.75 1/0002 2/0002
004.00
Connector WHl D 18 2.20 396.00 4.20 5/0002 7/0002

Q456 Junction A 3 618.00 1 7/000 8/000

854.00 1 1
P 769 Brushes WHl B 0 34.20 34.20 36.40 4/000 6/0002
2

Things that can be done with audit software:

1. Scan the entire file and produce a report of missing fields or duplicated item numbers, for example,
missing item number, description, location and selling price (see item number Q456).
2. Sort the file by category and add up value field by category to determine whether the major portion of
the inventory value is of a particular category. This will provide the auditor with a better idea of where to
direct the inventory audit focus.
3. Sort the file by location and add up value and quantity fields to assist in planning attendance at the
inventory count.
4. Extract a list of items with negative quantities, values or unit costs (NB a negative x a negative equal
a positive - see item number P492).
5. Extract a listing of inventory items where the quantity field is zero (0) but the date of last purchase is
after the date of last sale (see item number P769).
6. Re-perform the quantity x unit cost calculation and compare the result to the field to identify any differences
with the client's file (see connector R2,20x 18 = R39600 and P769,0 x R34.20 = R34.20)
7. Compare unit cost field to selling price field to identify instances where cost exceeds selling price (see item
number A123).
8. Extract a list of items where date of last sale is (say) more than nine months ago, but date of last purchase is
less than three months ago, and by enquiry establish why the order was placed, for example, was it because
goods in the inventory are damaged? (See item number A123.)
9. Extract a listing of items where date of last sale is (say) more than nine months (and purchase date is also
more than nine months) prior to masterfile date (30 June 0002) to assist in identifying non-saleable
inventory/inventory which should be written down.
10. Extract a listing of items where either the date of last sale or date of last purchase falls after the inventory
masterfile date (see connector 7/0002).
11. Extract a random sample of items to be counted at the inventory count (after summarising by location,
quantity and value).
12. Cast the value field to obtain the total value of inventory for comparison to the figure used in the trial balance.