How Auditors Test Automated Controls and System-Generated Reports
By SimplyCPA · 11 October 2026
On this page (7)
- Automated controls: Because a computer performs them consistently, testing one instance can be enough — if IT general controls are effective.
- Dependence on ITGCs: Effective change management and access controls are what let the auditor assume the control kept working all year.
- Benchmarking: An automated control that hasn't changed since it was last tested may be relied on in later periods without full retesting, if ITGCs remain effective.
- Key reports (IPE): The auditor tests that the report's source data, parameters and logic produce complete and accurate output.
- Spreadsheets and end-user computing: Not covered by ITGCs, so they need their own controls or direct testing.
Manual vs automated controls
| Manual control | Automated control | |
|---|---|---|
| Example | A manager reviews and signs off the monthly bank reconciliation | The ERP system blocks a purchase order above an approval limit; three-way match before payment |
| Consistency | Depends on the person every time | Performs the same way every time, unless the program changes |
| Typical test | Sample sized for frequency (e.g. 25–40 for a daily control) | Test of one instance per scenario, plus reliance on ITGCs |
Why ITGCs matter
IT general controls (ITGCs) support the continued functioning of application controls. The key ITGC domains are:
- Program change management — changes are authorised, tested and approved before going live.
- Logical access — users and privileged access are appropriate and reviewed.
- Computer operations — job scheduling, backups and incident handling.
- Program development — new systems are implemented with appropriate testing and data conversion.
If change management is ineffective, the auditor can't assume the automated control worked the same way all year, so it must test more instances or find compensating evidence. See IT general controls explained.
How an automated control is tested
- Understand the control's configuration (for example, the tolerance for a three-way match).
- Test each relevant scenario once — for example, an invoice within tolerance (passes), one outside tolerance (blocked), and an override attempt by an unauthorised user.
- Confirm ITGCs over the application were effective throughout the period.
- Where permitted, use benchmarking in later years: confirm the program hasn't changed (comparing versions or reviewing change logs) rather than retesting from scratch.
Testing key reports
When the auditor uses a system report — an aged receivables listing, a list of journal entries, an inventory valuation report — as evidence, it must evaluate whether the information is complete and accurate and precise enough. Common approaches:
- Test the controls over the report's generation (report logic changes, access to parameters).
- Agree totals to the general ledger (completeness).
- Test samples from report to source records and from source records to the report.
- Inspect report parameters (date range, entity, filters) each time it's run.
- Reperform the report or recreate it using data analytics.
Spreadsheets and end-user computing
Spreadsheets used for calculations (reserves, fair value models, consolidation) fall outside ITGCs. The auditor tests controls over their use — version control, locked formulas, independent review — or tests the calculations directly.
Service organisations
If an automated control sits at a service organisation (a cloud payroll provider, for example), the auditor typically relies on a SOC 1 Type 2 report covering the control and checks complementary user entity controls at the client.
This topic spans AUD and the ISC Discipline — see IT controls in an audit and ISC IT general controls.