Certain, conditional, curious: sorting the first document request

Several items on your standard document request do not apply to the client about to receive it. Not wrong items — sensible ones, correct for the average client and simply absent for this one. Limited company accounts for someone who never incorporated. A tenancy agreement for an owner-occupier. Three months of payslips for someone who pays themselves in dividends. You know the list. You wrote it once, for a composite client who does not exist.

The usual fix is a rule: ask for everything up front, so you only ask once. It beats the alternative most firms actually run, which is five separate requests dribbled out over three weeks until the client stops opening your emails. But it optimises the wrong variable. The cost of a document request is not how many rounds it takes. It is whether the client can finish it.

A list nobody can finish looks exactly like a list nobody has started

Put fourteen items in front of someone. They will work down it until they hit one they cannot supply. At that point a decision happens that you never see: send the eleven they have with a note about the other three, or wait until they have worked out what the other three mean?

Most people wait. Sending a partial answer feels like failing the task, and admitting you do not understand an item on a professional’s list feels worse. So nothing arrives. Four days later you chase, and the reply opens with sorry, I wasn’t sure what you meant by the second one. The list was never the problem. The unanswerable item on it was.

Which means the question to ask of each line is not how badly you want the document. It is whether you already know it exists.

Certain, conditional, curious

Certain — you know this document exists for this client and they can get hold of it. Photo ID for anyone. Last filed accounts for a company you have already looked up on Companies House. The lease for a business you know rents its premises.

Conditional — the item exists only if something is true that you have not yet confirmed. It may be the single most important document in the file. Importance is not the test. A P60 matters enormously and is conditional on employment.

Curious — you would quite like it. Someone needed one once. Nothing downstream actually stops without it.

Bucket	The test	Effect on the client	Where it goes
Certain	You already know it exists for this client	Answerable	The first request
Conditional	Exists only if something unconfirmed is true	Stalls the entire list	Follow-up with a stated trigger
Curious	Nothing downstream fails without it	Costs effort, buys nothing	Deleted

Note what the test measures. Not the category of document — your knowledge of this client. Proof of address is certain. Proof of address for the second property is conditional until you know there is a second property. The same line on the same list sorts differently for two clients, which is the point, and the reason a standard list cannot do this work for you.

Conditional items need a written trigger, not a good memory

The honest objection to moving items out of the opening ask is that they get forgotten. Frequently true. That is a failure of the follow-up, not evidence the item belonged in the first request.

A conditional item is only properly sorted once you have written its trigger down before you send anything. Not a reminder to review the file — an observable event and the request it fires:

• If the bank statement shows transfers in from an account you have not seen, ask for that account’s statements.
• If the accounts show a director’s loan, ask for the loan account schedule.
• If the client describes themselves as a partner rather than a sole trader, ask for the partnership agreement.

The pattern is: when X arrives and shows Y, send request Z. Triggers are things you will observe when the certain items land. They do not depend on you remembering, in three days, what you were speculating about today.

Branching is normal in this domain and the official guidance does it too. HMRC’s own page on Self Assessment records does not present one flat list — it separates the records everyone needs from the additional records that apply only if you are self-employed or in a partnership (checked 28 September 2026). If the tax authority will not hand out an undifferentiated list, your onboarding email probably should not either.

The curious column is where data protection stops being abstract

Article 5(1)(c) of the UK GDPR requires personal data to be adequate, relevant and limited to what is necessary for the purpose. The ICO’s guidance on the principle is direct about speculative collection: do not gather personal data on the off-chance it might be useful later (ICO guidance, checked 28 September 2026).

Most firms file that under retention. It is a collection rule first. Every curious item you delete is one you never have to store, secure, justify, retain, delete on schedule, or disclose in a subject access request. It is also one fewer document to lose. The cheapest possible compliance posture on a document you do not need is not asking for it.

The same logic pushes in the other direction on regulated items, and that is worth being clear about. For firms in scope of the Money Laundering Regulations 2017, regulation 28 requires the customer to be identified and their identity verified on the basis of documents or information from a reliable source independent of the customer (checked 28 September 2026). ID is not a nice-to-have you can defer to a follow-up. It is certain by law, for every client, which makes it one of the easiest lines on the list to place.

Do the sort on the list you already have

You do not need a new process. Open the request you send now and put a letter against every line: C for certain, X for conditional, ? for curious.

Two rules make this fast. If you cannot decide between certain and conditional, it is conditional — the test is knowledge, and hesitation is the absence of it. If you cannot name what breaks downstream without the item, it is curious, and curious items are deleted rather than demoted.

Then count. A first request that loses a third of its lines is a normal result, not a sign you did it wrong. Most sorts land somewhere around five to seven certain items and a short list of triggers sitting behind them.

The judgement

“Ask for everything at once” survives because it names a real cost. Fragmented requests do train clients to ignore you. But it treats the opening request as a container to be filled rather than a question to be answered, and a question that a large share of recipients cannot answer is not a well-designed question, whatever it saves you in round trips.

Send the list you already know they can complete. Hold the rest behind a trigger you have written down. The second request that arrives with a reason attached — your statements show another account, could you send those too — reads as someone paying attention. The opening list full of items that do not apply reads as a form.