Accounting, Tax & Bookkeeping// definition

The prepared-by-client list is a data structure, not a spreadsheet

In short

A PBC request list — prepared by client — is the itemised set of records a client must supply before a period can be worked. Treated as a document it gets retyped every period; treated as rows carrying item type, period, entity, owner, evidence and state, it can be generated, chased and queried across the whole client book.

Key takeaways

  • PBC means prepared by client: the records a client owes the firm before a period can be worked.
  • The unit is the request item, not the list. A list is a query over items, so it never needs retyping.
  • 9 fields make an item trackable: id, item type, period, entity, client owner, firm owner, evidence, state and dependency.
  • Item type must be a controlled value, or you can never ask which clients still owe a bank statement.

A PBC request list is the itemised set of records a client must supply before the firm can work a period: bank statements, loan schedules, payroll summaries, stock counts, the fixed asset additions listing. PBC stands for prepared by client. The word that matters is not the acronym but the unit underneath it — the request item — because everything useful about the list is a property of its rows.

The term came out of assurance work, where an auditor sends a schedule of items the client's own staff prepare and the auditor then tests. It has spread to compilation, bookkeeping and tax, doing one job: what we need, from whom, for which period, and what is missing.

The unit is the request item, not the list

Firms treating the list as the object end up with one workbook per engagement per period, copied forward, last quarter's ticks cleared by hand. That artefact answers nothing across clients. Which engagements wait on a bank statement? Which items are open more than 14 days? How many periods running has this client been late with payroll? Those are queries, and rows in a shared Excel file cannot answer them.

Treat the item as the record and the list becomes a view: everything for this entity, this period, still open. That is what makes a request list generatable rather than retyped, and the precondition for automated chasing, a status board the team can read, and the client intake, chasing and portals topic working as one system rather than four.

The fields a request item has to carry

FieldWhat it holdsWhat breaks when it is missing
idA stable identifier that survives re-sendingThe 3rd reminder creates a duplicate and the board double-counts
item_typeA controlled value — bank_statement, payroll_summary, loan_scheduleNobody can ask which clients still owe a bank statement; each preparer phrased it differently
periodThe covered range, as start and end dates"January" means one thing to the client, another to a firm on a 31 March year end
entityThe legal entity, not the client relationshipGroup companies merge silently and one entity's statement lands on another's period
client_ownerThe named person expected to produce itReminders reach the relationship contact, who forwards them nowhere in particular
firm_ownerWho in the practice is accountable for it arrivingChasing becomes whoever notices, which at peak volume is nobody
evidenceA versioned link to the file or feed that satisfied itThe item reads done and nobody can find what closed it 3 months later
stateWhere the item is, timestamped per transitionOne received flag collapses received, legible, complete and accepted into a lie
depends_onItems that must be satisfied firstThe client is asked for a reconciliation before the statement behind it
The record shape of a single PBC request item

Two are the ones firms leave implicit. Period is a range, not an engagement, stored as dates. Entity is what the ledger belongs to: a client with 3 companies and a partnership has four, each with its own file in Xero or QuickBooks. State has its own rules — the states a requested document passes through covers the transitions most trackers omit.

PBC list, open items list, and the due-diligence record

  • PBC list. What the client owes the firm for a period. Every row is an ask pointed outward.
  • Open items list. Everything unresolved in the engagement, internal review points included. The PBC list is the subset owned by the client, which is why the two are never one sheet.
  • Due-diligence record. Identity evidence, ownership chain, risk rating — once per client, not per period. What a client due-diligence record must contain covers its fields and refresh clock.
  • Handover pack. What a predecessor supplies at a change of accountant, seeding an incoming client's first list. Professional clearance and what actually transfers names its contents.

Why the shape decides what can be automated

Every automation a firm wants over client records is a function of these fields. Without item_type as a controlled value there is nothing to match an arriving document against; without period and entity there is nowhere to file it; without dependencies the list arrives in an order the client cannot satisfy, one mechanic behind clients abandoning the records upload halfway.

A request list you cannot query is a document. One you can query is a system, and the difference is nine fields.

Ordinary data modelling, and the part to get right before any model is pointed at it. Automated chasing and document routing on a well-shaped item store is work we scope under AI agents and automation for accounting and tax practices; what decides whether it survives production is in AI agents in production.

Frequently asked questions

Short answers to the follow-ups this page tends to raise.

What does PBC stand for in accounting?

Prepared by client. It labels the records and schedules a client produces and hands over, as opposed to workpapers the firm prepares itself. The term originates in assurance, where the distinction matters to who is responsible for a figure, and has spread to bookkeeping and tax work with the same collection problem.

Is a PBC list the same as an open items list?

No — a PBC list is the subset of open items whose owner is the client. An open items list also carries internal queries and review points, none of which should be sent outward. Firms keeping one list for both either expose internal notes or maintain two copies that disagree by the second week.

How many items should a PBC list have?

Fewer than most firms send, because every row is a separate chance to stall. The discipline is that each row names one artefact, one entity and one period, so "all bank statements" becomes 3 rows and "anything else relevant" is deleted. Ten precise rows come back faster than four vague ones.

Should the PBC list live in the practice management system?

Only if it can be queried across clients and linked to arriving evidence — that requirement decides it, not the vendor. Many practice systems model a checklist per job but cannot query across jobs or attach a versioned file to a row, at which point the list is a document again in a more expensive place.

  • PBC list
  • client intake
  • engagement workflow
  • data modelling
// shipped work

The work behind this page

Builds from our portfolio that this page draws on.

Working on something in this space?

Tell us where you are in a sentence or two. We'll tell you honestly whether we're the right team, and what a sensible first slice of the work looks like.

Start the conversation