A Due Date Isn’t Enough to Decide Whether a Reminder Should Send

I tied reminder eligibility to the current item status and next-action owner so clients are not chased for files the bookkeeping team already has.

The request row already had a due date.

I still could not tell whether a reminder was allowed to send.

That became obvious once I separated two situations that can share the same client, bookkeeping period, requested document, and overdue date:

• the client still has not uploaded the file;
• the client uploaded it, but staff have not reviewed it yet.

In both cases, the request may still look incomplete.

Only one of them needs another message to the client.

That made the reminder logic less about the calendar and more about who owns the next action.

The due date describes timing, not responsibility

A document tracker can hold useful scheduling fields:

• date requested;
• due date;
• next reminder date.

Those fields tell me when something was expected and when another follow-up might be considered.

They do not tell me who needs to act.

Take a bank statement request.

Before upload, it might look like this:

Current status: Waiting on client
Client action: Upload bank statement
Next action: Client upload

After the client uploads the PDF:

Current status: Uploaded / Pending review
Client action: None
Next action: Staff review

The due date did not change.

The person who owes the next action did.

If a reminder process looks only at due_date <= today, both records can appear eligible for follow-up even though the second client has already done what was requested.

“Pending review” needs to stop the client reminder

This is one reason I did not want Uploaded to mean Received.

When a file arrives, there is still useful work left for the bookkeeping team. Staff may need to check that it is the requested document, that it covers the correct period, and that it can be accepted or needs replacement.

So the tracker keeps an intermediate result:

Uploaded / Pending review

At that point, the file exists and staff own the next action.

That should affect the reminder path immediately.

The conceptual rule I wanted the tracker to support is closer to this:

if next_action_owner != "client":
    do_not_send_client_reminder

That is not production code. It is the boundary the data needs to make possible.

A next reminder date can schedule when to reconsider a follow-up, but it should not override the fact that the client is no longer the person blocking progress.

The reminder needs the item, not just the request

The problem becomes harder when one request contains several requested documents.

Imagine one July bookkeeping request with four items:

Operating bank statement
Received

Business credit card statement
Uploaded / Pending review

Payroll report
Waiting on client

Merchant report
Needs reupload

A single request-level label like Incomplete is not enough to decide what message to send.

The payroll report still needs an initial upload.

The merchant report needs a specific replacement.

The credit card statement needs staff attention, not another client reminder.

The operating bank statement needs neither.

That is why I kept the request context and item-level tracking together in the document request tracker for bookkeeping firms.

The client, period, due date, and request owner provide the surrounding context. Each requested item still needs its own current status, client action, review outcome, next reminder, and next action.

The reminder mechanism can then respond to the actual unresolved item instead of treating the whole request as one binary missing/not-missing record.

A rejection should change the message, not create a new item

Needs reupload creates another reminder case.

The client does need to act again, but the action is different from the original request.

The message should not behave as though nothing was ever uploaded.

Something arrived. Staff reviewed it. A specific problem was found. Now the affected item needs a replacement.

Keeping that history on the same requested item makes the next action easier to describe:

Requested item: Merchant report
Review outcome: Needs reupload
Client action: Provide replacement
Next action owner: Client

If rejection creates a fresh duplicate item instead, the reminder layer has to work out which request is current, which one was rejected, and whether both should still generate follow-up.

I would rather keep the replacement attached to the item that produced it.

Then Needs reupload can remain a client-owned action without pretending the original upload never happened.

The tracker is part of the reminder system

I initially thought of a document tracker as a reporting surface: something staff open to see what is missing.

But once reminders depend on it, the tracker becomes input to another part of the product.

Waiting on client means a follow-up may still be appropriate.

Uploaded / Pending review hands the work to staff.

Received closes that requested item from the client side.

Needs reupload gives the client a new, specific action.

Not applicable removes the item from the collection path for that period.

Those labels are not just useful colors for a table. They determine who should be interrupted next.

A reminder date can tell the system when to look again.

The current item and its next-action owner have to tell it who, if anyone, should hear from the product.