On this page
A condition can look closed in the loan origination system while the evidence behind it has expired. The borrower's bank statement is three months old, the insurance declaration has a new policy number, or the payoff letter passed its expiration date. Someone has to correct the record without erasing what happened before. The safest approach is a dated note, a source comparison, and a deliberate decision about reopening.
Confirm the condition is actually stale
Start by reading the condition as it was written. The requirement may have a defined period, a version, or an expiration date that the current document no longer satisfies. If the condition says most recent statement, a statement from two months ago may be stale even though it was acceptable when received. The definition belongs in the condition text, not in the reviewer's memory.
Then check whether a newer document already exists somewhere else. A borrower may have uploaded a replacement to the portal that never reached the file. A vendor may have sent an updated report to a different queue. Search the portal, the shared inbox, and the vendor folder before concluding that the evidence is absent. Confirm that the evidence is truly missing or expired before marking the condition stale.
Read the last three touches
Open the activity history and read the last three entries. Look for who touched the condition, what they changed, and what they said the next step would be. A condition may be waiting on a borrower response that was logged in a note rather than in the status field. The history often explains why the record looks stuck.
If the history is empty or contains only system-generated entries, ask the person who last owned the file. A short conversation can prevent a duplicate request to the borrower. Record the answer in the file so the next reviewer does not have to repeat the search. The mortgage operations support checklist should include this history check before any reopen. A short document control reference can also tell the reviewer which version of the source is current.
Compare the source document to the system record
Put the source document and the system field side by side. Check the borrower name, the account number, the period covered, and the date received. A mismatch in any of those fields can make a valid document unusable. The comparison should be specific enough that a second reviewer can repeat it without guessing which detail mattered.
Do not correct the system field until the source is confirmed. A quick edit based on a message summary can create a second error that is harder to unwind. If the source is unclear, leave the condition open and route the question to the owner. The record should show what was checked and what remains uncertain.
Correct the record with a dated note
Write a note that states the old value, the new value, the source, and the reason for the change. Include the date, the time, and the person making the correction. Avoid deleting the earlier note, even when it was wrong. If the correction affects a reported field, note whether the report needs to be regenerated. The history should show the correction as an event, not pretend the earlier value never existed.
Use a consistent note format so the team can scan for the important parts. A short structure such as condition, source checked, finding, action, and next review date is enough. Add the name of the reviewer who approved the correction when one was required. The CFPB's Regulation X recordkeeping expectations reinforce the value of a clear trail, but the daily benefit is that a backup specialist can understand the change.
Decide whether to reopen the condition
Reopening is a decision, not an automatic reaction. Reopen when the current evidence no longer satisfies the requirement or when a new decision is needed. Keep the condition closed with a note when the document is still valid and only the system label was wrong. The distinction prevents the queue from filling with items that need no borrower action.
Record who made the reopen decision and why. If the condition affects pricing, eligibility, or a closing date, route it to the accountable reviewer before changing the status. A specialist can prepare the comparison and the note, but the decision to reopen a cleared condition belongs with the owner. Clear boundaries keep the correction from becoming an unauthorized approval.
Prevent the next stale condition
Add an expiration check to the recurring file review. For documents with a defined age, record the date the evidence will become stale and review the file before that date. A simple column in the condition tracker is enough, and a conditional format can flag the week it turns. The goal is to find the expiration before a closing deadline does.
Review the stale conditions monthly for patterns. If the same document type keeps expiring, the team may be requesting it too early or failing to collect a current version. Adjust the request timing and the checklist rather than asking reviewers to remember. A condition that is caught early is a routine update, while one found at closing is a crisis.
Keep a short log of corrections that required a reopen and the reason behind each one. Share the log with the processing lead so the team can see which document types cause the most rework. If the same borrower communication triggers repeated stale evidence, revise the request template to state the required date range. The log turns individual fixes into a change the whole team can use.