Expected availability, client due dates, and staff review targets describe different moments, and combining them can trigger premature requests and reminders.
A client request dashboard shows a red warning:
Processor settlement report — overdue
The client has not uploaded it.
The problem is that the processor normally produces the report several days after the bookkeeping period ends. On the day the warning appeared, there may not have been a report available for the client to download yet.
Nothing failed technically.
The reminder ran on time. The requested item existed. The due-date comparison returned the result the code was written to return.
The interface simply treated every date as the same kind of deadline.
One “due date” was carrying four different meanings
A recurring source-report request can involve several moments:
- when the report normally becomes available
- when the firm plans to send the request
- when the client is asked to provide it
- when staff plans to review it
Those dates may happen close together, but they do not answer the same question.
An expected availability date is a planning estimate:
When does the firm normally expect this source to produce the report?
A request send date answers:
When should the client receive the request?
The client due date answers:
By when is the client being asked to provide the item?
The internal review target answers:
When does the team plan to review what arrived?
If those values are stored in one field named due_date, the interface cannot explain why the date matters or who is expected to act.
A source-report item needs enough structure to preserve the distinction:
{
"source_system": "Payment processor",
"report_type": "Settlement and fee report",
"bookkeeping_period": "2026-06",
"expected_availability_date": "2026-07-08",
"request_send_date": "2026-07-08",
"client_due_date": "2026-07-10",
"internal_review_target": "2026-07-11"
}
These dates are illustrative, not a universal schedule.
The useful part is that the application no longer needs to guess what one generic date means.
“Not yet expected” is not the same as “waiting on client”
Before the expected availability date, the report may simply not be ready.
That condition should not automatically become a client-facing workflow status.
I would treat it as a planning note:
Situation: Report not yet expected
Client reminder: No
Next action: Wait until the planned availability check
Once the report should normally be available and the client has been asked to provide it, the requested item can enter the collection workflow:
Should be available, no upload
→ Waiting on client
→ Next owner: Client
After the upload arrives:
Uploaded
→ Pending review
→ Next owner: Staff
After staff accepts it:
Accepted after review
→ Received
If staff finds the wrong period, an incomplete export, or another problem:
Replacement required
→ Needs reupload
→ Next owner: Client
The planning calendar and the request workflow work together, but they should not use the same labels for different facts.
“Not yet expected” describes timing.
“Waiting on client” describes an action the client currently owes.
Without that boundary, the client can receive an overdue reminder for a report that has not been generated, while an uploaded report waiting for staff review can trigger another unnecessary upload request.
The earliest date should not always receive the most attention
A calendar interface often emphasizes whichever date comes next.
That can be misleading when the dates belong to different roles.
Imagine three June reports:
| Source report | Expected availability | Client due | Review target |
|---|---|---|---|
| Bank statement | July 2 | July 5 | July 6 |
| Payroll report | July 5 | July 7 | July 8 |
| Processor settlement report | July 8 | July 10 | July 11 |
On July 4:
- The bank statement may require client action.
- The payroll report may still be waiting for its final source event.
- The processor report may not be expected yet.
Showing all three under one red “missing documents” count would hide those differences.
The more useful priority order is:
- Is the report expected to exist yet?
- Has the firm sent the request?
- Does the client currently owe an upload?
- Has a file arrived?
- Is the file waiting for staff review?
- Does staff need a replacement?
- Who owns the next action?
This does not require a complicated calendar interface.
A small timing label and a clear next-owner field can prevent a planning estimate from being mistaken for a client failure.
A fixed monthly request date is a choice, not a default truth
Using one request date for every source can be the right operational decision.
A client may reliably gather several reports at once. The firm may prefer one monthly request because it is easier for the client and the team to manage.
The problem begins when the interface presents that pattern as universally correct.
Different reports may follow different source events:
- A bank statement may appear after the statement period closes.
- A payroll report may be useful only after the final payroll run for the period.
- A processor settlement report may follow the relevant payout cycle.
- A sales export may need an exact custom date range after the reporting period ends.
The firm may choose one of several patterns:
- one fixed monthly request date
- source-specific request timing
- a hybrid approach with source-specific dates and one final firm cutoff
- a monthly batch or rolling weekly requests
The product does not need to decide which pattern is best.
It needs to make the selected pattern visible and keep each report’s timing attached to the requested item.
That is why one client-period calendar can contain multiple source reports without forcing them onto one identical schedule.
Put the next owner beside the timing information
A date without ownership creates another ambiguity.
Suppose the client uploaded the payroll report yesterday, and the internal review target is today.
The item is not waiting on the client.
It is:
Status: Pending review
Next owner: Staff
If the report was expected yesterday but has not been uploaded:
Status: Waiting on client
Next owner: Client
If a third-party provider has delayed the report, the firm may need planning fields such as:
- responsible contact or provider
- last checked
- current blocker
- next follow-up date
- next action owner
That does not require inventing a new native status for every operational exception.
The workflow status can remain narrow while the planning context explains what the team should do next.
This was the boundary I used in the bookkeeping source report availability calendar template.
The calendar plans when the firm expects to ask.
The request workflow records what happened after the request opened.
Neither one automatically monitors a bank portal, payroll provider, processor, or sales platform.
An overdue label needs two facts
Before marking a source report overdue, the interface should be able to support at least two claims:
- The report should normally be available under the firm’s current plan.
- The client has been asked to provide it and has not done so by the requested deadline.
If the first claim is missing, the reminder may be premature.
If the client already uploaded the file, the next action may belong to staff instead.
If staff rejected it, the next client action is a replacement request, not the original generic reminder.
A useful availability calendar does not make every report arrive on the same day.
It keeps the dates separate enough that the application can tell the difference between waiting for the source, waiting for the client, and waiting for the team.
Top comments (0)