Compare a client task list with an evidence request list so your team can separate actions, decisions, meetings, and approvals from specific files, reports, uploads, and review outcomes. A client task list tracks actions; an evidence request list tracks specific evidence. One workflow may need both. CollectCue belongs in the evidence request workflow and does not replace a full project management system.
Use a client task when the expected result is an action, decision, confirmation, meeting, or response. Use an evidence request when the expected result is a specific file, report, record, export, or replacement document that staff must review.
Client task: Confirm which bank accounts are in scope.
Evidence requests: Upload the June statement for Account A. Upload the June statement for Account B.
One client task may create several evidence requests. A completed task does not automatically complete its evidence requests. Uploaded does not mean Received. Pending review means staff owns the next action, and the firm decides what evidence is required.
Use this decision guide when a team needs a clear boundary between client actions and specific evidence collection.
The visible worksheet and copied text use one structured source. It contains placeholders only, with no client data, file names, links, tokens, query values, or user input.
The classification is practical: decide whether the client needs to do something, provide something reviewable, or do both in a linked workflow.
Use a client task list to track an action, decision, confirmation, meeting, review, clarification response, or process step. The expected result is that someone completes an action, makes a decision, answers a question, attends a meeting, or confirms an owner.
Use an evidence request list to track a specific file, report, statement, export, signed record, supporting document, source record, or replacement file. The expected result is a requested item that staff can review and mark Received or Needs reupload.
Compare the expected result first. The desktop table becomes one decision card per row on smaller screens.
Decision point
Primary purpose
Client task list
Track an action, decision, confirmation, or project step.
Evidence request list
Track a specific file, report, export, statement, or supporting record.
Decision point
Expected result
Client task list
The assigned person completes an action or provides an answer.
Evidence request list
A requested item is uploaded and reviewed.
Decision point
Typical examples
Client task list
Confirm the account list; schedule a review call; answer a clarification question.
Evidence request list
June bank statement; payroll summary; signed agreement; corrected export.
Decision point
Client action
Client task list
Complete the defined action, decision, response, or meeting.
Evidence request list
Provide the specific source item or replacement requested.
Decision point
File upload required
Client task list
Not necessarily.
Evidence request list
Usually, when the requested item needs a client upload and staff review.
Decision point
Owner
Client task list
Client owner completes the action; a firm owner follows the task.
Evidence request list
Evidence provider supplies the item; request owner follows it; review owner records the outcome.
Decision point
Due date
Client task list
Task due date for the action or decision.
Evidence request list
Evidence due date for the specific requested item; it can differ from the task due date.
Decision point
Completion definition
Client task list
The action or decision is complete.
Evidence request list
Staff reviews the item and records the appropriate result.
Decision point
Staff review required
Client task list
Only if the broader task calls for a staff decision outside this evidence workflow.
Evidence request list
Yes, before an uploaded item is recorded as Received or Needs reupload.
Decision point
Reminder behavior
Client task list
A task reminder asks for the action, decision, or response.
Evidence request list
An evidence reminder lists only requested items that still need client action.
Decision point
Status model
Client task list
Use the task system's action status and definition of done.
Evidence request list
Use Waiting on client, Pending review, Received, or Needs reupload for the requested item.
Decision point
Best system fit
Client task list
A project or practice management system can own broader engagement work.
Evidence request list
A document request workflow can own item-level collection and review context.
Decision point
Common failure
Client task list
A broad task hides the separate files needed to support it.
Evidence request list
One uploaded or Received item is mistaken for completion of the whole request.
Decision point
Relationship to other items
Client task list
One task may describe the objective behind several evidence requests.
Evidence request list
Each requested item remains independently missing, pending review, received, or needing replacement.
Classify the expected outcome before creating the record. Use both record types when one broader client action produces several independently reviewable source files.
Keep a client action, the output of that action, and the record staff must review distinct. This avoids turning every meeting or decision into a file request and avoids hiding a needed document inside a generic task.
A behavior someone needs to complete. Example: Confirm which locations are active.
The result created by that behavior. Example: A confirmed location list.
A specific record staff needs to review. Example: The July settlement report for each active location.
Use the broader task to confirm the source scope, then keep every reviewable record as its own requested item. The page describes this workflow concept; it does not claim that CollectCue creates task-to-request relationships.
Monthly bookkeeping input package
Confirm the accounts and platforms active during the bookkeeping period.
Ownership can change by record type. A task due date and an evidence due date can be different because the action and the requested record do not always have the same next step.
Completes the action, decision, confirmation, or response.
Has access to or can export the specific file or report.
Firm staff member who creates and follows the evidence request.
Staff member who reviews the upload and records Received or Needs reupload.
When the action or decision should be complete.
When the specific requested file should be submitted.
A client task and a requested item each need their own outcome. Avoid using a broad task status as a shortcut for document collection or staff review.
The specified action, answer, meeting, or decision is complete.
The system received an upload, but staff has not completed the review decision.
Staff owns the next action.
Staff accepted or recorded the requested item.
Staff needs the client to provide a replacement for that specific item.
Task complete does not mean every evidence request is complete.
Uploaded does not mean Received.
One Received item does not complete a multi-item request.
Pending review items should not remain in client reminder messages.
Use a task reminder for an action or response. Evidence reminders should list only the requested items that still need client action. A standardized status gives the fast handoff signal; a contextual note supplies extra background without replacing the requested item.
A status answers who owns the next action, whether the item is missing, whether staff is reviewing it, whether it is Received, or whether it needs replacement. A contextual note can explain a delay, unusual source context, or what staff should check next. A note does not replace a clear requested item. CollectCue does not provide comments, chat, or discussion threads.
The distinction is about responsibility, not a claim that one system should replace the other. Project management software can track milestones, meetings, responsibilities, internal tasks, client actions, and broader engagement progress. An evidence workflow can track requested files, missing items, uploads, review, Received, Needs reupload, and document-specific reminders.
For a document workflow after this classification, use the document request form, client document requests, the client upload flow, and document review. Use the client document follow-up workflow and automated reminders only for document request items that still need client action.
These examples show when an action belongs in a client task and when a separate source record needs its own evidence request. They use placeholders only.
Client task: Confirm every active bank account for July.
Evidence requests: July statement for checking account ending in [last four]; July statement for savings account ending in [last four].
Client task: Confirm who owns payroll access.
Evidence request: July payroll summary from the identified provider.
Client task: Review the bookkeeping source list.
Evidence requests: Bank statement; credit-card statement; processor settlement report; sales report.
Client task: Explain an unusual transaction.
Evidence request: Supporting invoice or receipt for the specific transaction, if available. The explanation is a response task; the file is an evidence request.
Client task: Approve the engagement scope.
Evidence request: Signed engagement document only if the firm requires that record and the action actually produces one.
Client task: Correct the July submission package.
Evidence request: Replacement export covering the required full date range.
When a requested item needs a client upload, name the source and period first, then state the expected source-generated file format. The current CollectCue client upload flow supports the shared product format list and maximum size below; the firm still decides which evidence is required.
PDF, DOCX, XLSX, CSV, JPEG, or PNG
25 MB
A multi-item request lets staff see each requested item in its upload and review context. That is different from a broad client action or a general project task.
One broader task can lead to several files, each with its own source, period, upload, review result, and next action. Keep those files as distinct requested items so a single upload does not hide what is still missing or waiting for staff review.
Product walkthrough — synthetic data
These mistakes usually come from treating actions, files, staff review, and next-action ownership as the same status.
A project task can identify the broader client action. The evidence request list should then name each document that needs separate collection and review.
These answers keep action tracking, document collection, staff review, and professional judgment in their proper boundaries.
A client task list tracks an action, decision, confirmation, meeting, or response. An evidence request list tracks a specific file, report, record, export, or replacement document that staff needs to review.
Create a client task when the expected result is a client action, decision, confirmation, meeting, clarification response, or another non-file deliverable. Define the owner, due date, and definition of done for that action.
Create an evidence request when the firm needs a specific reviewable file, report, statement, export, signed record, supporting document, or replacement file. Name the requested item, source, bookkeeping period, review owner, and next action.
Yes. A task such as confirming the active accounts can lead to a separate evidence request for each account statement. The task can be complete while one or more of those requested items are still waiting on the client.
No. Task completion only records that the defined action, decision, meeting, or response is complete. Each evidence request needs its own staff review result before it is recorded as Received or Needs reupload.
No. Uploaded does not mean Received. A file is Pending review until staff records the appropriate result for that requested item, and one Received item does not complete every item in a multi-item request.
Staff owns the next step when a file is Pending review. Client reminders should focus on items that still need a client action, rather than items waiting for staff review.
Project management software can track broader client actions, meetings, responsibilities, and engagement progress. A separate evidence workflow can still be useful when the firm needs item-specific uploads, review results, reuploads, and document-specific reminders.
No. CollectCue is for client document requests and their requested items, uploads, staff review, reupload actions, and reminders. It does not provide broad client task management or approval workflows.
Use a project or practice management system for broader tasks, meetings, approvals, and milestones. Use CollectCue when the firm needs to request specific evidence, review uploads, record Received or Needs reupload, and follow up on remaining client-action items.
Use these focused resources when the decision leads to a document request, a clear completion rule, a replacement-file request, or a staff follow-up step.
Compare the narrower document-request layer with broader practice management responsibilities.
Open resourceTurn a classified evidence need into a client, period, requested-item, due-date, and review request.
Open resourceChoose the records to request once the workflow needs a defined evidence list.
Open resourceDefine what staff needs before marking one requested item as Received.
Open resourceKeep a replacement request limited to the item with the wrong source, period, scope, or usability.
Open resourceRecord the current status and next action when a request is nearing closeout.
Open resourceCollectCue helps small bookkeeping teams organize evidence requests by client, bookkeeping period, requested item, upload, staff review result, reupload action, and reminder status. Use a project or practice management system for broader client tasks, meetings, approvals, and engagement milestones. CollectCue does not replace a full task-management or approval platform, automatically validate evidence, or decide whether evidence is professionally sufficient.
