Root cause analysis after a quality finding
How a firm investigates the root cause of a quality incident, inspection finding or client complaint, sets remedial actions and checks they worked.
By Achekam · · 4 min read · For Accountants & audit firms in South Africa, Nigeria, Kenya
The usual response to an inspection finding is training. The finding says the inventory work was thin, so the firm runs a session on inventory. Next year the same weakness appears on a different file, and the firm runs the session again.
Training fixes a lack of knowledge. Most findings are not caused by a lack of knowledge. They are caused by a plan that did not ask the right question, a review that came too late, a budget that left no time for the hard area, or a template that hid a step. Until the firm finds which, it is treating symptoms. ISQM 1 recognises this by requiring a firm to investigate the root causes of the deficiencies it identifies, and to design remedial actions that address them.
Why the cause matters more than the finding
A finding tells you what went wrong on one file. The root cause tells you why it went wrong, and therefore where else it is likely to be going wrong right now. Two findings that look identical can have entirely different causes: one team did not understand the standard, another understood it perfectly but ran out of time. The remedies are different, and applying the wrong one wastes effort and leaves the risk in place.
Root cause analysis also applies to good outcomes. When a difficult engagement went well, asking why can show what to repeat. The IAASB's page on ISQM 1 describes the system of quality management that this analysis feeds back into.
Logging the incident
Start with a record. Achekam keeps the firm's quality registers on its server, among them quality incidents, complaints and inspection progress, with every version and who changed it. Log each finding as soon as it is known, with:
- the source: inspection, cold file review, complaint, or something staff raised;
- the engagement and the area;
- a factual description of what was wrong, without blame;
- who will lead the analysis.
The version history is useful later. As the analysis progresses, the entry will be rewritten, and the earlier versions show how the firm's understanding developed.
Asking why until the cause is clear
The simplest method is to keep asking "why?" until the answer is something the firm controls and could change. A worked example, without figures:
Finding: revenue cut-off was not tested at a retail client's second branch.
- Why? The audit plan covered only the main branch.
- Why? The plan was rolled forward from the prior year, before the client opened the second branch.
- Why was the new branch not picked up? The continuance review did not ask about new locations or operations.
- Why did review not catch the gap? Manager review of the planning papers happened after fieldwork had started.
Two causes emerge: a continuance checklist with a missing question, and a review timetable that let planning be reviewed too late. Neither would be fixed by training on cut-off.
Achekam's own records help answer the "why" questions with evidence rather than memory:
- Review notes. Each note's history is kept, so you can see what reviewers raised, when, and how it was answered.
- Working-paper history. Sending back, reopening or locking a paper needs a written reason.
- Time. Time Reports shows engagement time by person, which tells you whether senior people were involved when it mattered.
- Work figures. The Performance Reviews table holds real work figures, including items returned by review and on-time rate, not appraisals.
- Consultations. The consultation record shows whether a difficult matter was taken to someone before it was concluded.
- Change log. Record Governance logs who did what and when on governed records.
Use these as facts about the work. A finding's root cause is almost never "the senior was careless"; if it looks that way, ask why the process allowed one person's slip to reach the report.
Remedial actions and their owners
Each cause needs an action that would stop it recurring, an owner and a date.
| Cause | Remedial action | Owner |
|---|---|---|
| Continuance checklist missing a question | Add a question on new locations and operations | Quality partner |
| Planning reviewed after fieldwork began | Planning sign-off required before fieldwork is scheduled | Managing partner |
| Area always under-budgeted | Set minimum hours for that area in budgets | Engagement partners |
Record the actions on the incident entry so the cause, the remedy and the owner sit together.
Keep the number of actions small. A long list of minor changes signals effort but rarely changes behaviour, and owners lose track of which ones matter. One or two actions aimed squarely at the cause, each with a date, will do more than ten aimed at the symptoms.
Checking that the fix worked
An action is not finished when it is done. It is finished when the evidence shows the problem has stopped. Decide at the outset how you will know:
- Choose files in the affected area for next year's cold file reviews.
- Check whether the new step appears on those files and was done at the right time.
- Record the result on the original incident entry.
If the same finding appears again, the analysis missed something. Reopen it rather than starting a new one, so the history stays in one place. This loop is part of the firm's wider system, described in setting up ISQM 1 in a small firm. Complaints deserve the same treatment, as explained in handling a client complaint.
Your most recent finding
Take the most recent finding against the firm, from any source, and run the "why" questions with the people involved in a single meeting. Write down the causes you reach, one action for each, and the date you will check it worked.
General guidance only, not advice on your own circumstances. Tax and payroll rules change: check the current position with the authority or your adviser.
