The tracker answers four different questions
A useful PBC ledger does not have one overloaded “received” column. It keeps four decisions apart:
- Was a response or reference recorded? This is an administrative fact.
- Can the assigned reviewer reach it? A restricted path can be real and still unusable.
- Has the material been inspected and tested? Availability is not validation.
- Has the responsible auditor accepted it for the relevant purpose? Only the engagement's review process can answer this.
For PCAOB engagements, AS 1105 distinguishes the quantity of evidence from its quality and directs attention to relevance and reliability. AS 1215 addresses documentation that lets an experienced auditor understand the work, evidence, and conclusions. Those are PCAOB-specific authorities, not a universal global rulebook.
For an English/global audience, also identify the audit framework that actually applies. On 5 August 2026, the IAASB issued an exposure draft covering proposed revisions to ISA 330, ISA 500, and ISA 520. It is a current proposal, not a new effective requirement. This tutorial therefore uses stable operational distinctions—recorded, reachable, reviewed, accepted—without claiming one jurisdiction's standard controls every engagement.
Start from two controlled populations
Freeze the request list and the evidence register separately. Give each export a cutoff time, preparer, source system, filter description, and population count. If either population changes during the exercise, create a new version rather than silently replacing rows.
| Request fact | Evidence fact | Never infer |
|---|---|---|
PBC-01 requests a trial balance for a stated period | FIN/TB-v3.xlsx is recorded as submitted | The workbook is accurate, complete, or responsive |
PBC-02 requests a cash reconciliation | No response or reference appears | The work was never prepared |
PBC-03 requests board minutes | A restricted reference exists | The audit team can open or rely on it |
PBC-04 requests a fixed-asset additions listing | An upload is recorded | The listing was signed off or reconciled |
Use the downloadable audit evidence request tracker CSV as a starting ledger. It contains the four fictional rows plus blank reviewer and review-date fields; replace the fixture rather than appending live client information to it.
Use mutually exclusive operational states
The test allows three classifications. AVAILABLE_UNVERIFIED means a reference exists but substantive review is unresolved. MISSING means neither a response nor an evidence reference is recorded. ACCESS_BLOCKED means the register points somewhere that the reviewer cannot yet confirm they can inspect.
Do not add a generic COMPLETE value unless your organization has defined exactly who may assign it and what it means. “Complete for request administration” and “sufficient appropriate audit evidence” are different claims.
Run the AI without giving it the answer
The second test prompt supplied the four request records, the state definitions, and an output schema. It did not list the expected status of any row and did not tell the model which overall gate to return. That distinction matters: the earlier test largely checked instruction following, while this one required classification from the fixture.
Answer-blind classification contract
Represent every request exactly once.
Choose only AVAILABLE_UNVERIFIED, MISSING, or ACCESS_BLOCKED.
Preserve supplied owners, dates, and evidence references.
Keep absent values null.
Do not treat a filename, submission, or access as audit sufficiency.
Derive the readiness gate from the classified rows.
Return valid JSON only.The first response assigned PBC-01 and PBC-04 to available-but-unverified, kept PBC-02 missing, marked PBC-03 access-blocked, and returned NOT_READY_FOR_AUDITOR. The local gate confirmed all four IDs, exact preserved fields, non-empty review actions, and the two blocked items.
What the retained test did—and did not—prove
| Check | Observed result | Meaning |
|---|---|---|
| Fresh answer-blind run | PASS | All fixture rows received the expected operational state |
| False-ready mutation | REJECTED | The gate would not accept readiness while blockers remained |
| Dropped-request mutation | REJECTED | Population coverage is enforced for this fixture |
| Erased-reference mutation | REJECTED | Available evidence cannot lose its recorded locator |
The test does not show that the referenced files are authentic, readable, complete, accurate, or appropriate. It also does not test a real PBC population. The downloadable blind-test pack provides the exact prompt, retained JSON, editable CSV, screenshot, Python gate, disclosed mutations, and hashes so those narrower claims can be inspected.
Review a request before changing its state
- Reconcile the tracker count to the frozen request population.
- Confirm entity, period, account, control, or meeting scope.
- Open the evidence through an authorized path and record who reviewed it.
- Test internal consistency and applicable completeness or accuracy assertions.
- Preserve contradictory evidence and unanswered questions.
- Record auditor disposition separately from preparer and coordinator status.
- Retain version, review date, and the basis for any accepted or rejected item.
Send exceptions to the right workflow
If the missing artifact is a cash reconciliation, prepare it with the bank-to-ledger reconciliation workflow before linking it here. Repeated payable records belong in the duplicate-invoice candidate review. When documents contain confidential information, use the sensitive-data boundary workflow before any approved AI processing.
Stop condition
The tracker is ready for auditor review only when every request appears exactly once, recorded references remain traceable, missing and access-blocked items are resolved, and the assigned reviewer can inspect the current version. Even then, readiness for review is not acceptance and says nothing by itself about audit sufficiency.
