The PBC list is broken — rethinking the prepared-by-client request

The engagement letter is signed, the audit is booked for March, and the first thing that goes out is the PBC list. It arrives as it always does: a spreadsheet attached to an email, forty-odd lines long, addressed to the client’s finance manager with a cheerful note that says “here’s what we’ll need to get started.” From that moment the list begins to rot.

By week two, half the items are in. Nobody can say which half without opening three inboxes and cross-referencing them against the tracker, which was last updated on a Tuesday that everyone has since forgotten. A junior has been told to chase the client, but chase what, exactly? The list they are working from and the files sitting in the shared drive are two different accounts of reality, and reconciling them is now a job in itself.

This is the prepared-by-client list, the backbone of a statutory audit, running on the weakest infrastructure in the firm.

Why the spreadsheet PBC fails

The PBC list is not a bad idea. A structured list of everything you need from the client, sent at kickoff, is exactly right. The problem is the container. A Word or Excel document emailed once has properties that work against you the moment fieldwork starts.

• It goes stale instantly. The version you sent and the version reality is at have already diverged by the first reply. Every subsequent email is an attempt to patch that gap by hand.
• It has no per-item status. A cell that reads “requested” tells you nothing about whether the client has seen the item, sent something, sent the wrong thing, or sent nothing at all. Status is the one thing the list most needs and the one thing a spreadsheet cannot hold reliably.
• It has no version control. The bank confirmation comes back, then comes back again, “corrected”. Now there are two files and one line on the tracker. Which one is fieldwork relying on? The list will not say.
• It has no audit trail. Who asked for the fixed-asset register, on what date, and when did the client actually send it? That history is scattered across sent-items folders, and it disappears the day someone tidies an inbox.

Each of these is survivable on its own. Together they mean the same thing: the PBC list cannot tell you the truth about your own engagement. So people fill the gap, and the people doing it tend to be the ones whose time is worth the most.

The PBC line is really a Request Item

The fix is not a better spreadsheet. It is to stop treating each line as a row of text and start treating it as a thing with a life of its own.

Every line of a PBC list becomes a Request Item: one specific ask, with an owner, a due date, written instructions, and a sample format so the client sends the right thing the first time. Each item carries its own status — draft → requested → submitted → needs revision | accepted | cancelled — and its own immutable activity log.

That last part is what changes the work. “What’s still outstanding” is no longer something a junior reconstructs by opening inboxes. It is read from the stored status: outstanding means an item sits at requested or needs revision, and nothing else. The junior chasing the client is now chasing a named list of genuinely missing items, not chasing blind.

Files hang off the item, with full version history. When the client sends the corrected bank confirmation, it attaches to the same item, and the earlier one is retained as a previous attempt, never deleted. Acceptance is a decision, not a shrug: when a reviewer accepts a Document against the item, it becomes Evidence on the permanent Engagement record, with their name and a timestamp.

The Pack: write the PBC once

A statutory audit asks for broadly the same things every year. Bank confirmations, the signed financial statements, the representation letter, the fixed-asset register, lease agreements, related-party details, tax computations. Rebuilding that list from memory or from last year’s email each January is wasted work, and memory drops items.

So the standard PBC lives as a Pack: your firm’s reusable set of Request Item templates for a service type, written once and maintained centrally. When you open a new Period — this year’s FY2026 audit for a given client — the Pack copies in as a snapshot. Every item, its instructions, and its sample format are already there before you send anything.

The snapshot matters more than it looks. Because each Period holds its own copy, editing the Pack in June to sharpen an instruction does not reach back and rewrite the FY2025 audit you already signed. Past work stays exactly as it was. Improvements flow forward, never backward. For a firm that has to stand behind what it did in a given year, that is the difference between a tidy process and a defensible one.

Clivanta ships with seeded Cyprus templates to start from — statutory audit, VAT and VIES, payroll, bookkeeping close, AML and KYC — which you adapt to how your firm actually works rather than building from a blank page. If audit and tax collection is your world, the audit and tax use case walks through the fuller picture.

What the partner gets back

None of this makes the audit judgement for you. That was never the problem. The judgement is the part your firm is trained for and good at. The PBC list was quietly taxing the part around it: the collection, the chasing, the reconciling of who sent what.

Move the PBC off the spreadsheet and a few things follow. Fieldwork starts against a list that is true. Reminders chase the routine items on their own, reading the same live status everyone else sees. The activity log builds the audit file as you go, so you are not reconstructing the story of an engagement six months after it closed. And your seniors spend their hours on the work that needed a senior. You can see how the whole loop fits together on the product overview.

The prepared-by-client list will always be central to an audit. It just shouldn’t be the thing that breaks first.