June 30, 2026

How to build a PBC list that doesn't stall fieldwork

Amanda Waldmann

Increasing trust with AI for audit and advisory firms.

Key insights

PBC lists rarely fail on missing items; they fail when evidence comes back wrong and nobody notices until testing starts.
Sequence requests by what blocks testing, not account order. Confirmation and control evidence go first.
An uploaded file is not a testable file; upload status alone hides whether evidence is sufficient.
Requests for client reports should name the source, parameters, date range, and tie-outs, or they come back unusable.

Compliance teams lose their early fieldwork stretch renaming PDFs, chasing missing files, and reconciling versions. By the time substantive testing starts, the team has already burned through budget and capacity, and realization, staff burnout, and next year's RFP all feel it. Email- and spreadsheet-based request loops stall fieldwork, and the new operating model changes the math. This article covers what belongs on a PBC list, how to sequence requests so they don't block testing, and where the request loop tends to break.

What is a PBC list and why does it stall audits?

A PBC list, short for Prepared by Client, is the firm's checklist of what the client provides before and during the engagement: what's needed, who owns it, the expected format, and when it's due. A complete list is the easy part. Keeping evidence, status, and review tied to each item once the requests go out is where engagements lose time.

The items on the list are usually right. What slips is usability: a reconciliation comes back as a flat PDF instead of a live Excel file, a confirmation authorization never gets signed, two associates request the same schedule. None of it gets caught until staff sit down to test, because the check happened too late, after the requests went out and the evidence came back.

When the problem surfaces matters as much as whether it's caught at all. A request loop that flags a wrong or incomplete file at submission gives the client weeks to correct it, while the rest of the work continues. The same problem caught when staff sit down to test gives the client days, in the stretch of the calendar where the team has the least room to wait. Late readiness problems also tend to cascade: a readiness gap the client can't close quickly pushes back document delivery, which pushes back the start of testing, which compresses everything after it.

What belongs on a PBC list

Start with a simple question: what evidence does the team actually need to do the work? Every item on the list should trace back to a procedure someone is going to run. If you can't picture how a file gets tied, tested, recalculated, or confirmed, the request probably needs more shape before it goes out. And when the client is producing the information themselves, it has to be accurate and complete enough to actually stand up under testing.

The foundational records anchor everything else:

Final trial balance for the period, in a searchable spreadsheet format
General ledger activity for accounts subject to testing
Draft financial statements, including footnotes and disclosures
Year-end journal entries, with support for non-standard entries
Account reconciliations for material balance sheet accounts
Rollforwards for accounts where period activity must be tested

Layered on top of those are the items that carry real lead time or real risk:

Confirmation support: contact lists, account listings, and authorizations for cash, receivables, investments, and debt. These need external response time, so they belong early.
Account-specific support: inventory count documentation, estimate data and assumptions, fair value support, lease registers, and litigation information.
Control and IT evidence: narratives and flowcharts for key cycles, access and change-management documentation, and the reports used in control operation, with support for completeness and accuracy.
Governance and planning items: board and committee minutes through the period, organization charts, related-party lists, and accounting policies.
Contingencies and subsequent events: support for matters that may require adjustment or disclosure. These are easy to underweight early and painful to chase late.

Knowing what to ask for is only half of it. The other half is specifying how each item should come back, because a request that doesn't define the format is the one that comes back unusable. Spell out the format you expect before anything gets submitted. A request for a reconciliation should say whether it needs to be in Excel, whether formulas stay intact, what balance it ties to, and what support comes with the reconciling items. A request for a report should name the system it comes from, the date range, and any filters. Vague asks come back wrong, and wrong files reopen the loop.

How to structure and sequence PBC requests

Treating every item as equal weight, due at the same time, slows the list down. Sequencing should follow the dependencies in the audit plan, and the goal is to unblock the workstreams that drive the most staffing, review, and partner attention.

Split planning from fieldwork

Most engagements benefit from separating requests into two phases. Planning requests cover interim financials, organization charts, board minutes, new contracts, new debt, and known operational changes. Fieldwork requests cover year-end statements, reconciliations, supporting schedules, confirmation support, and account-level testing evidence.

Separate planning and fieldwork requests so risk assessment can start before close. When planning items sit in the same list as year-end deliverables, the team waits for close before starting risk assessment and control understanding. That delay compresses everything that follows into the busy-season window where there's no slack to absorb it.

Sequence by what blocks testing

Once the phases are split, order within each phase by dependency rather than by account number. Two things push an item to the front: how long it takes to arrive, and how much work stalls behind it if it's late. Run the rules in that order.

Risk assessment requests come first, because everything downstream depends on them. Interim financials, board minutes, contracts, and management explanations of unusual activity let the team understand the business and decide where to test deeply. Until that's done, the rest of the sequence is a guess.

Control evidence comes next, because it has to arrive before control conclusions are needed. If the approach depends on testing controls, narratives, walkthrough support, report populations, and access listings need to be requested early. Late control evidence forces changes to the nature, timing, and extent of substantive testing, which is the most expensive kind of rework.

Confirmation support moves on its own track, because it's the one category the firm can't speed up. Bank, receivable, debt, and legal confirmations need client authorization plus external response time. Bury them among routine uploads and they become late-stage blockers, so isolate them and send them first.

High-risk areas come ahead of routine schedules, because they pull the most review. Revenue, estimates, complex transactions, and contingencies drive the most partner attention, so a late surprise there costs more than a late depreciation schedule. And when the team performs interim procedures, the list should spell out what's needed to roll conclusions forward to period end: updated populations, post-interim reconciliations, and support for significant later activity.

Sequencing only holds if it survives contact with the client, which is where three habits pay off. A kick-off meeting to set the schedule and communication preferences locks in the order before delays start. Pulling prior-year workpapers to see what saved or cost time last year helps tailor the current list. And matching request language to the client's actual report names and system labels means fewer wrong files come back in the first place.

Where the PBC request process breaks down

Even a perfectly sequenced list can fall apart in execution. The failures are operational, and they tend to surface in the same order on every engagement, each one compounding the next.

Version chaos starts early

The trouble starts the moment files come back. When the list doesn't specify naming conventions and required tie-outs, every wrong file restarts the handling, and partner-specific preferences for how documentation is scanned and signed off multiply the variations. Staff spend hours working out which version is current instead of testing against it.

Searchability goes next

Once the wrong files are in, finding anything in them becomes its own job. Hunting through 80 pages of a bulk PDF for one number is what happens when file type and schedule structure weren't specified up front. The team ends up doing the formatting work the client should have done at submission, on top of the version sorting it's already doing.

Missing shared status costs the most

The costliest problem is that nobody can see the real state of any of it. When requests and uploads live apart from the spreadsheet that tracks them, open, received, and reviewed all blur together, and the tracking friction compounds as the file count grows. A manager can't tell a partner what's outstanding without reconstructing it by hand, and that reconstruction takes time the team cannot spare in the week it's usually needed.

What changes when PBC intake moves off email

When the request, the client's uploaded file, and the review status all live on one record instead of split across a portal, a folder, and a tracking spreadsheet, the failures from the last section have less room to form. There's one list of requests and owners instead of three, so the duplicate requests that come from two associates emailing the same contact stop happening. Each request carries a real state rather than a binary sent-or-not: open, received, rejected, reviewed. Due dates and escalation paths sit with the request rather than in scattered email threads, and review comments stay attached to the file they're about, so the thread between a reviewer's question and the evidence answering it never gets lost.

The gap between received and reviewed is the one that shows up in inspection findings. The 2024 PCAOB inspection cycle reported a 39% deficiency rate, down from 46% in 2023, where inspectors concluded firms hadn't obtained sufficient appropriate evidence, often because of the completeness and accuracy of client-produced reports used in controls. The failure there isn't that the client sent nothing. It's that what they sent didn't hold up, and the team didn't establish that until late. A tracker that marks a request "uploaded" records that a file arrived; it says nothing about whether anyone checked that the file is the right one, complete, and tied out. That is why the field that matters on any request isn't received, it's reviewed and sufficient.

Establishing sufficiency late is expensive on any engagement, and it is most expensive on the teams that have the fewest people to absorb it. An hour a senior spends in March working out whether a misnamed upload is the current version is an hour not spent on the judgment the engagement is billed for, and leaner teams have no slack to give that hour back. A request loop that flags the bad file the day it arrives spares it. This is the kind of friction Fieldguide is built to take off the engagement.

Run intake in one place with Fieldguide

The PBC list itself is rarely the problem. The time goes to handling evidence after the requests go out, and that handling gets faster when the request, the uploaded file, and its review status sit on a single record instead of across separate tools. Fieldguide keeps request management together with client uploads and status, with Request Analysis Agent reviewing evidence as it arrives and flagging gaps early for the team to confirm. The client sees exactly what's needed and what's still open through the Client Hub, so the back-and-forth that usually runs on email runs on a shared record instead. Because requests sit inside the same platform that carries the engagement from planning through reporting, reviewed evidence flows straight into testing rather than across disconnected tools. To see how it works on a live engagement, book a demo.