Making "what's still outstanding" a fact, not a guess

A manager opens the engagement folder on Thursday morning and starts counting. Twelve files are in the folder. The request email listed eighteen asks. So six are missing. Except two of those files are last year’s, dropped in by mistake, and one is a duplicate the client sent twice. So really it is more like nine outstanding. Or is it eight? She opens the email thread to check what she actually asked for, then opens the client’s last reply to see what they said they had sent. Twenty minutes later she has a number she is only mostly sure of.

That number is the single most important thing in the whole engagement, and she is calculating it by hand from two systems that do not agree.

The number you re-derive is the number that goes wrong

“What is still outstanding” is the question that everything else hangs on. It tells you whether you can start fieldwork, whether to chase the client, whether the period is nearly done. And in most firms it is not stored anywhere. It is inferred, on demand, by a person comparing what they remember asking for against what happens to be sitting in a folder or an inbox.

Derived state is fragile for a simple reason: the moment you compute it, it is already drifting. A file arrives an hour later and your count is stale. A client emails a correction and now the folder holds two versions and you cannot tell which one you were relying on. Someone drops a document in the wrong place and it is either invisible or double-counted.

The classic failure follows directly. You chase a client for a document they sent last week, because your mental tally and their inbox disagree. It is a small embarrassment each time, and it erodes exactly the trust you depend on. The client starts to wonder whether you are paying attention. You start to wonder whether they actually sent it. Both of you are right, because the truth lives in no single place.

The deeper problem is that a folder and a checklist are two systems, and two systems drift. The files say one thing, the tracker says another, and reconciling them becomes its own recurring job. We wrote about why this pushes toward the wrong design in request items, not folders. The short version: a folder can tell you a file exists. It cannot tell you what you asked for.

Store the status, don’t infer it

The fix is to stop deriving “outstanding” and start storing it. That means the unit of work cannot be a file, because a file has no status of its own. It has to be the ask itself.

In Clivanta that unit is the Request Item: one specific thing you have asked a Client for, carrying its own status, its own conversation, and its own versioned files. The item has a defined lifecycle, and every transition is stored and audited rather than guessed:

• draft — the ask exists but has not been sent to the Client yet. It is not counted as outstanding, because you have not actually requested it.
• requested — sent, and the Client has not yet responded. This is genuinely open.
• submitted — the Client has uploaded a Document, and it is waiting for your review. The ball is in your court, not theirs.
• needs revision — you reviewed it and sent it back with a reason. Open again, and clearly attributable.
• accepted — you reviewed it and accepted the Document as Evidence. Done, with a reviewer’s name and a timestamp.
• cancelled — you decided you no longer need it. Excluded, deliberately, not forgotten.

Once every item carries a stored status, “outstanding” stops being arithmetic. An item is outstanding when it sits at requested or needs revision — those are the two states where the Client still owes you something. An item is satisfied when it is accepted. Items in draft or cancelled are excluded, because you have either not asked or decided not to. There is nothing to count by hand. The number is read, not reconstructed.

Note that submitted is not outstanding in the sense the Client cares about. The Client has done their part; the item is now waiting on your review. Keeping that distinct matters, because it tells you precisely whose action is holding the item up. A firm that conflates “waiting on the client” with “waiting on us” chases the wrong party.

One stored status, read by everything

The real payoff is not one clean number in one place. It is that everything downstream reads from the same stored status, so nothing can drift out of agreement with anything else.

• The worklist your team uses reads it. When a manager wants to know what is holding up a Period, she is not counting files. She is looking at the items that sit at requested or needs revision.
• The Client portal reads it. The “what’s still missing” summary a Client sees is the same set of open items, described plainly, so the two sides are never working from different lists. There is no version where you think six things are outstanding and the client thinks it is three.
• Reminders read it. A reminder only chases items that are genuinely requested or needs revision. It never asks for a document the Client already submitted, because the status moved the moment they uploaded. That is what makes an automated reminder trustworthy enough that clients do not tune it out.
• Exports read it. When you pull an Excel request list or an Evidence index for the workpaper file, it reflects the same stored state, not a snapshot someone typed up separately.

Because all of these draw from one audited source, they cannot disagree. The portal cannot say “done” while the worklist says “open.” The reminder cannot fire for something already accepted. The export cannot show a different picture than the screen your reviewer is looking at. There is exactly one answer to “what is still outstanding,” and every surface is a view of it.

That is the whole idea behind how Clivanta models collection: the ask is a first-class object with a stored status, and outstanding is simply a state it is in.

Counting files will always give you a guess. A stored status gives you the answer.