IT in a small client's audit

How much an auditor of a small client must understand about its IT systems and general IT controls under ISA 315, and how that shapes journal testing.

By Achekam · 11 October 2026 · 4 min read · For Accountants & audit firms in South Africa, Nigeria, Kenya

"The client uses an off-the-shelf package, so there is no IT risk." It is a common sentence in small-company audit files, and a hard one to defend. The package may be off the shelf, but the bookkeeper shares the administrator password with the owner, posted entries can be edited without a trace, the inventory valuation lives in a spreadsheet with formulas nobody has checked, and the only backup is a flash drive in the owner's car.

ISA 315 (Revised 2019) made the auditor's understanding of IT more explicit and more scalable. It does not expect a small audit to look like a bank audit. It does expect the auditor to know which systems the figures come from, who can change them, and whether that matters to the risks of material misstatement.

Why IT matters even in small audits

The statements are produced by the client's IT environment, however simple. The auditor's risk assessment depends on it in three ways:

• Where the data comes from: the accounting package, a separate payroll system, an online point-of-sale system, spreadsheets for estimates and stock.
• Whether the data can be trusted: if anyone can change posted entries or master data without a record, reports from the system are weaker evidence.
• Whether the auditor can rely on automated controls: a package that enforces approval of payments only helps if the approval cannot be bypassed.

ISA 315 (Revised 2019) requires the auditor to understand the IT environment relevant to the information system, and, for the controls the auditor identifies as relevant, to identify the IT applications involved, the risks arising from the use of IT and the general IT controls that address them. In a simple environment, that understanding can be short. It cannot be absent.

Packages, spreadsheets and who has access

For a typical small client, map the environment on one page:

The questions that matter most are about access and change. Who has administrator rights? Are user accounts shared? Can the package be configured to allow back-dated postings or edits to closed periods, and is it? Are spreadsheets used for material figures, and who checks them?

IT general controls in plain terms

General IT controls support the continued proper operation of the systems. For a small client, think of them in three groups:

1. Access: individual user accounts, passwords not shared, administrator rights limited, leavers removed promptly.
2. Change: package updates applied by someone responsible, settings changed only with authority, spreadsheet formulas controlled.
3. Operations: backups taken and tested, problems logged and resolved.

The auditor does not have to test these controls unless planning to rely on automated controls or system reports that depend on them. But a weakness in them can itself be a risk, particularly the risk of management override, and it often belongs in the management letter.

Effects on journal entry testing

Journal entry testing under ISA 240 is where IT understanding pays off most directly. The test is only as good as the population, and the population comes from the client's system.

Before testing, establish:

• that the extract is complete, by reconciling its totals to the trial balance;
• whether the system records who posted each entry and when, or whether all entries appear under one user;
• whether posted entries can be edited or deleted, which would mean the extract may not show the original postings;
• which entries are system-generated and which are manual.

In Achekam, staff load a whole-population journal extract as CSV and map its columns, and Achekam flags entries such as manual, weekend, after-hours and post-close postings for staff to select and test. The CSV itself is not stored; its hash and row count are. Two IT points follow. First, the flags depend on the columns the client's system provides: if every entry carries the same user and a midnight timestamp, the after-hours and manual flags have nothing to work with, and the team needs other criteria. Second, record the source of the extract, the reconciliation to the trial balance and the row count on the working paper, so the population can be identified later.

Documenting the understanding

Achekam's Controls & Walkthrough Studio saves its work on the server for the chosen engagement, which makes it a natural place to record the IT environment alongside walkthroughs of the processes it supports. The ISA numbers on its badges are labels, not evidence of compliance.

On the work item for risk assessment, each procedure is marked done only with a written response and its documents, or set aside with a reason; steps are never deleted. Attach the one-page systems map, record who was asked about access and changes, and state the conclusion: which IT risks were identified, and how they affect the planned response. Staff can ask AI to draft that conclusion, and the draft goes into the file only when a person saves it; the judgement about which IT risks matter is the team's.

Walkthroughs of the processes that sit on these systems are covered in walkthroughs and controls, and the wider risk assessment in understanding the entity and assessing risk. The IAASB's ISA 315 first-time implementation guide explains the most substantial changes in the revised standard, including the IT requirements, to help auditors apply them as intended.

One question for every client

At planning, ask the client to show you, on screen, what happens when someone tries to change an entry in a closed period. The answer will tell you more about the IT environment than a questionnaire.

General guidance only, not advice on your own circumstances. Tax and payroll rules change: check the current position with the authority or your adviser.