I Didn't Want “Not Applicable” to Be a Client-Controlled Final State

Letting clients mark a requested document as not applicable sounds simple, but I found it works better when that choice stays reviewable instead of final.

A client clicks “not applicable this period” on a requested item.

That feels like the end of the story until you ask a second question:

Who gets to decide that?

While working through a document review flow, I realized that Not applicable looked like a normal status on the surface, but it actually hides two different events.

The client can say, “I don't think this document applies this month.”

The bookkeeping team can decide, “Yes, we agree, and this item no longer needs follow-up.”

Those are not the same action. Treating them as the same state would make the request look more resolved than it really is.

I needed one status for the request and another for the decision

My first instinct was to keep the list small:

Waiting on client
Pending review
Received
Needs reupload
Not applicable

That seemed tidy.

The problem showed up as soon as I thought through the client-facing side. If the upload page lets a client mark an item as not applicable, the system now has a statement from the client, not a confirmed team decision.

For example, a payroll report might truly be unnecessary for one month. But it could also be a misunderstanding, the wrong period, or a case where the team still wants supporting context.

If I immediately convert that click into final Not applicable, the request can quietly stop asking for something the team never actually agreed to waive.

So I started treating the action as a reviewable claim, not a finished outcome.

That is why the review flow behind the document review page works better to me when not applicable stays inside the same review logic as uploads and reuploads.

“No file” can still be something the team has to review

File review is easy to picture when a PDF arrives.

A staff member opens the item, checks whether it is the right client, the right month, and the right document, then accepts it or asks for a reupload.

But the same review discipline matters when no file arrives and the client is effectively saying, “This item should not be required.”

That decision still affects close work.

If the team accepts it too quickly, the request may appear complete when something important is actually missing.

If the team has no structured way to review it, the decision will happen in scattered replies, side notes, or memory.

So I found it useful to think about Not applicable as part of the review queue rather than as a shortcut out of it.

The item may not contain a file, but it still contains a decision that somebody on the team should own.

The review action should be explicit

Once I separated the client's claim from the team's decision, the review controls got clearer too.

The meaningful staff actions were no longer just about files. They became item-level decisions such as:

Accept file
Reject and request reupload
Mark as received from email or Drive
Approve not applicable
Keep pending review

That last one matters more than it first appears.

Not every ambiguous item needs to be forced into a yes-or-no decision immediately. Sometimes the right first move is to leave it pending until someone confirms whether the exception is legitimate.

I like that better than overloading one status with too much meaning.

If the client has requested not applicable but the team has not approved it yet, the product should still show that the item is unresolved. It should not disappear into a completed-looking state.

This also keeps reminders honest

I keep running into the same pattern in small workflow products:

a label doesn't just describe reality — it changes what the system does next.

If Not applicable becomes final too early, reminders stop.

That sounds efficient, but it can suppress the wrong follow-up.

The safer logic is:

• a client can request an exception
• the item stays reviewable
• the team decides whether the exception is valid
• only then does the item become truly resolved

That way, reminder behavior follows a reviewed decision instead of a client-side guess.

This is also more consistent with the rest of the review flow. An uploaded file is not automatically Received just because a file exists. In the same way, a client-marked exception should not automatically become accepted just because someone clicked it.

Both are inputs.

Neither should pretend to be the final accounting judgment.

I would rather keep the friction here

In an MVP, I usually want less process, not more.

But this is one place where a small amount of extra friction feels worth keeping.

If the product is meant to help a bookkeeping team understand what is really ready for close, it cannot treat every client-side action as self-validating.

A client can upload the wrong file.

A client can say something does not apply when it still needs a quick team check.

The product does not need a giant approval engine to handle that well.

It just needs to avoid collapsing client input and team acceptance into the same state.

That was the line I wanted the review flow to hold.

Not applicable can be a valid outcome.

I just don't want it to become true before the team agrees that it is.