← All Notion guides

Journal · Problem note

How to Track Missing Client Documents Before a Tax Return Stalls

A tax return often stops moving for a simple reason: one document, answer, signature or client action is still missing.

The problem gets expensive when nobody can see exactly what is missing, who is following up, when the client was last contacted or what happens next.

Track the missing item, not just the client

A client can have several outstanding items at once. Treat each meaningful missing item as something that can be seen and resolved independently.

  • client;
  • missing document, answer or action;
  • return or engagement affected;
  • internal owner;
  • date requested;
  • date needed;
  • last client contact;
  • current status;
  • next follow-up date;
  • next action.

This turns “waiting on client” from a vague state into work that can actually be managed.

Separate the tax deadline from the follow-up deadline

The statutory or filing deadline is not the date the practice should first notice something is missing.

Set an internal date for when the item is needed and a separate next-follow-up date. That creates room to chase, review and resolve the item before the real deadline becomes an emergency.

Give every follow-up an owner

Shared inboxes and general reminders make it easy for everyone to assume someone else is handling the chase.

Assign one person to the next action. Ownership can change, but it should never be ambiguous.

Keep the last touch visible

Before contacting a client again, the team should be able to see when the last reminder was sent and what was requested.

That prevents duplicated messages, long silent gaps and the uncomfortable situation where nobody knows whether the client has already responded somewhere else.

Use precise statuses

A single Waiting status hides too much. Use only the states your practice can act on, for example:

  • Requested;
  • Follow-up due;
  • Client responded;
  • Needs review;
  • Resolved.

The exact labels matter less than being able to tell what requires attention now.

Review the queue by urgency

Do not review missing documents alphabetically by client. Review them by what is due soon, what has had no response and what is blocking the next stage of the return.

A fictional follow-up queue

This example describes internal coordination, not which documents a particular return legally requires. Let the responsible preparer define the actual request and the verified deadline.

  • Item A — Requested: the coordinator sent a specific request through the approved client channel. Record the request date and next follow-up date.
  • Item B — Client responded: an upload arrived. Assign a reviewer; receipt alone does not establish that the item is complete.
  • Item C — Needs clarification: the reviewer identified an unreadable page. Request that page, keeping the original request history.
  • Item D — Resolved: the reviewer accepted the response and recorded the outcome. Remove it from the open queue while retaining its history.

A reminder that makes the next action clear

Use a short message such as:

We are still waiting for [specific item] for [engagement]. Please provide it through [approved secure channel] by [confirmed internal date], or let us know what is preventing you from doing so. If you have already sent it, please tell us when and through which channel so we can locate it.

Replace every bracket before sending. Avoid putting tax documents or sensitive identifiers into a reminder. Keep files in the practice’s approved document system; a tracking row can hold a reference and review status without storing the document itself.

A ten-minute queue review

  1. Check responses first. Reconcile the approved inbox or portal before sending another reminder.
  2. Review follow-ups due. Filter open items whose next-follow-up date is today or earlier. Group items by client where one clear message can cover them.
  3. Review items awaiting staff. A client response can still block the engagement if nobody reviews it.
  4. Escalate unresolved blockers. Route approaching verified deadlines to the responsible professional. A tracking status does not decide filing, extension or engagement obligations.
  5. Finish with a next action. Every open row needs an owner and the next review or follow-up date.

Build the queue in Notion

Create Clients and Missing Items databases, with each item related to its client. Add owner, status, request date, internal needed-by date, last contact and next-follow-up date. Use separate views for follow-ups due, responses awaiting review and unresolved blockers. See how to connect two databases in Notion for the relationship setup.

For deciding what to request at intake, use the separate tax client document checklist. This workflow starts after a request exists and keeps the follow-up visible.

For a broader practice workspace, explore The Tax Practice and compare the system with your team’s operating requirements.

Build a missing-document register in Notion

Create one record for each requested item, rather than one long checklist per client. The example below uses fictional coordination records. It does not define the documents required for a tax return.

Suggested properties for an internal document-request database.
PropertyTypeWhat to record
Requested itemTitleOne specific item with enough context to identify it
ClientRelationThe existing client record
StatusSelectRequested, Received, Needs clarification or Reviewed
OwnerPersonThe team member responsible for the next action
Last Contact / Next Follow-upTwo Date propertiesWhen contact happened and when the next check is due
Next ActionTextA concrete action, such as asking for a readable replacement

If your client database already exists, use the database connection guide to link requests to it. Keep confidential files in the storage and access process approved by your practice; a tracking record does not require uploading the document itself.

Frequently asked questions

Should each missing document have its own record?

Yes, when it can be requested, received or resolved independently. Link each record to its client so several requests remain connected.

Does receiving a file mean the request is resolved?

No. Use Client responded while the item awaits checking. Mark it Resolved only after the responsible reviewer accepts it.

What happens when the next follow-up date is empty?

The record may be absent from a date-based chase queue. Review unresolved items with empty follow-up dates separately.

Should tax documents be uploaded into this tracker?

Use the practice’s approved document storage and access process. A tracking row can record a reference, ownership and review status without holding the file.

Use one consistent set of status labels

The worked setup below uses Received for the earlier Client responded stage and Reviewed for Resolved. Choose one label for each stage in your database and use it consistently in every filter. If you retain the earlier labels, substitute Client responded for Received and Resolved for Reviewed in the steps below.

Create two queues with different jobs

  1. Client follow-ups: combine an OR group containing Status is Requested or Status is Needs clarification with an AND condition requiring Next Follow-up on or before today. Sort Next Follow-up ascending.
  2. Received — review needed: filter Status is Received. This keeps incoming items visible until somebody checks them.
  3. Missing next action: inspect unresolved records where Next Follow-up is empty. These will not reliably appear in a date-based chase queue.

Use the AND and OR filter guide to check the grouping. A reminder date alone should not bring a reviewed item back into the chase queue.

Test a partial response before relying on the queue

Suppose a client sends a file that is unreadable. Record receipt, set Status to Needs clarification, explain the problem in Next Action and assign a new follow-up date. Do not mark it Reviewed solely because an attachment arrived.

For a readable file awaiting an internal check, use Received. It should leave the client chase queue and enter the review queue. After the responsible reviewer accepts it, change it to Reviewed. Keep a note of what was checked through your normal practice process.

Test those three states with a fictional record. Confirm that Requested appears in the chase queue when its follow-up is due, Received appears in the review queue, and Reviewed appears in neither operational queue. Leave an All requests view available so records remain easy to find.

For related workflow ideas, see the client document checklist guide. Keep requests specific enough that the client knows what to send and the reviewer knows what remains unresolved.

The rule worth keeping

“Waiting on the client” is not a workflow.

Keep the missing item, deadline, owner, last contact and next action visible so the practice knows exactly what needs chasing before the return stalls.