A commercial submission is never one document. It is a cover email, two or three ACORD forms, a statement of values or exposure workbook, five years of loss runs from different carriers, and often a prior quote or binder. Account teams rekey all of it before a market sees the risk. Document AI can take that work off their desks, but only if it does more than OCR: it has to classify each document by what it is, read spreadsheets every broker builds differently, normalize values into one shape, reconcile facts that appear in several documents, resolve insureds and locations to one identity, and score its confidence field by field so people review only the shaky values. Below is the document landscape, the architecture, how to measure accuracy honestly, and a four-week pilot.
The packet, not the form
Ask an account team what a submission is and nobody points to a single file. They describe a bundle: the cover email with the narrative and the deadline, an ACORD 125 with the applicant and business detail, line-specific ACORD sections such as the 126 for general liability or the 140 for property, an ACORD 131 when there is an umbrella or excess layer, a statement of values or a multi-sheet exposure workbook, and loss runs from every carrier that wrote the account in the last five years.
Each document has a different author, a different format and a different slice of the same risk. The broker’s job is to turn that bundle into something a market can quote without coming back with questions — which, as Part 1 argued, is what “complete” really means. Today most of that turning is done by hand: someone opens each file, rekeys the values into the agency management system or a submission template, fixes the formats, and chases what is missing.
| Document | What it carries | Why it is hard |
|---|---|---|
| Cover email & attachments | Narrative, target dates, requested limits, what is attached | Free text; attachments forwarded, zipped or pasted inline |
| ACORD applications & sections | Applicant, operations, locations, coverages, prior carriers | Filled by many hands; scanned, flattened or hand-annotated |
| SOV / exposure workbook | Locations and values, payroll by class, vehicle schedules, subcontractors | Every broker builds the spreadsheet differently, often across many sheets |
| Loss runs | Claims, paid, reserves, incurred, status, valuation date | Every carrier has its own layout; grouped columns and per-line grids |
| Quotes, binders & slips | Terms, limits, retentions, subjectivities, premium | Market-specific wording for the same terms |
Why OCR is not enough
The first generation of document tools treated this as a reading problem: find the text on the page, map zones on a template, copy values into fields. That works on a clean, known form. It breaks on the four-hundredth broker template, the loss run with merged cells and a footnote, and the workbook with three tables on one sheet. Broker documents fail OCR-first tools in six predictable ways.
1. Classification: intent over form
Before anything is extracted, each file has to be identified — and in a forwarded broker thread that is not trivial. A loss run arrives inside a PDF that also holds an application; a prior carrier’s cancellation notice looks like correspondence. InsightXtract classifies documents by what they are for rather than what they look like, and returns the evidence behind each verdict so downstream steps can trust it (how classification works).
2. Layout: spreadsheets nobody builds the same way twice
The exposure workbook is the hardest document in many submissions and the most valuable. A metadata block sits one blank row above a wide table; stacked group headers sit over sub-columns; one sheet holds several tables; each region gets its own sheet. Template OCR collapses these, and pasting the spreadsheet into a language model drops rows. InsightXtract loads every sheet, splits it into regions, classifies each region as a key-value block or a table, and maps each table to a typed schedule by its headers (reading the exposure workbook).
3. Loss runs: one layout per carrier
Loss runs decide the conversation with the market, and every carrier formats them differently: PDFs with one grid per line of business, spreadsheets with stacked claim-identity headers, Loss, ALAE and Total each split into paid, reserve and incurred under a merged header. Status codes arrive as “O”, “Open” and “OP”. Each claim has to come out as one typed row, keyed on the right identifier, with status and cause normalized (loss runs without the headache).
4. Normalization: the tax nobody demos
A value can be read perfectly and still be unusable. “3/4/25”, “04-Mar-2025” and “March 4, 2025” are the same date; “$1.2M” and “1,200,000” are the same limit; “GL”, “CGL” and “Gen’l Liab” are the same coverage. Your agency management system, your submission template and your markets each expect one form. Normalizing at extraction — dates to ISO, money to amount plus currency, states and coverages to codes — is what stops the cleanup scripts from multiplying (the normalization tax).
5. Reconciliation across documents
The same fact appears in several places with different values: total insured value on the SOV and on the application, the named insured on the email and on the ACORD, prior premiums on the loss run and in the narrative. Extracting each document once, keeping the results, and consolidating them into one submission record means a correction to one document does not mean re-running the whole packet — and conflicts surface as conflicts instead of whichever value was read last.
6. Entity resolution: one insured, one location
“Apex Holdings”, “Apex Holdings LLC” and “APEX HLDGS” are one insured; “100 Main St” and “100 Main Street, Suite 2” may be one location. Resolving parties against a registry of known identities at extraction time, with a confidence score, is what lets you roll up an account’s history, avoid duplicate records in the agency management system, and spot that this year’s SOV has a location last year’s did not (master data at extraction time).
Reference architecture
For a brokerage, the pipeline sits between the inboxes and portals where documents arrive and the systems the account team works in. It runs inside your environment — InsightXtract is self-hosted in your cloud or data center — and writes structured, cited data back to the systems of record rather than into yet another screen.
Confidence per field, review by exception
The whole business case for document AI rests on one sentence: high-confidence results clear without a person. That is only safe if the confidence number means something. A model asked how sure it is will cheerfully report 0.95 about a value it invented, so self-reported confidence is the wrong control.
InsightXtract grounds confidence in evidence: does the value trace to a real span on the page, did it pass its type and cross-field checks, did it survive re-extraction? And it scores each field, not each document, so a 38-field record can clear the fields it is sure of and flag only the two it is not (confidence as a first-class output).
| Condition | What happens |
|---|---|
| Field above threshold, all checks pass | Accepted automatically |
| Field below threshold, or a warning | That field is flagged for targeted review |
| An unresolved error-severity check | The document is held for review |
| Every field clear | Straight through — the document is done |
For an account team, this changes the shape of the work. Instead of rekeying a packet, the account manager reviews a handful of flagged fields, each shown beside its source on the page, and approves, corrects or sends it back. The thresholds are yours to set, and you can start strict and loosen them as the numbers earn it.
Corrections should not be wasted. When a reviewer fixes a value and records why, that correction is evidence. Enough of the same correction reveals a systematic blind spot — a carrier’s loss-run layout, a broker’s workbook convention — that can be fixed once at the source instead of by hand every week (closing the loop).
Measuring accuracy honestly
Every extraction demo looks good on a clean form. The only number worth trusting is accuracy on your own documents, scored field by field against a gold dataset that a person has verified. InsightXtract scores field accuracy, straight-through rate and per-document-type results against gold datasets — and that is the harness we use in every pilot.
- Build the gold set from real traffic. Take a sample of recent submissions across lines and carriers, including the messy ones, and have an experienced account manager verify the values.
- Score the fields that matter most first. Named insured, dates, limits, total insured value, location count and loss totals decide whether a market can quote.
- Track review effort, not just accuracy. The outcome that matters to an account team is how many fields a person still touches per submission, and how long that takes.
- Re-score after every change. A tuning fix for one carrier’s loss runs should not quietly break another’s.
Feeding the systems account teams use
Extraction that ends in a new screen creates another place to copy from. The value lands when structured, normalized, cited data writes back to where the work happens:
- Agency management system: insured, locations, coverages, prior carriers and loss history attached to the right client record, without duplicates thanks to entity resolution.
- CRM and the client record: what changed since last year — new locations, new vehicles, payroll growth — visible to the producer before the renewal meeting.
- The submission itself: a consistent, complete package to each market, with the source documents attached and every value traceable to its page.
- Analytics: clean exposure and loss data across the book, which is the raw material for renewal preparation and placement analytics later in this series.
Security and client confidentiality
Submissions are full of client financials, payroll, personal data on drivers and claimants, and sometimes health information. A brokerage cannot send that to a tool whose data handling it cannot explain to a client.
| Concern | What we put in place |
|---|---|
| Where the data lives | Self-hosted in your cloud or data center, integrated with your systems |
| Who sees what | Access follows the client and practice permissions you already have |
| Personal data | Identified at extraction and masked where downstream use does not need it |
| Audit | Every value carries its source, every correction its reviewer and reason |
| Models | Your choice of model provider, called from your environment under your agreements |
The failure modes we plan for
1. Demoing on clean forms. The pilot passes on tidy ACORDs and fails on the first real exposure workbook. Build the gold set from your messiest recent submissions, not your best ones.
2. Trusting a document-level score. One confidence number per document hides the two wrong fields. Score and route per field.
3. Skipping normalization. Correct values in ten formats still break the agency management system load. Agree the canonical forms before you go live.
4. Last value wins. When the SOV and the application disagree on total insured value, silently keeping one is worse than flagging the conflict.
5. Corrections that go nowhere. Reviewers fix the same loss-run layout every week because nothing feeds back. Capture the reason with each correction and act on the patterns.
6. A new screen instead of write-back. If account managers still copy from the extraction tool into the agency management system, the hours did not go away; they moved.
A four-week pilot
Week 1 — Pick the slice and build the gold set
One practice or line, the five document types that matter most there, and a verified sample of recent submissions including the hard ones. Agree the canonical forms and target fields with the account team.
Week 2 — Configure and score
Configure extraction for those documents, run the gold set, and score field accuracy, straight-through rate and classification per document type.
Week 3 — Run beside the team
Process live submissions in parallel with the current process. Account managers review only flagged fields, and every correction is captured with its reason.
Week 4 — Decide on evidence
Compare review effort per submission, accuracy on the fields that matter and the corrections log against the baseline, then decide whether to expand to the next practice and wire write-back to the agency management system.
Readiness checklist
| Item | Ready when |
|---|---|
| Scope | One practice or line, and its five most common document types, are chosen |
| Gold set | A verified sample of real submissions, including messy ones, exists |
| Canonical forms | Dates, money, codes and coverage names are agreed with downstream owners |
| Thresholds | Starting confidence thresholds and who reviews flagged fields are agreed |
| Systems | The target fields in the agency management system and CRM are mapped |
| Security | Hosting, access, personal-data handling and model provider are approved |
| Baseline | Current time and touches per submission are measured, so the pilot has something to beat |
The bottom line
Brokers do not need another tool that reads ACORD forms. They need the whole packet — applications, workbooks, loss runs, quotes and the email around them — turned into one clean, reconciled, cited record, with people looking only at the values the system is unsure of. That takes classification, layout reading, normalization, reconciliation and entity resolution around the extraction, and an honest gold-set measure of how well it works on your documents.
Get that right and the account team’s hours move from rekeying to the conversations only they can have with clients and markets. The next part of this series takes that clean data one step further: a renewal pack that is prepared before anyone asks for it.