DEV Community

Miran
Miran

Posted on

The Accept Button Shouldn't Be the First Thing on a File Review Screen

#webdev #saas #product #buildinpublic

A file review screen should show the expected document, source, period, and coverage before asking staff to accept or reject the upload.

A bookkeeper reviews a July bank statement under a magnifier lamp with the expected source, account, period, and coverage visible before the Accept and Reupload actions

A bank statement is waiting for review. The PDF opens correctly, and the bottom of the screen has two obvious actions:

Accept

Request reupload

But the reviewer still needs one piece of context before choosing either one: What was this file supposed to prove?

If that information lives in an email, a client note, or another tab, the interface is asking for a decision without showing what the decision should be based on.

Completion criteria belong on the review screen, not just in the original request setup.

The action comes at the end of the review

Imagine the requested item is:

Operating bank statement
Period: July 2026
Account: ••4821
Enter fullscreen mode Exit fullscreen mode

The uploaded file is:

statement-july.pdf
Enter fullscreen mode Exit fullscreen mode

A plausible filename and a working PDF are not enough to accept the item. The reviewer still needs the criteria attached to the request:

Expected document:
Official bank statement

Expected source:
Operating account ••4821

Required period:
July 1-31, 2026

Coverage required:
Full stated period
Enter fullscreen mode Exit fullscreen mode

Those fields should appear before the decision controls become the dominant part of the page.

Without them, the Accept button invites a vague question:

Looks plausible. Is this probably fine?

The screen should ask something more specific:

Does this upload match the criteria attached to the requested item?

Put the expected evidence beside the file

The bookkeeping document request completion criteria template keeps several fields separate:

  • expected document or report
  • expected account, platform, or source
  • required period or date range
  • accepted file format
  • coverage required
  • completion evidence

That separation matters during review.

A PDF labeled July 2026 does not tell the reviewer whether the request was for a bank statement or a transaction export. A document from the correct bank may still belong to the wrong account. A first page dated July 1 does not show that the file covers the full period.

The uploaded file is one side of the comparison. The requested-item criteria are the other. Keeping both visible makes the review decision much easier to understand.

Partial coverage is where memory gets risky

A partial-period file is a useful test.

The request says:

Required period:
July 1-31
Enter fullscreen mode Exit fullscreen mode

The uploaded report covers:

July 1-15
Enter fullscreen mode Exit fullscreen mode

The file itself may be perfectly usable. It opens, the source is correct, the account may be correct, and the available dates may still be useful.

Whether it is enough depends on the criteria set by the responsible bookkeeping team.

That is why the review screen should not stop at:

File uploaded ✓
Enter fullscreen mode Exit fullscreen mode

or even:

Correct source ✓
Correct month ✓
Enter fullscreen mode Exit fullscreen mode

The required coverage needs to remain visible while the reviewer decides what to do. The item may stay Pending review, or the reviewer may request a replacement or additional coverage under the firm's process.

The product does not need to make that professional decision automatically. It needs to show the information the reviewer needs to make it.

Accepting one item should not close the whole request

The same distinction matters after a file is accepted.

Consider a monthly request with three items:

Operating statement
Received

Credit card statement
Waiting on client

Payroll summary
Pending review
Enter fullscreen mode Exit fullscreen mode

The operating statement is resolved, but the request is still open. A large request-level Completed state after the first acceptance would imply more progress than the underlying items support.

The completion-criteria page keeps the item decision separate from its effect on the full request. That gives the review screen a clearer sequence:

What item am I reviewing?

What evidence was expected?

What does this upload show?

What is the review result?

Who owns the next action?

Do other required items keep the request open?
Enter fullscreen mode Exit fullscreen mode

The Accept button still matters. It simply cannot answer all of those questions on its own.

Keep professional judgment with the reviewer

A bookkeeping team can define observable criteria for its request:

source identifiable
period identifiable
expected document present
stated coverage available
file ready for staff review
Enter fullscreen mode Exit fullscreen mode

That does not mean the document-request product should decide that the accounting is complete, financially accurate, reconciled, legally sufficient, or professionally acceptable.

CollectCue can keep the requested item, upload, review decision, replacement context, and next action connected. The responsible firm still decides what evidence its engagement requires.

The interface should show enough context to make the decision explicit without making the button seem smarter than the reviewer.

Show the criteria before asking for the decision

Accept and Request reupload should still be easy to reach. Hiding them would only add clicks.

The item context and expected evidence should appear first:

Operating statement
July 2026
Account ••4821

Expected:
Official statement
Full July coverage

Uploaded:
statement-july.pdf

Review:
[Accept] [Request reupload]
Enter fullscreen mode Exit fullscreen mode

Now the reviewer does not have to reconstruct the request from memory, and the buttons have a specific question attached to them.

First show what success was supposed to look like. Then ask whether the file meets it.

Top comments (0)