The Upload Finished. The Document Request Didn’t.

A property-management document request showed why file arrival, staff review, completion, and replacement need separate item states.

A client uploads a PDF.

The upload request returns successfully. The filename appears in the interface. The file is attached to the right request.

It would be easy to mark that item complete.

But the PDF might be for a different property.

Or the right property and the wrong bookkeeping period.

Or it might be unreadable. It could be an owner statement attached to an item that asked for a security-deposit ledger.

The file arrived. The bookkeeping team still has a decision to make.

That was the reason I kept Uploaded / Pending review separate from Received while structuring a property-management document request.

File arrival is only one event

The request I was working through can contain several kinds of records for the same client and period:

• an owner statement;
• property expense invoices;
• a security-deposit ledger;
• a deposit account statement;
• reserve support;
• another named property-level source record.

Those records do not become equally useful just because they have files attached.

For each requested item, staff still need to check what arrived against the context already attached to the request: the property or portfolio, bookkeeping period, source, and the specific record being requested.

So I ended up with a deliberately plain progression:

Waiting on client
      ↓
Uploaded / Pending review
      ↓
   Received

And there needs to be another path:

Uploaded / Pending review
      ↓
  Needs reupload

This is a conceptual state model, not production code. What matters is that the successful upload sits in the middle rather than at the end.

“Received” belongs to the review result

There is a small wording problem here that changes the behavior of the whole request.

If the interface marks an item Received as soon as storage accepts a file, the status is reporting a technical event.

But a bookkeeping firm usually needs the status to report something more useful: whether staff have reviewed the uploaded record sufficiently to resolve that requested item.

That is why I prefer the intermediate label.

Uploaded / Pending review says exactly what the application knows at that point. Something arrived, but staff have not recorded the review result yet.

Only after reviewing the item, period, source, and readable context should that item move to Received.

I used the same distinction in the property-management owner statement and security deposit checklist, where owner-statement records, deposit support, reserve records, and property expenses can remain independently reviewable.

It adds another visible state, but it removes a more expensive ambiguity: whether “complete” means “a file exists” or “the requested evidence was actually reviewed.”

The state needs to live on the item

A property-management request makes this especially obvious because one request can contain several unrelated review outcomes at the same time.

Imagine a request containing:

• one owner statement;
• two property expense invoices;
• one security-deposit ledger;
• one reserve report.

The owner statement may be reviewed and accepted.

The deposit ledger may have arrived but still be waiting for staff review.

One invoice may not have arrived at all.

The reserve report may be for the wrong property.

There is no useful single status that describes all four situations.

The request can have an overall progress indicator, but the actionable state has to stay attached to each requested record.

Otherwise a single accepted file can make the whole request look healthier than it is, or one bad file can make unrelated records appear blocked.

This also changes how follow-up works. “Still waiting” should point to the missing invoice, not to every document in the request.

Reupload should be a narrow action

The same item-level rule matters when something is wrong.

Suppose the client uploads a reserve report for Property B into the requested item for Property A.

The useful action is not:

Please upload all property-management documents again.

The useful action is to mark that reserve-report item Needs reupload and ask for a replacement there.

The owner statement that has already been reviewed can remain Received. The deposit ledger can remain Pending review. The missing invoice can remain Waiting on client.

Each status continues to describe its own unresolved action.

That may sound like a small modeling decision, but it affects the client experience too. A broad reupload request makes people repeat work they already completed. A narrow replacement request tells them exactly which file needs attention.

It also keeps the staff side easier to read. A reviewer can see whether the next action belongs to the client or to the firm instead of treating every incomplete item as the same kind of problem.

Status should stop before judgment

There was another boundary I wanted to keep out of these states.

A security-deposit ledger becoming Received does not mean the software has decided whether the deposit was handled legally.

Receiving an owner statement does not determine whether an owner payout is correct.

A reserve report does not tell the application whether reserves are sufficient.

Those are different questions.

The request system can record something much narrower:

• which property the item belongs to;
• which period it covers;
• which source record was requested;
• whether something has been uploaded;
• whether staff reviewed it;
• whether that item needs replacement.

That is enough to make the collection process useful without turning a document status into an accounting or legal conclusion.

For me, that is the useful limit of the state machine.

A successful upload should change what staff do next.

It should not pretend the review has already happened.