An underwriter opens a new file and starts typing. Values from a broker email go into one screen, figures from a partner spreadsheet go into another, and a legacy export gets retyped line by line. None of it is underwriting, and all of it happens before the risk is analyzed.
That work has two different sources, and they need different fixes. Treating them as one problem is why re-keying survives modernization projects.
This guide defines manual data entry in underwriting, shows what recent sources say about the time it takes, and explains why it persists. It then introduces a simple audit for matching each data path to the right fix, and shows where ETL-free ingestion with GenCruise fits.
What Counts as Manual Data Entry in Underwriting?
Manual data entry in underwriting is any step where a person retypes, copies, or reformats data that already exists in another document, file, or system. The data is not new. It is only in the wrong place.
The work falls into two groups, and the difference decides which fix applies.
Entry From Documents
Broker submissions arrive as emails, ACORD forms, statements of values, and loss runs. An underwriter or assistant reads each one and keys the values into the underwriting system.
The data lives inside documents, so the task is reading, not moving.
Entry From Systems and Files
Policy, claims, billing, and partner data sit in legacy systems, spreadsheets, and feeds from third parties. Someone exports it, reshapes it, and loads it where underwriters can use it.
The data is already structured, so the task is moving and standardizing, not reading.
Why the Split Matters
A tool that reads documents does nothing for a partner file that needs reshaping. A tool that moves structured data does nothing for a scanned loss run.
A team that buys one tool for both jobs fixes one path and leaves the other untouched.
How Much Underwriter Time Goes to Administrative Work?
More than a third of underwriter time goes to administrative work, according to an Accenture managing director writing in February 2026. That figure covers all administrative tasks, not data entry alone, and no published source we reviewed isolates entry hours for underwriters.
The Underwriter Side
Michael Reilly of Accenture wrote in Carrier Management that administrative tasks currently account for more than a third of underwriters' time. He named data ingestion as one application that reduces it.
The figure is a viewpoint, not a measurement of your book. Treat it as a reason to time your own files.
The Agency Side of the Handoff
Applied Systems surveyed 702 independent agents in April and May 2026. Commercial-heavy agencies re-key data at a rate of 70%, against 62% for personal-lines-focused agencies.
The same survey found commercial-heavy agencies rely on email for 49% of submissions and on dedicated submission capture software for 7%. Data that leaves the agency as an email arrives at the carrier as something a person must read and retype.
The Burden on Both Sides
Corporate Insight surveyed 214 independent agents in Q4 2025. Of those agents, 61% said 60% or more of their day goes to administrative tasks rather than selling.
Administrative load sits on both sides of the submission handoff. Retyping on one side creates retyping on the other.
Why Does Manual Re-Keying Persist?
Re-keying persists because each source needs its own path into the underwriting system, and nobody owns all of the paths. Each path is a small project that competes with larger priorities.
One Pipeline Per Source
Traditional ETL (extract, transform, load) moves data through a custom pipeline. Every new source needs its own pipeline, and each pipeline needs a developer to build it.
Underwriting teams rarely control that queue. A partner file that arrives monthly gets retyped because a pipeline for it never reaches the top of the list.
Pipelines Break When Structures Change
A source system renames a field or reorders a column, and the pipeline built for it fails. Someone must find the break, fix the logic, and reload the data.
Until then, the manual route is the only route that works. Each failure teaches the team that retyping is safer than waiting.
Errors Hide Inside the Work
A value typed wrong at intake carries forward into rating and portfolio reporting. The error surfaces later, far from the keystroke that caused it.
Nobody logs the retyping as a cost, so it never reaches a project list.
What Is ETL-Free Ingestion, and Where Does It Fit?
ETL-free ingestion brings source data into a target environment without a custom ETL pipeline built for each system. It addresses the systems-and-files group of manual entry, not the documents group.
The Data Path Audit below sorts every source by path so the fix matches the problem.
Path | Typical source | Manual step today | Fix type |
|---|---|---|---|
Document path | Broker emails, ACORDs, statements of values, loss runs | A person reads each document and keys values | Document reading |
System path | Legacy and modern policy, claims, and billing systems | A person or developer exports and reshapes data | Ingestion |
File path | Partner spreadsheets and third-party feeds | A person reformats and loads each file | Ingestion |
Live path | Data that must reach the system of record continuously | Batch loads that fall behind between runs | Integration |
Map the Paths
List every source that feeds an underwriter's screen. Assign each one to a path, and note who touches it and how often.
The system and file paths carry recurring manual work, because the same steps repeat every month.
Match the Fix to the Path
Ingestion fits the system and file paths. Document reading fits the document path. Integration fits the live path, where data must stay current rather than load in batches.
These are separate jobs, and one does not lead to another. Choose each on its own terms.
Know What Ingestion Does Not Cover
ETL-free ingestion does not read a broker's PDF. If your largest manual burden is the document path, ingestion alone leaves it in place.
Knowing that before you buy prevents a project that clears one path and reports success on all three.
How Do You Measure Whether Underwriters Are Re-Keying Less?
Five measures show whether manual entry is shrinking, and none of them counts activity.
Measure | What it shows | What it catches |
|---|---|---|
Sources with a manual step | Count of data sources retyped or reshaped by hand | Paths nobody has addressed |
Entry time per file | Minutes spent keying data before analysis starts | Where hours actually go |
Touches per data element | Times a value is typed or copied | Duplicate entry across screens |
Correction rate | Share of files needing a data fix after intake | Errors introduced by retyping |
Time to first analysis | Elapsed time from file receipt to the underwriter's first analytical step | Whether freed time reaches the work |
Baseline Before You Change Anything
Without a starting measurement, there is no result to report. This sequence takes about 90 days.
Days 1 to 30: time-stamp 50 recent files and log every source, every manual step, and the minutes each one takes.
Days 31 to 60: sort each source into the document, system, file, or live path and pick the first path to address.
Days 61 to 90: change one path, then compare entry time per file and correction rate against the day-one baseline.
If entry time has not moved by day 90, the path chosen was not the biggest one. That is a cheaper lesson than a full rollout.
How InsOps Helps
InsOps assists underwriting and operations teams with the data tasks around a file. GenCruise is our ETL-free data ingestion product, built so teams stop constructing and maintaining a custom pipeline for every source.
Our Guidewire Integration Gateway is a separate product for the live path. It connects to Guidewire UnderwritingCenter and PolicyCenter so data flows directly into your workflow without custom engineering, and a person validates every mapping before deployment.
InsOps is building toward reading submission documents inside LiLa, our insurance-trained LLM. LiLa runs inside your own environment, so PII and PHI never leave controlled infrastructure, and an underwriter would review every extracted field before it is used.
If you are evaluating how to cut manual data entry without building a pipeline for every source, contact us to talk through what this looks like for your operation.
Frequently Asked Questions
What is manual data entry in underwriting?
It is any step where a person retypes or reformats data that already exists elsewhere. It covers keying values from broker documents and reshaping files or exports from other systems.
How much time do underwriters spend on administrative work?
Published figures describe administrative work as a large share of the day, and they cover more than data entry. Time a sample of your own files to isolate the entry portion.
What is ETL-free data ingestion?
It brings data from source systems into a target environment without a custom ETL pipeline for each source. The goal is to stop building and repairing one pipeline per system.
Does ETL-free ingestion read broker submission documents?
No. It moves data that is already structured in systems and files. Reading documents is a separate task, and InsOps is building toward it inside LiLa, so contact us to discuss your submission flow.
Why does manual re-keying create risk?
A value typed wrong at intake travels into rating and reporting, where it is harder to trace. Each additional touch on a data element adds another chance for that error.
What metrics should insurers track to see whether underwriters are re-keying less?
Track entry time per file, touches per data element, and the share of files needing a data correction after intake. Baseline all three before changing any path.
How long does it take to reduce manual data entry?
Start with a one-month baseline, then scope the first path. Timelines depend on how many sources you connect and how access is granted, and the common pitfall is skipping the baseline.