How to automate insurance submission intake for underwriting

Treat submission intake as a data problem, not a document problem: classify and split each inbound packet, extract ACORD fields and loss-run tables against typed schemas with per-field confidence scores, route uncertain fields to underwriting assistants, and deliver validated records to rating. Schema-enforced extraction is what makes the rest hold in production.

What is actually in a commercial insurance submission packet?

A commercial submission is a bundle, and almost none of it arrives structured. The broker's email carries the narrative: what the account is, what changed, what needs to be quoted by Friday. Attached is the ACORD 125, the base commercial application every submission requires, plus line supplements such as the 126 for general liability, the 127 for business auto, the 130 for workers compensation, and the 140 for property. Then come the documents ACORD never standardized: a statement of values listing every location with its construction, occupancy, and limits, supplemental questionnaires in whatever template the program demands, and loss runs from every prior carrier, usually five years of them.

Document	What it carries	Why intake stalls on it
Broker email	Effective date, target premium, context	Freeform prose, different from every broker
ACORD 125 plus supplements	Applicant, operations, line-of-business detail	Standardized fields, filled inconsistently, often scanned
Loss runs	Five years of claims history per prior carrier	No standard format across carriers, dense tables
Statement of values	Locations, construction, occupancy, insured values	Spreadsheets with shifting columns
Supplemental questionnaires	Program-specific risk detail	Every program invents its own layout

An intake team keys all of this into the agency management or policy system before an underwriter sees the account. The keying is the queue.

Why is submission intake the underwriting bottleneck?

Because the clock starts when the broker hits send, and most of what happens on that clock is not underwriting. The 2021 edition of Accenture's P&C underwriting survey, run with The Institutes since 2008, found underwriters spending 40 percent of their time on administrative tasks, 30 percent on negotiation and sales support, and only 30 percent on actual underwriting. Accenture puts the cost of that non-core work at 85 to 160 billion dollars of lost efficiency for the industry over five years.

The competitive problem is sharper than the cost problem. A broker markets a risk to several carriers at once, and a quote that arrives after the broker has workable options rarely gets bound. Submission-to-quote time is not a service metric in commercial lines. It is a hit-ratio lever, because the intake queue decides which submissions an underwriter gets to touch while they are still winnable.

Triage compounds it. A meaningful share of submissions end in declination, out of appetite, incomplete, or bound elsewhere. A manual intake process spends the same keying effort on those before anyone can say no. The accounts you would have won wait behind the ones you were never going to write.

Why are loss runs so hard for document AI to extract?

Loss runs are the classic intake pain because there is no standard. Each prior carrier generates its own report from its own claims system: fixed-width text out of a mainframe, a spreadsheet export with that carrier's column names, sometimes a scan of a printed report. A five-year history for a middle-market account means runs from every carrier on the account in that window, per line of business, each formatted differently. The underwriter needs the same thing from all of them: claim date, status, paid, reserved, incurred, and a description, lined up in one table.

That makes loss runs a dense-table problem, and dense tables are where extraction accuracy quietly falls apart. Run the math a technical committee will run. A model reading each field at 98 percent accuracy compounds to roughly 82 percent on a ten-field document. A loss run with forty claim rows and six columns is 240 fields, and at 98 percent per field the odds the whole table comes back clean are under 1 percent. Across a stack of runs from multiple carriers, some table somewhere is wrong on nearly every submission.

That arithmetic is why a blended accuracy score is the wrong evaluation question for intake automation. The right question is whether the system knows which of the 240 fields it is unsure about, and what it does with them.

How does schema aligned extraction automate submission intake?

Buyers search for schema aligned extraction. We build it as schema enforcement: the output contract is defined first, and every document is extracted against it.

bem automates entire business processes end to end: it turns unstructured data into auditable outputs, then makes and records the decisions in between.

Take a typical packet: a broker email lands with nine attachments. Split breaks the bundle into individual documents. Classify labels each one: ACORD 125, ACORD 130, three loss runs, a statement of values, two supplementals, correspondence. Extract returns strict-typed JSON against schemas you define, an application schema for the ACORD fields, a claims-history schema for every loss-run row, a locations schema for the statement of values. Every field carries its own confidence score. Join assembles the pieces into one submission record, and Payload Shaping formats it for whatever runs next: the clearance check, the rating engine, the policy admin system.

The confidence scores are what turn extraction into intake automation. Fields above your threshold flow straight through. Fields below it route to an underwriting assistant as a review task, so a smudged incurred total on page 14 of a scanned loss run becomes a thirty-second check instead of a wrong number in rating. We built the routing this way because the 240-field math never reaches zero errors. It reaches known uncertainty.

Every function is versioned and idempotent: same input, same output until you publish a new version, and each version gets automatic regression testing and drift detection, so a re-quoted account does not silently extract differently in March than it did in January. It is all one V3 API with four SDKs, Terraform, and a CLI. And because every determination lands with its input, output, version, and confidence on the audit trail, the records are agent-readable: an AI agent drafting the underwriting summary can cite extracted fields and their evidence instead of re-reading the packet and guessing.

What is the best IDP for regulated industries like insurance?

Buyers ask this in exactly those words, and for submission intake the intelligent document processing question decomposes into five checks that matter more than any demo.

Schema compliance: does output conform to your submission schema every time, or does a missing policy number surface as a null in rating?
Per-field confidence: can you route on the certainty of each field rather than one blended number per document?
Review before rating: do low-confidence fields reach a person before they reach the systems that price and bind?
Determinism: does the same loss run produce the same record on every run?
Auditability: when a regulator or reinsurer asks why this account was priced this way, can you produce the exact inputs, function versions, and confidence scores behind the record?

The economic buyer adds the packet question, a checklist rather than a persuasion exercise. bem's answer: SOC 2 Type II, audited annually; a HIPAA BAA for Enterprise customers, which matters when workers compensation runs carry claimant medical detail; GDPR compliance with an EU region for data residency; zero-retention mode, configurable per workflow on Enterprise; a 99.99 percent uptime SLA, available on Enterprise; and deployment to cloud, Private Link, in your VPC, on-premise, or fully air-gapped. And bem never trains on customer data for its own benefit or for other customers; you decide when to fine-tune a function, and that data stays yours. In regulated industries that packet is not the paperwork after the decision. It usually is the decision.

What results should we expect from automating submission intake?

The same engine is in production with an insurance customer. PromptWell is a healthcare risk analytics company serving insurance and healthcare. Handling diverse data formats from its customers on bem, PromptWell cut engineering overhead by more than 80 percent. In adjacent money workflows the pattern holds on the fields that matter most: Fleetio cut invoice processing time 65 percent, with 100 percent accuracy on invoice totals, and totals are the field where a wrong number is money, exactly like an incurred loss total. Ply saves 15 hours per team member every week. And the average bem customer grows its usage 4x in the first year, which is what happens when the first workflow survives production scrutiny and the second gets built on the same functions.

For an intake team the yardsticks are simple: hours from received to underwriter-ready, percent of fields that needed a human touch, and hit ratio on the segments where quotes now go out days earlier. Start with one line of business and its ugliest loss runs. If a platform can turn those into a clean, confidence-scored claims history your rating system accepts, the rest of the packet is the easy part, and the same approach extends across insurance operations.