A client with three warehouses uploads the inventory count sheets on Thursday, the request shows as answered, and the team turns to other sections. However, ten days later, a senior opens the file, finds counts for two of the company's three warehouses, and sends the request back to a client who considered it closed. Here’s why so many Prepared by Client (PBC) responses need correction, why the problems surface late, and what firms can change in the way they request and check client documents. While audit engagements serve as the main example throughout, the same issues carry over to other recurring client work.
Client document collection ends when the team has a response it can use, and a request list that measures uploads rather than accuracy can show progress while the next procedure sits idle. A better measure is whether the assigned staff member can start work.
Suppose the audit team requests a year-end inventory listing to plan its price testing. The client sends quantities by location without unit costs, and the status of the request changes to submitted. Without costs, the team cannot select a sample, so the request stays open in practice.
Each inaccurate response starts a chain of rework tasks: a clarification, a second search by the client, and another check before work resumes. Those rounds pull staff off planned work and strain a budget built for one pass. Clients often receive the follow-up after turning to their own month-end close, and much of the friction traces to missing context, a theme behind Suralink's research on the Client Readiness Gap.
Suralink's research groups correction-prone client responses into five types. The hypothetical examples below show how each one appears in a typical audit and what would make the response usable.
The file covers a different period. A client with a June 30 fiscal year exports fixed asset additions for the whole calendar year, so the file includes six months the team doesn't need and misses six it does. A similar problem appears when the previous year's schedule is updated in name only and sent again. Naming the entity and exact dates in the request, such as "fixed asset additions for Northfield Holdings LLC, July 1, 2025 through June 30, 2026," gives the client something concrete to check before they upload.
The transaction detail does not reconcile. A deferred revenue listing totals $612,000 while the general ledger shows $640,000, and nothing in the upload explains the difference between the two. The team can't test a population that disagrees with the balance, and guessing at reconciling items takes more time. Asking for the reconciliation, or a short note on known differences, alongside the detail lets the team resolve the variance in one round.
The supporting evidence does not meet the request. The team asks for insurance policy declarations pages and receives the broker's coverage summary. The summary offers useful context, but an intermediary prepared it, and it may leave out the policy period or premium. A request that names the required document and gives a brief example, such as "the declarations page showing insurer, coverage dates, and premium," shows the client what qualifies.
The response answers only part of the request. A lease request asks for agreements signed during the year, any amendments, and the schedule of discount rates. The client sends accurate agreements and a complete schedule but leaves out two amendments. A partial response differs from an incorrect one, yet both keep the request open. Splitting multi-part requests into separate line items lets the client see exactly which pieces remain outstanding.
The request leaves room for interpretation. "Send the revenue support" could mean contracts, invoices, shipping records, or cash receipts, for almost any period. When the client chooses one and the team needs another, part of the correction belongs to the firm. Requests that specify the period, the document type, and the sample being supported remove the guesswork, a point Suralink's report on accounting's biggest and often ignored bottleneck makes about the request step as a whole.
Incomplete client documents can sit unnoticed long after upload, delaying the audit procedures that depend on them. Proprietary Suralink platform data shows that firms take about 16 days on average to review a client submission, and that figure covers firm review time only, not the time the client spent preparing the response. Three things tend to lengthen the review time:
Most audit engagements reuse a large share of last year's request list, so recurring requests offer the quickest return on a little preparation. Before the next engagement begins, work through these steps with the team:
None of these steps requires new staff, and each one shortens the distance between an upload and a usable response. Even a disciplined first look, though, depends on someone opening the file.
Client document collection is the process of requesting, receiving, and confirming the documents an audit team needs from a client, usually through a PBC list. Collection is complete when each response is usable for the procedure it supports.
Most corrections stem from missing context, such as an unstated period, an unclear evidence requirement, or a multi-part request the client reads as a single item. Clearer requests and earlier checks address both the firm's side and the client's side of the problem.
Recurring requests that came back last year are the best place to start. Rewrite them with specific periods and requirements, assign an owner to check priority uploads soon after they arrive, and keep one shared record of request status and corrections.