How often do closing dates slip after a condition is cleared?

A cleared condition feels like progress. The document is accepted, the reviewer closes the item, and the file moves to the next stage. Yet a closing date can still move after that moment because of a title issue, a funding delay, or a new lender requirement. The borrower sees the date change and may not understand why the file looked complete.

This study measures how often a closing date moves after a condition is cleared. It separates the clearance event from the closing promise so the team can see whether clearance is a reliable milestone. The result is a rate with a cause breakdown, not a judgment about any one processor. It helps operations leaders decide where to add checks and where to stop adding them.

Question and scope

The question is what share of files with a cleared condition experience a later closing date change. The scope names the team, the loan types, the closing stages, and the period. A team might study files that closed or were canceled during a twelve-week window. The result applies to that setting and should be reported with it.

Define the closing date as the date communicated to the borrower and recorded in the system. Use one source for the date, such as the loan origination system field or the closing calendar. A date that exists only in an email is hard to measure and easy to dispute. The source should be named in the protocol.

Define the clearance event as the moment a reviewer marks a condition complete in the system. The event needs a timestamp and a reviewer identity. A verbal clearance or a note that says "looks good" is not enough for measurement. The protocol should require a system record so the before and after can be compared.

Why clearances are a useful milestone

Clearance is a meaningful milestone because it represents a decision by a reviewer. The team has checked the document against the requirement and accepted it. If dates often move after that point, the clearance may not mean what the team thinks it means. The measure tests whether the milestone is trustworthy.

The milestone is also a natural handoff point. Work often moves from document review to closing coordination after clearance. A slip after that point may point to a handoff problem rather than a review problem. That distinction is useful because the fix is different.

Not every post-clearance slip is a failure. A borrower may change the closing date for a personal reason, or a seller may need more time. The study should include these causes so the rate is not presented as entirely preventable. A credible rate separates controllable causes from external ones.

Defining a post-clearance slip

A post-clearance slip occurs when the promised closing date moves to a later date after at least one condition was cleared. The move must be recorded in the system or the closing calendar. A change in time on the same day is not a slip unless it crosses a business boundary that affects the borrower. The recorded time should include the date the borrower was told about the change.

Count only the first move after clearance for the headline rate. Later moves can be tracked as a secondary measure. Counting every move would make one file look like several failures and distort the rate. The first move is the clearest signal that the promise did not hold.

Record the number of days between the clearance and the move. A move two days after clearance is different from a move thirty days after clearance. The timing helps the team see whether the issue is a closing-week problem or a long-tail problem. Report the median and the range, not only an average.

Building the cause categories

Use a small set of causes that reviewers can apply consistently. A practical set includes title, appraisal, borrower documents, lender review, funding, and external scheduling. Add a category for unknown only when the evidence is insufficient. Too many categories produce inconsistent coding and a weak comparison.

Define each cause in one sentence. Title means a title commitment issue or a missing payoff. Appraisal means a value or repair issue that affects closing. Lender review means the lender has not issued a clear to close or has added a condition. The definitions should be visible during coding.

Pilot the categories on ten files before the main sample. Ask two reviewers to code the same files and compare. If they disagree, rewrite the definition or add an example. A category that requires a meeting every time will not survive a busy week.

Sampling files and clearance events

Sample files, then identify the clearance events within each file. A file-based sample is easier to draw from the closing calendar and avoids over-weighting files with many conditions. The sample should cover different loan types, lenders, and processors. A sample from one queue will not represent the team.

Use consecutive weeks to avoid seasonal bias. A month-end or a holiday week may behave differently from a quiet week. If the team cannot cover every day, use a rotating schedule that includes each weekday. Record the period and the sample size in the report.

Include files that were canceled after clearance, but separate them from files that closed. A canceled file may have a closing date change for reasons that are not comparable to a closed file. The report should show both groups. Combining them can make the rate look better or worse than the team's actual closing experience.

Coding and agreement

Have a second reviewer code a subsample without seeing the first coder's choice. Compare the results and report agreement by cause. A low agreement on a category means the definition is still ambiguous. Keep the examples that caused disagreement and use them in training.

Resolve disagreements with a written rule. For example, decide whether a borrower's request to move a closing for a vacation counts as an external scheduling cause or a borrower cause. Write the answer in the protocol and apply it to the rest of the sample. Apply the rule to the next ten files and check agreement again.

Do not change the definition mid-sample without marking the change. A mid-study change can make the rate move for reasons unrelated to the work. If the team must change a rule, start a new segment and report both segments separately. Report the first segment as the baseline.

Reporting the rate

Report the rate as a range with the sample size, the period, and the scope. Show the median across files and the spread across weeks. A rate that moves from ten percent to thirty percent across weeks may reflect a change in the review process rather than a change in accuracy. A range is more honest than a single decimal.

Break the rate down by cause and by the number of days after clearance. A high share of title causes may point to a closing coordination step. A high share of lender review causes may point to an incomplete submission. The breakdown is more actionable than the total.

Pair the rate with the notice given to the borrower. A slip with five days of notice is a different service event from a slip with one day. The report should show the share of slips with less than two business days of notice. That measure captures the borrower impact better than the raw rate.

What the result can change

A high post-clearance slip rate does not automatically justify more staff. It may justify a closing checklist, a title follow-up, or a clearer definition of cleared. The study should list the changes that could reduce the rate before it recommends additional capacity. The team should separate a process problem from a volume problem.

The mortgage operations support team can test one change on a small group and rerun the protocol. A closing checklist for title and funding is easy to test because the team can compare slips before and after. The test should run long enough to cover a normal closing cycle. Keep the test group small enough that the rest of the team can continue the normal work.

If the rate stays high after the change, the team may have a genuine capacity gap or an external dependency problem. The loan processing support lead can review the handoff path and the closing calendar. The result should distinguish a process defect from a workload problem. A measure that leads to the wrong fix is worse than no measure.

Limits and sources of error

The study measures recorded slips, not every slip. A date changed in a phone call and never entered in the system is invisible. A borrower who does not notice the change may not create a record. The result is a lower bound on the true rate in many teams.

Recall and attribution can bias the coding. A reviewer who remembers the file may assign a cause that fits the outcome rather than the evidence. Use the system history, the closing calendar, and the borrower messages to check the cause. When the evidence is insufficient, code the event as unknown rather than guessing.

The sample may miss files that were canceled before closing. Those files can have valuable evidence about why a promise failed. Add a short review of canceled files each quarter. The review should focus on the cause and the notice given, not on assigning blame.

Review cadence

Repeat the study after a change to the closing checklist, the clearance definition, or the lender mix. Use the same categories and the same sampling rule so the comparison is meaningful. A rate that falls while borrower complaints rise may mean the team is moving dates earlier, not communicating better. A comparison across different definitions is not valid, so freeze the codebook before the second round.

Share the result with the people who recorded the events. Ask which causes were hardest to code and which slips felt avoidable. The discussion can reveal a handoff that nobody owns or a closing step that starts too late. The next study should test one of those findings.

End with a single sentence that states the rate, the period, and the main cause the team can affect. A precise finding with a named owner is more useful than a long report. The goal is a closing date that holds after the file looks complete. The sentence should name the change the team can make, not a cause outside its control.