What share of mortgage file rework traces to data entry errors?

Rework is the work a mortgage team does twice. A condition is cleared and then reopened, a disclosure is regenerated, or a closing package is rebuilt because a field was wrong. The team feels the cost in hours, but the file rarely records why the rework happened. Without a cause, the fix is usually another reminder.

This protocol traces rework events back to their causes, with a focus on data entry errors. It separates a typing mistake from a missing source document, a changed borrower fact, and a guideline change. The result is a share that a team can use to target training, system checks, or intake design. It is not a measure of individual performance.

Question and scope

The study asks what share of rework events traces to a data entry error. Scope names the team, the loan stages, the systems, and the period. A team might study files from application through closing during an eight-week window. The result applies to that setting and should be reported with the scope.

Define rework before collecting data. A rework event occurs when work that was marked complete must be redone after a reviewer identifies a defect. The definition should exclude a normal revision that follows new information, such as a borrower changing a closing date. The distinction matters because not every change is a defect.

Decide which systems count as the record. If the loan origination system is the source of truth, a correction in a spreadsheet is not a file rework event unless it changes the system. The protocol should name the systems and the evidence used. A broad definition will produce a large number that cannot be compared across teams.

Defining a data entry error

A data entry error is a mismatch between the value in the system and the value in the source document at the time of entry. The error may be a typo, a transposition, a wrong field, or a value copied from the wrong borrower. The key is that the correct value was available and the system value did not match it. A missing source document is a different cause.

Do not count a value that changed after entry as a data entry error. A borrower who updates an employer after the application is a legitimate change, even if the system value is now different. The protocol should record the date of the source document and the date of the change. A change after the source date belongs in a separate category.

Do not count a judgment call as a data entry error. If a processor classified a bonus as regular income and a reviewer later disagreed, the cause is a guideline interpretation, not a typo. The protocol should include an interpretation category so these events are not forced into the wrong bucket. A misclassified event weakens the whole study.

Building the cause categories

Use a small set of causes that the team can apply without a long debate. The set might include data entry, missing source, changed borrower fact, guideline interpretation, system import, and reviewer error. Add a category for unknown cause only when the evidence is genuinely insufficient. Too many categories produce inconsistent coding.

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

Keep the category list visible during the study. A printed card or a pinned note helps the reviewer choose the same way each time. The study measures the existing work, not a redesign. A category that changes daily cannot be compared across months.

Capturing the rework event

Record the date, the file, the stage, the system, the field, and the person who found the defect. Add the source document and the corrected value. The note should be specific enough that a second reviewer can verify the cause without asking the first reviewer. A note that says "fixed data" is not evidence.

Capture the time spent on the rework. The time can be a stopwatch entry, a calendar block, or a reasonable estimate recorded at the end of the task. Estimates are weaker than timers, but a consistent method is more important than perfect precision. Report the method with the result.

Record the downstream consequence when it is visible. A rework event may delay a disclosure, reopen a condition, or require a new borrower call. The consequence helps the team prioritize the causes that matter most. A small typo that never leaves the system is different from one that reaches a closing package.

Sampling files and events

Sample rework events rather than files. A file may have several rework events, and a file-based sample would overweight the files with many defects. Use the rework log as the sampling frame and select events across stages and processors. If the log is incomplete, note the gap before interpreting the result.

Use consecutive weeks to avoid seasonal bias. A closing week or a month end may produce more rework than a quiet week. If the team cannot cover every day, use a rotating schedule that includes each weekday at least once. Record the period and the sample size in the report.

Include events that were caught before they reached a borrower or a closing package. These near misses are still rework because the team had to redo the work. Excluding them would hide the value of the review process. The report can separate caught-before-release from caught-after-release as a secondary view.

Coding and agreement

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

Resolve disagreements with a written rule, not a private understanding. For example, decide whether a wrong middle initial that does not affect the legal name is a data entry error. Write the answer in the protocol and apply it to the rest of the sample. Apply the rule to the next ten events and check whether the coders still agree.

Do not change the definition in the middle of the sample without marking the change. A mid-study change can make the share 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.

Report the data entry share as a range with the sample size and the period. Show the median across reviewers and the spread between the highest and lowest week. A share that moves from fifteen 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 share down by field and by stage. A high share of name errors may point to an intake form, while a high share of asset errors may point to a statement review step. A high share late in the file may point to a handoff. The breakdown is more actionable than the total.

Pair the share with the time spent on rework. A cause that is common but cheap may matter less than a cause that is rare but expensive. The combination helps the team choose the first fix. A report with both a count and a cost is easier to act on.

What the number can change

A high data entry share does not automatically justify more staff or more training. It may justify a validation rule, a second check at a high-risk field, or a clearer source document. The study should list the changes that could reduce repeat errors before it recommends additional capacity. The team should separate a system problem from a knowledge problem.

The loan processing support team can test one change on a small group and rerun the protocol. A validation rule for the legal name is easy to test because the team can compare the name errors 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 share stays high after the change, the team may have a genuine capacity gap or a source document problem. The mortgage operations support lead can review the intake path and the review sequence. The result should distinguish a data problem from a workload problem. A measure that leads to the wrong fix is worse than no measure at all.

Limits and sources of error

The study measures recorded rework, not all rework. A correction that happens quietly in a spreadsheet may never appear in the log. A reviewer who fixes a field without recording the event is invisible to the study. The result is a lower bound on the true rework 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 source document and the system history to check the cause. When the evidence is insufficient, code the event as unknown rather than guessing.

The sample may miss work that happens outside the team's systems. A processor who asks a colleague to correct a value may not record it. Add a short end-of-day prompt that asks for unlogged corrections. The prompt improves coverage without turning the study into surveillance.

Review cadence

Repeat the study after a change to the intake form, the review checklist, or the loan origination system. Use the same categories and the same sampling rule so the comparison is meaningful. A share that falls while rework time rises may mean the team is catching fewer errors, not making fewer. A comparison across different categories is not valid, so freeze the codebook before the second round.

Share the result with the people who recorded the events. Ask which categories were hardest to apply and which corrections felt avoidable. The discussion can reveal a field that nobody trusts or a handoff that creates duplicate entry. The next study should test one of those findings.

End with a single sentence that states the share, the period, and the main field the team can fix. A precise finding with a named owner is more useful than a long report. The goal is a file that moves without being rebuilt. The sentence should name the change the team can make, not a cause outside its control.