AUE3702: Computer Auditing Science Study Notes (UNISA, CUT & SA Universities)

These exam notes provide a comprehensive, practice‑oriented guide to AUE3702 Computer Auditing as offered at UNISA (University of South Africa) and aligned topics in Computer Auditing and IT Governance as taught in CUT (Central University of Technology) ACCA/AUD modules and other South African universities. The focus is on helping students master core computer auditing theory, apply it to typical exam questions, and connect it with real‑world audit practice in South African organisations. Particular attention is paid to accounting information systems, IT general and application controls, and computer‑assisted audit techniques (CAATs).

1. Overview of Computer Auditing in the South African University Context

1.1 Position of AUE3702 and Related Modules

At South African universities, computer auditing is usually taught as an intermediate to advanced module within accounting and auditing programmes. Key examples include:

• UNISA

  • AUE3702 – Computer Auditing (third‑year undergraduate auditing module)
  • Linked to other modules in the UNISA: Accounting Information Systems & Auditing stream (e.g., AIS3701, AUE3761).

• CUT (Central University of Technology)

  • AUD40AB – Auditing IV (Computer Auditing and Forensic Applications) (example naming pattern)
  • Often combined with ACC40xx accounting information systems modules emphasising ERP systems and IT governance.

• Other South African universities (e.g., UJ, NWU, TUT) offer similar subjects under titles like:

  • INF300 / INF305 – Information Systems Audit
  • AIS370 – Accounting Information Systems & Computer Auditing.

Across these institutions, the core learning outcomes are similar:

• Understand how IT affects the financial statement audit.
• Identify and evaluate IT risks relevant to financial reporting and business processes.
• Design and perform tests of IT general controls (ITGCs) and application controls.
• Use computer‑assisted audit techniques (CAATs) for substantive testing and control testing.
• Provide assurance over systems, including outsourced, cloud‑based and ERP systems.

AUE3702 specifically expects students to integrate knowledge from earlier auditing modules (e.g., AUE2601/AUE2602 at UNISA) and from accounting information systems modules (e.g., INF2603, FAC2601) and apply them in IT‑rich environments.

1.2 Why Computer Auditing Matters

Modern organisations in South Africa (banks, retailers, municipalities, SOEs) run their critical processes on integrated financial systems, ERPs (e.g., SAP, Oracle, Microsoft Dynamics), and cloud services. This transforms how evidence is generated, processed, stored and accessed, which directly affects:

• Audit risk (risk of expressing an inappropriate audit opinion).
• Effectiveness of internal controls (especially over financial reporting).
• Nature, timing and extent of audit procedures (more reliance on IT controls and data analytics).

Key reasons auditors must understand computer auditing:

1. Pervasive use of IT
   Every significant transaction (sales, purchases, payroll) is often initiated, processed and recorded within a computer system. Errors or fraud in the system can affect thousands of transactions simultaneously.

2. Complexity of systems
   Systems include access controls, automated calculations, interfaces, batch jobs, APIs and more. Without understanding these, auditors cannot properly assess control risk or plan substantive procedures.

3. Audit efficiency
   CAATs and generalised audit software enable auditors to test entire populations rather than small samples, improving assurance and sometimes reducing audit time and cost.

4. Regulatory expectations
   South African auditing standards (ISAs as adopted by IRBA) and corporate governance codes (e.g., King IV) expect auditors and those charged with governance to understand IT risk and controls.

1.3 Key Exam Themes in AUE3702 and Similar Modules

Typical AUE3702 and related exam papers from UNISA and CUT concentrate on:

• Impact of IT on the audit process
  How IT changes the auditor’s risk assessment, internal control testing, and substantive procedures.

• Understanding computerised environments
  Distinguishing between stand‑alone systems, client‑server architectures, online real‑time systems, batch processing, ERP systems and cloud‑based systems.

• IT general controls (ITGCs)
  Examining controls around program development, program changes, access security, and computer operations.

• Application controls
  Understanding controls at the transaction processing level, such as input validation, processing controls, output controls, and master file controls.

• CAATs
  Designing data extraction and analysis tests using audit software (e.g., examples reference IDEA, ACL, Excel).

• Reliance on service organisations
  E.g., payroll bureaus, cloud accounting services, and how to use service auditor reports (ISAE 3402 / SSAE 18 type reports).

• IT governance and risk
  How frameworks like COBIT and King IV influence the control environment and auditor’s understanding of governance over IT.

For exam preparation, it is crucial to be able to define key terms, discuss advantages/disadvantages, explain impacts on audit risk, and design audit procedures tailored to different IT environments.

2. Information Systems, IT Risks and Their Impact on the Audit

2.1 Types of Computerised Accounting Environments

Exams often start with scenario‑based questions describing an entity’s IT environment and asking you to identify risks, controls and audit responses. Common environments include:

1. Standalone PC‑based systems

   • Example: A small business using Pastel Partner or Sage 50 installed on a single computer.
   • Risks:
     • Single point of failure (hardware crash)
     • Weak access controls (shared usernames/passwords)
     • Poor backup practices.

2. Client‑server and LAN‑based systems

   • Example: A medium‑sized manufacturer using an on‑premise ERP where multiple users access a central database server over the LAN.
   • Risks:
     • Centralised database increases impact of unauthorised access.
     • Network vulnerabilities (e.g., lack of firewalls, unpatched servers).

3. Online, real‑time systems

   • Example: A retailer using real‑time point‑of‑sale (POS) integrated directly to the general ledger.
   • Risks:
     • Immediate update of records gives little time for manual review.
     • Dependence on continuous system availability.

4. Batch processing systems

   • Example: A bank processing day‑end batch jobs to update interest on loans.
   • Risks:
     • Incorrect or incomplete batch processing affects many accounts.
     • Weak controls over scheduling and monitoring of batch jobs.

5. Cloud‑based systems / Software as a Service (SaaS)

   • Example: A startup using Xero or QuickBooks Online hosted by the vendor.
   • Risks:
     • Limited direct control over infrastructure and backups.
     • Dependence on service provider controls and security.

For AUE3702, you must be able to:

• Describe how each environment influences inherent risk and control risk.
• Explain implications for audit evidence (evidence may be digital, logs may be overwritten, etc.).
• Design audit procedures that take advantage of system features (e.g., automated logs) and compensate for system weaknesses.

2.2 IT Risks Relevant to Financial Statement Audits

Computer auditing focuses on IT risks that can lead to material misstatements in the financial statements (due to error or fraud). Important categories:

1. Data integrity risks

   • Inaccurate, incomplete or unauthorised changes to data.
   • Example: Unauthorised changes to vendor bank account details in a procurement system, leading to payments to fraudsters.

2. Processing risks

   • Errors in automated calculations, sequence of processing, or system configurations.
   • Example: Payroll system incorrectly calculating overtime because of a mis‑configured rule.

3. Access and security risks

   • Unauthorised access to programmes or data; failure to segregate duties.
   • Example: A user with rights to create suppliers and capture payments, defeating segregation of duties.

4. Change management risks

   • Inadequately controlled system changes leading to bugs, data corruption or loss of functionality.
   • Example: A new update to the stock module causing negative stock quantities and incorrect cost of sales.

5. Availability and continuity risks

   • System downtime or data loss affecting business operations and completeness of accounting records.
   • Example: A ransomware attack encrypting the accounting database, resulting in loss of records for part of the year.

6. Interface and integration risks

   • Errors when data moves between systems (e.g., POS to GL, HR to payroll).
   • Example: Sales captured in POS not fully imported to the accounting system, leading to understatement of revenue.

In exam answers, link each risk to a financial statement assertion (occurrence, completeness, accuracy, cut‑off, classification, rights and obligations, valuation, and presentation) and to a potential misstatement.

2.3 Impact of IT on the Audit Risk Model

The audit risk model used in AUE3702 (as in other auditing modules) is:

Audit Risk (AR) = Inherent Risk (IR) × Control Risk (CR) × Detection Risk (DR)

IT affects each component:

• Inherent Risk (IR)

  • May increase due to complex IT systems, automated calculations, complex business logic.
  • May decrease for certain assertions where automation reduces random errors (e.g., automatic interest calculations with tested formulas).

• Control Risk (CR)

  • May increase if management does not implement strong IT controls (e.g., poor access controls).
  • May decrease if well‑designed automated controls are operating effectively and consistently.

• Detection Risk (DR)

  • Use of CAATs may allow auditors to reduce detection risk by testing entire populations.
  • Conversely, poor understanding of the IT environment may increase detection risk.

In scenarios, be prepared to explain how an entity’s IT environment causes you to increase or decrease IR, CR and DR, and how this changes:

• The nature of audit procedures (manual vs automated, reliance on reports vs direct data extraction).
• The timing (interim vs year‑end; continuous auditing possibilities).
• The extent (sample sizes, population testing, additional substantive tests).

2.4 Advantages and Disadvantages of Computerised Systems for Auditors

Advantages

• Stronger control environment possibilities

  • Automated controls (e.g., input validation, calculation checks, exception reports) can reduce errors.
  • Segregation of duties can be better enforced through role‑based access controls.

• Improved audit trail (if well‑configured)

  • System logs can record detailed user actions (who did what, when), improving traceability.

• Efficient data analysis

  • Ability to extract complete sets of transactions for analysis.
  • Enables analytical procedures, matching, outlier detection.

• Consistency of processing

  • Same procedures applied systematically (e.g., same depreciation formula every month).

Disadvantages

• Concentration of risk

  • Single system failure or misconfiguration can cause widespread misstatements.

• Technical complexity

  • Auditors require IT knowledge or support (e.g., IT audit specialists) to understand systems.

• Reduced visible audit trail

  • Less paper documentation; more reliance on electronic audit trails that may be overwritten or archived.

• Potential for sophisticated fraud

  • Insiders may bypass controls using privileged access, manipulating logs, or exploiting system weaknesses.

In exam answers, always consider both advantages and disadvantages, and conclude on how the auditor should respond (e.g., involve IT specialists, plan CAATs, test automated controls thoroughly).

3. IT General Controls (ITGCs) in AUE3702 and CUT Auditing Modules

3.1 Definition and Role of ITGCs

IT General Controls (ITGCs) are overarching controls that support the effective functioning of all application controls and help ensure the integrity, confidentiality and availability of systems and data. They usually apply across multiple applications and environments.

Categories most frequently examined in AUE3702 and similar modules:

1. Program Development Controls
2. Program Change Controls
3. Access (Logical Security) Controls
4. Computer Operations Controls
5. Physical and Environmental Controls (often grouped with operations)

ITGCs are important because:

• Weak ITGCs can undermine the reliability of application controls, even if the application design seems sound.
• If ITGCs are weak, auditors may need to increase substantive testing and reduce reliance on controls.

3.2 Program Development Controls

Program development controls address the process of designing, developing, acquiring and implementing new systems or major applications.

Key objectives:

• Systems meet business requirements and are properly authorised.
• Changes are tested and approved before implementation.
• Data conversion from old systems to new systems is accurate and complete.

Typical controls:

• Formal project approval: Management authorises new systems based on documented business cases.
• Systems development life cycle (SDLC) methodology:
  • Phases: Requirements → Design → Development → Testing → Implementation → Maintenance.
• User involvement: Users specify functional requirements, review system design and sign off on user acceptance testing (UAT).
• Segregation of duties: Developers should not have unrestricted access to production systems.
• Data conversion controls: Reconciliations between old and new systems, parallel runs.

Example exam scenario:
A UNISA AUE3702 question might describe a company implementing a new inventory module in its ERP system. You may be asked to list program development controls the auditor would expect to see and explain how each reduces risk of misstatement (e.g., ensuring quantities and costs of opening stock are converted correctly).

Auditor’s procedures:

• Review project documentation, including approved project charter, requirements specs, and UAT sign‑off.
• Inspect evidence of testing (test plans, test results, defect logs).
• Reperform sample data conversion reconciliations (e.g., total stock value before vs after go‑live).
• Interview users about their involvement in design and testing.

3.3 Program Change Controls

Program change controls govern modifications to existing systems, such as patches, enhancements, configuration changes, or emergency fixes.

Key risks:

• Unauthorised or untested changes introduce errors or backdoors.
• Changes to programmes affect core financial processing without adequate review.

Typical controls:

1. Formal change request process

   • Changes logged with unique IDs.
   • Justification and impact assessment documented.

2. Approval and prioritisation

   • Changes authorised by appropriate management or change advisory board.

3. Development and testing in separate environment

   • Changes developed in development/test environment, not directly in production.
   • Testing includes regression tests to ensure no unintended side‑effects.

4. Segregation of duties

   • Developers do not have direct ability to move changes into production.
   • Production deployments handled by operations or release management staff.

5. Version control

   • Source code controlled via tools (e.g., Git, SVN) ensuring traceability.

6. Post‑implementation review

   • Verify that change achieved intended objectives without causing new issues.

Auditor’s procedures:

• Inspect change management policies and compare with actual practices.
• Sample changes from the change log and trace:
  • Request → Approval → Development → Testing → Approval to deploy → Deployment evidence.
• Confirm no direct developer access to production code repositories or servers.
• For major changes affecting key controls (e.g., credit limit checks), perform re‑testing of application controls post‑change.

Example exam angle:
Explain the impact on audit risk if change controls are weak. Answer: Increased risk that unauthorised or faulty changes compromise key application controls, so the auditor may not rely on automated controls and must increase substantive testing.

3.4 Access Controls (Logical Security)

Access controls (logical security) ensure that only authorised users have access to systems and data, and that their access rights are appropriate to their job responsibilities.

Objectives:

• Maintain confidentiality (e.g., payroll data).
• Maintain integrity (preventing unauthorised changes).
• Support segregation of duties (e.g., separate initiation, approval, and recording).

Typical controls:

1. User provisioning and de‑provisioning

   • Formal process to create, change and delete user accounts.
   • Access requests approved by line managers.
   • Immediate removal of access when employees leave.

2. Authentication controls

   • Strong passwords (minimum length, expiry, complexity).
   • Multi‑factor authentication (where feasible), especially for remote access.

3. Authorisation (role‑based access)

   • Users assigned to roles or profiles with necessary permissions only.
   • Periodic review of user access rights by management.

4. Logging and monitoring

   • System logs of login attempts, privileged activities, changes to master data.
   • Regular review of logs for suspicious activities.

5. Restriction of privileged access (e.g., administrators)

   • Limited number of admin accounts; strong controls over their use.
   • Separate generic shared accounts discouraged or tightly controlled.

Auditor’s procedures:

• Obtain user access listing for key systems (e.g., general ledger, payroll, procurement).
• Test a sample of users for appropriate access (e.g., no incompatible duties such as creating and approving payments).
• Test terminations: select sample of resigned employees and verify their access was removed promptly.
• Evaluate password parameters and other configuration settings.
• Review exceptions and security incident reports.

Exam tip:
When asked about segregation of duties in computerised environments, remember to connect role design and access rights to typical functions:

• Initiation (capture of transaction)
• Authorisation/approval
• Recording in accounting records
• Custody of assets.

3.5 Computer Operations and Physical Controls

Computer operations controls ensure that IT operations are carried out reliably and securely on a day‑to‑day basis. This includes job scheduling, backup and recovery, incident management and batch processing.

Typical controls:

1. Job scheduling and monitoring

   • Formal schedules for batch jobs (e.g., daily GL postings, month‑end processes).
   • Automated alerts for failed jobs and procedures for follow‑up.

2. Backups and recovery

   • Regular backups of system and data (e.g., daily incremental, weekly full).
   • Off‑site storage of backups or secure cloud backups.
   • Regular testing of data restoration procedures.

3. Incident and problem management

   • Logging of system incidents (downtime, errors).
   • Root cause analysis and corrective actions.

4. Physical and environmental controls

   • Secure server rooms (locked, access controlled, CCTV).
   • Fire suppression systems, climate control, UPS power.

5. Anti‑virus and patch management

   • Up‑to‑date anti‑malware on servers and endpoints.
   • Timely application of security patches and updates.

Auditor’s procedures:

• Review backup policies and inspect evidence of backup completion and restoration tests.
• Inspect server rooms (if practical) or obtain photos/certificates of physical security controls.
• Evaluate incident logs and verify major incidents were resolved appropriately.
• Inquire about disaster recovery and business continuity plans and test, where relevant, existence of failover sites or arrangements.

Exam questions often require you to list and explain ITGCs in a given scenario, then discuss their impact on the auditor’s reliance on automated controls. Make sure your explanations always link the control to the risk it addresses, and state the implication for the financial statement audit.

4. Application Controls in Computerised Accounting Systems

4.1 Nature and Purpose of Application Controls

Application controls are automated (or sometimes manual) controls built into specific computer applications that ensure completeness, accuracy, authorisation and validity of transaction processing. They typically operate at the level of:

• Specific transaction cycles (sales, purchases, payroll).
• Modules in ERP systems (accounts receivable, inventory, fixed assets).

Application controls protect against data entry mistakes, invalid transactions, processing errors, and unauthorised data changes at the application level.

Key categories for AUE3702 and similar modules:

1. Input controls
2. Processing controls
3. Output controls
4. Master file and standing data controls
5. Interface controls

4.2 Input Controls

Input controls ensure that data entering the system is valid, complete, accurate and authorised.

Typical types:

• Data validation checks:

  • Field format checks (e.g., date field must be dd/mm/yyyy).
  • Range checks (e.g., quantity cannot be negative, discount cannot exceed 20%).
  • Validity checks (e.g., customer codes must exist in master file).
  • Check digit verification (e.g., for account numbers).

• Edit and reasonableness checks:

  • Compare input to historical averages or budgets (e.g., gross salary increases above 50% flagged).

• Sequence checks:

  • Ensuring no missing or duplicate document numbers (e.g., invoice numbers).

• Required fields and completeness checks:

  • Mandatory fields must be completed (e.g., tax code, VAT registration number).

• Authorisation controls:

  • Electronic approvals before transactions are posted (e.g., purchase orders must be approved by a manager).

• Batch controls (for batch input):

  • Control totals (record count, hash totals) used to verify that all items in a batch have been input and processed.

Example in South African context:
In a university’s procurement system, input controls ensure that supplier banking details are captured correctly (e.g., bank code must match list of valid South African banks, account number length checks, IBAN/SWIFT fields for foreign payments).

Auditor’s procedures:

• Inspect configuration of input controls in system settings or documentation.
• Perform test of controls:
  • Attempt to input invalid data (e.g., negative quantity, invalid date) in a test environment and observe system rejection.
• Use CAATs to identify anomalies indicating input control failures (e.g., negative stock levels, duplicate invoice numbers).

4.3 Processing Controls

Processing controls ensure that transactions, once entered, are processed completely, accurately and in the correct period.

Examples:

• Run‑to‑run controls

  • Totals from one processing stage are reconciled to another (e.g., from sales order to invoice to GL).

• Automated calculations

  • System automatically calculates VAT at standard rate for South African sales.
  • System applies payroll tax (PAYE) based on up‑to‑date SARS tax tables.

• Posting controls

  • Only balanced journal entries (debits = credits) are posted.
  • System prevents posting to closed periods or uses strict period‑end procedures.

• Exception reports

  • Reports listing transactions that failed to process or that breached thresholds (e.g., credit limit exceeded).

Auditor’s procedures:

• Walk through a sample transaction from initiation to posting in the general ledger, verifying system‑driven checks.
• Inspect exception reports and confirm they are reviewed and resolved by responsible personnel.
• Recalculate sampled automated calculations manually or using independent tools and compare to system results.

Exam angle:
Describe processing controls in a payroll system and explain how they address risks such as incorrect net pay, incorrect deductions, and wrong posting to GL.

4.4 Output Controls

Output controls ensure that system outputs (reports, statements, screen displays) are accurate, complete, distributed to the right people, and used appropriately.

Examples:

• Control over report generation

  • Access to sensitive reports (e.g., payroll reports) restricted to authorised users.

• Reconciliations and reviews

  • Daily listings of transactions reviewed and signed off by supervisors.
  • Bank reconciliations tying system bank balance to bank statements.

• Distribution controls

  • Secure methods to deliver reports (e.g., encrypted emails, secure portals).
  • Logs of who accessed which reports.

• Archiving and retention

  • System retains reports and electronic documents for the period required by legislation and policy.

Auditor’s procedures:

• Observe management’s review of key reports (e.g., detail of journal entries above a threshold).
• Inspect evidence of reconciliations (e.g., signatures, dates, reconciling items).
• Confirm that sensitive outputs (e.g., payroll with names and salaries) are only accessible to appropriate staff.

4.5 Master File and Standing Data Controls

Master files hold critical, relatively stable data such as customer details, supplier details, employee records, product lists, tax rates. Standing data errors or unauthorized changes can cause systematic misstatements.

Controls:

• Restricted access to master file maintenance

  • Only designated staff can create, change or delete master records.

• Approval workflows

  • New suppliers or changes to bank details require independent approval.

• Audit trails

  • System logs recording who changed what data, when, and from what value to what value.

• Periodic reviews

  • Regular review of master files for accuracy and completeness (e.g., remove inactive customers or suppliers).

• Verification procedures

  • Bank account changes confirmed with supplier using independent contact details.

Auditor’s procedures:

• Inspect user access matrices for master file maintenance privileges.
• Obtain change logs and test a sample of changes for proper authorisation.
• For high‑risk standing data (e.g., supplier bank accounts, tax rates), perform independent verification (e.g., confirm tax rates with SARS tables, confirm bank details with suppliers).

4.6 Interface and Integration Controls

Most organisations operate multiple systems that must share data (e.g., HR system interfacing with payroll, POS system interfacing with GL). Interface controls ensure that data is transferred completely, accurately, and without duplication.

Examples:

• Record counts and control totals sent from source system and compared in destination system.
• Error logs for failed interface transactions; processes for investigating and reprocessing errors.
• Reconciliation of interface totals to overall GL postings or sub‑ledger totals.
• Timing controls ensuring all day’s transactions are included in daily batch transfers.

Auditor’s procedures:

• Understand the data flow between systems using system flowcharts or data flow diagrams.
• Inspect interface control logs, error reports, and reconciliations.
• Reperform sample reconciliations of interface totals to GL or sub‑ledgers.
• Use CAATs to compare total records in source vs destination tables for a given period.

Exam‑type scenario:
A retailer using an integrated POS and GL system may be described, and you may be asked to describe interface controls that ensure all sales are recorded accurately and completely, and audit procedures to evaluate those controls.

5. Computer-Assisted Audit Techniques (CAATs) and Practical Exam Application

5.1 Introduction to CAATs

Computer‑Assisted Audit Techniques (CAATs) are methods that use computer software and tools to perform audit procedures, especially on large volumes of electronic data.

In AUE3702 and related CUT and UNISA modules, CAATs are tested in two main ways:

1. Conceptual questions

   • Define CAATs, distinguish types (e.g., test data, integrated test facilities, parallel simulation, data extraction and analysis).

2. Practical application questions

   • Given a dataset (described in text) and a specific objective (e.g., identify duplicate payments), you must design CAATs procedures using generalised audit software or spreadsheet functions.

Advantages of CAATs:

• Test 100% of a population or large samples efficiently.
• Enable complex analysis (e.g., trend analysis, Benford’s law, cross‑matching lists).
• Provide better evidence when systems are highly automated.

Disadvantages/limitations:

• Require IT skills and understanding of data structures.
• Depend on data quality and completeness.
• Data extraction may be restricted by client’s system or security constraints.

5.2 Types of CAATs

5.2.1 Test Data

Test data is fictitious data created by the auditor and processed by the client’s application to test specific controls.

Key features:

• Auditor prepares test cases (valid and invalid transactions).
• Test data is run through the client’s system (usually in a test environment).
• Auditor reviews results to determine whether controls (e.g., input validation, edits) work as expected.

Limitations:

• Only tests the specific cases prepared (not full population).
• Requires separate environment to avoid corrupting real data.

Example:
To test an input validation control in a payroll system, the auditor may input a fictitious employee with a negative salary and expect the system to reject this input.

5.2.2 Integrated Test Facility (ITF)

An integrated test facility involves creating fictitious entities (e.g., dummy customer, dummy department) within the client’s live system to process test transactions without affecting real balances (because test balances are segregated or reversed).

Characteristics:

• Test data is entered during normal processing, without users always being aware.
• Test entities are flagged in the system so their transactions can be identified.

Limitations:

• Must ensure test data does not contaminate real reports.
• Requires careful design and agreement with management.

5.2.3 Parallel Simulation

Parallel simulation means the auditor uses an independent programme to re‑process client data and compare results to the client’s outputs.

Example:

• Auditor extracts the client’s loan portfolio data and runs it through independently programmed interest calculation routines in audit software, then compares calculated interest to the amounts recognised by the client.

Benefits:

• Strong evidence on processing accuracy of critical calculations.
• Particularly useful where calculations are complex or high‑risk.

5.2.4 Data Extraction and Analysis (Generalised Audit Software)

This is the most frequently examined type of CAATs in AUE3702 and related modules.

Tools can include:

• Dedicated audit packages (e.g., IDEA, ACL).
• Database tools (SQL).
• Spreadsheet tools (e.g., Excel, Excel Power Query).

Common data analysis CAATs:

• Stratification: Grouping transactions by value bands to identify high‑value transactions for targeted testing.
• Sampling: Selecting samples using random or systematic methods.
• Duplicate detection: Identifying duplicate invoice numbers, amounts, supplier details.
• Gap detection: Finding missing invoice numbers or receipt numbers.
• Aging analysis: Analyzing aged debtors or creditors.
• Join and match: Comparing two data sets (e.g., employee list vs vendor list to identify conflicts of interest).
• Summarisation: Totaling transactions by account, user, date, or department to identify unusual patterns.

Exam ability required:

• Clearly describe steps to perform specific tests (even if software is not named).
• Link each CAAT procedure to a financial assertion and risk.

5.3 Designing CAATs for Common Audit Objectives

5.3.1 Detecting Duplicate Payments (Creditors / Payables)

Objective: Ensure completeness and accuracy of expenses and liabilities; detect possible errors or fraud from duplicate supplier payments.

Typical CAATs:

• Extract all supplier payment transactions for the year.
• Use audit software to sort and identify duplicates based on:
  • Invoice number + supplier + amount.
  • Same bank account numbers used for multiple suppliers (possible fictitious suppliers).
• Generate exception report listing potential duplicates for further investigation.

Assertions addressed:

• Accuracy of expenses and creditors.
• Occurrence (duplicate payments may indicate fictitious or unauthorised expenses).

5.3.2 Testing Revenue Completeness (Retail POS to GL)

Objective: Ensure all sales recorded in the POS system are completely and accurately reflected in the general ledger.

CAATs:

1. Extract daily sales totals from POS system for the period.
2. Extract GL postings to sales account for same period.
3. Use join/match function to match POS totals to GL totals by date.
4. Investigate any unmatched days or significant differences (beyond expected timing differences like cut‑off).

Assertions addressed:

• Completeness and accuracy of revenue.
• Cut‑off if mismatches appear around year‑end.

5.3.3 Testing Payroll for Ghost Employees

Objective: Detect ghost employees (people being paid but not working for the entity), which is a known risk in South African public sector and private sector environments.

CAATs:

• Extract employee master file from HR system and payroll file from payroll system.
• Compare HR employee list to payroll list:
  • Identify payroll employees not in HR list.
  • Identify HR employees with no salary payment (possible underpayments or data issues).
• Match employee bank account numbers across employees to detect multiple employees sharing the same bank account (possible fictitious employees).

Assertions addressed:

• Occurrence of payroll expenses.
• Completeness and accuracy of payroll records.

5.3.4 Testing Inventory Valuation and Movement

Objective: Ensure inventory is correctly valued and inventory movements are complete and accurate.

CAATs:

• Extract inventory transactions for the year (receipts, issues, stock adjustments).
• Perform reconciliation between:
  • Opening balance + purchases − sales/usage ± adjustments = closing balance.
• Identify negative stock quantities as potential red flags.
• Compare standard cost or unit cost across items and periods; flag sudden large changes in cost that might indicate errors.

Assertions addressed:

• Existence and valuation of inventory.
• Completeness and accuracy of inventory movement records.

5.4 Practical Exam Tips for CAATs Questions

1. Understand the data

   • Clearly state what data you will request: fields, date range, systems.
   • Example: “Obtain a complete extract of all purchase invoices processed during the year, including invoice number, supplier code, date, gross amount, VAT, and GL account.”

2. Explain the technical steps in simple terms

   • Even without specifying particular software, describe actions like:
     • Sort by specific fields.
     • Use “summarise” or “group by” to obtain totals.
     • Use “join” or “match” to compare different files.

3. Link each step to the audit objective

   • Each test should be justified in terms of which risk/assertion it addresses.

4. Consider data completeness and integrity

   • Mention that you will perform control totals and basic reconciliations to ensure that the extracted data is complete (e.g., compare record counts and total amounts to the system’s own totals).

5. Address limitations

   • Where appropriate, state that if CAATs cannot be performed (e.g., data not accessible), you would fall back on alternative manual or substantive procedures.

6. IT Governance, Outsourcing and the Auditor’s Response in AUE3702 and CUT Modules

6.1 IT Governance and Frameworks (e.g., COBIT, King IV)

South African entities are expected to practice sound IT governance, guided by frameworks like:

• King IV Report on Corporate Governance for South Africa

  • Emphasises that governing bodies must ensure technology and information are effectively governed, aligned with overall strategy and risk management.

• COBIT (Control Objectives for Information and Related Technologies)

  • A framework providing best practices for IT management and governance, focusing on aligning IT with business, managing risk, and providing reliable information.

In exam answers:

• Describe IT governance as structures, processes and mechanisms that ensure IT supports and enhances the organisation’s strategy and objectives, while managing IT risks and complying with regulations.

Key IT governance concepts:

• Alignment of IT strategy with business objectives.
• Value delivery from IT investments.
• Risk management relating to IT.
• Resource management (people, infrastructure, data).
• Performance measurement (using KPIs and metrics).

Auditor’s interest:

• Strong IT governance typically enhances the control environment and may reduce control risk.
• Weak IT governance can indicate higher risk of IT failures or security breaches, increasing audit risk.

6.2 Outsourcing and Service Organisations (e.g., Cloud Providers, Payroll Bureaus)

Many South African organisations, including universities and municipalities, outsource key IT services, such as:

• Cloud‑based accounting systems (SaaS).
• Payroll processing to specialist bureaus.
• Data hosting and backup services.

Key concept: Service organisations and relevant auditing standards (e.g., ISAE 3402 report on controls at a service organisation).

Types of reports:

• Type 1 report: Describes service organisation’s controls and gives opinion on design at a specific date.
• Type 2 report: Includes description and tests of operating effectiveness of controls over a period.

Auditor’s responsibilities:

• Understand the nature of services provided by the service organisation.
• Determine whether the service organisation’s controls are relevant to the user entity’s internal control over financial reporting.
• Obtain sufficient appropriate audit evidence about these controls, which may involve:
  • Obtaining and evaluating a service auditor’s report (preferably Type 2).
  • Contacting service organisation directly or using another auditor.
  • Performing procedures at the user entity that cover the effects of service organisation’s controls.

Exam scenario example:

• A UNISA AUE3702 paper might describe a company that outsources its payroll to an external bureau. You may be asked to discuss:
  • Risks arising from this arrangement (e.g., lack of direct control over access, data security, processing).
  • Audit procedures to obtain evidence over payroll completeness and accuracy.

Typical risks:

• Confidentiality breaches of payroll data.
• Unauthorised changes to payroll (e.g., adding ghost employees).
• Inadequate backup and recovery by provider.

Mitigating controls:

• Service level agreements (SLAs) specifying responsibilities, performance, and security standards.
• Regular reconciliations between service provider reports and client’s GL.
• Management’s independent review of payroll input and output.

6.3 Cloud Computing and Virtualised Environments

Cloud computing presents new challenges for auditors:

• Infrastructure as a Service (IaaS): Client controls operating systems and applications but uses provider’s infrastructure.
• Platform as a Service (PaaS): Provider controls platform; client deploys applications.
• Software as a Service (SaaS): Provider hosts entire application; client mainly configures and uses software.

Key issues:

• Data location: Data may be housed in foreign data centres, with regulatory implications (e.g., POPIA in South Africa).
• Access and security: Dependence on provider’s controls.
• Availability: Risk of downtime affecting transaction recording.

Auditor’s considerations:

• Evaluate contracts and SLAs to understand responsibilities, rights to audit, data retention.
• Obtain and evaluate third‑party assurance reports on cloud provider controls.
• Verify that client performs regular backups (where possible) or obtains export capabilities for critical data.
• Assess whether application controls configured in the SaaS system are adequate (e.g., access profiles, approval workflows).

Exam‑style question:
Discuss risks and audit responses for a company using a cloud‑based accounting system like Xero to process all its accounting transactions.

Sample answer points:

• Risks:
  • Dependence on internet connectivity.
  • Limited physical control over data centre.
  • Access management mainly enforced through web credentials.
• Audit responses:
  • Evaluate provider’s security certifications and service auditor reports.
  • Assess the client’s user access and configuration management within the cloud application.
  • Perform CAATs using data exports from the cloud system.

6.4 Ethics, Professional Skepticism and IT

Computer auditing also intersects with audit ethics and professional skepticism:

• Over‑reliance on management’s representations about IT controls can be dangerous; auditors must obtain independent evidence.
• Familiarity with IT personnel or reliance on the same outsourced service provider across many clients may threaten independence or professional skepticism.
• Use of CAATs should be planned and documented with the same professional care as manual procedures.

In exam answers, emphasise:

• The need for auditors to maintain professional competence in IT topics relevant to their engagements.
• The importance of critical evaluation of system‑generated evidence, including testing source data and processing.

6.5 Integrating Knowledge Across AUE3702, CUT Auditing and AIS Modules

The AUE3702: Computer Auditing module at UNISA and equivalent modules at CUT and other institutions draw heavily on core auditing principles from other subjects (like AUE2601, AUE2602, AUD40AB) and on accounting information systems knowledge.

To succeed in exams:

• Always link IT topics (ITGCs, application controls, CAATs, outsourcing) back to:

  • The audit risk model.
  • Assertions for classes of transactions, account balances and presentation.
  • Internal control components (control environment, risk assessment, control activities, information and communication, monitoring).

• Structure written answers clearly:

  1. Identify the risk (inherent or control risk).
  2. Describe the relevant IT control(s) (general or application).
  3. Explain the impact on audit approach (test of controls, substantive testing, CAATs).
  4. Where relevant, discuss the role of governance and outsourcing.

• Use realistic South African examples:

  • Entities using popular local accounting software (Pastel, Sage, SAP).
  • Regulatory references (POPIA, SARS requirements, Companies Act).
  • Governance codes (King IV) and IRBA standards.

By mastering these integrated aspects of computer auditing, students in UNISA’s AUE3702 and CUT’s advanced auditing and AIS modules will be well prepared both for examinations and for practical audit work in South African organisations that rely heavily on information technology.