Ch 4: Internal Control Fundamentals

Learning objectives

By the end of this chapter you will be able to:

• Explain the main components of an internal control system and how they work together to support organisational objectives.
• Identify typical control objectives within major transaction cycles and explain why they matter for financial reporting.
• Analyse the inherent limitations of internal controls and explain the implications for audit planning and execution.
• Evaluate control strengths and weaknesses and explain how they influence the audit approach, including the balance between testing controls and substantive procedures.

Overview & key concepts

An internal control system is the framework of policies, processes, behaviours, and oversight mechanisms used to manage risk and help an organisation achieve its objectives. In practice, internal control supports three broad organisational outcomes:

• Reliable financial reporting
• Effective and efficient operations
• Compliance with laws, regulations, and internal policy

These organisational outcomes are not the same as financial statement assertions. For financial reporting, controls in each transaction cycle are designed to support the assertions that underpin the numbers and disclosures, including:

• Occurrence (transactions recorded actually happened)
• Completeness (all relevant transactions/balances are recorded)
• Accuracy (amounts and data are recorded correctly)
• Cut-off (recorded in the correct accounting period)
• Classification (recorded in the correct account and presentation category)
• Rights and obligations (the entity controls the assets and owes the liabilities)
• Valuation and allocation (balances are measured appropriately, including estimates)

Internal control does not change the accounting equation, but it influences whether recorded assets, liabilities, equity, income, and expenses are complete, valid, accurately measured, properly classified, and recorded in the correct period.

Components of internal control

A useful way to remember internal control is as a loop rather than a checklist. The organisation sets the tone (control environment), identifies what could go wrong (risk assessment), builds responses into day-to-day routines and systems (control activities), ensures information reaches the right people at the right time (information and communication), and checks and improves the system over time (monitoring). Weakness in any part of the loop reduces the reliability of the rest.

1) Control environment

The control environment is the foundation. It reflects governance, ethical values, management style, competence, accountability, and how seriously policies are applied. A strong control environment makes other controls more likely to operate consistently.

Example: A clear code of conduct, robust oversight by those charged with governance, and performance measures that reward compliant behaviour reduce incentives to bypass procedures.

2) Risk assessment

Risk assessment is the process of identifying and analysing risks that could prevent objectives being achieved, then deciding how those risks should be managed.

Example: If there is a risk of unauthorised access to accounting records, management may restrict access rights and review system logs.

3) Control activities

Control activities are the specific procedures that reduce risk. They may be manual or automated, preventive or detective.

Common control activities include:

• Authorisation and approval
• Segregation of duties
• Reconciliations (bank, control accounts, supplier statements)
• Physical controls (locks, restricted access, counts)
• System controls (validation checks, workflow rules)
• Reviews of performance and exception reporting

4) Information and communication

This component ensures that relevant information is captured, processed, and communicated so that people can perform their responsibilities.

Example: An integrated sales and inventory system that records dispatches promptly supports accurate revenue cut-off and inventory records.

5) Monitoring

Monitoring means reviewing whether controls exist, whether they are operating as intended, and whether they remain appropriate as the business changes. Monitoring includes ongoing supervision and separate evaluations such as internal audit work.

IT controls: application controls and IT general controls

Many controls operate through IT systems. For exam purposes, it is helpful to distinguish between:

Application controls

These are controls built into specific processes and transactions. They help ensure transactions are authorised, complete, and accurate.

Examples:

• Validation rules (e.g., cannot post a sales invoice without a customer ID)
• Automated sequence checks and completeness checks
• Automated price lists, credit limits, and tolerance checks
• System-generated exception reports and automated matching routines

IT general controls (ITGCs)

These are broader controls that support the reliability of systems overall. If ITGCs are weak, even strong application controls may not be dependable.

Common ITGC areas:

• Access controls (user provisioning, strong authentication, role-based permissions, periodic access reviews)
• Change management (approved and tested system changes, segregation between developers and live system access, controlled releases)
• IT operations (backups, recovery testing, incident management, batch processing controls, interface monitoring)

Control objectives within transaction cycles

Control objectives describe what the control system is trying to achieve in each cycle. For financial reporting, these objectives typically align to assertions.

Sales and receivables (revenue cycle)

Typical objectives include:

• Sales are recorded only when goods/services are provided (occurrence).
• All valid sales are recorded (completeness).
• Sales, returns, and credit notes are recorded in the correct period (cut-off).
• Revenue and receivables are recorded at correct amounts (accuracy).
• Receivables reflect recoverable amounts, including appropriate expected credit losses (valuation).

Purchases and payables (expenditure cycle)

Typical objectives include:

• Purchases occur only for business purposes and are properly authorised (occurrence).
• All liabilities incurred are recorded (completeness).
• Purchases are recorded at correct amounts and in the right accounts (accuracy/classification).
• Expenses and inventory purchases are recognised in the correct period (cut-off).
• Payments are made only once and only to valid suppliers (occurrence/accuracy).

Inventory

Typical objectives include:

• Inventory records reflect actual quantities on hand (completeness/accuracy).
• Movements are recorded promptly and correctly (cut-off/accuracy).
• Costs are calculated using the entity’s stated method and appropriate cost components (valuation).
• Obsolete or damaged items are identified and adjusted appropriately (valuation).

Payroll

Typical objectives include:

• Only genuine employees are paid (occurrence).
• Pay rates and changes are authorised (occurrence/accuracy).
• Time worked is approved and accurately processed (accuracy).
• Deductions are calculated correctly and remitted on time (accuracy/completeness).

Cash and banking

Typical objectives include:

• Cash receipts are recorded completely and banked promptly (completeness).
• Payments are authorised and supported by valid documentation (occurrence).
• Bank reconciliations are performed regularly and reviewed independently (accuracy).
• Access to payment systems is restricted and monitored (occurrence/accuracy).

Preventive and detective controls

• Preventive controls stop a problem before it occurs (e.g., approval limits, access controls, system validation checks, segregation of duties).
• Detective controls identify problems after they occur so corrective action can be taken (e.g., reconciliations, exception reports, management reviews).

Strong systems combine both: prevention reduces the number of issues, while detection provides feedback and discourages override.

Segregation of duties and compensating controls

Segregation of duties reduces risk by ensuring that no one person controls an entire process from start to finish. In a typical transaction flow, duties are separated between:

• Authorising transactions
• Recording transactions
• Custody of assets and access credentials
• Reviewing and reconciling (independent checks)

Where full segregation is impractical, risk is reduced through compensating controls such as:

• Enhanced supervision by management
• Independent review of bank reconciliations and exception reports
• Dual authorisation for payments
• Periodic independent inventory counts
• Mandatory vacations and role rotation for key staff

Inherent limitations of internal controls

Internal controls can raise confidence in the numbers, but they cannot make misstatement risk disappear. The reasons fall into three practical groups:

People and behaviour risks

Even competent staff make mistakes under time pressure, misunderstand instructions, or apply inconsistent judgement. Some individuals will intentionally bypass rules. Senior staff may override controls (sometimes for legitimate operational reasons), creating a particular fraud risk because override can affect approvals and system permissions. Collusion between individuals can also defeat controls that rely on segregation of duties.

Design trade-offs

Controls are designed for reasonable protection, not perfect protection. Management must balance the cost and disruption of controls against the risks they are meant to reduce, so some exposure will always remain.

Systems and change risks

Reliance on IT introduces new failure points—access rights that are too broad, poorly controlled system changes, interface failures, or weak backup and recovery arrangements. A control that worked previously may be less effective after growth, new products, system upgrades, or staff turnover.

Audit implications: linking controls to risk and procedures

A control deficiency increases the likelihood of misstatements and therefore increases the risk of material misstatement. This typically leads to an audit response such as:

• more extensive substantive procedures (larger samples or broader coverage),
• testing performed closer to the reporting date, and/or
• increased focus on areas where errors can be concealed (often completeness and valuation).

Where controls appear well designed and are shown to operate effectively, it may be possible to place reliance on them. This can reduce the extent of some substantive procedures or allow some work to be performed earlier, depending on the risk assessment and the nature of the balance or transaction stream.

Substantive procedures are, however, performed for each material class of transactions, account balance, and disclosure. The strength of controls influences the nature, timing, and extent of substantive work, but does not remove the need to obtain direct evidence over material areas.

Exam-directional cues:

• If controls are weak, the typical response is to increase sample sizes, move testing closer to year end, and target higher-risk assertions (often completeness and valuation).
• If controls are strong and tested as effective, the typical response is to reduce extent in some areas and/or perform some testing earlier, while still completing substantive procedures over material balances and disclosures.

Worked example

Narrative scenario

This is an integrated controls illustration. It combines cash and banking routines with purchase processing, inventory reporting, and revenue-related controls to show how different controls interact across cycles.

ABC Retailers operates online and through physical stores. During January the following occurred:

1. Sales of $150,000 were made: $120,000 collected in cash and $30,000 on credit.
2. Inventory purchases totalled $80,000: $60,000 paid in cash and $20,000 bought on credit.
3. A customer returned goods priced at $5,000, and a credit note was issued.
4. Salaries of $25,000 were paid.
5. A bank reconciliation identified a $500 bank charge not recorded in the cash book.
6. A supplier invoice of $2,000 was received but had not yet been recorded at month end.
7. A payment of $1,500 was made to a supplier by cheque; it had not cleared the bank at month end.
8. A cash deposit of $3,000 was in transit at month end.
9. A system validation rule blocked posting an invoice unless a purchase order number was entered.
10. An exception report identified negative inventory balances for two items.
11. A monthly review was performed on credit notes above $2,000.
12. Dual authorisation was required for payments above $5,000.

Additional information: Opening cash book balance on 1 January was $100,000. The bank statement balance at 31 January was $131,500.

Required

1. Compute the closing cash book balance after accounting for all cash book entries and adjustments.
2. Prepare a bank reconciliation statement for January.
3. Identify and explain control deficiencies and suggest improvements.
4. Discuss the impact of these controls on the financial statements.

Solution

1) Closing cash book balance

Cash book (before posting bank charge):

• Opening balance: $100,000
• Cash sales receipts: +$120,000
• Cash paid to suppliers (inventory purchases): -$60,000
• Salaries paid: -$25,000
• Cheque paid to supplier (issued): -$1,500

Cash book balance before bank charge = $133,500

Adjust for item identified by the bank reconciliation:

• Bank charge not yet in cash book: -$500

Closing cash book balance (31 January) = $133,000

Notes:

• Credit sales affect receivables, not cash.
• Credit purchases and unrecorded invoices affect payables and profit measurement, not cash until payment occurs.
• Timing differences (deposit in transit, unpresented cheques) explain differences between cash book and bank statement.

2) Bank reconciliation statement (31 January)

Balance per bank statement (31 January): $131,500 Add: Deposit in transit: +$3,000 Less: Unpresented cheque: -$1,500

Adjusted bank balance = $133,000

Balance per adjusted cash book = $133,000

The reconciliation agrees.

3) Control deficiencies and improvements

(a) Unrecorded supplier invoice ($2,000)

• Deficiency: Invoices not recorded promptly increase the risk of understated payables and understated expenses (or inventory) at period end, affecting completeness and cut-off.
• Improvement: Use an invoice log and workflow: record invoices on receipt, match to purchase orders and goods received notes, and post promptly. Reconcile supplier statements to the payables ledger to detect missing invoices.

(b) Negative inventory balances on exception report

• Deficiency: Negative balances suggest failures in recording receipts/issues or weaknesses in master data and process discipline. This increases the risk of misstated inventory quantities and misstated cost of sales (accuracy and valuation).
• Improvement: Prevent issues being recorded before receipts where appropriate, require approval for inventory adjustments, investigate causes (timing errors, unit-of-measure issues, barcode errors), and strengthen cycle counts with reconciliation back to records.

(c) Threshold and pattern risk (credit notes and payments)

• Deficiency: Threshold-based reviews can be bypassed by splitting items into amounts just below the limit.
• Improvement: Add analytics to identify patterns (frequent small credit notes, repeated payments just under approval limits) and periodically reassess thresholds.

4) Impact of the controls on the financial statements

• Bank reconciliation supports accurate cash reporting and identifies unrecorded items. Here it ensures the $500 charge is recorded, preventing overstatement of cash and profit.
• Purchase order validation supports the occurrence and accuracy of purchases and payables by reducing the risk of unsupported invoices.
• Credit note review reduces risk of inappropriate revenue reduction or concealment of fraud through unauthorised refunds, supporting occurrence and accuracy in revenue-related balances.
• Inventory exception reporting draws attention to conditions that can distort inventory and cost of sales and therefore gross profit, supporting accuracy, cut-off, and valuation.
• Dual authorisation reduces risk of significant unauthorised cash outflows, supporting the occurrence of payments and safeguarding liquid assets.

Common pitfalls and misunderstandings

• Confusing organisational outcomes (reporting/operations/compliance) with financial statement assertions.
• Treating preventive and detective controls as substitutes rather than complements.
• Assuming automated controls are reliable without strong IT general controls (access, change management, operations).
• Weak segregation of duties, especially where one person can create suppliers, amend bank details, and process payments.
• Performing reconciliations but not reviewing them independently or not clearing reconciling items promptly.
• Ignoring how thresholds can be bypassed by splitting transactions.
• Underestimating management override and collusion risks in areas with concentrated authority.
• Poor documentation of controls and evidence of performance, weakening monitoring and audit trail review.

Summary and further reading

Internal control supports reliable reporting, efficient operations, and compliance by reducing the risk of error and fraud. The system can be understood as a continuous loop: the organisation sets the tone (control environment), identifies risks (risk assessment), embeds responses into processes (control activities), communicates information effectively (information and communication), and reviews and improves performance (monitoring). Control objectives within transaction cycles support financial statement assertions such as occurrence, completeness, accuracy, cut-off, classification, rights/obligations, and valuation.

Internal control has limitations arising from human behaviour, design trade-offs, and systems/change risk. These limitations shape audit planning: control deficiencies increase the risk of material misstatement and usually lead to more extensive and later substantive procedures. Strong controls may be relied upon where tested as effective, influencing the nature, timing, and extent of substantive work, but substantive procedures are still performed over each material class of transactions, account balance, and disclosure.

For further reading, use introductory financial reporting texts and governance/risk/control guidance focused on how risks translate into misstatements and how controls provide prevention and detection.

FAQ

What are the main components of an internal control system?

The components are the control environment, risk assessment, control activities, information and communication, and monitoring. Together they form a loop that designs, operates, and improves controls over time.

How do organisational outcomes differ from financial statement assertions?

Organisational outcomes describe what internal control is trying to achieve overall (reliable reporting, efficient operations, compliance). Financial statement assertions describe what must be true about reported transactions and balances (for example occurrence, completeness, accuracy, cut-off, and valuation). Controls are designed within cycles to support these assertions.

How do preventive and detective controls differ?

Preventive controls reduce the chance an error or fraud occurs (such as authorisation limits and validation checks). Detective controls identify issues after they occur (such as reconciliations and exception reports) so they can be corrected.

What are IT general controls and why do they matter?

IT general controls cover access, change management, and IT operations (including backups and recovery). They matter because weak IT general controls can undermine reliance on application controls embedded in business systems.

How do internal controls influence audit work?

Control deficiencies increase the risk of material misstatement and usually lead to more substantive work, performed closer to year end. Strong controls, if tested as operating effectively, may allow reduced extent or earlier timing of some substantive procedures, but substantive procedures still cover each material class of transactions, account balance, and disclosure.

Summary (Recap)

This chapter explains internal control fundamentals: the five components of internal control, control objectives across transaction cycles, and the distinction between organisational outcomes and financial statement assertions. It outlines preventive and detective controls, segregation of duties, and compensating controls. It also presents inherent limitations of internal control and shows how these limitations affect audit planning through their impact on the risk of material misstatement. The worked example demonstrates how cash and banking controls, purchase processing controls, and inventory exception reporting interact to support reliable financial reporting.

Glossary

Internal control The overall framework of policies, procedures, behaviours, and oversight used to manage risk and support reliable reporting, efficient operations, and compliance.

Financial statement assertions The characteristics that must be true about transactions, balances, and disclosures (for example occurrence, completeness, accuracy, cut-off, classification, rights/obligations, and valuation).

Control objective A practical outcome a control system aims to achieve within a process, typically aligned to one or more assertions.

Control activity A specific procedure that reduces risk, such as authorisation, reconciliations, access controls, system validation, and independent reviews.

Control environment The governance and behavioural foundation that influences how seriously controls are designed, implemented, and followed.

Risk assessment The process of identifying and analysing risks to objectives and deciding how to manage those risks.

Monitoring Ongoing supervision and periodic evaluation of controls to confirm they operate effectively and remain appropriate.

Segregation of duties Separating key responsibilities (authorising, recording, custody, and review) so errors or fraud are harder to commit and easier to detect.

Preventive control A control designed to stop errors or fraud before they occur.

Detective control A control designed to identify errors or fraud after they occur so corrective action can be taken.

Application controls Controls embedded in transaction processing systems that help ensure completeness, accuracy, authorisation, and valid processing.

IT general controls (ITGCs) Controls over the IT environment that support reliable system operation, typically covering access, change management, and IT operations (including backups and recovery).

Management override Bypassing established controls by senior personnel, creating particular risk where approvals or system permissions are involved.

Compensating control An alternative procedure that reduces risk where a preferred control (such as full segregation of duties) is not feasible.

Control deficiency A weakness in control design or operation that increases the likelihood a misstatement or loss could occur and not be prevented or detected promptly.

Residual risk The level of risk remaining after controls have been applied.

Collusion Cooperation between two or more individuals to bypass controls, often to commit or conceal wrongdoing.

Learning objectives

By the end of this chapter, you should be able to:

• Produce a clear system narrative for a business process, highlighting where controls operate and what evidence should exist.
• Draft a simple flowchart that shows the movement of documents, data, and authorisations through a process.
• Use a questionnaire to assess whether control design addresses key risks, including application and general IT controls that support reliability.
• Identify control deficiencies and suggest practical improvements, including compensating controls where constraints exist.
• Use system understanding to shape audit planning decisions by adjusting the nature, timing, and extent of audit procedures.

Overview & key concepts

The ability to record and evaluate systems is essential in audit and finance roles. Many business processes are easy to describe informally (“we raise an order, receive goods, then pay the supplier”), but professional work requires the process to be documented in a form that can be assessed, challenged, and linked to financial reporting risks.

System documentation helps you to:

• understand how transactions are initiated, approved, processed, recorded, and reported
• identify where errors or fraud could arise (and whether controls reduce that risk)
• design audit work efficiently by focusing on areas most likely to contain misstatements

Three practical tools are commonly used together:

• System narratives (written descriptions)
• Flowcharts (visual maps of steps and document/data flows)
• Questionnaires (structured prompts to evaluate whether controls address key risks)

These tools are not part of published financial statements. They are typically used for internal governance and, in an audit context, form part of the auditor’s documentation and working papers.

System narratives

A system narrative is a structured written description of how a process operates from start to finish. It normally sets out:

• who performs each activity (roles and responsibilities)
• what documents or data are created and used
• what authorisations and checks occur
• how transactions are recorded (including interfaces into the ledger)
• how exceptions are identified and resolved

A good narrative is not a story: it is a clear, step-by-step description written so that another person could follow the process and perform a walkthrough. In practice, a walkthrough also records what was observed (documents, screens, approvals) and how the auditor confirmed the flow (enquiry, inspection, and limited re-performance).

What a narrative is for

• to identify points where misstatements could arise (for example, recording purchases not received, or paying invalid suppliers)
• to locate controls (authorisations, matching procedures, reconciliations, reviews)
• to understand what evidence should exist to demonstrate control operation (signatures, system approvals, logs, exception reports)

Flowcharts

A flowchart presents the process visually. It is particularly useful for:

• showing sequence (what happens first, next, and last)
• showing handoffs between departments or systems
• showing where documents and data flow
• spotting weaknesses caused by poor segregation or missing checks

A simple flowchart is usually enough for exam and practice purposes. The goal is clarity rather than artistic complexity.

Good flowchart habits

• keep symbols consistent (process step, decision point, document, data store)
• show ownership: make it obvious who performs each step
• use swimlanes (separate lanes for departments/roles) where possible, as a quick way to show segregation and handoffs
• label control points clearly (for example, “Manager approval” or “Invoice matched to order and receipt”)
• show exception paths (what happens if a match fails, or if approval is declined)

Questionnaires

A questionnaire is a structured set of prompts that helps assess whether controls are appropriately designed to address key risks. It is commonly used to ensure coverage and consistency across processes.

Well-designed questions focus on:

• control objectives (what the process needs to achieve)
• key risks (what could go wrong that matters to financial reporting)
• control features (authorisation, completeness checks, accuracy checks, reconciliations, access controls)
• evidence (how the control is demonstrated in practice)

Questionnaires are not a substitute for understanding. They work best when used after you can already describe the process and identify risk points.

Control objectives and key controls

A control objective is the result the control environment should achieve within a process. Examples in a purchases process include:

• purchases are recorded only when they relate to the entity and are supported by evidence
• liabilities are complete and recorded in the correct period
• payments are made only for valid obligations and to valid supplier bank accounts

A key control is one that addresses a significant risk of misstatement and is important to the auditor’s response—typically selected for testing when planning to rely on controls.

Segregation of duties

Segregation of duties reduces risk by ensuring no one person can complete a transaction end-to-end without appropriate challenge. In practice, separate the ability to:

• approve the decision (commit the organisation)
• carry out the activity (place the order, release the payment)
• record it in the accounting records
• review or reconcile the outcome

Independence is most critical for reviews and reconciliations, and for high-risk areas such as cash/bank access and supplier master data. Where full independence is not possible, strengthen review quality, documentation, and management oversight, and focus it on the highest-risk activities.

Control deficiencies and compensating controls

A control deficiency exists where control design (or its operation) is not sufficient to reduce risk to an acceptable level. Deficiencies commonly arise from:

• missing controls (no approval, no reconciliation, no matching)
• poor design (thresholds too high, reviews not sufficiently robust)
• weak evidence (a “review” that leaves no audit trail)
• access issues (users can override controls or change master data without oversight)

A compensating control is an alternative control that reduces risk when the preferred control cannot be implemented. Compensating controls are often detective in nature (for example, independent reviews after the event) and should be:

• performed by an appropriate person with sufficient objectivity
• frequent enough to detect issues promptly
• evidenced clearly (sign-off, review notes, exception resolution)

A practical method for documenting and evaluating systems

Documenting processes

A reliable process description normally follows a consistent method:

1. Define the boundary
2. Identify actors and systems
3. List inputs and outputs
4. Write the sequence

System documentation supports reliable accounting because it clarifies how transactions should be initiated, processed, and recorded. It does not replace the need to apply correct recognition, measurement, and double-entry recording; instead, it helps ensure transactions are captured completely and accurately.

Creating flowcharts

When building a flowchart:

• start with the trigger (for example, “Purchase request raised”)
• show each step in the order performed
• include decision points (approval required? match successful?)
• show documents/data created (PO, receipt record/GRN, invoice, payment run)
• show who performs the step (ideally using swimlanes for departments/roles)

A flowchart is most useful when it makes control points obvious—either by labelling them or positioning them where they prevent or detect errors.

Evaluating control design

Control design evaluation asks a practical question:

If the control were performed exactly as described, would it reduce the key risk meaningfully?

This evaluation typically considers:

• whether the control addresses a specific risk clearly
• whether it is performed by an appropriate person (and sufficiently objective where needed)
• whether it happens at the right time (preventive versus detective)
• whether there is a reliable evidence trail
• whether the control can be bypassed or overridden without visibility

How to spot control deficiencies in practice

Control deficiencies are easiest to identify by comparing:

• what the process needs to achieve (control objectives), with
• what the system actually does (controls present, who performs them, and what evidence exists)

Common diagnostic prompts include:

• Where could a transaction be initiated or changed without approval?
• Where could a transaction be recorded without a supporting document trail?
• Are exception reports produced, reviewed, and followed up?
• Are reviews sufficiently robust and evidenced?
• Can users override controls or amend master data without logging and oversight?

Proposing improvements

Improvements should be practical and proportionate. Strong proposals are:

• directly linked to a stated deficiency and risk
• realistic for the size and complexity of the entity
• clear about who performs the control and what evidence will exist
• targeted at the point in the process where the risk arises

Where ideal segregation is not possible, suggest compensating controls with clear evidence requirements and targeted oversight of the highest-risk activities.

Linking system understanding to audit planning

System understanding informs:

• risk assessment (where material misstatement could arise)
• whether controls testing is efficient (and which controls are key)
• how substantive procedures should be shaped (nature, timing, extent)

If key controls are suitably designed and evidence of operation is expected to be strong, it may be efficient to test controls and adjust substantive procedures accordingly. Reliance on controls typically reduces the extent of detailed substantive testing and may shift timing, but it does not eliminate substantive work altogether.

Linking risks and controls to assertions

When evaluating a process, it helps to connect risks and controls to common financial statement assertions:

• Occurrence/validity: recorded transactions are genuine and relate to the entity
• Completeness: all relevant transactions and balances are captured
• Accuracy: amounts are correctly calculated and recorded
• Cut-off: transactions are recorded in the correct period
• Classification: transactions are recorded in the correct account/category
• Rights and obligations: assets and liabilities represent the entity’s rights/obligations

For purchases and payables, the highest-risk assertions are often completeness and cut-off (unrecorded liabilities), alongside occurrence and accuracy (invalid purchases, incorrect amounts, or payment diversion).

Worked example

Scenario (risk-first lens)

A medium-sized importer uses an integrated purchasing and inventory system with automated invoice capture. Orders are usually raised through the system, but urgent spend is sometimes made using corporate cards and later coded to the ledger. Supplier master data is maintained centrally, and payment files are uploaded to online banking. Management wants comfort that liabilities are complete at period end and that supplier changes cannot be used to divert payments.

The process is intended to work as follows:

1. A department raises a purchase request including quantity, suggested supplier, and budget code.
2. A purchasing officer creates a purchase order (PO) after confirming supplier terms.
3. A manager approves POs above a stated threshold.
4. Goods received are checked against the PO; a goods received note (GRN) is created.
5. Accounts payable performs an agreement check before posting by comparing supplier invoice details to the PO and GRN. (This “agreement check” is the matching of order, receipt and invoice data.)
6. Approved invoices are posted to the purchases ledger; payment runs are authorised by a senior manager.
7. Bank payments are reconciled to the bank statement by someone independent of payment processing.

Required

• Document the purchases process using a system narrative.
• Create a flowchart illustrating the purchases process.
• Evaluate the design of controls using a questionnaire.
• Identify control deficiencies and propose improvements.
• Link system understanding to audit planning decisions.

Solution

1) System narrative (focused on control points and evidence)

The process begins when a department identifies a need for goods or services and raises a purchase request stating quantity, supplier suggestion, and budget code. The purchasing officer reviews the request, confirms commercial terms with the supplier as needed, and raises a purchase order (PO) in the purchasing system. POs above the specified threshold are routed for manager approval before being issued to the supplier. Evidence is retained through system approval records and the approved PO.

When goods are delivered (or services are confirmed as received), receiving staff check the delivery against the PO and create a goods received note (GRN). Any discrepancies (short delivery, damaged items, or delivery without a valid PO) are recorded and followed up with purchasing before acceptance.

Supplier invoices are captured and routed to accounts payable. Accounts payable performs an agreement check by comparing the invoice details to (i) the authorised PO and (ii) the GRN. Invoices that do not agree are placed on hold and investigated. Only invoices that successfully match (or have an approved exception) are posted to the purchases ledger. Evidence is retained through match status reports, hold/exception logs, and posting records.

Urgent corporate card spend is recorded based on card statements and supporting receipts. Coding and approval are documented, and spend is reviewed to ensure it is appropriately classified and complete.

Periodically, accounts payable prepares a payment run based on due dates and approved invoices. A senior manager reviews the payment proposal (supplier, amounts, and unusual items) and authorises release of payments. Payment authorisation is evidenced through system approval or signed payment reports, depending on the platform used.

An independent person—who does not prepare or authorise payments—performs a bank reconciliation by matching ledger movements and payment listings to the bank statement. Reconciling items are investigated and resolved, with evidence of review retained (sign-off and follow-up notes).

2) Linear flowchart (text version suitable for exam conditions)

Start → Department raises purchase request → Purchasing officer creates PO → Decision: PO above approval threshold?  • Yes → Manager approves PO → PO issued  • No → PO issued → Goods/services received → Receiving checks against PO and prepares GRN → Supplier invoice captured and routed to accounts payable → Agreement check (match PO + GRN + invoice) → Decision: Agreement successful?  • Yes → Post invoice to purchases ledger  • No → Hold invoice and investigate/resolve exception → Payment run prepared (approved invoices only) → Senior manager authorises payment run → Bank payment released → Independent bank reconciliation performed and reviewed → Corporate card spend (where used): statement received → receipts matched → coding/approval → post to ledger End

3) Questionnaire (design-focused)

Supplier master data and payment security

Are changes to supplier bank details verified independently (for example, call-back using a trusted number, or separate approval by an independent person)?

Purchase authorisation and completeness

Are purchase orders required for all purchases, and are exceptions monitored and approved?

Reconciliations and review

Is there evidence that bank reconciliations are prepared promptly and reviewed by an appropriate person with sufficient objectivity?

Application controls (within the process/system)

Does the system enforce approval workflows and matching rules (for example, preventing posting where the agreement check fails unless an authorised override is applied)?

General IT controls (supporting the reliability of system processing and audit trails)

Are access rights restricted for high-risk actions (supplier master data amendments, override permissions, payment release), and are audit logs monitored?

4) Control deficiencies and improvements

Deficiency A: Supplier bank detail changes not independently verified

• Risk: Payments may be diverted to an incorrect or fraudulent account, leading to loss and misstated expenses/cash.
• Improvement (primary control): Restrict bank detail changes to nominated users and require independent verification/approval before changes become active.
• Improvement (supporting controls): Weekly report of supplier bank amendments reviewed with evidence of follow-up and resolution.

Deficiency B: PO bypass for urgent low-value items with no monitoring

• Risk: Purchases may be unauthorised, incorrectly coded, duplicated, or omitted from liabilities at period end (completeness/cut-off risk).
• Improvement: Introduce a controlled exception route requiring documented reason, after-the-event approval, and periodic management reporting on exception volume/value.

Deficiency C: Override and master data activity not monitored (IT/audit trail weakness)

• Risk: Overrides or supplier amendments could enable invalid invoices or payment diversion without timely detection.
• Improvement (primary control): Limit override permissions to nominated users and require documented approval for overrides above defined tolerances.
• Compensating control: Independent monthly review of audit logs/reports covering overrides, supplier amendments, and payments to new/changed bank accounts, evidenced by sign-off and exception resolution.

Deficiency D: Segregation risk around supplier maintenance and payments (where roles overlap)

• Risk: If a single individual can amend supplier data and also prepare or authorise payments, the opportunity for fraudulent payments increases materially.
• Improvement: Separate permissions so supplier master data maintenance, invoice posting, and payment authorisation cannot be performed by the same user. Where full separation is not feasible, strengthen management oversight and focus review on supplier changes and payment releases, with clear evidence.

5) Linking to audit planning decisions

This process understanding highlights key risk areas in purchases, payables, and cash, and whether controls reduce those risks.

• Where controls appear well designed and evidenced (for example, consistent agreement checks with system logs and robust bank reconciliation review), controls testing may be efficient and can support reducing the extent of some detailed testing and/or adjusting timing. Substantive procedures, however, still remain necessary in many areas and are tailored rather than removed.
• Where controls are weak or not reliably evidenced (for example, unverified bank detail changes, uncontrolled exceptions, or unmonitored overrides), the audit approach typically increases substantive procedures. This may include enhanced payables completeness and cut-off work, detailed testing of payments to new or amended supplier accounts, and expanded procedures over corporate card spend classification and authorisation.

Interpretation of the results

The narrative, flowchart, and questionnaire convert an informal description into documentation that can be evaluated. Together they clarify:

• where transactions enter the accounting records
• where controls are expected to prevent or detect misstatements
• what evidence should exist to demonstrate control operation
• where weaknesses increase the likelihood of error or fraud

In this scenario, strong features include independent bank reconciliation and an agreement check before invoice posting (where consistently applied and evidenced). Significant weaknesses relate to supplier bank detail security, unmanaged exceptions to PO requirements, and insufficient oversight of high-risk system actions (overrides and master data changes). These weaknesses increase misstatement risk and influence both audit strategy and detailed procedure design.

Common pitfalls and misunderstandings

• Narratives that are too vague: A narrative should specify who does what, what evidence exists, and how exceptions are handled.
• Treating documentation as proof: Documentation describes what should happen; walkthroughs and testing confirm what actually happens.
• Flowcharts without ownership: If roles are not shown (ideally via swimlanes), segregation issues are easy to miss.
• Ignoring exception routes: Many failures occur in overrides, urgent purchases, unmatched invoices, or manual adjustments.
• Confusing design and operation: A control can look strong on paper but fail in practice if not performed consistently or evidenced.
• Unrealistic improvements: Recommendations should be proportionate and workable.
• Overlooking compensating controls: If ideal segregation is not feasible, propose targeted oversight with clear evidence.
• Weak audit linkage: Control findings should lead to a clear adjustment in audit focus and procedure design, not a generic statement that “more testing is needed.”

Summary and further reading

Documenting and evaluating systems is essential for understanding how transactions are processed and where financial reporting risks arise. System narratives, flowcharts, and questionnaires work best as a set: the narrative explains, the flowchart visualises, and the questionnaire tests design against key risks.

Effective documentation supports risk assessment and helps shape audit planning decisions—whether controls testing is efficient and how substantive procedures should be tailored (nature, timing, and extent).

For further reading, use introductory texts on internal control, audit planning, and business process documentation, alongside high-level guidance on governance and financial reporting risk.

FAQ

What is the primary purpose of a system narrative?

A system narrative documents how a process operates from start to finish, identifying roles, documents/data, key steps, control points, and exception handling. Its main purpose is to support understanding of transaction flow, highlight risk points, and show where controls are expected to prevent or detect errors and fraud.

How do flowcharts complement system narratives?

A flowchart shows the process visually, making sequence, handoffs, and control points easier to see. Using ownership (and swimlanes where possible) helps reveal segregation weaknesses and areas where steps can be bypassed.

Why are questionnaires important in evaluating control design?

Questionnaires provide structured coverage of common risk areas and control features. They help ensure you consider authorisation, completeness, accuracy, access restrictions, audit trails, and review—especially in areas where weaknesses are easy to overlook.

What are the consequences of failing to identify control deficiencies?

If deficiencies are missed, errors or fraud may go undetected, increasing the risk of misstated financial information. It can also lead to ineffective audit planning, with insufficient work in high-risk areas or unnecessary work in low-risk areas.

How does system documentation impact audit planning?

System documentation helps identify where misstatements could occur and whether controls reduce those risks. Strong, well-evidenced controls may support efficient controls testing and a tailored substantive approach. Weak or poorly evidenced controls generally push the audit strategy towards more extensive substantive procedures.

Summary (Recap)

This chapter covered how to document and evaluate systems using narratives, flowcharts, and questionnaires. It explained control objectives and key controls, segregation of duties, how to diagnose control deficiencies, and how to propose practical improvements including compensating controls. The worked example illustrated a purchases process in a modern environment and showed how system understanding shapes audit planning by influencing the balance between controls testing and the design of substantive procedures.

Glossary

System narrative A structured written description of how a process operates, including roles, documents/data, key steps, control points, and exception handling.

Flowchart A visual map of a process showing activities, decision points, documents/data flows, and handoffs between people or systems.

Swimlanes Separate lanes within a flowchart (typically by department or role) used to show ownership of steps and highlight handoffs and segregation.

Questionnaire A set of structured prompts used to assess whether key controls exist and whether their design addresses significant risks effectively.

Control objective A specific outcome a process should achieve to manage risk (for example, ensuring only valid liabilities are recorded and paid).

Key control A control that addresses a significant risk of misstatement and is important to the auditor’s response—typically selected for testing when planning to rely on controls.

Segregation of duties The separation of end-to-end capability so that approval, execution, recording, and review are not concentrated in one individual without appropriate challenge.

Control deficiency A weakness in control design or operation that reduces the ability of the system to prevent or detect misstatements.

Compensating control An alternative control that reduces risk when the preferred control cannot be implemented, often through targeted oversight and exception reporting.

Application controls Controls built into a process or system that help ensure transactions are authorised, complete, and accurately processed (for example, automated approvals, matching rules, tolerance limits).

General IT controls Controls that support the overall reliability of systems and data (for example, user access management, change controls, and logging/monitoring).

Design effectiveness Whether a control, if performed properly, would be capable of preventing or detecting a misstatement.

Operating effectiveness Whether a control actually worked in practice over a period, performed consistently by appropriate people with reliable evidence.

Learning objectives

By the end of this chapter, you should be able to:

• Explain the difference between general IT controls, application controls, and IT-dependent manual controls, and why each matters for reliable financial reporting.
• Identify common technology-related risks (access, change, operations, and interfaces) and link them to relevant financial statement assertions.
• Structure audit responses clearly so the link from risk to evidence is explicit and marking-friendly.
• Evaluate system-generated information (reports, extracts, logs) for audit use, including whether it is complete, unchanged, and produced from controlled parameters.
• Document a conclusion on technology-enabled controls and explain how it affects the nature, timing, and extent of substantive procedures.

Overview & key concepts

This chapter is written from an audit perspective: technology-enabled processes create risks to financial reporting, and auditors respond by linking those risks to assertions, assessing controls, and designing procedures that obtain reliable evidence.

Modern financial reporting depends on technology-enabled processes. Sales systems, payroll applications, inventory modules, and banking interfaces often initiate, process, and post transactions with limited manual intervention. When controls are designed and operating effectively, they help ensure transactions are recorded completely, accurately, and in the correct period. When controls are weak, errors or unauthorised changes can affect high volumes of data, and misstatements may be hard to detect without targeted audit work.

Technology controls typically fall into three broad categories:

• General IT controls (GITCs): controls over the IT environment that support dependable processing across systems.
• Application controls: controls within a specific application that prevent or detect transaction processing errors.
• IT-dependent manual controls: manual checks that rely on system output (for example, an exception report) and therefore depend on the reliability of the system and the report.

A key judgement is whether auditors can rely on automated processing and on system-generated information. That judgement is driven by the strength of GITCs and the design and operation of relevant application controls.

Core theory and frameworks

1. General IT controls (GITCs)

GITCs support the reliability and security of the IT environment. If GITCs are weak, reliance on automated controls and system outputs is usually reduced because the information may be susceptible to unauthorised change.

Access management (logical access)

Risk → assertion link: Weak access controls can allow unauthorised amendments to data or processing (for example, pay rates, supplier bank details, user permissions). This increases the risk of misstatement affecting accuracy, classification, and occurrence (for transaction streams) — and potentially completeness if transactions can be deleted, suppressed, or bypassed.

Typical access features include:

• controlled user provisioning and removal (joiners, movers, leavers)
• role-based permissions aligned to job responsibilities
• separate and restricted privileged access (administrator accounts)
• periodic access reviews with follow-up of exceptions
• strong authentication for higher-risk access

Audit response (examples):

• Test controls over user access changes (sample joiners/leavers: approved request → access granted/removed → evidence).
• Review audit logs for privileged activity and investigate unusual changes (for example, amendments to supplier bank details, pay rates, or posting rules).
• Where access controls are weak, increase substantive work on vulnerable areas (for example, test a sample of standing data changes and trace through to supporting approvals and resulting transactions).

Change management

Risk → assertion link: Uncontrolled changes can alter calculations, account mappings, interface logic, and configuration. This can create systematic misstatements across many transactions, affecting accuracy, classification, and cut-off. It can also undermine the credibility of reports used as audit evidence.

How auditors evaluate change control (practical lens) When a system, configuration, interface, or report changes, auditors want comfort that the change was requested for a valid reason, checked before release, and cannot be put into the live environment by someone who also built it. In practice, the audit trail for a change should show:

• who requested it and who approved it (business ownership)
• what testing was performed and the outcome (including sign-off for significant changes)
• how the change moved from development/testing into live use (a controlled release path)
• how the version in use is identifiable, and whether the change can be reversed if it creates errors

This includes changes to report logic and query parameters (see section 4 on system-generated information). If these features are missing, a small configuration change (for example, payroll calculation logic or posting mappings) can repeat the same error across a large population.

Audit response (examples):

• Select a sample of changes and trace end-to-end: request → approval → test evidence → deployment evidence.
• If change control is weak, reduce reliance on automated controls and increase substantive testing, especially around period-end and automated postings.

IT operations (processing, backups, incident handling)

Risk → assertion link: Operational weaknesses can lead to failed processing runs, incomplete interface postings, or loss/corruption of data. This can affect completeness and cut-off, and can also undermine the reliability of system evidence used in the audit. Operational instability can also make system logs incomplete, so auditors may rely more on independent extracts and external corroboration.

Key areas include:

• monitoring and resolution of processing failures (job scheduling, batch processing)
• incident recording and follow-up
• backups and recovery capability (including periodic restore testing)
• patching and vulnerability management where it affects integrity or availability of systems used for financial reporting

Audit response (examples):

• Review evidence that failed interface runs are identified, investigated, and corrected.
• Where operational controls are weak, perform additional reconciliation and completeness procedures using independent evidence (for example, bank outputs, third-party reports, or source documents).

2. Application controls

Application controls operate inside a specific system and are designed to prevent or detect errors at the transaction level. A practical way to remember them is to follow the data lifecycle: what goes in (input), what happens to it (processing), and what comes out (output).

They are often grouped as:

Input controls

Aim to ensure data entered is valid, complete, and authorised, such as:

• mandatory fields and format checks (dates, codes)
• reasonableness checks (hours, rates, thresholds)
• workflow approvals for sensitive entries (for example, new supplier setup)

Processing controls

Aim to ensure transactions are processed correctly, such as:

• automated calculations using approved rates and rules
• system rules that prevent completion until required approvals occur
• matching controls (for example, invoice matched to authorised purchasing and receipt evidence)

Output controls

Aim to ensure reports and outputs are complete and accurate, such as:

• reconciliations of report totals to ledger postings
• distribution controls (restricted access to reports)
• exception reporting and documented follow-up

Risk → assertion link: Application control failures commonly affect accuracy, completeness, classification, and cut-off depending on where in the processing flow the failure occurs. For balances, the related risk may affect existence (for example, overstatement through duplicate postings) or completeness (for example, missing postings), depending on the direction of error.

Audit response: Test whether the control operates as described, including how exceptions are handled. Where the control is automated, also consider whether GITCs support reliance.

3. IT-dependent manual controls

These are manual controls that rely on system output (for example, a reconciliation using a system report).

Risk → assertion link: A manual review can appear strong, but if the report is incomplete, altered, or produced from uncontrolled parameters, the review may not address completeness or accuracy risk.

Audit response (two-step expectation):

1. Test the manual review (who performs it, frequency, evidence of investigation and follow-up).
2. Validate the system output used in the review (report parameters, access to amend report logic, completeness of the population, and whether the report is generated from controlled data).

If the report cannot be validated, auditors may need to obtain a controlled extract, reperform the analysis using independent data, or design substantive procedures that do not rely on that report.

4. System-generated information: when it is reliable and when it isn’t

System-generated information includes reports, data extracts, logs, and automated reconciliations. Auditors often use it both to test controls and to perform substantive procedures.

Validating system-generated information is not just agreeing totals to the general ledger. A reconciliation may show that two numbers match, but it does not prove:

• the report contains the full population (completeness)
• the report parameters were appropriate and consistent (accuracy and completeness)
• the report logic has not been changed without approval (integrity)
• the user generating the report could not alter the output or underlying data (integrity)

Audit response (examples of validation work):

• confirm who can change report logic and parameters, and whether those changes are controlled
• inspect the report criteria and ensure it covers the intended period and population
• agree a small sample of report items back to source records to confirm extraction logic
• obtain the report directly from a controlled environment or through an authorised system administrator where appropriate

5. Interface controls and data transfers

Interfaces fail in predictable ways: items can be lost, duplicated, or posted with incorrect values or coding.

Interface controls: start with the objective

Controls are designed around three questions:

1. Did everything transfer?
2. Compare the number of records sent and received, and review accepted/rejected item logs.
3. Did values transfer correctly?
4. Compare totals from the sending system to totals posted in the receiving ledger, and investigate differences.
5. Were problems captured and cleared before reporting?
6. Review exception reports, ensure rejected items are corrected and reprocessed, and retain evidence of reconciliation and sign-off.

For large data files, organisations may also use hash totals / batch hash checks (non-monetary batch checks) to detect unexpected alteration or corruption across the population.

Technical note: hash totals are not monetary totals; they are designed to detect unexpected changes across many records and are most useful when combined with record counts and control totals.

Audit response (examples):

• Reperform the interface reconciliation using independent extracts from both systems and explain differences.
• Inspect interface exception logs and trace rejected items to correction and eventual posting.
• Where interface controls are weak, increase substantive completeness and cut-off testing around the posting period.

6. Exam structure: build your answer in five steps

A marker can only award full credit when your answer shows the logic from the problem to the work performed. A simple way to structure technology-control answers is:

1. What can go wrong? (state the technology risk)
2. Why does it matter? (name the assertion(s) affected — occurrence for transaction streams; existence for balances)
3. What should prevent or detect it? (describe the relevant control and whether it is strong/weak)
4. So what will the auditor do? (tailor the response: tests of controls and/or more substantive work)
5. What evidence supports the conclusion? (logs, tickets, extracts, reconciliations, external corroboration)

Using this structure avoids generic answers and makes the audit response clearly driven by the control assessment.

Worked example

Narrative scenario

A company uses a payroll application to calculate monthly salaries. Once the payroll run is finalised, an interface posts totals to the general ledger (GL). The payroll application produces a summary report showing:

• number of employees paid
• total gross pay
• total deductions
• total net pay

The GL interface posting should agree to these totals. In prior months, differences have occurred between the payroll report and the GL posting.

Required

1. Compare the payroll summary report with the GL interface posting.
2. Identify discrepancies in employee count, gross pay, deductions, and net pay.
3. Explain a likely cause and propose corrective actions.
4. Explain the impact on relevant financial statement assertions.

Solution

1. Compare record counts (employees paid)

• Payroll report: 120 employees
• GL posting: 119 employees
• Discrepancy: 1 employee

Risk → assertion: This points to a possible completeness risk (a payroll item not posted) and a potential cut-off risk if the missing item posts later.

2. Compare control totals (amounts)

Gross pay

• Payroll report: £360,000
• GL posting: £357,000
• Difference: £3,000 short

Deductions

• Payroll report: £72,000
• GL posting: £72,000
• Difference: £0

Net pay

• Payroll report: £288,000
• GL posting: £285,000
• Difference: £3,000 short

Internal consistency check: Payroll gross (£360,000) − deductions (£72,000) = net (£288,000). GL gross (£357,000) − deductions (£72,000) = net (£285,000).

The pattern is consistent with one omitted gross-to-net package of £3,000 gross with £0 deductions, resulting in £3,000 net missing from the GL.

3. Likely cause and corrective actions

Likely cause: One employee’s payroll line failed to transfer (for example, rejected due to an invalid cost centre, missing GL mapping, or an interface error affecting a single record). The matching deductions total suggests the missing item relates to gross and net pay rather than deductions (or that employee’s deductions were nil).

Corrective actions (control and fix):

• Inspect interface exception logs to identify rejected or unposted items and isolate the missing employee record.
• Confirm whether the interface run shows partial success (for example, one record rejected) and whether the exception was escalated.
• Correct the root cause (for example, update mapping for the employee’s code) and reprocess the rejected item.
• If reprocessing is not possible before reporting, post a controlled adjustment supported by evidence and approved review.
• Strengthen the control by enforcing a pre-posting check: record counts and totals must agree, and exceptions must be cleared before the GL posting is finalised.

4. Impact on financial statement assertions

Payroll expense (income statement):

• Completeness / accuracy risk: expense may be understated by £3,000 if not recorded.

Payroll-related liabilities (balance sheet): Depending on how payroll is recognised (for example, net pay payable, taxes payable), liabilities may be understated if the missing amount is not reflected in the period-end accruals and payables. This affects completeness of liabilities (and therefore the completeness of the related balance).

Cut-off: If the missing item posts in a later period, the expense and related liabilities may be recognised in the wrong period.

Classification: If corrected manually, there is a risk the adjustment is coded to the wrong account without an independent review.

Audit response implication: This indicates the interface completeness control may not be operating effectively. Auditors would extend testing (for example, reperform reconciliations for additional months, trace exceptions to resolution, and increase substantive payroll completeness and cut-off work).

Interpretation of the results

The record count difference and consistent pattern in totals indicate an incomplete interface transfer rather than a payroll calculation error. This shows why interfaces should not post automatically unless completeness and accuracy checks have been performed and exceptions cleared. Strong answers identify the discrepancy, link it to assertions, and state how audit work would change.

Common pitfalls and misunderstandings

• Treating system outputs as inherently reliable without considering access, change control, and report parameters.
• Confusing environment controls (GITCs) with transaction-level controls (application controls).
• Describing risks without linking them to assertions and specific audit procedures.
• Treating interface differences as harmless timing issues without investigating missing or rejected items.
• Testing an IT-dependent manual control but not validating the report or extract used in the review.
• Listing audit procedures that still rely on uncontrolled system information.
• Failing to evidence investigation and resolution of exceptions.
• Using inconsistent assertion language (occurrence for transaction streams; existence for balances).

Summary and further reading

Technology-enabled processes can create high-volume, systematic misstatement risks. Effective GITCs support a dependable environment; application controls address transaction processing risks within systems; and interface controls protect completeness and accuracy when data moves between systems. Audit answers should clearly connect the risk to the affected assertion and then to tailored procedures and evidence.

FAQ

What is the difference between general IT controls and application controls?

General IT controls support the reliability of the IT environment overall (for example, access governance, change governance, and stable operations). Application controls operate within a specific system to prevent or detect errors in transaction processing (for example, validation checks, automated approvals, matching routines). Application controls are generally more dependable when supported by effective GITCs.

How do weak technology controls affect financial statements?

Weak controls can allow unauthorised changes, incomplete processing, or incorrect postings. These issues can cause missing transactions, duplicated postings, incorrect values, and incorrect period recognition. The impact can be widespread because automated processing affects large transaction volumes.

What audit responses are typical when technology controls are weak?

Auditors commonly increase substantive testing, use more independent evidence, and reduce reliance on system outputs that cannot be validated. Procedures may include reperforming reconciliations from independent extracts, tracing exceptions to resolution, expanding period-end cut-off testing, and reviewing high-risk journals and standing data changes.

Why is change management important in technology-enabled processes?

Because changes to system logic, mappings, and reports can create repeated errors across many transactions. Controlled change governance provides evidence that changes were authorised, tested, and released in a controlled way.

How can auditors assess the reliability of system-generated reports?

Auditors consider more than whether totals agree. They assess whether the report population is complete, whether parameters are appropriate, who can change report logic, whether changes are controlled, and whether output can be altered. They often corroborate by sampling items back to source data and obtaining reports from controlled access pathways.

Summary (Recap)

This chapter explains controls in technology-enabled processes and how they support reliable financial reporting. It distinguishes general IT controls, application controls, and IT-dependent manual controls, and links common technology risks—access, change, operations, and interfaces—to assertions. It also explains how to evaluate system-generated information so that reports and logs used in the audit are complete, correctly parameterised, and protected from unauthorised change. The worked example demonstrates interface completeness and accuracy checks in a payroll-to-GL transfer, showing how discrepancies drive audit implications and procedures.

Glossary

General IT controls (GITCs) Controls that support the reliability and security of the IT environment as a whole, commonly covering access management, change governance, and IT operations.

Application controls Controls within a specific application designed to prevent or detect errors in transaction processing, including input, processing, and output controls.

Access controls Controls that restrict system and data access based on user identity and role, including restrictions over privileged access.

Change management Controls that govern changes to systems, configurations, interfaces, and reports to ensure changes are approved, tested, and released in a controlled way.

Segregation of duties (SoD) The separation of incompatible responsibilities so that one person cannot initiate, approve, and record the same transaction without independent oversight.

Interface controls Controls that ensure data transferred between systems is complete and accurate, including record counts, totals comparisons, exception handling, and reconciliation sign-off.

IT-dependent manual control A manual review that relies on system output; its effectiveness depends both on the quality of the manual review and on the reliability of the system-generated information used.

System-generated information Reports, extracts, logs, and automated outputs produced by systems, used as audit evidence only when completeness, parameters, and protection from unauthorised change are addressed.

Audit logs System records of significant activity (for example, user access changes, configuration changes, privileged actions) used to support monitoring and audit evidence.

Configuration System settings that determine how transactions are calculated, processed, mapped, and posted.

Backup and recovery Processes to protect data and restore systems after failure or cyber incidents, supporting continuity and integrity of reporting.

Data integrity The extent to which data remains complete, accurate, and consistent through input, processing, storage, transfer, and reporting.

Automated controls Controls performed by a system once configured, such as validations, matching routines, and workflow enforcement.

Learning objectives

By the end of this chapter you should be able to:

• Explain why an internal audit function exists and describe the main types of work it performs across risk management, internal control and governance.
• Distinguish internal audit from an external audit by comparing purpose, audience, scope and reporting relationships.
• Assess whether work performed by internal audit can be used by the external auditor by evaluating independence in practice, capability and the strength of the evidence trail.
• Identify how internal audit outputs can inform external audit planning, including risk assessment and the design of audit procedures.
• Recognise situations where using internal audit work is inappropriate and describe how the external auditor responds.
• Explain the difference between (a) using the work of internal audit as audit evidence and (b) using internal auditors to provide direct assistance, and the safeguards and jurisdiction limits that may apply.

Overview & key concepts

Many organisations structure assurance activities using a commonly used “lines of assurance” model. In simple terms:

• Management designs and operates controls as part of running the business.
• Internal audit evaluates how well risks are identified and managed, and how effectively controls and governance arrangements operate in practice.
• External audit reports to shareholders (or equivalent users) on the financial statements.

This is a helpful way to think about roles, but organisations may apply it differently in practice.

Internal audit and external audit can complement each other, but they are not interchangeable:

• Internal audit is part of the organisation. It helps the organisation achieve its objectives by evaluating and improving risk management, internal control and governance. It may also provide advisory work, but it must retain independence of thought and challenge.
• External audit is an independent engagement. Its objective is to obtain sufficient appropriate evidence to support an opinion on whether the financial statements are prepared, in all material respects, in accordance with the applicable financial reporting framework.

The external auditor remains responsible for the audit opinion. Internal audit work may improve efficiency, but it cannot replace the external auditor’s judgement or professional scepticism.

Core concepts

Internal audit (IA)

Internal audit is an assurance and advisory activity that evaluates how effectively the organisation identifies and manages risks and how well internal controls and governance processes operate in practice.

Typical internal audit activities include:

• Reviewing the design and operation of internal controls (for example, controls over purchasing, payroll, revenue processing, inventory counts and IT access).
• Testing compliance with internal policies, delegated authorities and legal or regulatory requirements.
• Investigating control breakdowns, near-misses and root causes of recurring issues.
• Performing operational reviews (for example, efficiency, value-for-money, process redesign).
• Reporting findings and recommendations to those charged with governance and monitoring management’s remedial actions.

Reporting line and independence: The credibility of internal audit is strengthened when it has a clear mandate, unrestricted access to records and staff, and a reporting route that supports independent challenge (commonly to the audit committee or an equivalent governance body).

External audit (EA)

External audit is an independent examination of financial information leading to an audit opinion. The external auditor plans and performs procedures to address the risk of material misstatement in the financial statements, whether due to error or fraud.

External audit procedures include:

• Understanding the entity and its environment, including internal control.
• Assessing risks at the financial statement level and assertion level.
• Designing and performing audit procedures that respond to the assessed risks.
• Evaluating whether the financial statements are presented fairly in accordance with the reporting framework.
• Communicating matters of significance to those charged with governance.

How the external auditor decides whether internal audit work is usable: “Can we trust it?”

The decision is fundamentally a trust decision. The external auditor considers whether internal audit work is reliable enough to help achieve specific audit purposes, and then validates it where appropriate.

1) Can internal audit speak freely?

The external auditor looks for signs that internal audit can report unwelcome findings without pressure.

Strong indicators include:

• A functional reporting route to the audit committee (or equivalent).
• Unrestricted access to people, systems and records.
• No evidence that management narrows scope, delays reports, or filters messages.

Red flags include:

• Internal auditors being involved in operating or approving the process they later review.
• Frequent scope restrictions, “off-limits” areas, or management rewriting conclusions.
• A culture where challenging findings are discouraged.

2) Can internal audit do the job well?

The external auditor considers capability in practical terms, not just credentials.

Indicators of strong capability include:

• A team with relevant experience for the work performed (for example, procurement process reviews led by staff with process and controls knowledge).
• Appropriate training and continuing development.
• Use of specialists where needed (for example, IT controls work supported by IT expertise).
• Clear supervision, review and sign-off in the file.

Weak capability often shows up as vague objectives, shallow testing, inconsistent conclusions, or poor evidence retention.

3) Is the work built like audit work?

This is about the method and evidence trail: can an independent reviewer understand what was done and why the conclusion is justified?

What good looks like (one-line summary): clear objectives, sensible testing, and evidence that supports every conclusion.

The external auditor typically looks for:

• A scoped plan linked to risks and objectives.
• Procedures that clearly address those objectives.
• A rationale for selections or sampling (not just “we tested a few items”).
• Evidence that is sufficient and appropriate for the conclusion reached.
• Reports that separate what was found, why it matters, and what action is needed.

Bottom line: If independence in practice is doubtful, capability is inconsistent, or the evidence trail is weak, internal audit reports may still be useful background—but the external auditor should not treat the work as audit evidence.

How internal audit can support external audit planning

Internal audit outputs can help the external auditor understand processes, identify control weaknesses, and refine risk assessment. This is particularly useful early in planning.

Useful inputs include:

• The internal audit plan and how it prioritises risk.
• Reports issued during the year and management’s responses.
• Follow-up reports showing whether issues are resolved or recurring.
• Coverage summaries across processes, sites, and systems.
• Themes from investigations, incidents, or whistleblowing (where relevant and appropriately shared).

Internal audit insights should be mapped to financial statement areas and audit assertions. For example:

• Weak procurement approvals may increase the risk of unauthorised or inaccurate purchases, duplicate payments, or misclassification between operating costs and capital expenditure.
• Poor inventory controls may increase the risk of incorrect quantities or valuation errors.
• Revenue control weaknesses may increase the risk of cut-off or inappropriate recognition.

Exam focus: The external auditor first decides the overall audit approach and identifies key risks. Only then does the external auditor decide whether any internal audit work can help achieve specific audit purposes within that strategy.

Using internal audit work as audit evidence

When using internal audit work may be appropriate

Using internal audit work as audit evidence is most likely to be appropriate when:

• The work relates directly to audit objectives and assertions.
• The subject matter is not heavily judgemental (for example, routine control operation rather than complex estimates).
• The work is timely and relevant to the audit period.
• The external auditor has evaluated trust factors and validated key parts of the work (often by re-performance).

Typical areas where it may be useful include tests of controls in stable, process-driven systems—provided documentation is strong.

When using internal audit work is usually inappropriate

The external auditor should be cautious or avoid using internal audit work as audit evidence where:

• Internal audit objectivity is weak or compromised.
• The area involves significant judgement or estimation uncertainty (for example, complex provisions, impairment modelling, fair values).
• The area is sensitive to fraud or management override.
• Documentation is poor or evidence is missing.
• The work is outdated relative to the audit period or controls have changed.
• Scope restrictions prevented internal audit from testing relevant populations or accessing key evidence.

If internal audit work cannot be used, the external auditor expands independent procedures to obtain sufficient appropriate evidence.

Direct assistance versus using internal audit work

Using internal audit work (as evidence)

This means the external auditor uses internal audit’s completed work as part of the audit evidence base—after evaluating quality and performing appropriate validation. The external auditor decides the extent of use and remains responsible for the conclusions.

Direct assistance (when allowed)

In some environments, internal auditors may help by carrying out specified audit steps for the external auditor. Whether this is permitted depends on local law, regulation, and the standards applied, and in many settings it is restricted or not used in practice.

Where it is permitted, the external auditor must control the work tightly: set the instructions, supervise performance, review what was done, and remain fully responsible for the audit conclusions. Direct assistance is typically kept away from higher-risk areas (high judgement, high fraud risk, or matters involving significant management override concerns).

Worked example

Narrative scenario

A manufacturing company, XYZ Ltd, has an internal audit function that reports to the audit committee. Internal audit recently reviewed the procurement process, focusing on controls over supplier approvals and purchase order authorisations. The review identified control weaknesses, including:

• Inadequate segregation of duties between supplier set-up, ordering and goods receipt.
• Missing evidence of required dual approvals for certain purchase orders.
• Instances where supplier changes were made without clear authorisation trails.

The external auditor, ABC Audit Firm, is considering whether and how to use internal audit’s work when planning the year-end audit.

Required

1. Evaluate internal audit’s objectivity, competence and approach.
2. Decide whether any of internal audit’s work can be used as audit evidence.
3. Identify how internal audit’s findings can support risk assessment (including relevant assertions).
4. Plan re-performance and other validation procedures.
5. Document the evaluation and the decision on use.

Solution

Requirement 1: Evaluate internal audit’s objectivity, competence and approach

Objectivity

• Reporting to the audit committee supports independent challenge and reduces the risk of management influence.
• Confirm there are no operational responsibilities in procurement (e.g., approving suppliers, setting procurement approvals, or running the procurement system).

Competence

• Review internal audit staffing: procurement process experience, training, and any specialist support (e.g., IT access controls or data analytics).
• Confirm supervision, review and sign-off are evidenced in the files.

Approach and evidence trail

• Inspect planning documentation: objectives, scope and how tests were selected.
• Review work programmes, sampling rationale, test results and evidence retention (e.g., approvals, system audit trails).
• Check that conclusions follow from evidence, and exceptions are clearly described.

Conclusion (Req. 1): Internal audit appears suitably positioned and potentially reliable for limited use, subject to file review and validation.

Requirement 2: Decide whether internal audit work can be used as audit evidence

Internal audit’s testing is relevant because procurement controls affect the risk of misstatement in purchases, payables, and cash payments.

Potentially usable areas (subject to validation) include:

• Evidence-based testing that purchase orders above thresholds show the required approvals.
• Testing that supplier master file changes have documented authorisation and appropriate access controls.
• Testing segregation-of-duties controls supported by reliable system evidence.

Less suitable areas (external auditor should lead with independent work) include:

• Judgement-heavy matters linked to procurement (e.g., complex provisions, disputes, unusual cut-off issues, or classification areas requiring significant judgement).

Conclusion (Req. 2): Internal audit work may be used only for specific procurement control tests with strong evidence, after re-performance of a subset confirms reliability.

Requirement 3: Use findings for risk assessment and link to assertions

Internal audit’s findings indicate procurement controls are not operating consistently. This increases control risk in procurement-related processes and influences the external auditor’s risk assessment.

Likely affected assertions include:

• Purchases/expenses:
• Trade payables and accruals:
• Cash/bank (payments):

Planned audit responses may include:

• Expanding substantive testing in purchases and payables.
• Increasing focus on supplier master file controls and change authorisation.
• Performing targeted procedures on period-end cut-off for goods received and invoices.

Conclusion (Req. 3): The findings point to higher risk in purchasing and payables, requiring a stronger audit response aligned to occurrence/authorisation, completeness and cut-off.

Requirement 4: Plan re-performance and other validation procedures

A suitable validation plan includes:

Re-performance (subset of internal audit tests)

• Select items from internal audit’s tested population, focusing on:
• Re-perform approval checks:

File review and corroboration

• Inspect internal audit evidence for supplier set-up/change testing (audit trails, access logs, authorisation forms).
• Trace a sample of internal audit exceptions to source evidence to confirm accurate reporting.

Decide the impact

• If validation supports reliability, reduce duplicated control testing only in the specific areas validated.
• If validation reveals weakness (evidence gaps, flawed selection, incorrect conclusions), do not use internal audit work as evidence and expand independent testing.

Conclusion (Req. 4): Re-performance and targeted corroboration determine whether internal audit work can be used and whether external audit testing must increase.

Requirement 5: Document the evaluation and decision on use

Documentation should include:

• Assessment of internal audit’s ability to operate independently in practice.
• Assessment of competence, supervision and quality control within internal audit.
• The internal audit reports and files reviewed and why they are relevant.
• Validation performed (including re-performance selections and results).
• Areas where internal audit work will be used (and excluded), with reasons.
• How findings affected risk assessment and planned audit procedures.

Conclusion (Req. 5): Clear documentation demonstrates that any use of internal audit work is justified, validated, and consistent with the audit strategy and risk response.

Interpretation of results

Internal audit’s work can materially improve understanding of procurement risks and guide external audit planning. Where internal audit demonstrates independence in practice, capability, and a strong evidence trail—and where the external auditor validates key work through re-performance—internal audit work can be used in a controlled, targeted way. Procurement deficiencies typically indicate increased risk, so the external auditor’s overall response may need to be strengthened rather than reduced.

Common pitfalls and misunderstandings

• Treating internal audit as an automatic substitute for external audit work.
• Using internal audit work mainly for “efficiency” rather than because it supports the planned audit response to assessed risks.
• Failing to validate internal audit work before using it as evidence.
• Ignoring threats to objectivity created by operational duties or management influence.
• Using internal audit work in highly judgemental or fraud-sensitive areas.
• Relying on internal audit work that is not aligned to the audit period or where controls have changed.
• Poor linkage between internal audit findings and audit assertions.
• Inadequate documentation of the evaluation, validation, and final decision.

Summary and further reading

Internal audit strengthens organisational assurance by evaluating risk management, internal controls and governance. External audit provides an independent opinion on the financial statements for external users. Internal audit work can support external audit planning and, in limited cases, contribute to audit evidence—provided the external auditor evaluates independence in practice, capability, and the strength of the evidence trail, and validates key work. Direct assistance may be permitted in some environments but is subject to jurisdictional and standards-based limits and requires tight external auditor control.

FAQ

What is the main difference between internal audit and external audit?

Internal audit is an in-house function that helps the organisation by evaluating and improving risk management, controls and governance, often reporting to the audit committee. External audit is an independent engagement that results in an audit opinion on the financial statements for external users.

How does an external auditor decide whether to use internal audit work?

The external auditor assesses whether internal audit can operate independently in practice, whether the team is capable, and whether the work has a reliable evidence trail. The external auditor then validates the work—often by re-performing selected tests—before deciding whether any use is appropriate.

Can internal audit work replace external audit evidence?

No. Internal audit work may contribute to evidence in a limited, controlled way, but the external auditor remains responsible for audit conclusions and the audit opinion. Independent procedures are still required, particularly in higher-risk and judgemental areas.

When is it inappropriate to use internal audit work?

It is generally inappropriate where internal audit objectivity is weak, capability is inconsistent, documentation is poor, the work is outdated, or where the audit area is highly judgemental or fraud-sensitive.

How can internal audit findings affect external audit planning?

Internal audit findings often identify weak controls and recurring issues. This can increase assessed risk and lead to expanded procedures, stronger substantive testing, or additional targeted work in affected areas.

What does professional scepticism involve when evaluating internal audit work?

It involves challenging whether internal audit work is sufficiently robust: testing is appropriate, evidence supports conclusions, exceptions are accurately reported, and no bias or limitations undermine reliability.

What is meant by a systematic and disciplined approach?

A structured method of planning and executing work with clear objectives, appropriate procedures, sensible selection rationale, sufficient evidence, and documented review and sign-off, leading to conclusions that can be independently understood and supported.

Summary (Recap)

This chapter explained the purpose of internal audit and how it differs from external audit in objective, scope and audience. It set out a practical “Can we trust it?” approach to deciding whether internal audit work is usable, focusing on independence in practice, capability, and the strength of the evidence trail. It showed how internal audit findings inform risk assessment and how any use of internal audit work as evidence must be driven by the audit strategy and the response to assessed risks. The worked example linked procurement weaknesses to assertions in purchases, payables and cash and demonstrated targeted re-performance and documentation of reliance decisions. Direct assistance was explained as a separate concept that may be restricted depending on local requirements.

Glossary

Internal audit (IA) An in-house assurance and advisory function that evaluates and improves risk management, internal control and governance processes.

External audit (EA) An independent engagement that gathers evidence to support an opinion on the financial statements in accordance with the relevant reporting framework.

Independence in practice (objectivity) The ability of internal audit to report without bias or undue influence, supported by appropriate reporting lines, unrestricted access, and safeguards against conflicts.

Competence (capability) The skills, experience, training and resources needed to perform high-quality work, including effective supervision and review.

Evidence trail (systematic approach) The documented link from objectives to procedures to evidence to conclusions, enabling an independent reviewer to see what was done and why the conclusion is justified.

Use of internal audit work (reliance) Using internal audit’s completed work as part of the external auditor’s evidence base after evaluating quality and performing appropriate validation.

Direct assistance Internal auditors performing specified external audit procedures under the external auditor’s direction, supervision and review, where permitted by law, regulation and applicable standards.

Scope limitation A restriction that prevents the auditor from performing procedures considered necessary, requiring alternative work or an adjusted audit response.

Professional scepticism A questioning mindset that critically evaluates evidence, remains alert to inconsistencies, and considers the possibility of error, bias or fraud.

Control deficiency A weakness in the design or operation of a control that reduces its ability to prevent, detect or correct misstatements on a timely basis.

Quality control (within internal audit) Internal audit’s internal processes for supervision, review, sign-off, and consistent working practices to support reliable outputs and credible conclusions.