Table of contents
A borrower uploads a bank statement, waits two days, and receives a one-line message that says the document was rejected. The borrower guesses what went wrong and uploads the same file again. The team reviews the same document, rejects it again, and the cycle consumes time on both sides. A clear rejection note breaks that cycle before the second upload.
The note is not a longer rejection message. It is a structured explanation that names the defect, shows what an acceptable version looks like, and tells the borrower what to do next. It also gives the processor a consistent record for the file. This guide explains how to write the note and how to tell a rejection apart from a new request.
Say what is wrong in plain language
Start with the specific problem, not a general conclusion. "The statement is missing page two" is useful, while "document not acceptable" is not. Name the document, the page, the date range, or the field that failed. The borrower should be able to look at the file and see the same issue.
Avoid internal codes and underwriting shorthand. A borrower does not know what a condition code or a guideline section means. If the system requires a code, keep it in the internal note and translate the reason into everyday words. The borrower message should stand on its own.
Show the acceptable version
Describe the document the team can accept. Include the account, the date range, the page count, and any required identifying information. If the lender requires a stamped or certified copy, say so. A borrower who knows the target is more likely to send the right file once.
Use an example without exposing another borrower's information. A simple line such as "all four pages, including the page with the account number" is often enough. If the team has a sample image, use a redacted version that shows the layout and the required details. Do not ask the borrower to guess from a generic checklist.
State the deadline or the next review time when one exists. A borrower who knows the team will review the new upload on the next business day can plan. Do not invent a deadline the team cannot meet. A clear review time is more useful than a pressure tactic.
Separate a rejection from a new request
A rejection means the document was received but does not meet the requirement. A new request means the team needs something that was never asked for. The two need different messages because the borrower's action is different. Mixing them makes the borrower think the first document was never received.
Label the message clearly as a correction of a received document. Reference the original upload date and the condition number. Then state the correction and the resubmission path. This keeps the history clean and prevents the borrower from resending unrelated documents.
If the review reveals a genuinely new requirement, send a separate request with its own condition number. Explain why the new item is needed and how it relates to the file. Do not hide a new request inside a rejection note because it will look like the goalposts moved. Separate messages are easier to track and easier to explain.
Give the borrower a way to ask
Include a named contact or a secure channel for questions. A borrower who is confused should not have to call a general line and repeat the whole file history. The contact should be able to see the rejection note and the original document. A short path to help reduces repeat uploads and frustration.
Set a rule for what the contact may explain. The contact can describe the document defect and the upload process. The contact should not interpret underwriting guidelines or promise that a corrected document will be accepted. Route those questions to the processor or loan officer.
Record the borrower's response in the file. If the borrower asks a question, note the answer and the date. If the borrower says the document does not exist, route the issue to the processor because it may require a different condition. The note should show the conversation, not just the rejection.
Track repeat rejection reasons
Count rejections by reason, such as missing page, unreadable scan, wrong date range, wrong account, or expired document. Review the counts weekly and look for the top reason. A high count for missing pages may mean the request did not specify the page count. A high count for unreadable scans may mean the upload instructions are unclear.
Separate borrower-caused repeats from team-caused repeats. A borrower who sends the wrong account after a clear request is a borrower issue. A borrower who sends the wrong account after a vague request is a team issue. The distinction matters because the fix is different. Do not blame the borrower for a request the team did not make clear.
Share the top reason with the intake team and update the request template. A small wording change can remove a large share of repeat uploads. Test the change on a sample of requests and compare the rejection rate. The goal is fewer cycles, not a longer rejection note.
Fix the request before blaming the borrower
Review the original request that led to the rejection. Did it name the document, the date range, and the page count? Did it explain how to upload and what to do if the document is unavailable? A request that omits those details is incomplete, even if the borrower should have known.
Ask a colleague who did not write the request to read it. If the colleague cannot state what is needed, the borrower probably cannot either. Rewrite the request and use it as the new template. This simple review catches more problems than a post-rejection scolding.
Update the condition library when a request repeatedly causes confusion. The library should contain the approved wording and the acceptance rule. A template that is easy to use will be used consistently. A template that requires judgment will be rewritten by each processor.
Review the note with the intake team
Bring two recent rejection notes to the next team meeting. Read them aloud and ask whether the borrower would know what to do. Look for jargon, missing details, and a vague next step. Rewrite one note together and save it as an example.
Check that the note fits the borrower's channel. A portal message may need a shorter format than an email. A text message may need a link to the upload page. The note should work in the channel where the borrower will read it. A well-written note that is hard to find does not help.
Set a monthly review of the rejection template and the top reasons. Assign an owner and a review date. Keep the template short enough that processors will use it during a busy day. The best template is the one that gets used, not the one that covers every possible case.
The Consumer Financial Protection Bureau's mortgage servicing resources emphasize clear borrower communication. A rejection note supports that principle when it is specific and actionable. The borrower communication support team can own the template while processing keeps the acceptance decision. Pair it with the condition counter so every rejection stays linked to one numbered condition.