A PBC list is the one document in an engagement that both sides are meant to be reading at the same time, which is the thing email is worst at. Attach it and you have not shared a list, you have issued copies. The work is keeping one of them true while the answers come back in fifty separate messages.
- A document request is one ask to one person and then it is finished. A PBC list is a standing register, held by two organisations, alive for the length of the job.
- Every line has two states, theirs and yours, and most lists carry one column for both. Provided and accepted can be a fortnight apart.
- The item number is the only part of a list that email carries without damage. Everything else gets paraphrased on the way.
- The list grows while you work it, so a percentage measured against the list you issued is reporting against a denominator that stopped existing in week two.
A register, not a request
Inside your office the list is a work plan: everything the job needs before anybody can start it. The moment it leaves, it turns into something else. It becomes an instrument addressed to people who did not write it, do not share your vocabulary, and have no idea which of its forty lines is the one holding everything up.
Four things separate it from an ordinary request for documents, and the rest of this follows from them.
It is standing. A request is answered and closed. A list stays open for weeks and changes state every few days without anyone opening it.
It is shared. Two organisations are supposed to be looking at the same object, which is true of nothing else in the engagement. The workpapers are yours. The ledger is theirs. The list is meant to be one thing in two places.
It has several owners at both ends. A manager, a senior and whoever is doing the fieldwork on your side. On theirs, an owner, a controller, an outside bookkeeper, and a payroll bureau nobody mentioned at planning.
And it is the record of what was asked and when. If the engagement runs late, the conversation is conducted against the list, which means its dates have to be as accurate as its items.
The same object turns up under different names. An audit or a review calls it the PBC list. Due diligence calls it a request list. A tax practice calls it the organiser, plus the dozen things it turns out you also need once the organiser comes back. What is on it varies enormously; how it behaves in a mailbox does not vary at all.
The ask itself is a separate craft with a guide of its own. Naming a document the way the client’s own paperwork names it, keeping a request small enough to be an errand, asking for a date where the thing has not been issued yet: all of that is managing client document requests, and none of it changes because the request is sitting on a numbered line. What changes is everything around the ask. One copy, two states, and a count that means something.
Who each line is addressed to
A list sent to the client is addressed to nobody.
The client is not a person. It is an owner who signed the engagement and reads mail on a phone, a controller who has the ledger, a bookkeeper who works two days a week and holds the bank feeds, and a payroll provider with no relationship to you whatsoever. Send forty lines to all of them and you have built a document that anybody can reasonably assume somebody else is dealing with.
Worse, a real fraction of any list is not in the client’s possession at all. The broker statement, the legal letter, the actuarial report, the bank confirmation, the last two years of a scheme the client has never logged into. Those lines are not requests to your client. They are requests your client has to make, and the chain is one link longer than the list admits. A line like that wants two things written next to it on the day it is issued: who has to be asked, and the fact that it is a forwarded request rather than a search of a filing cabinet. Otherwise it sits in the same visual class as a bank statement, and it is not remotely the same job.
So every line carries a name at issue, not at the first chase. Two things come out of that, and the second is the valuable one. Lines go to somebody who can act on them. And the lines nobody can be named for become visible in week one, which is when they are still cheap, rather than in week six.
It also means the list should come apart. The bookkeeper does not want the forty lines, they want their twelve. Four short lists, each sent to the person who can actually produce what is on it, move faster than one long list sent to four people, and the reason has nothing to do with reading speed. A list addressed to one named person is a task. The same list addressed to a company is a notice.
The argument for keeping any single ask short enough to be acted on that morning is made in managing client document requests. What is different here is that the list cannot be made shorter, because the list is the whole job. So the cut is by owner rather than by count.
The copy that forks
Here is the ordinary failure, and it costs more than every chase in the engagement put together.
You send the list out on the fourth. The controller works through it on Sunday evening, ticks eight rows and writes useful notes in the last column: two do not apply, one is with the bank, one was sent to a partner in March. Meanwhile your senior has added four rows discovered during planning and sends the new version out on the eleventh. That version has none of the controller’s notes, because those notes were in a file sitting in somebody’s sent items and nobody merged them.
Two weeks on the client says they filled it in, which is true, and the firm says it never arrived, which is also true, and both of them are looking at a spreadsheet with their own name on it.
Nobody was careless. A file sent by mail is a copy by definition, and a list with two copies has no state at all. It has opinions.
There are two arrangements that hold, and they are opposites.
The list lives somewhere both sides can open, and the mail carries only pointers to it and news about it. That costs a decision about access and a small amount of client patience in week one, and it removes the fork completely.
Or the list stays yours, the client never edits it, and answers come back as messages against item numbers. That costs you a transcription, removes the fork just as completely, and has a side effect worth more than the transcription: the client’s reasoning arrives as prose. “We sold the van in March” is information you cannot get from a tick in a cell, and it is the sentence that closes three lines at once.
What fails is the arrangement in the middle, which is the one most firms are running. Send an editable copy, receive an edited copy back, merge the two by eye. That merge is a manual reconciliation between two spreadsheets, usually done by whoever is least busy, usually at the end of a day, and it is the most error-prone act in the whole engagement.
One rule sits on top of whichever you pick. Whatever the client has to read in order to act should be readable without opening anything. A status message of twelve numbered lines in the body is read on a train. A workbook with a frozen header row and conditional formatting is opened on Thursday, if at all.
The only thing email carries intact
Prose about documents is ambiguous, and everybody involved is fluent enough not to notice. “Sent the bank stuff.” “The other statement.” “That one you asked about last week.” Each of those needs interpreting, and the interpreting is done from memory by whoever opens the message, without the list in front of them.
A number is not ambiguous. Two rules make it work, and neither is interesting.
Numbers are permanent. Item 14 is item 14 in the first version, the fourth version and next February’s rollforward. A new line takes the next unused number and rows are never renumbered to keep them tidy. The version of this that costs real money is a renumber between two issues of the list, because after it the client’s “we have sent 12 and 14” names two different documents on each side, and both sides believe the reconciliation has been done.
Numbers travel. Ask for them in replies, put one in the subject line when an item earns a thread of its own, and use them at the front of file names. Clients do this once asked, because quoting a number is less work than describing a document.
What it buys is that reconciliation stops being interpretive. A reply reading “3, 7 and 12 attached, 9 does not apply, we sold the van in March” updates four lines in fifteen seconds, and it can be done by anyone who opens the message rather than only by the person who wrote the list. That last part is what carries the engagement through somebody being away for a week.
The number is your handle on a line and the description is theirs, and a line wants both. The number is what survives a phone call, a forward and a photograph of a document taken at a kitchen table. The description is what lets somebody recognise the thing in front of them as the thing you meant.
Follow-up items hang off the line that produced them: the three purchase invoices the fixed asset register turned up are 22.1, 22.2 and 22.3. It costs nothing to write them that way, and it makes the next section countable.
Provided is not accepted
Most lists carry one status column, and the words in it belong to one side. Outstanding and received are your words. Sent it and not yet are theirs. They look like the same two states and they are not.
Between them sits a third state that no list has a column for and every engagement spends weeks inside: it arrived, and nobody has looked at it.
Plenty can be waiting in there. It is the wrong period. It is the right period, unsigned. It is a summary where you needed the detail behind it. It is exactly right and raises three new questions. In every one of those the client is entitled to believe they have provided the item, and you are entitled to say you have not received it, and both are true, because received is being asked to carry two meanings.
Two things follow.
Do not close a line on arrival. Closing on arrival is what produces the conversation where a firm tells a client they are all done on Tuesday and reopens four items on Thursday, and the second time that happens the list stops being believed. A line closes when somebody has opened the file and it is usable. Until then it has landed, which is a different word and deserves to look different on the page.
And keep their state where they can see it, not only yours. A line reading “sent 9 March, with us, not yet reviewed” is honest, it tells a client their Sunday counted, and it stops a document being sent twice. It also shows you something your own column cannot: how much of what is outstanding is sitting with them and how much is sitting with you. On a slow engagement that split is usually the entire answer, and it is usually not the answer the firm was expecting.
Why an acknowledgment is worth writing at all, and what it does to the chasing you would otherwise have to do, belongs to managing client document requests. What belongs here is only that a list with one status column cannot hold one, because it has nowhere to put the difference between a document being sent and a document being any use.
The list grows while you work it
Every document you receive makes more items. The bank statement raises a transfer nobody can explain. The fixed asset register raises three purchase invoices. The trial balance raises two reconciliations and a question about a director’s loan. On an audit that is most of fieldwork. On a compilation it is most of the questions. On a tax return it is the follow-up nobody could have written down in January, because it did not exist until the client answered.
So the list you issued is not the list you are working. A percentage computed against the original is reporting on a denominator that stopped existing in week two, which is why the status number reads sixty, then seventy, then sixty-eight. A figure that goes backwards is a figure a client stops reading.
Two numbers work where one does not, and they answer different questions.
How many items are open now, and whether that fell this week. That is progress, and it is the only honest form of it.
How many of the open items are ones you added rather than ones you issued. That is scope, and it is the number worth watching internally from the first week.
The second one has a conversation attached, and the timing of that conversation is most of its value. A list that has doubled is not a slow client. It is a job larger than the one that was priced, and saying so in week three is a conversation, while saying so in week nine is an argument. The list is the evidence either way, which is the practical reason its dates have to be right.
There is a smaller reason to keep the two kinds apart. The items you added are your questions, so they are yours to word properly and yours to send in batches. Released one at a time as they occur to you, they read to the client as being nibbled at, and a client who feels nibbled at answers more slowly than one who gets four questions on a Tuesday.
At the end of the job, those added items are the part worth keeping. They are the questions this client’s records raise every year, and next year they belong on the list as issued rather than being rediscovered in week four. That is what a rollforward is actually for. Not the rows, which the template already has, but the annotations: the lines that never apply to this client, the ones that always come from the bookkeeper rather than the owner, the one that took six weeks because it comes from a bank. Rebuilding from a clean template each year gets you a list where six of the forty lines are irrelevant, and a list carrying six irrelevant lines has taught the client, correctly, that it can be skimmed.
Which client needs six weeks and two phone calls is a fact about the client, and where to write that down is managing client document requests. What belongs on the list is narrower and easier to keep: which of its own lines this client’s books always turn into three more. What all of it feels like from inside a practice in the middle of March, as a week rather than as a method, is told in tax season without the inbox spiral.
Where does Point fit?
None of the above is software. Firms have run these lists on a spreadsheet and a telephone for as long as there have been engagements, and the careful ones run them well. What a tool changes is which half a person is carrying: the noticing, the matching and the first draft of the words, rather than the deciding.
Point reads the mailbox ahead of you and weighs what is in it on how much it matters and how soon, so a controller’s reply naming three items is not sitting underneath a renewal notice on a morning when both arrived. That weighing is explained properly in how triage decides what needs you. Every thread carries its summary in a line, which on a delivery thread answers the only question you have: whether something came, and whether it was for the period you asked about.
Three things fit a list in particular. Attachments stop disappearing inside threads and gather into a single list, each still tied to the message that brought it, which is the raw material of any reconciliation against numbered lines. A question put to a document comes back with a pointer to the place in the file it was read from, which shortens the walk from landed to accepted more than anything else here. And a standing request in plain words covers the item you are genuinely waiting on: ask to hear when the signed representation letter arrives, and you hear once, on the day it does, instead of looking.
The waiting is handled the same way. A request buried three paragraphs into a client’s message turns into a dated item, without anybody retyping it. Every request you send stays visible as an open loop with your own date attached, and it surfaces again on that date rather than whenever the client next crosses your mind. Where the answer has already landed, the reminder flags itself as probably settled and waits for you to agree, so nobody chases item 14 the morning after item 14 arrived.
Replies come back drafted in the way you write, so the status message naming what is in and what is still open starts as something you correct rather than something you compose. Point runs the scheduling back-and-forth itself on the day a list conversation turns into asking the controller for twenty minutes. How far Point goes without you is a separate setting per kind of action, and out of the box every one of them sits at review: the work is prepared, then it waits. The dial explains that setting properly. Acknowledging a delivery is the first kind worth raising. The message telling a client their list has doubled is not one of them, and should have somebody’s eyes on it first. What was done is written down in order with times against it and can be reversed from there, apart from the exception no mail software escapes: a message already sitting on somebody else’s server has been sent.
Connecting is a sign-in to the mail account the practice already uses, on Google or on Microsoft, so the address on the engagement letter is untouched.
What Point does not have is the list. There is no item 14 in it, no status column, and no view on whether the fixed asset register was for the right year. The numbering, the owner against each line, the two states and the count of what you added are yours, and they are the parts of this that are the actual work. The benefits page is the whole inventory, and Point for accountants works through it in the setting of a practice. Whether a tool ought to be reading engagement mail in the first place is a prior question, answered at length in what AI may safely be pointed at in a practice.
Common questions
Should the PBC list go out as a spreadsheet attachment?
Sent as something to read it is fine, and sent as something to fill in it has already forked. The distinction is not the file type, it is whether the copy the client is holding can drift away from yours while both of you work. If the client is going to write in it, the copy needs to be one you both open rather than one each of you keeps. If that is not available, hold the list yourself and take answers as numbered replies in the body of a message. It costs a few minutes of transcription per round and it buys a single state, plus the client’s reasons in their own words, which a tick in a cell never gives you.
How often should we reissue the list?
On a change of state, not on a calendar. A weekly reissue that looks the same as last week’s teaches a client that the list is a mailing rather than a record, and by the fourth one it is being skimmed on the way to the next thing. What earns a reissue is news: the lines closed since last time, the lines added and what raised them, and the count of what is open now with the direction it moved. If a week has genuinely changed nothing, that is still worth saying, and it is one sentence rather than an attachment.
Who should own the list inside the firm?
One named person, and not automatically the most senior one on the job. The list’s accuracy is a function of how fast an arrival reaches it, so the owner is whoever is reliably reading the mail every day. What the senior person owns is different in kind: deciding that a line does not apply, and having the conversation when the items you added start to outnumber the items you issued. Splitting it that way also answers the holiday question, because a list kept by number can be updated by anyone who can read a reply. If arrivals are currently landing in four mailboxes rather than one, that is the prior problem, and running the firm inbox is where it gets settled.
The client says they have sent everything and our list says otherwise.
Both statements are usually true, which is why arguing about it never resolves anything. Answer with numbers instead of with a position: here is what we hold against 3, 7 and 12, here is what is still open, and here is the group we do have and cannot yet use, with the reason for each. That last group is what the disagreement is almost always about, and naming it is the only version of the sentence that does not require either side to be wrong. If it happens twice with the same client, the fault is in the list rather than in them. A single status column has been asked to hold two people’s meaning of the word received.
Would a portal or a request tracker fix this?
It fixes one of the five problems above, and it is the one with the highest cost, so that is not nothing. A shared register with a status against each line removes the fork outright and gives both sides one place to look. It does not decide who each line is addressed to, it does not stop a firm closing an item on arrival, and it has no way of telling an item you issued from an item your own review created, which is the count that tells you whether the job has grown. Those are decisions about how the list is run, and any tool inherits them rather than supplying them. Whether the chasing itself gets easier is a different question, and it is answered in managing client document requests.
The short version
A PBC list is not a request, it is a register two organisations are supposed to share, and email is the one channel that cannot share anything. So the jobs are these. Address each line to a person at the moment you issue it, and mark the lines the client has to obtain from somebody else, because those are a longer chain than they look. Keep exactly one copy authoritative, either somewhere you both open or by holding it yourself and taking answers as numbered replies, and never run the merge in the middle. Number every line permanently and ask for numbers back, because a number is the only thing that travels through a mailbox without being paraphrased. Keep their state as well as yours, and never close a line before somebody has opened the file. Then count what is open now and how much of it you added yourself, since the second number is the one that tells you the job has grown while the first was standing still. The other recurring jobs in a practice each have their own guide in this collection, and the buying question is sorted out in AI email for accountants.