# Document-chasing test checklist

Astraeus Business Solutions | Prepared 24 September 2026

Use this worksheet to assess one reminder workflow with fictional records before considering live client data. This is an illustrative operating checklist, not a tax-document list, compliance certification or a connected automation.

## Define the trial

- Owner and backup:
- Type of work and period:
- Authoritative tracker:
- Approved document store and upload route:
- Internal records date:
- Applicable filing date, conditions and official source (confirmed by the practice):
- Permitted recipients and client contact holds:
- Who approves each outgoing message:
- How sending permissions enforce approval:
- Where held items appear and when they are reviewed:
- How the owner pauses all sending:

## Record each requested item

Use one row for each item, even when several items belong to the same client request. This fictional example shows a partial delivery:

| Client ref | Period | Requested item | Status | Owner | Next action |
| --- | --- | --- | --- | --- | --- |
| EXAMPLE-01 | Agreed period | Bank statement | Received, awaiting review | Reviewer | Check the period, then accept or request a correction. Pause its missing-item reminder. |
| EXAMPLE-01 | Agreed period | Purchase invoices | Missing | Owner | Recheck the latest record and any contact hold before approving a reminder. |

Copy this blank row into the practice system or a spreadsheet, adding rows as needed:

| Client reference | Period | Requested item | Internal records date | Status | Owner | Last contact | Next action and review date | Approved storage reference |
| --- | --- | --- | --- | --- | --- | --- | --- | --- |
|  |  |  |  |  |  |  |  |  |

Suggested statuses: missing; received, awaiting review; accepted for this request; needs attention. Acceptance closes this request only. It does not approve accounts or a tax return.

## Draft the client message

For a still-missing item after a partial delivery, adapt this wording and have a person approve it against the latest record:

> Thanks for sending the [item received]. We are checking it. We still need the [missing item] for [agreed period]. Please upload it through [approved route] by [agreed records date]. If you have already sent it, tell us where so we can check before asking again.

For a wrong-period upload, pause the routine chase and ask a reviewer to confirm the correction request:

> Thanks for sending the [item]. It covers [period received], but we need [period requested] for this request. Could you upload that version through [approved route] by [agreed records date]? If it is difficult to get, please let us know.

Do not paste a Revenue filing deadline into the records-date field without checking the client's conditions. The practice sets and explains its own earlier records date.

## Test cases

Use fictional reference DEMO-001. Request a bank statement and purchase invoices for an agreed period. No real names, email addresses, bank details or documents are needed. Direct all test messages to a controlled test destination.

### 1. Partial delivery

Input: only the statement arrives.

Expected: pause the statement reminder; assign a reviewer; only the invoices remain eligible for a draft. Do not mark the client's entire request complete.

Observed result / evidence / pass or fail:

### 2. Arrival after drafting

Input: prepare the invoices reminder, then record that the invoices arrived before sending. Also test an arrival after approval but before sending.

Expected: recheck current status; withdraw or hold the stale draft; do not send the old request. A changed message or status requires another review.

Observed result / evidence / pass or fail:

### 3. Wrong period or unreadable upload

Input: the statement covers a different period, or cannot be opened.

Expected: needs attention; routine missing-item chase stays paused; named reviewer decides the correction request and approves its wording.

Observed result / evidence / pass or fail:

### 4. Conflicting records or unavailable tracker

Input: inbox indicates receipt but tracker says missing. Repeat with the authoritative tracker unavailable.

Expected: no routine send; visible held item with evidence, owner and review date. Test the backup route when the owner does not respond.

Observed result / evidence / pass or fail:

### 5. Repeated run or uncertain delivery

Input: run the same eligible reminder twice; then simulate a send whose outcome is unknown.

Expected: no duplicate reminder. Confirm the existing send record or hold for investigation before any retry. Keep the approval and send evidence together.

Observed result / evidence / pass or fail:

### 6. Client contact hold

Input: set a client-level hold while both items remain outstanding.

Expected: every affected outgoing reminder stops, including already prepared drafts. A person owns the next client action. Only an authorised person clears the hold.

Observed result / evidence / pass or fail:

## Measure and decide

Record the baseline and trial period separately. Use comparable requests and record differences in volume or complexity.

- Number of requested items:
- Staff minutes checking status:
- Staff minutes preparing and reviewing messages:
- Staff minutes correcting mistakes:
- Reminders sent after receipt:
- Items waiting beyond the agreed review interval:
- Exceptions and reasons:
- Total staff time (include review and correction):

Decision: extend / revise / keep manual

Reason and evidence:

Reviewer and date:

Resolve failed cases before live use. Confirm data handling and access separately; a successful fictional test does not establish that a supplier or live configuration meets the practice's obligations.

Article: https://astraeus.ie/insights/client-document-chasing-accountants (publication pending)
Consultation: https://astraeus.ie/services/free-ai-consultation