Running post-issuance file reviews
How a firm chooses completed audit files and reviewers for monitoring under ISQM 1, reviews the locked archive and turns findings into action.
By Achekam · · 4 min read · For Accountants & audit firms in South Africa, Nigeria, Kenya
A post-issuance review, often called a cold file review, is the closest a firm gets to seeing its work the way an inspector will. The report has gone out, the client is happy, and the file is closed. Someone who was not on the engagement now opens it and asks whether the evidence supports the opinion.
Done well, these reviews find problems while they are still the firm's own business. Done badly, they become a form that confirms every file was "satisfactory" and teaches nobody anything. The difference lies in how files and reviewers are chosen, what the reviewer actually reads, and what happens to the findings.
Monitoring under ISQM 1
ISQM 1 requires a firm to monitor its system of quality management and to remediate what it finds. Inspecting completed engagements is one of the monitoring activities the standard expects firms to consider, with the firm deciding how many, which ones and how often, and with engagement partners covered over a cycle.
A cold file review therefore has two purposes. It checks the individual file, and it tests the system: whether the firm's policies on planning, review, consultation and documentation actually produced good work. Keep both purposes in mind, because a finding that "the file was weak" is far less useful than one that says which policy failed.
ACCA's article on ISQM 1 and its eight components explains where monitoring and remediation sit among the parts of a firm's system.
Choosing files and reviewers
Random choice alone wastes reviews on simple files. Mix risk-based and rotational selection:
- every engagement partner at least once in the cycle the firm sets;
- files with significant risks, first-year clients or modified opinions;
- files that ran well over budget or finished close to the deadline;
- areas where last year's reviews or inspections found weaknesses.
Achekam's real figures help with the risk-based part. Time Reports shows engagement time by person, so you can find audits where partner time was light. The Performance Reviews table, which holds work figures rather than appraisals, shows items returned by review and on-time rates.
The reviewer must be objective: not on the engagement team and, ideally, not reporting to its partner. There is a practical constraint too. Only a partner, a manager or the quality reviewer can download a locked audit file's archive in Achekam, so the person reviewing needs one of those positions, or a colleague in one who downloads it for them.
Reviewing the locked archive
After the report is issued, the engagement partner assembles and locks the audit file. From then on, changes can only be added as addenda, and unlocking needs a second partner or the quality reviewer. That lock is what makes a cold review meaningful: the reviewer sees the file as it stood, not as it was improved after someone heard a review was coming.
Each locked file is built into an archive of its papers, workbooks, signed report and logs, with a hash manifest that can be re-verified. Anything that could not be included is listed as an omission. Start every review with two checks: that the archive verifies, and that the omissions list is empty or explained.
Then read the file the way the work was done. Working papers in Achekam move through preparation, manager review, partner review, an optional engagement quality review, completion and lock, and sending back, reopening or locking needs a written reason. Those reasons are evidence. So is the history of review notes, which shows what reviewers raised, how preparers answered and when notes were cleared. A note cleared the day after the report date tells its own story.
Assembling and archiving the audit file explains how the archive is built.
Recording findings in the quality registers
Write findings down where the firm's other quality records live. Achekam keeps the quality registers on its server, among them quality incidents and inspection progress, with every version and who changed it. Record each finding with the engagement, the area, what was wrong, its seriousness and the policy it touches.
A simple grading helps when comparing across years:
| Grade | Meaning |
|---|---|
| Satisfactory | Evidence supports the opinion; minor points only |
| Improvement needed | Evidence adequate but documentation or review weak |
| Significant concern | Evidence does not clearly support a material area |
Grades are for the file, not for the people on it.
Write each finding so it can be checked later. "Inventory work weak" cannot be checked. "No evidence that the count attendance covered the second warehouse, which held a material part of closing stock" can, and it points straight at the planning and briefing policies that should have caught it. Note also what the file did well. A review that records only failures teaches the team to dread the next one, while one that names good practice spreads it.
Feeding results back to the team
A finding nobody hears about changes nothing. Share results in three ways:
- With the engagement team, in a conversation about what the file shows, not a verdict on them.
- With all partners, as themes across the year's reviews.
- Into the firm's remediation process, where significant concerns get a root cause analysis and an action with an owner and a date.
Close the loop next year. Choose at least one file in each area that had findings, and check whether the remediation worked.
Setting the first round
Choose the files for this year's reviews now, before the busy season starts, using the selection list above. Name a reviewer for each, confirm they can download the archive, and put the review dates in the diary alongside the client deadlines.
General guidance only, not advice on your own circumstances. Tax and payroll rules change: check the current position with the authority or your adviser.
