DEV Community

Miran
Miran

Posted on

A “Rejected” Badge Is Not a Next Action

#webdev #ux #saas #buildinpublic

I separated staff rejection categories from client-visible replacement instructions so a failed document review ends with one concrete upload request.

A bookkeeping file return station puts a July statement replacement instruction in front of a smaller internal note explaining that the uploaded June statement covered the wrong period
A client uploads a bank statement.

Staff reviews it and marks the file:

Rejected

Now imagine being the client.

What exactly should you do next?

Upload the same file again? Find a different month? Export a complete statement instead of a screenshot? Remove the password? Send the missing pages?

The word “Rejected” explains almost none of that.

While working through a bookkeeping file rejection flow, I started treating the staff review result and the client’s next action as two different pieces of information.

The first helps the team classify what went wrong.

The second helps the client fix it.

The internal reason is not the instruction

A compact reason category is useful on the staff side.

For example:

Review status: Needs reupload
Reason category: Wrong period
Enter fullscreen mode Exit fullscreen mode

That gives the reviewer a consistent way to record the outcome.

But if the client only sees:

Wrong period
Enter fullscreen mode Exit fullscreen mode

they still have to reconstruct the request.

Which period was requested?

Which document needs replacing?

Should they create a new request or use the existing one?

The client-facing information needs one more step:

Requested item: Operating account statement
Requested period: July 2026

Uploaded file: June statement

Replacement needed:
July 2026 statement for the operating account
Enter fullscreen mode Exit fullscreen mode

Now the review result produces an action.

The extra wording is not there to make the interface friendlier. It carries information that the reason category deliberately leaves out.

“Why it failed” and “what to send” can diverge

The distinction becomes clearer across different rejection reasons.

Consider an inaccessible file.

Internally, staff might record:

Reason: Cannot open
Enter fullscreen mode Exit fullscreen mode

The useful replacement instruction is closer to:

Upload an accessible copy that can be opened for review.
Enter fullscreen mode Exit fullscreen mode

For an incomplete statement:

Reason: Incomplete
Enter fullscreen mode Exit fullscreen mode

may become:

Upload the complete statement, including the missing transaction pages.
Enter fullscreen mode Exit fullscreen mode

For a file attached to the wrong requested item:

Reason: Wrong document
Enter fullscreen mode Exit fullscreen mode

may become:

Upload the payroll report through the Payroll Report item.
Enter fullscreen mode Exit fullscreen mode

The reason describes the review failure.

The replacement requirement describes the next successful state the client should aim for.

I kept both pieces visible in the bookkeeping file rejection and reupload checklist instead of forcing one field to do both jobs.

That also gives the UI a useful hierarchy.

Staff can see the category and specific issue while reviewing.

The client can see the exact replacement request after the decision has been made.

Keep the next action attached to the original item

There is another easy UI shortcut I wanted to avoid.

Once a file is rejected, the product could create a fresh requested item:

July bank statement — rejected
Enter fullscreen mode Exit fullscreen mode

then:

July bank statement — new request
Enter fullscreen mode Exit fullscreen mode

That produces two records for what is still one unresolved requirement.

I would rather keep the replacement action attached to the original requested item.

Conceptually:

Operating account statement
July 2026

Upload 1:
June statement
→ Needs reupload

Replacement needed:
July statement

Upload 2:
waiting on client
Enter fullscreen mode Exit fullscreen mode

The client does not have to determine which request is now current.

Staff does not have to reconcile duplicate request items later.

The rejected file remains useful context, but the unresolved requirement is still the same requirement.

This is especially helpful when the original problem is specific: wrong reporting period, missing pages, unreadable image, unsupported format, or conflicting versions.

The replacement instruction can stay next to the exact item that produced it.

A second upload should not erase the review step

There is a tempting interaction after the replacement arrives:

replacement uploaded
→ Received
Enter fullscreen mode Exit fullscreen mode

That would make the flow feel fast.

It would also skip the thing that caused the first rejection: staff review.

The new upload may still cover the wrong period.

It may still be incomplete.

A replacement for an unreadable receipt can still be too blurry.

If two versions conflicted before, the new file may still fail to make the current version clear.

So the arrival of a replacement should change the interface to another review state, not directly to completion.

The useful sequence is closer to:

Needs reupload
    ↓
Replacement uploaded
    ↓
Pending review
    ↓
Received
Enter fullscreen mode Exit fullscreen mode

That sequence is not about adding more statuses for their own sake.

It keeps the client action and the staff decision from collapsing into the same event.

Put the replacement instruction where the eye lands first

If I had to choose one thing to emphasize on the client-facing rejection screen, it would not be the word Rejected.

It would be the replacement requirement.

Something like:

Please upload:
July 2026 operating account statement
Enter fullscreen mode Exit fullscreen mode

Then, underneath:

Why:
The submitted file covers June 2026.
Enter fullscreen mode Exit fullscreen mode

The order matters.

The first line tells the client what can resolve the request.

The second line explains why they are being asked to do it.

Internal details such as reviewer, review date, reason category, and staff notes can still exist without competing for the same visual priority.

A rejection result is useful for the team.

A replacement instruction is useful for the person who has to act on it.

When those are presented as the same field, the client has to translate the bookkeeping team’s review language into their next upload.

I would rather make the interface do that translation.

Top comments (0)