Evidence requests (PBC)
Internal Audit → an engagement → Requests
A PBC request is the audit team asking the business for documents. It has a reference like PBC-014, an owner, a due date — and a numbered line for every document asked for: PBC-014.1, PBC-014.2, and so on.
The lines are the point. An audit rarely asks for one thing, and until each item was tracked on its own, a request for eight documents that received five looked exactly like a request that was finished.
For the auditor
One request per team. An engagement usually asks several teams for different things — cyber for four documents, IT for eight, risk for two. Raise one request per team, addressed to that team's contact, so each contact sees only their own items and each item is chased on its own.
Building the list. Give the request a title, an owner and a due date, then type the first item and press + Add item — or just press Enter, which adds the next row and puts the cursor in it. Keep going until the list is complete. You rarely know all eight up front, so the list grows as you think.
Asking for a single document is still a single form: leave the item list empty and the request gets one line taking its title.
Adding later. The same control is inside every request under Add lines. Numbers are never reused, so a reference you have quoted in an email always means the same item — and anything added after the request was raised is marked added later, so an auditee who answered five and finds six owed can see when the sixth appeared.
Reviewing. Each line is accepted, sent back, or marked not applicable on its own:
- Accept — locks that line and its evidence. Only available once something has actually been attached.
- Send back — returns only that line, with a reason. Everything already accepted stays accepted. You no longer have to choose between accepting an incomplete submission and discarding good evidence.
- Not applicable — closes the line without evidence, with a reason. Use it when the item genuinely does not exist at this entity; it is not a mark against the auditee.
Rejection and N/A both require a reason. A decision without one tells the auditee nothing, and an unexplained N/A is how audit scope quietly shrinks.
Accepting the whole request is a shortcut for deciding every open line at once. It only touches lines that were actually submitted — you cannot accept evidence nobody sent.
For the auditee
Open My Actions to see everything asked of you.
Attach a file or a link to the specific line it answers. That is all — there is no "mark as submitted" button, because attaching is submitting. A line with something against it is submitted; a line with nothing is still owed.
You can also leave a note on any line: "With IT — expected Thursday", or "The March file is missing from the archive". The auditor sees it beside the line, which is better than it arriving by email outside the record.
If a line is sent back, attach the replacement to the same line and it is resubmitted. Nobody has to reopen anything for you.
What the status means
The status of a request is calculated from its lines — nobody sets it:
| Status | What it means |
|---|---|
| Requested | Nothing has been attached yet. |
| Partially submitted | Some lines answered, some still owed. |
| Submitted | Every line answered, waiting on the auditor. |
| Rejected | At least one line was sent back. |
| Accepted | Every line is accepted or not applicable. |
| Overdue | A line is still owed past the due date. |
Because five of eight is not done. Before this, a request was one row with one status, so a half-answered request could read submitted before its due date — and then fell outside both the overdue check and the reminder, so the three missing documents were never chased. Overdue and reminders now work at the line, and a chase-up names the items you still owe rather than saying a request is late.
The register
Register at the top of the Requests tab downloads the whole engagement's PBC list as CSV, one row per line: reference, request, item, owner, due date, status, how many files are attached, days late, and both notes.
That is the working list a fieldwork team tracks against, and it is the answer to "which documents are we still waiting for?" — a question a list of requests cannot answer.