Controls in Technology-Enabled Processes

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 themanual review(who performs it, frequency, evidence of investigation and follow-up).
2. Validate thesystem outputused 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 (accuracyandcompleteness)
• 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,000short

Deductions

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

Net pay

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

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):

• Inspectinterface exception logsto 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) andreprocessthe rejected item.
• If reprocessing is not possible before reporting, post a controlled adjustment supported by evidence and approved review.
• Strengthen the control by enforcing apre-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 / accuracyrisk: expense may be understated by£3,000if 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.