A PBC request list that checks every file before the auditor sees it
Evidence checked before the auditor sees it, and the request list closed before fieldwork.
See one case, screen by screen ↓Audit Evidence Collection runs your PBC request list for internal, external and SOX audits. Seven agents write each request in plain words, check every upload for period, population and completeness against the system count, return wrong files to their owner with one reason, and chase owners on a schedule worked back from fieldwork. The audit lead accepts each item as final, and only accepted evidence is released to the auditor.
How to choose AI solutions for back-office and enterprise work →
Updated
Every audited company answers PBC lists: the external auditor's, the SOX testers' and internal audit's, often for the same quarter. Someone in group finance splits each list by control and owner, rewrites the vague lines, merges the duplicates by hand and emails control owners. The owners run what they think was asked and upload it. The tracker turns green when a file arrives.
Nobody checks the evidence itself until an auditor opens it, often in fieldwork. Then it is the wrong quarter, a population missing two company codes, or a screenshot without the report parameters, so the count cannot be tied to the system. The request goes back, the owner is chased again, and fieldwork stretches. Under AS 1105.10 the auditor has to evaluate whether information the company produces is complete and accurate, so these faults surface either way — the only question is when.
Estimated split for one interim list of about 190 requests at a large group, by hand and with the solution.
Seven agents write, check, cross-check and chase every request; the audit lead accepts each one as final.
Thursday 15 October 2026, 10:12. Kestrel & Vane Group is four days from Q3 interim fieldwork with its external auditor, Harcourt Lyle LLP. Three lists are open — 186 external audit requests, 94 for SOX testing, 38 for internal audit's P2P review in Leeds. Here is how the audit lead, a control owner and the agents work one request through together, screen by screen, in the working solution.
Elena opens the external audit list: 112 of 186 accepted (60%), 23 checked and waiting for her, 11 returned to owners, 24 waiting on owners and 14 not yet sent. The chaser forecasts 7 at risk for fieldwork. Every row opens to its files and six check results — HL-133's terminated-users file came back because leavers from company codes 3000 and 4000 were missing.
“Checker this quarter: 412 uploads checked · 63 returned before the auditor saw them · median 38 s.”
Harcourt Lyle wrote “Provide vendor master change report for the period with parameters.” Ravi's request, HL-114 for control AP-C07, says exactly what to send: run ZVM_CHG in the ERP for change dates 1 Jul – 30 Sep 2026 and company codes 1000, 1100, 2000, 3000 and 4000, with the eight columns it must have and a screenshot of the parameters screen. Beside it sits last year's accepted file, names redacted: 1,116 rows, with the parameters screen.
The request writer never changes what the auditor asked for; the original stays beside it.
Ravi uploads VM_change_log_Q2_2026.xlsx. The checker opens it, reads the report header and finds change dates 1 Apr – 30 Jun. Population, legibility and fields pass; the period fails. Forty seconds after the upload the file is back with Ravi, with the reason and the fix, and the auditor never sees it.
“How to fix: run ZVM_CHG again with change date 01.07.2026 to 30.09.2026, then upload the file and a screenshot of the parameters screen.”
Ravi uploads the Q3 file and the parameters screenshot. The checker shows every step with its source: period 1 Jul – 30 Sep, all five company codes, 1,284 rows = 1,284 in the ERP, all eight fields, saved two seconds after the export. 97% sure, handed to Elena. The consistency checker adds a note: 3 changes, rows 211, 640 and 1102, were approved by the person who made them.
“That may be a control exception for AP-C07. It is noted for you only; it is never sent to the auditor.”
Elena reads the trace, opens the files from their source chips and accepts HL-114 with AC-01 · Meets the request in full. The acceptance carries her name and role and goes on the audit trail. She opens a deficiency review with Graham Achterberg for the three self-approved changes; the auditor is not told until he decides. The request closes four days before fieldwork.
“Only you can accept evidence as final. The owner cannot accept their own.”
The review queue holds 23 checked items. Nineteen are 95% sure or more and can be accepted together, each still logged on its own. Four need her judgement and stay out of the bulk accept: HL-121's payroll register has bank account numbers in 1,912 rows and is blocked until redacted, and HL-148's bank reconciliation has a faint reviewer signature at 71% legibility.
Harcourt Lyle's second batch arrived on Wednesday at 16:02; by 16:05 the agents had mapped all 14 lines to a control, an owner and a due date. HL-278 “Provide user access listing” is rewritten as the users and roles listing in ERP production at 30 Sep, because last year the same line was re-requested twice. HL-279's owner is 58% sure and marked to check, and HL-282 is the same report as SOX-047, so one upload can answer both.
Below 80% sure, the owner matcher asks the audit lead instead of assigning.
Every request has a schedule: sent, half-way, three days before, due, to the manager, to the audit manager. Tomás Rivera in Monterrey is three requests late, so the chaser escalated them to his manager, Alejandro Pardo, on 14 Oct with the nudge history. Hannah Ostrowski is on leave until 23 Oct, so reminders to her are paused and her open requests can be reassigned to her delegate, Callum Reid.
The chaser never escalates beyond the owner's manager without the audit lead.
Marisol releases accepted evidence to Harcourt Lyle in batches — 104 items in four so far, 9 in the next, HL-114 among them. Three people at the firm can see released evidence until 30 Nov; Tobias Lindgren sees IT controls only. A follow-up question from Owen Pritchard becomes a tracked request with one click.
“The auditor never sees files that are not accepted, the checker's heads-ups, internal notes, or reminder history.”
Graham sees 113 of 186 accepted, 73 open, a forecast of 94% at fieldwork against a 95% target, and 2 auditor re-requests this quarter against 41 at the FY25 interim. Every one of the 64 returned files is counted by its reason — wrong period now 22. The weekly status is drafted for him and Margaret Owusu, the group financial controller, with every number linked to its request.
The same quarter's request lists, seen by four of the people who carry them — what the quarter looked like, and what it looks like now.
Seven agents write, check, cross-check and chase every request; the audit lead accepts each one as final.
Turns each auditor line into a plain request: the report, its parameters, the period, the population, the fields and a redacted example of last year's accepted file.
Assigns each request to its control owner from the control register and the HR directory, and finds duplicates across the three audits.
Opens every upload and checks the period, the population, completeness against the system count, legibility, the requested fields and that it was not edited after export.
Compares files across requests and audits the way the auditor will, and flags possible control exceptions to the audit lead.
Reminds owners on a schedule worked back from fieldwork, by email and chat in their own time zone, escalates to managers and forecasts what will miss.
Offers last year's accepted evidence for standing items, only after confirming the document version, configuration or owner is unchanged.
Reports readiness by audit, process and owner, the burn-down to fieldwork, return reasons and the weekly status.
Accepts, returns or overrides with a reason code. The agents propose; a named person decides.
Ask about any request, owner or file, or say who to chase. Every answer cites the requests and files it comes from, and changes are proposed for you to approve.
What will miss fieldwork, and why?
Seven requests are at risk for Mon 19 Oct: HL-140, HL-141 and HL-142 from Tomás Rivera, 2–3 days late and escalated to Alejandro Pardo on 14 Oct; HL-131, Kenji Arai's privileged access review, the largest pull of the quarter; HL-125, because Hannah Ostrowski is on leave to 23 Oct; HL-170, the tax provision, finalised on 20 Oct; and HL-152, which Ravi Menon says may not be signed. The list is filtered to these seven.
Remind every owner with an overdue request
Nine requests are late, across seven owners. Each owner got one reminder with the request, its example and the days left before fieldwork. Hannah Ostrowski is on leave, so hers went to her delegate, Callum Reid. Each reminder is on the audit trail.
Why was HL-119 returned?
HL-119, the duplicate vendor check report, was returned to Ravi Menon on 13 Oct at 11:20, 36 seconds after he uploaded it. The file has the period and all five company codes but no parameters screen, so its 38 rows can't be tied to the system count — evidence standard GAS-03 §3.2.
Draft the weekly status for Graham
External audit, Q3 interim: 112 of 186 accepted (60%), fieldwork Mon 19 Oct, 9 late and 7 at risk. This quarter the checker caught 63 wrong files before the auditor saw them, and Harcourt Lyle has re-requested 2 items (FY25 interim: 41). The draft is open on the Status screen, ready to send.
13 screens from the working solution, on its sample data. Pick one to see it large.
What the checker checks, when the chaser reminds and who may do what are settings. Every change is a new version that the audit manager approves.
| Setting | Default | Choose from |
|---|---|---|
| Period and population checks | On | Locked on by policy — cannot be turned off |
| Return automatically when the period or population fails | On | On · Off (sent to the audit lead instead) |
| Send to a person when the checker is less than | 85% sure | Any threshold, changed in a new version |
| Legible: text confidence at least | 85% | On or off, with its threshold |
| Exports must be newer than | 30 days | Days between the export and the upload |
| Screenshots must show | System name · user · clock | Set by your evidence standard (policy GAS-03) |
| Reminders | At half the time to due, 3 days before, on the due date at 08:00 | Each step editable, in the owner's time zone, with quiet hours |
| Escalation | To the owner's manager 1 business day after due; to the audit manager after 3 | Beyond the manager without the audit lead: never, fixed by policy |
Every figure is labelled: a target the solution is built to, an estimate, a typical published result, or a proven one.
“demo” = seen in the working solution, on its sample data · “target” = the design goal, measured in the live solution · “estimated” = our estimate · “typical” = published figures (KPMG, The 2025 SOX Survey — an average SOX program of $2.3M and 15,581 hours in FY24; PCAOB AS 1105.10 on information produced by the company). People, companies, controls and figures named on this page are fictional — characters and sample data in the working solution.
Audit Evidence Collection runs your PBC request list for internal, external and SOX audits. Seven agents write each request in plain words, check every upload for period, population and completeness against the system count, return wrong files to their owner with one reason, and chase owners on a schedule worked back from fieldwork. The audit lead accepts each item as final, and only accepted evidence is released to the auditor.
A PBC (“provided by client”) list is the set of requests an auditor sends before fieldwork: reports for a period, populations to sample from, policies, reconciliations, sign-offs and ITGC listings. Each line goes to a control owner, who has to provide the evidence by a due date.
The evidence checker opens every upload within a minute and runs six checks: the period, the population (entities, company codes, user types), completeness against the system's own count or parameters screen, legibility, every field the request asked for, and that the file was not edited after export. A failed period or population goes straight back to the owner with the reason; anything less certain goes to the audit lead.
For standing items only — policies, approval matrices, configurations. The reuse agent offers last year's accepted file after confirming the document version, configuration or owner is unchanged, and refuses period-bound evidence with its reason. The audit lead decides.
No. The audit firm sees only evidence the audit lead accepted and the liaison released, scoped by audit or by IT controls, until access expires. It never sees returned files, the checker's heads-ups, internal notes or the reminder history.
Yes. The agents write, check, cross-check and chase; they never accept evidence, never send anything to the auditor and never decide a deficiency. The audit lead accepts or returns each item with a reason code, the audit manager approves every settings change, and a control owner can never accept their own evidence.
Yes. The checks and their thresholds, when files go to a person, how recent an export must be, the reminder and escalation schedule, reason codes, roles and notifications are settings. Each change is a new version the audit manager approves, and some rules, such as redacting personal data before release, are locked on.
The Agentic Solution Engine builds and deploys it from your requirements and documents — your control register, evidence standard and a past request list — and it goes live once every quality gate has passed. Setting up a new audit takes six steps, with a dry check on 20 files before go-live.
Every sample cited, re-performed and signed before your auditor asks.
1-min demoContinuous Controls MonitoringControl failures found in a day, not at year-end, and every fix proved by a re-test.
1-min demoJournal Entry TestingEvery entry tested for override, not a sample, with each conclusion cited to its support.
1-min demoWe'll run Audit Evidence Collection on your auditor's last request list and a sample of the evidence your owners sent.