Table of contents
Borrowers notice duplicate requests faster than teams expect. A processor asks for a bank statement, a loan officer asks for the same statement a day later, and the borrower concludes that nobody is reading the file. The extra request costs trust and creates another document to review. A condition counter gives the team one place to see what has been asked, by whom, and whether it has arrived.
The counter is not a new software purchase. It is a simple rule for naming, numbering, and closing conditions in the system the team already uses. It works best when the loan officer, processor, and borrower communication all reference the same condition number. This guide explains how to build the counter and keep it accurate during busy weeks.
Treat one condition as one request
Define a condition as one specific item that clears one underwriting requirement. A request for two months of bank statements for one account is one condition. A request for statements from two different accounts may be two conditions if each supports a separate asset. The definition should follow the lender's condition list rather than the team's convenience.
Number each condition when it enters the file. Use a stable format such as the loan number plus a sequence, and never reuse a number after a condition is cleared. Reusing a number makes the history confusing and can cause a cleared condition to look open. The number should appear in the system note, the borrower request, and any internal handoff.
Map each condition to the document that clears it
Every condition needs a clear acceptance rule. The rule names the document, the date range, the account or property, and any required pages. A condition without an acceptance rule becomes a debate at review time. A reviewer who has to interpret the request may reject a document that another reviewer would accept.
Store the acceptance rule beside the condition number. The rule can be a short note in the system or a line in the team's checklist. It should be specific enough that a backup processor can review the document without calling the primary owner. A rule that lives only in one person's memory is not a control.
Update the rule when the lender changes a requirement. A stale rule produces false rejections and repeat requests. Assign an owner to review the rules after any guideline update or lender notice. Record the review date so the team knows which version was used.
Show the borrower one running list
Borrowers should see a single list of open conditions with a status for each. The list can be a secure portal view, a written summary, or a structured email. It should show what is open, what has been received, and what is still needed. It should not show internal underwriting comments or speculation about approval.
Use the same condition numbers in every message. A borrower who sees "condition 3" in an email and "asset statement" in a portal may not connect the two. Consistent numbering reduces confusion and makes a follow-up call shorter. It also gives the borrower a way to ask about a specific item without re-explaining the whole file.
Update the counter when a document arrives
Create one intake step that checks every incoming document against the open condition list. The step records the date, the condition number, and the reviewer. If the document matches an open condition, the reviewer marks it received and begins the acceptance check. If it does not match, the reviewer routes it to the right condition or returns it with a clear reason.
Do not let a document sit in a general inbox without a condition link. An unlinked document is invisible to the counter and likely to trigger another request. The intake step should be part of the daily routine, not a weekly cleanup. A same-day link prevents most duplicate requests.
Escalate conditions that conflict
Sometimes two conditions ask for overlapping documents or give conflicting instructions. A borrower may be asked for a full statement and a specific page from the same statement. The counter should flag the overlap before both requests reach the borrower. The processor can then combine them into one clear request.
Give the processor authority to merge duplicate requests and close the extra condition with a note. The note should explain which condition remains open and why. This prevents a reviewer from reopening the duplicate later. The authority should come with a rule, not depend on individual confidence.
Escalate a conflict that involves underwriting judgment to the underwriter or the operations lead. The processor should not decide which of two lender requirements controls. The escalation should include both condition numbers, the documents requested, and the borrower impact. A quick decision protects the borrower from a confusing message.
Audit the counter every week
Sample a small number of files each week and compare the counter with the borrower messages. Check whether every open condition has one clear request and whether every received document is linked. Look for conditions that were cleared but still appear on the borrower list. A simple five-file sample can reveal a template or handoff problem.
Track duplicate requests as a separate measure. Count a duplicate when the borrower receives two requests for the same condition without a new reason. The count should include requests sent through different channels. A low count with a high volume of borrower questions may mean the messages are unclear rather than duplicated.
Review the results with the intake and processing teams. Choose one fix, such as a revised template or a daily document link step. Assign an owner and a review date. The counter should improve through small changes, not a complete rebuild every month.
Protect the borrower from request fatigue
A borrower who receives too many requests may stop responding or send incomplete documents. Set a rule that no new request goes out without a check against the open list. The check takes seconds and prevents most duplicate messages. It also gives the team a chance to combine requests into one clear ask.
Use a single channel for borrower document requests when the lender allows it. A request split across email, text, and portal notifications is hard for the borrower to track. If multiple channels are necessary, send one summary that names the channel for each item. The borrower should never have to reconcile three lists.
Close the loop when a condition is cleared. A short confirmation tells the borrower that the item is complete and no further action is needed. This message is especially important after a rejection or a second request. It reduces the chance that the borrower sends another copy out of uncertainty.
The Consumer Financial Protection Bureau's mortgage servicing resources describe clear communication as part of a fair borrower experience. A condition counter supports that goal by making requests specific and consistent. The borrower communication support team can own the list while processing keeps the acceptance decisions. Connect it to the loan processing support workflow so every document lands against a numbered condition.