Karbon client requests and document reminders workflow

Do not let the next bottleneck start when the client replies

Test what happens after partial replies and incorrect uploads so reminders lead to usable work. Keep requests in Karbon; when supplier invoice PDFs need to become a spreadsheet, test ParseMill for extraction, source review and Excel export.

Inspect the interactive invoice sample, then try your own invoices. Eligible new workspaces get 10 pages for 7 days after email verification, with no card or automatic subscription.

What Karbon Client Requests already handles

Karbon's Client Requests overview describes requests within work items, template-based sending rules and automatic reminders tied to a due date. Client completion updates the task and notifies staff in Triage. The documented automatic reminder limit is five; the guide also notes that Gentle reminders can stop for a group when it contains a completed task with a due date.

Those details make partial completion and reminder limits important test cases. Check current behavior in your account before relying on a cadence. Vendor functionality here was checked on 5 October 2026; this is an independent workflow guide, not a Karbon integration or a claim that ParseMill provides those features.

Check the request design and the staff review task

Start with one recurring engagement and write item-specific requests. “Upload documents” leaves the client to infer the entity, period and file. A request for the June bank statement for a named business account gives staff a defined item to review. Use the firm's approved level of detail and client channel.

Karbon's task documentation describes task owners, descriptions, due dates and client-specific changes to work created from a template. Use those existing controls to make the internal acceptance step explicit. Client completion is a signal for review; your firm still decides whether the evidence meets its requirement.

• Name the staff member who checks the returned evidence.
• Define the expected entity, period and document for each item.
• Specify the next action after a wrong file or incomplete response.
• Choose an escalation owner for requests still unresolved after the reminder cycle.
• Decide how a reply received outside the request will be associated with the work.

Test this design with a small set of synthetic requests before changing a live template used across many clients.

Test the paths that can keep document chasing manual

The table is a test plan, not a claim that any particular path fails. Write down the actual result, current settings and date. A confirmed configuration fix should take priority over building a second reminder service.

Example: a partially completed month-end request

Hypothetical case: a bookkeeping team requests a June bank statement, June card statement and payroll summary. The client completes the bank-statement item but uploads the May file, then comments that payroll will arrive on Friday.

There are three different actions: review the wrong-period upload, keep the card statement request outstanding and record the promised payroll date. Sending the original full list again risks asking for work the client believes is finished. Treat the completion event as a review trigger, record why June is still required, and make the next request precise.

Observe the reminder behavior for this combination in your account, particularly if the group uses Gentle reminders. Keep one person accountable for the client's next action and one clear record of the remaining items. This example illustrates a process design; it is not a measured customer outcome.

Separate useful automation from work that needs a decision

Routine candidates include finding open work, presenting an approved reminder list, updating a known status and notifying the assigned reviewer. Before proposing automation, define the source of truth for each item and how the process detects a new reply. A delayed status update should not cause a second system to repeat a resolved request.

Wrong-period documents, disputed requirements, unavailable evidence and changes to an engagement need an explicit decision. Record the reason and next action with an owner. Do not use a generic “complete” status to hide work that remains with staff.

For the cross-tool process, read automating document chasing for accounting firms. If the repeated work is locating email and assigning it, use the shared inbox workflow guide to examine that handoff separately.

Measure the remaining checks before changing tools

For one recurring cycle, record how many requests required manual handling and why: partial reply, wrong document, reply outside the request, promised later or no response. Time the status lookup, evidence review, reminder preparation and update separately where they are separate actions.

Illustrative model: 60 manual follow-up actions × 4 minutes ÷ 60 = 4 staff hours. Reducing a repeated lookup by one minute on those same actions releases a modeled gross hour. If monitoring adds 30 minutes, the modeled net difference is 30 minutes before setup. The small example shows why counting review work matters; it is not a forecast.

Use the free workflow audit checklist to record the baseline and the capacity calculator to explore your own assumptions. Request a document-chasing workflow audit with the residual step, case counts and current stack if you want help assessing a practical improvement.

Questions about this workflow