Multi-document submissions, handled as one

Ask any underwriting-ops team what a “submission” is and they will not point to a single file. They will describe a bundle: the broker’s cover email, an ACORD 125 with the business detail, an ACORD 131 with the excess structure, a statement of values, and a loss run going back five years. Each document is a different format, a different author, and a different slice of the same risk. The underwriter does not want five extractions — they want one clean, reconciled account record. The gap between those two things is where most document-AI tools quietly fall down.

Handling a submission as one record sounds simple until you hit the operational reality: documents arrive at different times, one of them is often wrong, and the same fact appears in more than one place with different values. A tool that treats the packet as an indivisible blob has to re-process everything whenever anything changes. InsightXtract takes the opposite approach — extract each document independently, cache the result, and consolidate by role — and that architectural choice is what makes the whole thing efficient and correct.

The pipeline: per-document extract, then consolidate

The flow has two distinct phases. First, every document in the packet is classified and extracted on its own, against its own spec, producing its own structured result with confidence scores and citations. That per-document result is cached. Second, a consolidation step merges those cached results into a single submission record, resolving overlaps by source role — a defined precedence about which document is authoritative for which field.

flowchart TB
    E["Broker email"] --> Xe["Extract email
(cached)"]
    A125["ACORD 125"] --> Xa["Extract ACORD 125
(cached)"]
    A131["ACORD 131"] --> Xb["Extract ACORD 131
(cached)"]
    SOV["Statement of values"] --> Xs["Extract SOV
(cached)"]
    LR["5-yr loss run"] --> Xl["Extract loss run
(cached)"]
    Xe --> C["Consolidate by source role
ACORD authoritative for
insured, limits, premium"]
    Xa --> C
    Xb --> C
    Xs --> C
    Xl --> C
    C --> R["One submission record
+ provenance per field"]
                    

The important word is cached. Once the loss run has been extracted — and its 40 rows parsed, and any low-confidence figures reviewed — that result is settled. It does not need to be touched again just because a different document in the packet changed. Consolidation reads from the cache; it does not re-extract. This is the difference between an architecture that scales and one that re-does its own work.

Consolidation by source role: who is authoritative for what

When the same fact lives in multiple documents, you need a rule for which one wins — and that rule should encode how underwriters already think. The broker’s email might mention a target premium; the ACORD carries the bound premium. The email might paraphrase the insured’s name; the ACORD carries the legal named insured. In P&C, the ACORD form is the authoritative document for the core account structure, and consolidation reflects that.

Field	Authoritative source	Why
named_insured, FEIN, mailing_address	ACORD 125	Legal application of record
requested_limits, underlying schedule	ACORD 131	Excess/umbrella structure lives here
total_premium	ACORD (bound) over email (target)	Email target is pre-negotiation
Location values / TIV	Statement of values	SOV is the schedule of record
Claim history rows	Loss run	Carrier-issued loss record
Effective date, context, intent	Broker email	Narrative and timing cues

These precedences are configurable, not hardcoded assumptions. A program with its own conventions can define its own roles. What matters is that the resolution is deterministic and explicit — the same conflict resolves the same way every time, and you can point to the rule that decided it.

The payoff: correcting one document doesn’t re-run the packet

Here is where the architecture earns its keep. Suppose the ACORD 131 was a scanned copy and the underlying-limits schedule came back with one low-confidence figure. A reviewer opens it, verifies against the source, and corrects it. In a monolithic system, that single correction would force the entire submission — email, both ACORDs, SOV, and the 40-row loss run — to be re-processed, because the tool has no concept of independent documents. That is wasted compute, wasted time, and a fresh chance to introduce new low-confidence flags on documents that were already fine.

In InsightXtract, correcting the ACORD 131 re-extracts only the ACORD 131. The email, the SOV, and the loss run results are read straight from cache — untouched, already reviewed, still valid. Consolidation then re-runs (it is cheap; it is just merging cached results by role) and produces an updated submission record. The reviewer’s one fix costs one document’s worth of work, not five.

Worked example: a premium conflict resolved by source priority

Take the Summit Logistics excess-casualty renewal. The broker’s cover email quotes a target premium of $148,000. The ACORD 131 states an annual premium of $152,500. Both are extracted, both are cached, and both are correct as readings of their own document — the email really does say 148, the ACORD really does say 152.5. The conflict is not an extraction error; it is a real difference between a target and a bound figure.

Consolidation resolves it by role: for total_premium, the ACORD outranks the email, because the ACORD carries the bound figure while the email target is pre-negotiation. The submission record shows $152,500 — and, critically, it records why. Now suppose the reviewer later corrects the ACORD 131 premium (say the scan was cut off and it should read $152,000). Only the ACORD re-extracts; consolidation re-applies the same role precedence; the record updates to $152,000. The email extraction never moved.

Provenance: every field knows where it came from

A consolidated record raises an obvious governance question: if this account record was assembled from five documents, which document did each field come from? InsightXtract answers that at the field level. Every value in the submission record carries provenance — the source document, the page, and the citation — so a reviewer or auditor can trace any number back to the exact place it was read.

This is what makes the “handled as one” promise trustworthy rather than a black box. The underwriter sees one record, but every field remembers its origin. When the premium shows $152,500, the provenance shows it came from the ACORD 131 and notes that the email’s target figure was superseded by source priority — not silently dropped.

What this means for an ops team

• One record to underwrite. The team acts on a single reconciled account, not a pile of five documents they have to mentally merge.
• Cheap corrections. Fixing one document re-runs one document. The reviewed loss run and SOV are reused, not redone.
• Deterministic conflict resolution. When the same fact appears twice, source role decides — the same way every time, and visibly.
• Full traceability. Every field in the consolidated record knows its source document, page, and any conflict it resolved.

A submission is many documents. The underwriter should never have to feel that. By extracting each piece once, caching it, and consolidating by role, InsightXtract lets a five-document packet behave like a single, coherent, correctable record — efficient to process, cheap to fix, and honest about where every number came from.