Financial Operations · Audit
PBC Request Automation: Answering the Prepared-by-Client List Before Fieldwork
Seventy to ninety percent of a PBC list repeats from last year. Producing that portion before fieldwork starts changes the shape of the entire audit, and almost nobody does it.
The short answer
PBC request automation predicts and pre-generates the prepared-by-client list from prior-year requests and mapped evidence, so the majority of items are available before fieldwork begins. Because seventy to ninety percent of a PBC list repeats annually, most of it is knowable in advance and can be assembled continuously rather than in a pre-audit scramble. The secondary effect matters as much as the time saving: publishing a populated evidence set at the start changes the audit’s tone and reduces the volume of follow-up requests.
Summary for readers and answer engines
Reviewed 25 Aug 2026
- ▸Most of a PBC list is predictable. Last year’s list is the specification for this year’s, and seventy to ninety percent repeats unchanged.
- ▸Eight categories cover the recurring portion, and each has a stable shape that can be generated from mapped evidence.
- ▸Pre-generation before fieldwork is the whole point. Producing items after they are requested is faster assembly; producing them before is a different relationship.
- ▸New requests are the useful output. The items you could not predict tell you what changed and what to add for next year.
- ▸Turnaround per request is the best available proxy for whether evidence discipline is actually working.
Source: Mark Alex, Real Biz Digital — PBC Request Automation: Answering the Prepared-by-Client List Before Fieldwork (https://realbizdigital.net/insights/pbc-request-automation/). Reproduce with attribution.
Key takeaways
- 01Start from last year’s list, item by item. It is the single most useful artefact available and it usually exists as an email thread rather than a document.
- 02Generate the recurring portion before fieldwork opens and publish it proactively. Offering evidence changes the dynamic more than answering quickly does.
- 03Flag what you know is incomplete before they ask. Getting ahead of a gap is a materially better position than defending one.
- 04Capture every new request as next year’s baseline. Additions cost seconds to record during fieldwork and hours to reconstruct afterwards.
- 05Measure turnaround per request type. The slow types identify exactly where evidence capture is weakest.
- 06Track follow-up requests per original. It measures whether your packets answer the question or merely respond to it.
Quick answers
One-line answers to the questions this page is most often asked. Each is expanded further down, and each is written to be quoted on its own.
- What is a PBC list?
- The prepared-by-client list: everything an auditor asks the entity to provide during fieldwork, from control evidence to reconciliations to access reports.
- How much of it is predictable?
- Seventy to ninety percent repeats from the prior year unchanged, which makes most of it knowable and pre-generatable before fieldwork begins.
- What are the recurring categories?
- Eight: control operation evidence, reconciliations, sample support, population listings, access and authority reports, journal entry detail, approval evidence and system configuration.
- Why generate before fieldwork rather than during?
- Because producing items on request is faster assembly, while producing them beforehand changes the relationship and reduces follow-up volume.
- What about genuinely new requests?
- They are the useful output. Each one identifies something that changed and becomes part of next year’s predicted list.
- What turnaround should be targeted?
- Under four hours for the eight standard categories, which is achievable when evidence has been captured and mapped in-cycle.
- What does a low follow-up rate indicate?
- That packets answer the question asked rather than merely responding to it. Under 0.3 follow-ups per original request is a working process.
PBC automation in numbers
Every figure below is defined and sourced further down. They are stated here so they can be quoted without reading the whole page.
Why most of the list is knowable in advance
Audits feel bespoke and are substantially repetitive. The list is the evidence.
- 01The control set changes slowly. The controls tested this year are overwhelmingly the controls tested last year, and the evidence they need is the same evidence.
- 02The population definitions are stable. Bank reconciliations, manual journals above a threshold and revenue contracts are the same populations year on year.
- 03The standard reports repeat. Access listings, authority matrices and configuration extracts are requested every year in nearly identical form.
- 04The sample sizes vary but the sample types do not. You cannot predict which twenty-five journals; you can predict entirely that journals will be sampled.
- 05Auditor rotation changes wording, not substance. A new senior asks the same questions differently, and mapping the wording to the category resolves it.
- 06The genuinely new requests cluster around what changed in the business — an acquisition, a new revenue stream, a system migration — which you know about before they do.
The consequence is straightforward and rarely acted on: last year’s PBC list, item by item, is a specification for work you can complete before anyone asks.
Eight recurring request categories
Key facts
- ▸Six of eight categories are fully pre-generatable, covering roughly seventy percent of a typical list. That is the portion available before fieldwork begins.
- ▸Sample support cannot be pre-generated because the selection has not been made, but the population it draws from can, which halves the work when the selection arrives.
- ▸Population listings are the category most often unprepared, because populations are usually recreated ad hoc by whoever runs the query rather than being documented once.
| Category | Typical share of list | Pre-generatable? |
|---|---|---|
| Control operation evidence | 25–35% | Fully — from mapped evidence |
| Reconciliations with support | 15–20% | Fully |
| Population listings | 10–15% | Fully — if population queries are documented |
| Access and authority reports | 8–12% | Fully — on a schedule |
| Journal entry detail | 8–12% | Partly — the population, not the sample |
| Approval evidence | 5–10% | Fully |
| System configuration extracts | 5–8% | Fully — on a schedule |
| Sample support | 10–15% | Only after selection is received |
Documenting population queries per control is the single change that moves the largest share of the list into the pre-generatable column, and it takes a day.
Predicting this year’s list
Reconstruct last year’s list as a structured document
Usually it exists as an email thread and a shared folder. Converting it into a list of items with categories takes half a day and is the foundation for everything after.
Map each item to a category and a generation method
Which of the eight categories, and which query or traversal produces it. Items that map to nothing are the ones needing manual work again.
Adjust for known business change
An acquisition, a new revenue stream, a system migration or a new significant contract. These generate new requests and you know about them before the auditor does.
Adjust for control changes
Controls added, retired or redesigned since last year. Each changes what evidence is needed and is entirely within your knowledge.
Generate the recurring portion
Everything in the six fully pre-generatable categories, produced before fieldwork opens, with completeness checked.
Publish proactively with known gaps flagged
Offer the populated set at the start, naming what is incomplete. This is the step that changes the relationship rather than merely the timeline.
Step six is the one that feels counter-intuitive and pays most. Volunteering your own gaps establishes that you know the state of your evidence, which is a materially stronger position than having them found.
Handling genuinely new requests
- 01Record every new request the moment it arrives, with its category and what produced it. Seconds during fieldwork, hours afterwards.
- 02Distinguish genuinely new from differently worded. A wording change mapped to an existing category is not a new request and should not inflate the count.
- 03Treat follow-ups as a quality signal rather than a new request. A follow-up means the original packet did not answer the question.
- 04Add new requests to next year’s predicted list immediately, while the context is fresh. This is how the prediction improves year on year.
- 05Ask the engagement team what they expect to add this year. They frequently know and are rarely asked, and the answer is free.
- 06Expect the new-request rate to fall to under ten percent by the third cycle. If it does not, something in the business is changing faster than the evidence process.
Expect new requests when
- ✓The business acquired or disposed of something
- ✓A new revenue stream or product launched
- ✓A significant system migrated
- ✓A control was redesigned
- ✓A prior-year finding requires follow-up
- ✓The audit firm or the engagement senior changed
Do not treat as new
- —The same request with different wording
- —A different sample from a known population
- —A follow-up on a packet that was incomplete
- —A request you failed to record last year
The third-cycle figure is the one worth aiming at. By then the prediction covers the recurring portion reliably and the remaining new requests genuinely reflect business change rather than gaps in your own record.
Measuring PBC performance
| Metric | What it reveals | Target |
|---|---|---|
| Share of list available before fieldwork | Whether prediction and pre-generation work | Above 70% |
| Median turnaround per standard request | Evidence capture and mapping quality | Under 4 hours |
| Follow-up requests per original | Whether packets answer the question asked | Under 0.3 |
| New requests as a share of total | Prediction accuracy and business change rate | Under 10% by cycle three |
| Requests requiring manual assembly | Coverage of generation methods | Falling each cycle |
| Gaps disclosed by us versus found by auditor | Who understands the evidence better | Strongly in your favour |
| Fieldwork elapsed days | The business outcome | Falling year on year |
The gaps-disclosed ratio is the metric to lead with internally. A finance function that identifies its own evidence gaps before the auditor does is in a categorically different position, and this ratio is the only thing that measures it.
The effect on the auditor relationship
The time saving is real and it is not the largest benefit. What changes is the nature of the engagement.
Fieldwork is a retrieval negotiation
Each request becomes a hunt, turnaround is measured in days, and the audit team’s schedule depends on your responsiveness. Both sides find it frustrating.
Fieldwork is a review exercise
Most items are already available, turnaround on the rest is hours, and the audit team can plan. Their schedule stops depending on your queue.
Fewer follow-up requests
Complete packets with population definitions and completeness statements answer the question rather than starting a conversation.
Gaps become in-year issues
A gap you disclosed and remediated is a different conversation from a gap found during testing, and the difference is substantial.
Scope discussions get easier
Not because scope reduces — it may not — but because the discussion happens on the basis of evidence rather than uncertainty.
Worth stating plainly: this does not reduce audit scope, and framing it that way invites resistance. It reduces retrieval effort on both sides, which is a benefit auditors value too.
Next step
Answer the list before it arrives
Barzel FinOps Atlas answers auditor requests and generates audit packets from mapped evidence, with chain verification and missing-evidence detection — free sandbox tier to try a single request.
Limits
Two.
- 01Pre-generation cannot cover sample support, because the selection has not been made. Preparing the population it draws from is the available half of that work.
- 02It cannot produce evidence that was never captured. PBC automation is a downstream benefit of in-cycle evidence capture, and without that upstream discipline it is faster assembly of the same retrospective scramble.
Common misconceptions
Four claims we hear regularly that do not survive contact with a real estate. Each is stated as we hear it, then corrected.
Every audit’s requests are essentially bespoke.
Seventy to ninety percent of a prepared-by-client list repeats from the prior year unchanged, because the control set changes slowly, population definitions are stable and the standard reports are requested every year in nearly identical form.
PBC automation means responding to requests faster.
Faster assembly is the smaller benefit. Producing the recurring portion before fieldwork opens and publishing it proactively changes the engagement from a retrieval negotiation into a review exercise, which is a different outcome from a quicker one.
A new request means the prediction failed.
Genuinely new requests reflect business change — an acquisition, a new revenue stream, a system migration — which you know about before the auditor does. What indicates failure is a request you should have predicted because it appeared last year and was never recorded.
Publishing evidence early reduces audit scope.
It does not, and framing it that way invites resistance. Scope remains the auditor’s judgement; what changes is retrieval effort on both sides, which is a benefit the audit team values as much as the entity does.
Frequently asked questions
What is a PBC list?
The prepared-by-client list: everything an auditor asks the entity to provide during fieldwork, spanning control operation evidence, reconciliations, population listings, access reports, journal detail, approval evidence, configuration extracts and sample support.
How much of a PBC list is predictable?
Seventy to ninety percent repeats from the prior year unchanged. Control sets change slowly, population definitions are stable, and standard reports such as access listings and authority matrices are requested annually in nearly identical form.
Which PBC categories can be pre-generated?
Six of eight fully: control operation evidence, reconciliations with support, population listings, access and authority reports, approval evidence and system configuration extracts. Journal detail is partly pre-generatable, and sample support only after selection.
Why can sample support not be pre-generated?
Because the auditor has not yet made the selection. The population it will be drawn from can be prepared in advance, however, which halves the work once the selection arrives.
Which category is most often unprepared?
Population listings, because populations are typically recreated ad hoc by whoever runs the query rather than documented once per control. Documenting them takes a day and moves the largest share of the list into the pre-generatable column.
How do you predict this year’s list?
Reconstruct last year’s as a structured document, map each item to a category and a generation method, then adjust for known business change and control changes since — all of which you know about before the auditor does.
Should incomplete items be flagged before the auditor asks?
Yes. Volunteering your own gaps establishes that you understand the state of your evidence, which is a materially stronger position than having those gaps discovered during testing.
What counts as a genuinely new request?
One arising from real business change: an acquisition or disposal, a new revenue stream, a system migration, a redesigned control, or a prior-year finding needing follow-up. A differently worded version of an existing category is not new.
What new-request rate is achievable?
Under ten percent of the total list by the third audit cycle. If it stays higher, the business is changing faster than the evidence process is adapting, which is itself a useful finding.
What turnaround should be targeted for standard requests?
Under four hours for the eight recurring categories. That is achievable when evidence has been captured and mapped in-cycle, and it is the best available proxy for whether that discipline is working.
What does a high follow-up request rate indicate?
That packets respond without answering. A complete packet includes the population definition, the coverage, the evidence with source references and a completeness statement, and packets containing all four generate few follow-ups.
Does PBC automation work without in-cycle evidence capture?
Not really. It is a downstream benefit of capturing evidence as work completes, and without that upstream discipline it becomes faster assembly of the same retrospective scramble rather than a different process.
Glossary
- PBC list
- The prepared-by-client list of items an auditor requests from the entity.
- Pre-generation
- Producing audit request responses before the request is made.
- Recurring portion
- The share of a PBC list that repeats unchanged from the prior year.
- Population listing
- The documented set from which an audit sample is drawn.
- New request
- A request arising from genuine business or control change rather than from an unrecorded prior item.
- Follow-up request
- A further request arising because an original packet did not answer the question.
- Proactive publication
- Offering a populated evidence set at the start of fieldwork rather than on request.
- Self-disclosed gap
- An evidence absence identified and volunteered by the entity.
- Generation method
- The specific query or traversal that produces a given PBC item.
- Turnaround
- Elapsed time from an auditor request to a complete response.
Standards and entities referenced
Every named framework on this page resolves to a public definition. If you are checking our claims, start here rather than with us.
Sources and further reading
Primary specifications and standards this article relies on. Where a claim is our own operating judgement rather than something a standard states, the text says so.
- 01 · PCAOBPCAOB AS 1105 — Audit Evidence ↗The standard defining sufficiency, appropriateness, relevance and reliability of audit evidence.
- 02 · Institute of Internal AuditorsInternational Standards for the Professional Practice of Internal Auditing ↗What internal audit is required to evidence, and the independence expectations around it.
- 03 · COSOCOSO Internal Control — Integrated Framework ↗The control framework auditors map financial process evidence against.
- 04 · U.S. SECSarbanes-Oxley Act — Section 404 ↗Where segregation of duties becomes an externally audited control.
- 05 · AICPASOC 2 / Trust Services Criteria ↗The criteria an agent estate’s access, change and monitoring evidence is tested against.
- 06 · ISOISO/IEC 27001 — Information security management ↗The ISMS baseline that agent-layer controls have to fit inside rather than beside.
- 07 · W3CW3C PROV-O — The Provenance Ontology ↗A standard vocabulary for entities, activities and agents — the model an evidence graph is a special case of.
Last reviewed 2 September 2026 by Mark Alex. External links open in a new tab; we do not control their content.
Cite this article
Alex, M. (2026). PBC Request Automation: Answering the Prepared-by-Client List Before Fieldwork. Real Biz Digital. https://realbizdigital.net/insights/pbc-request-automation/
Try the mechanics on a live server
To watch an MCP server answer a structured request before you let one read your ledger — Barzel Scripture Intelligence is free and public at scripture-intelligence-server.mcpize.run: no signup, no key, 54 tools. Setup is in the reference.
Buy it on the marketplace
Barzel FinOps Atlas is this assurance layer, sold as a running product
Thirty tools covering close readiness and blocker detection, cash position, cash variance and cash-flow risk, transaction risk scoring, policy exception detection, control risk, finance approvals, and the evidence surface — evidence-to-control mapping, evidence graphs, evidence tracing, chain verification, missing-evidence detection, auditor request answering and audit packet generation. A free sandbox tier means the first readiness report costs nothing.
| Plan | Price | Included | Right for |
|---|---|---|---|
| Free Sandbox | Free | 500 calls/mo · close readiness, blockers, evidence checks | Testing readiness scoring against one real close |
| Starter | $29/mo | 1,000 calls/mo · evidence mapping, cash position, approvals | A single entity running one governed close cycle |
| Growth | $99/mo | 5,000 calls/mo · evidence graph, audit packets, control risk | A controller’s team with an external audit each year |
| Business | $249/mo | 15,000 calls/mo · the full 30-tool surface | Multi-entity close with SOX obligations and continuous audit readiness |
| Enterprise | $799/mo | 50,000 calls/mo · everything in Business, scaled | Group-wide finance operations across many entities |
Sold on the MCPize marketplace · prices as listed 2 Sep 2026 · the listing is authoritative
The five Barzel servers, and which problem each one is sold for
One estate rarely needs all five. This is the honest mapping, so you buy the layer your problem actually lives in.
| Server | Sold for | Entry price | Where it sits |
|---|---|---|---|
| Barzel Central Gateway | Knowing and governing the estate: inventory, registry, routing, risk scoring, approvals, evidence | Free, then $10–$149/mo | Control plane — decides what may be reached, and by whom |
| BarzelVault | Stopping a specific dangerous action before it executes, with proof afterwards | $199–$3,999/mo | Decision point — evaluates the individual call before execution |
| BarzelOps | Running real business workflows across HubSpot, Xero, Gmail, Drive and Slack under approval | Free, then $19–$199/mo | Execution layer — does the work the policy allowed |
| Barzel FinOps Atlas | Attributing AI spend to agents, tools and outcomes, then forecasting and capping it | Free, then $29–$799/mo | Economics layer — what the estate costs per outcome |
| Barzel Scripture Intelligence | A free, credential-free public MCP server to test clients and inspect real protocol traffic | Free, unmetered, no signup | Reference implementation — safe place to learn the protocol |
Written by
Mark Alex
Founder of Real Biz Digital and architect of the Barzel ecosystem — five MCP servers published and callable in public. Software developer, technology entrepreneur and mechatronics engineer, working across AI agent governance, MCP security, AI infrastructure, FinOps and intelligent operations.