Audit evidence standards: what ISA 230 and PCAOB documentation rules actually require
A finding that cannot be traced back to a document and a rule is an opinion, not evidence. Here is what ISA 230 and PCAOB AS 1215 actually require of audit documentation, and why it applies to automated checks too.
"We found an issue" is not audit evidence. What makes a finding usable — to a business owner deciding whether to act on it, to an external accountant deciding whether to trust it, to anyone reviewing the work later — is that it can be traced back to a specific document, a specific rule, and a specific reason the rule applies. That standard is not a modern invention specific to automated tools; it is the substance of long-established audit documentation requirements.
What ISA 230 requires
ISA 230, "Audit Documentation," sets the working principle international auditors are held to: documentation must be sufficient to enable an experienced auditor, with no prior connection to the engagement, to understand the work performed, the results obtained, and the significant conclusions reached. The standard does not just want the answer — it wants the trail that lets someone else verify the answer was reached properly.
What PCAOB documentation rules require
In the US, PCAOB AS 1215, "Audit Documentation," sets an equivalent bar for issuer audits: documentation must contain sufficient detail to provide a clear understanding of the work performed, including the evidence obtained and its source, and the conclusions reached. Both standards converge on the same underlying test — a finding without a traceable source and a traceable reason is not documentation, it is an assertion.
Why this standard applies just as much to an automated check
A rule-based document check produces findings the same way a human reviewer's working papers do, and the same evidentiary bar applies: every finding should be traceable to the specific document (or documents) it came from, the specific check that produced it, and the specific legal or procedural basis the check is built on. A tool that says "anomaly detected" without naming which document, which figure, and which rule fails this test just as thoroughly as a human reviewer's undocumented gut feeling would.
What "traceable" looks like in practice
| Element | What it should specify |
|---|---|
| Source document | Which specific document (or documents) the finding is based on |
| Rule applied | Which specific check produced the finding, by name or reference |
| Legal or procedural basis | The specific statute, regulation or standard the check is derived from |
| Applicable period | The date range the rule was in force, checked against the document's own date |
| Confidence level | Whether the finding is a confirmed discrepancy or a pattern that warrants investigation |
What this changes about evaluating a document-review tool
The right question to ask a vendor is not "does it find anomalies" — nearly everything claims that. It is: for any given finding, can you show me the exact document, the exact rule, and the exact legal basis it rests on, the same day it was generated, without needing to ask an analyst to reconstruct it after the fact? A tool that can answer that on demand is producing documentation in the ISA 230 / PCAOB AS 1215 sense. One that cannot is producing a summary, which is a different — and less defensible — thing.
What documentation failure actually looks like
The gap between a defensible finding and an unsupported claim rarely announces itself as an obvious problem in the moment — it surfaces later, when someone other than the original reviewer needs to rely on the finding. A business owner receiving a report that says "potential duplicate payment identified" with no invoice numbers, no dates, and no explanation of what specifically triggered the flag has no practical way to investigate it, verify it, or act on it beyond taking the claim on faith. The same finding, with the two specific invoice numbers, the amounts, the dates, and the matching logic that connected them, becomes something the business owner (or their external accountant) can check independently in minutes.
This distinction matters most exactly when a finding turns out to be wrong. A vague, unsupported flag that turns out to be a false positive erodes trust in every subsequent finding from the same source, because there is no way to tell in advance which flags are solid and which are not. A specific, sourced finding that turns out to be a false positive is still useful — the reviewer can see exactly why the check triggered, confirm the benign explanation, and move on with the false positive itself serving as a data point about where the check's logic could be refined.
Why this standard matters more, not less, as checks become automated
There is a natural worry that automated checks make documentation worse by removing a human's explanatory judgment from the process. The opposite is true when the automation is built correctly: a deterministic, rule-based check can attach its exact source document, exact rule, and exact legal basis to every single finding it produces, every time, without the variability a human reviewer's notes inevitably carry across a busy review season. The documentation standard does not get harder to meet with automation — it gets easier to meet consistently, provided the underlying system is built to preserve that traceability rather than collapse it into an unsupported summary.
Related reading
- Inside a 55-point audit control framework: what auditors actually check, and why each one has a legal source
- Duplicate payment detection: the audit controls that catch it before the second check clears
FAQ
Do ISA 230 and PCAOB AS 1215 apply to internal, non-statutory document reviews?
Strictly, both standards govern statutory audit engagements. But the underlying principle — a finding should be traceable to its source and its basis — is good practice for any document review a business intends to rely on, statutory or not, because the alternative is a finding nobody can verify later.
What happens when a finding's legal basis changes between when the document was issued and when the review runs?
A properly built check applies the rule that was in force on the document's own issue date, not the date the review happens to run — a requirement that changed mid-year should never retroactively apply to documents issued before the change took effect.
Can a narrative summary written by AI satisfy this documentation standard?
Only if the underlying findings themselves — the specific documents, rules and legal bases — were generated by a deterministic, traceable process first. A narrative can make findings more readable; it cannot substitute for the findings having a real, checkable source, since a generated summary is not itself evidence.