How much rework comes from lender-specific checklist differences?

Two files can look identical at intake and follow different checklists because they are going to different lenders. The processor learns the difference through a correction, and the file returns to the queue. Measuring that rework shows whether the team needs better references or a simpler standard. A study that separates the difference from the error gives the team a clearer place to invest.

Question and scope

The study asks how much rework comes from differences in lender-specific checklists. Scope names the lenders, the loan programs, the stages, and the period. It also names the team's standard checklist and the version used during the sample. A study without a standard cannot separate a lender difference from a team error.

Define rework as work that repeats a step because the first attempt did not meet the requirement. The repeat may be a corrected field, a new document request, or a second review. A file that simply waits for a borrower is not rework. The codebook should give examples of each.

Decide whether to count rework events or rework hours. Events are easier to count, while hours show the capacity cost. Report both when the team records time. A high event count with a low hour total may be less urgent than a low event count with a high hour total.

Define the checklist difference

A checklist difference exists when a lender requires a step, document, or field that the team's standard checklist does not include, or requires it in a different form. The difference can be a lender overlay, a program rule, or a proprietary form. The study should record the source of the requirement. The source field is important because a requirement without a source is hard to defend when the file is reviewed.

Separate a difference from an error. A processor who misses a step that is already on the standard checklist has made an error. A processor who follows the standard checklist and later learns that the lender requires an extra step has encountered a difference. The two causes need different fixes.

Record whether the difference was known before the file started. A known difference should be in the lender reference, while an unknown difference may require a guide update. The study should show the share of differences that were known and the share that were discovered during the file. The second share is a measure of reference quality.

Build the lender crosswalk

Create a table with the standard step, the lender-specific requirement, the evidence, and the source. Mark whether the difference is additive, substitutive, or formatting. An additive difference adds a step, a substitutive difference replaces a step, and a formatting difference changes how the evidence is presented. The version date lets the team see whether the rework happened before or after a guide update.

Review the crosswalk with a processor and a reviewer. Ask them to identify a difference that is missing or mislabeled. The crosswalk should reflect the work as it is done, not only the guide as it is written. A difference that exists only in practice still causes rework.

Keep the crosswalk versioned. A lender can change a requirement without notice, and an old crosswalk can create a new error. Record the date of the source and the date the team last verified it. The review date is part of the evidence.

Sample the rework

Select files that had at least one rework event during the window. Include files from each lender and each active program. If the volume is high, use a random sample and record the selection rule. If the volume is low, review all rework files and state that the sample is a census.

For each event, record the file key, the lender, the step, the cause, the time spent, and the owner who corrected it. Do not include borrower identifiers. The event record should be specific enough that a second reviewer can classify it without asking the processor. The event record should also note whether the correction was caught internally or by the lender.

Include a comparison group of files with no rework. The comparison shows whether the rework files share a lender, a program, or a step. Without the comparison, the team may attribute a general problem to the checklist. The group should be selected from the same period and lender mix.

Code the cause

Use a short codebook: lender difference, team error, borrower document, system issue, and unknown. A lender difference requires evidence that the requirement was not on the standard checklist. A team error requires evidence that the requirement was available and missed. The codes should be mutually exclusive.

Have a second reviewer code a subsample. Compare the results and discuss the disagreements. A disagreement between lender difference and team error may mean the reference was hard to find. That is a finding about the reference, not only about the coder. Keep the examples.

Do not use the code to assign blame. The purpose is to decide whether to invest in a better crosswalk, a clearer standard, or more training. A blame-oriented review will produce defensible codes but poor information. The team should know the purpose before the sample starts.

Analyze the result

Report the share of rework events attributed to lender differences and the share attributed to team errors. Show the hours for each cause and the lenders with the highest difference rate. A lender with many differences may need a dedicated reference, while a lender with many team errors may need training. The hours show the capacity cost, while the event share shows how often the issue appears.

Compare the rework rate with the file volume for each lender. A low-volume lender with a high rework rate can consume more support time than its file count suggests. The report should show both numbers so the reader can prioritize. A simple count can hide a costly tail.

Look at the steps that produce the most rework. A formatting difference may be fixed with a template, while an additive difference may need a checklist branch. The step view turns the result into a specific change. The mortgage operations support lead can assign the change to the person who maintains the lender reference.

Report the result

Open with the number of rework events, the share attributed to checklist differences, and the hours. Show the top three lenders and the top three steps. Add a short example of a difference and the correction it caused. Remove borrower details from the example.

Add a section on the differences that were known before the file started. A high share of known differences may mean the team needs a better way to surface the reference at the point of work. A high share of unknown differences may mean the guide review is out of date. A reference that is hard to find at the point of work behaves like a missing reference even when it exists.

End with one change and a review date. The change might be a lender-specific tab in the checklist, a required field, or a monthly guide review. The review should use the same codes so the team can see whether the change reduced the rework. A report without a test is only a count.

Limits and sources of error

The study relies on the team's ability to recognize a checklist difference. A processor who has internalized a lender's requirement may not report it as a difference. Add a review of the lender guide and a sample of files to catch the hidden differences. The estimate will still be a lower bound.

The time spent on rework may be recorded after the fact. A processor may remember the correction but not the minutes. Use a short log at the time of the event when possible. If the time is estimated, label it as an estimate and report the range.

The sample may overrepresent lenders with strict review. A lender that returns every missing page will appear more often than a lender that accepts a correction later. The report should describe the review practice, not only the count. The reader needs to know how the rework was detected.

Review cadence

Repeat the study after a lender guide change, a new program launch, or a checklist redesign. Use the same event definition and the same lender mix. A share that falls while file volume rises may mean the reference improved, or it may mean the team is catching fewer errors. Report both movements.

The loan processing support team can review the top difference with the lender contact and ask whether a standard form is available. A small change at the source can remove a recurring rework event. The goal is a checklist that is specific where it must be and simple where it can be. A standard form from the lender can remove a difference that no amount of internal training can fix.

End with the difference that costs the most time and the owner who will fix the reference. A rework study is useful when it removes a repeat, not when it produces a longer list of causes. The owner should be the person who maintains the reference, not the processor who found the error. A short follow-up note after the test will show whether the reference change reached the people who work the files.