How much of mortgage data entry time goes to rekeying lender portals?

Mortgage data entry often happens in more than one place. The processor enters a borrower's information into the loan origination system, then enters much of the same information into a lender portal. The second entry may be required, but it is rarely measured. It looks like part of the job rather than a cost that could be reduced.

This study measures how much active data entry time goes to rekeying lender portals. It defines rekeying narrowly so the result does not count necessary verification or new information. The protocol uses a short time sample and a simple field map. The result helps a team decide whether to test an integration, a template, or a different order of work.

Question and scope

The question is what share of active data entry time is spent rekeying values that already exist in another system. The scope names the team, the loan stages, the portals, and the period. A team might study file setup and condition entry during a six-week window. The result applies to that setting and should be reported with it.

Define active data entry time as the time a person spends entering or correcting values in a system. Exclude time waiting for a page to load, reading a source document for the first time, or discussing a file. The study is about the entry work, not the whole processing task. A clear boundary keeps the study from turning into a general time audit.

Define rekeying as entering a value into a second system when the value already exists in the first system and no new source document is being used. A correction of an error is not rekeying unless the same corrected value must also be entered elsewhere. The definition should be visible during timing. The rule should also state whether a portal's own confirmation counts as a new source.

Why rekeying is hard to see

Rekeying is embedded in the workflow, so it does not appear as a separate task. A processor may describe the work as "setting up the file" without mentioning that half the time was spent copying fields into a portal. The cost is invisible in a task list and visible only in a time study. A short sample can show whether the duplication is concentrated in a few fields.

Rekeying also feels necessary, which makes it hard to question. A lender may require portal entry, and the team may assume there is no alternative. The study should separate the part that is truly required from the part that could be automated or eliminated. A required entry can still be faster with a template or a bulk upload.

Not all duplicate entry is waste. A second entry can serve as a check on the first, and some portals require an independent confirmation. The study should record the purpose of each entry so the team does not remove a control that prevents errors. The goal is to reduce avoidable rekeying, not all repeat entry.

Building the field map

List the fields the team enters in both systems. Group them into borrower identity, property, loan terms, income, assets, and conditions. A field map shows where the duplication is concentrated. It also helps the team choose a test that targets the largest group.

Mark each field as required in both systems, required in one, or optional. A field that is required only in the portal may still be rekeyed from the internal system. A field that is optional in both may be unnecessary. The map should be reviewed by a processor who does the work.

Update the map when a portal changes. A new required field can add rekeying time without appearing in the old baseline. The map should have a date and an owner. A stale map can lead the team to test a fix for a problem that no longer exists.

Timing the entry work

Use a timer at the start and end of each entry segment. Record the system, the field group, and whether the value came from a source document or an existing system. If the work is interrupted, pause the timer and record the reason. A simple stopwatch and a shared form are enough.

Time a mix of file setup, condition entry, and correction work. A sample from only one stage may overstate or understate the rekeying share. Record the loan type and the portal for each sample. The mix should reflect the team's normal week, not a special project.

Do not rely on memory at the end of the day. A person who entered a hundred fields will not remember the split accurately. Time the sample while the work is happening, or ask the person to record each segment immediately. A consistent method is more important than perfect precision.

Sampling files and entry segments

Sample files across processors, loan types, and portals. A sample from one processor may reflect a personal shortcut rather than the team's process. Include files at different stages because the field mix changes from setup to closing. Record the date and the stage for each sample.

Use a fixed number of files, such as ten, and time every entry segment within each file. A file-based sample is easier to interpret than a random field sample because the work stays connected. Report the number of segments and the total time. The sample should also note any file that was paused for a lender response.

Include files that required a correction. Correction work can be a large share of entry time, and it may involve rekeying if the corrected value must also be entered in the portal. The study should separate initial entry from correction. The two have different causes and different fixes.

Report the rekeying time as a share of active data entry time, with the sample size and the period. Show the median across files and the range. A share that moves from twenty percent to forty percent across files may reflect different portal requirements rather than different work habits. A range is more useful than a single average when the portals behave differently.

Break the share down by field group and portal. A high share in borrower identity may point to a portal with a long intake form. A high share in conditions may point to a duplicate condition entry. The breakdown is more actionable than the total.

Pair the share with the error rate. A rekeying step that prevents errors may be worth keeping, while one that creates errors is a candidate for removal. The study should record any correction that followed a rekey. The combination helps the team choose the first test.

Testing a single fix

Choose one fix that targets the largest field group. The fix might be a browser autofill template, a bulk upload, a saved portal profile, or an integration. Test it on a small group and compare the rekeying share before and after. Keep the rest of the workflow unchanged during the test.

Define the success measure before the test. A lower rekeying share is the primary measure, but accuracy and cycle time should also be checked. A fix that saves time but increases errors is not an improvement. The test should run long enough to cover a normal file cycle.

Record the test setup and the result. A failed test is useful if the team documents why it failed. The next test can avoid the same problem or choose a different field group. The goal is a series of small, evidence-based changes, not one large redesign.

What the result can change

A high rekeying share does not automatically justify a new system. It may justify a template, a different portal sequence, or a conversation with the lender about a bulk upload. The study should list the changes that could reduce rekeying before it recommends additional capacity. The team should separate a tool problem from a workload problem.

The loan processing support team can test one change on a small group and rerun the protocol. A saved portal profile is easy to test because the team can compare entry time before and after. The test should run long enough to cover a normal file 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 portal design problem. The mortgage operations support lead can review the intake path and the field map. The result should distinguish a tool defect 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 entry time, not every entry. A person who works around a slow portal without recording it may understate the rekeying share. A person who records every minor correction may overstate it. The protocol should define the segment clearly and apply the definition consistently.

The observer effect can bias the timing. A person who knows the work is being timed may enter data differently. Use a sample that includes both observed and self-reported segments, and compare the results. If the two methods differ widely, report both rather than choosing the more convenient one.

The sample may miss work done by a different team or channel. A loan officer who enters portal data directly may not appear in the processing log. Add a short note to the study about coverage and any known gaps. A clear limitation is more credible than a complete-looking number.

Review cadence

Repeat the study after a portal update, a template change, or an integration test. Use the same definitions and the same field map so the comparison is meaningful. A rekeying share that falls while total entry time rises may mean the team is doing more work elsewhere. 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 segments. Ask which fields were most repetitive and which shortcuts worked. The discussion can reveal a portal setting or a saved profile that nobody documented. The next study should test one of those findings.

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