A tax-firm document workflow: a worked example

A team is collecting documents for September 2026. A domain owner maintains the expected-document list for each client. Staff currently assign arrivals manually, record unresolved items and draft requests in the mailbox.

The proposed workflow supports assignment and preparation. The firm retains the professional decision about which documents are required. The workflow does not give tax advice, post transactions or file returns independently.

The proposed tax-firm document workflow runs in six steps:

1. Register intake: store the file, arrival time and stable transaction identifier. Keep the original linked to its processing status.
2. Propose assignment: derive client and period from permitted information. Do not guess between several plausible matches.
3. Compare the checklist: use only expectations maintained by the firm. Refer unclear or outdated lists for review.
4. Prepare the request: display unresolved items with their current status, recipient and period.
5. Obtain domain approval: check arrivals again before sending. A new document may invalidate the draft.
6. Track execution: retain sending status. Resolve an uncertain outcome before retrying.

Five questions need answers before software is connected:

• Where is the authoritative checklist?
• Where is receipt confirmed?
• Which client identifier may cross system boundaries?
• Is the necessary read or write access available?
• Which staff may see which clients?

A product name alone cannot answer these questions. In Austria, start with the BMD capability assessment. A German DATEV or Swiss fiduciary environment needs its own supported data route assessed separately.

This example uses three separate records: expected documents, actual submissions and resulting tasks. One requirement may need several files, and a file may answer more than one requirement. Recording these relationships prevents a single upload from closing an entire monthly checklist.

The three records of this example hold different information:

A clarification request therefore belongs to a traceable case rather than existing as an isolated email draft.

Four invented cases illustrate how expectation, submission and decision relate:

These identifiers and records are invented. In a real practice, expectations and professional decisions come from responsible employees. AI may suggest a possible additional gap, but it becomes an authoritative client request only after review.

08:30. At 08:30 a document arrives. The workflow records it and proposes the M17-09-RENT requirement. The source matches the client, the period is clear and the file is readable. Intake is confirmed. Whether all professional questions are resolved depends on the requirement: available and reviewed remain separate facts.

10:00 to 11:00. At 10:00 the system prepares a request for two outstanding items. At 10:15 the client uploads one through the portal. When the employee reviews the draft at 11:00, it is checked against current intake again. The message now asks only for the remaining item, and the obsolete version is not sent separately.

14:00. At 14:00 a reply arrives without a clear case reference. Instead of guessing from the sender's name, the workflow creates an internal assignment task. An employee connects the response to the correct client and records the decision. A reminder is paused while the response may satisfy that requirement.

End of day. At the end of the day, the team reconciles submissions with completed, unresolved and deliberately excluded cases. This exposes documents left behind. It also helps distinguish client delay from a technical interface that temporarily stopped collecting files.

Responsibilities. The practice owns the expected list, professional assessment and recipient approval. The operator owns technical delivery, monitoring and recovery. Client-service staff take over ambiguous or repeatedly unanswered questions. A substitute needs access to the same history without relying on another employee's private inbox.

Existing portal functions. Check existing portal functions first. TaxDome documents structured requests and reminders, while DATEV offers distinct data services for different destination outcomes. These capabilities are not interchangeable by default. TaxDome requests, DATEV data services, checked on 26 September 2026.

Minimum access. A request workflow may need only read access to a status and a controlled messaging channel. It does not automatically need write permission in the accounting ledger. Record the minimum operations required and have the support partner confirm the actual path. This bounds both implementation effort and the consequences of an error.

Portal unavailable. Suppose the portal is unavailable for two hours. The workflow must not interpret the absence of newly synchronised files as a professional finding that documents are missing. Expose the technical problem, pause reminders based on uncertain intake and assign an operational task. After recovery, collect the missing events and compare them with previously processed identifiers.

Lost acknowledgement. A separate failure occurs when a message is accepted but its acknowledgement disappears. Check delivery evidence before sending again. If the state cannot be determined, a person takes over. Two identical reminders in quick succession are an avoidable operational error and a poor client experience.

Manual work during a longer outage. Define how staff continue manually during a longer outage. On recovery, those manual decisions must be reflected in the case records. Otherwise automation will remind clients about issues already resolved by telephone.

Test the recovery. Test this recovery with the same care as normal processing. A successful return to operation means no missing submissions, duplicate requests or overwritten human decisions. It is more than restoring a green connection indicator.

Comprehension test. Add a short comprehension test. Someone who did not draft the message should explain which document is needed, for what period and where to submit it. If those points are unclear, improve the wording even when internal assignment is correct.

Clients with several companies. Also consider a client with several companies. A generic request for missing documents can remain ambiguous despite a correct internal identifier. The message needs sufficient authorised context without unnecessary confidential detail. An internal case number helps only if the recipient can use it.

What the test shows. This does not measure real client satisfaction or replace a pilot. It checks before sending that automation creates an answerable request, providing an additional acceptance criterion beyond data quality and technical delivery.

Who reopens and closes the case?

Also record who reopens the case after a manual correction. A substitute needs the same source documents and task history as the original reviewer; otherwise each change of owner repeats the investigation.

In this example, each open request has a due date and an accountable person. When the expected bank statement arrives, that person checks its period and readability before closing the case. A matching filename is insufficient. If the statement remains incomplete, refine the existing request instead of sending a separate, conflicting task list.

Handover package. Provide the current requirement list, roles, status definitions, acceptance cases and a short correction guide. For any failed case, the operator should be able to answer what happened, which client is affected, what has already executed and which next action is permitted.

Assignment versus communication. Assess assignment quality separately from communication quality. A correctly assigned document can still trigger an incorrect reminder if a status update failed. Measure completed requirements, unnecessary contacts, unresolved tasks and actual handling time. These describe the service better than the number of drafts produced.

Stopping outbound messages. The practice should also know how to stop outbound messages while continuing intake. That allows investigation without losing new submissions. Resume only after reconciling the affected cases and confirming which messages remain appropriate.

Before a real trial, measure current handling time for the same transaction types. In the proposed process, count assignment, review, correction, questions and incident handling. Do not compare a difficult historical backlog with carefully selected easy test cases.

Record the tested environment and every unresolved deviation. Assignment working on synthetic examples does not prove performance on real client correspondence. Sampling and a manual fallback remain useful after acceptance.

We deliberately publish no invented time-saving result. Our measurement method explains how observed outcomes can later be reported. Use the document acceptance template for the technical test route.

Replace the client identifiers, period and document types with professionally approved inputs. Start with one bounded intake channel and somebody able to review outputs. Expand after assignment and exception handling are understandable and working.

See automation for tax firms and document processing for our services. An initial conversation needs only a process description; real client data belongs in an agreed, protected workspace.