A submission is more than a form.

An underwriter receives an ACORD application and a short note from a broker. The form has the named insured, requested coverage, locations, limits, and a few answers. It is readable. It is not yet a submission that another reviewer can evaluate without asking for the rest of the packet.

Commercial insurance risk is described across documents. A loss run supplies claims history. A property schedule supplies location-level detail. Statements, supplemental questionnaires, vehicle lists, payroll records, or prior-policy evidence may fill in the facts that the application only summarizes. The operational task is to reconcile these pieces without turning a completed form into a false sense of completeness.

The form is an index, not the whole packet

An ACORD form gives a submission a familiar structure. That structure is useful because it names the questions a reviewer expects to answer. It does not mean every risk fact belongs in the form, or that a blank answer can be safely treated as a negative answer.

The ACORD forms extraction guide describes the document layer: identify the form, extract its fields, preserve the source regions, and make the result usable downstream. Submission intake adds the surrounding question: which other document supports, qualifies, or contradicts this field?

• Application — the declared business, requested coverage, and answers supplied by the broker or insured.
• Loss runs — claims history that needs a period, carrier context, and enough identity to connect it to the risk.
• Schedules — location, vehicle, equipment, or property detail that turns a summary into reviewable units.
• Evidence — supporting records that explain an answer, an exception, or a change from prior submissions.

The packet is not four independent extraction jobs. It is one review context with several document types, each authoritative about a different slice of the risk.

Completeness is a relationship between documents

A submission can pass a field-level completeness check and still be incomplete as a packet. The application may list three locations while the property schedule names four. The business description may say “manufacturing” while a supplemental form describes installation work. A loss run may cover two policy years when the review asks for three.

These are not OCR errors. They are relationship checks. The intake system should compare identities, counts, periods, and coverage between the form and its attachments, then show the reviewer what needs confirmation.

A reviewer can resolve a mismatch only when the system names both sides of it. “Packet inconsistency” is a queue label; the useful exception is “application lists three locations, schedule lists four, row 4 has no matching application address.”

Preserve the unit that underwriting reviews

Flattening a schedule into one array of values loses the unit that matters. A property schedule is not just a list of addresses and amounts; it is a set of locations with relationships between address, occupancy, construction, values, protection, and requested coverage. A loss run is not just a total claim count; it is a set of claims tied to a policy period, status, cause, and amount.

Keep those units intact when extracting. Store the document, page, row or field, and the normalized value together. When an underwriter asks why a location was included or why a claim total changed, the answer should lead back to the source region rather than to a manually copied spreadsheet.

• Keep identity — retain the insured, policy, location, vehicle, or claim identifier beside every extracted record.
• Keep provenance — store page, region, source file, and extraction version for each material field.
• Keep units — distinguish dollars, percentages, dates, counts, and limits before comparing values.
• Keep uncertainty — route low-confidence reads and ambiguous matches with their reasons attached.

One submission, one review queue

Broker submissions arrive through email, portals, shared folders, and follow-up messages. If each attachment creates its own task, the team has to reconstruct the packet before it can review the risk. A better intake model creates one submission record and adds documents, extracted facts, and exceptions to it.

That record should distinguish missing documents from conflicting documents. A missing loss run asks for an upload. A loss run that covers the wrong period asks for clarification. A schedule that disagrees with the application asks for a decision. The next action is different even when all three appear under “incomplete.”

1. Identify the submission and associate each attachment with it.
2. Classify documents and extract fields, tables, and source regions.
3. Normalize identities, dates, units, and repeated entities.
4. Run cross-document checks and create specific exceptions.
5. Return a packet with resolved facts, unresolved questions, and evidence.

This is where automation earns its place. It reduces the work of finding and comparing facts while keeping the underwriting decision with the people accountable for it.

Do not turn blanks into answers

Document extraction is especially dangerous when a blank field is silently normalized to a default. A blank on an application can mean the question was not answered, the field did not apply, the scan was poor, or the broker expected a supplemental document to carry the detail. Those meanings are not interchangeable.

Represent absence explicitly. Track whether a field is present, blank, illegible, not applicable, or contradicted elsewhere. If a required supporting document is missing, the packet should say “missing,” not present a clean-looking record with an empty value.

The same rule applies to loss runs and schedules. No claims is not the same as no loss run. No listed property is not the same as a property schedule that was reviewed and found empty.

Separate intake from underwriting judgment

A submission system can identify a missing attachment, compare a location count, and preserve the line behind a claim amount. It should not decide whether the risk is acceptable, whether a discrepancy is material, or which coverage terms an underwriter should offer.

The insurance document workflow is strongest when the boundary is explicit: extraction and reconciliation produce a reviewable packet; underwriting applies policy, authority, and professional judgment. An automated match can be a useful control without becoming an underwriting decision.

That boundary also improves auditability. A later reviewer can see what the documents said, what the intake system compared, what exception was raised, and who resolved it. The record does not pretend that a form completed the judgment on its own.

Questions to ask about submission intake

“Can you extract an ACORD form?” is a starting question, not an evaluation. Ask what happens to the packet after the form has been read.

• Packet identity — can the system keep forms, loss runs, schedules, and follow-ups under one submission?
• Cross-document checks — does it compare names, locations, periods, counts, and material values?
• Table structure — can a reviewer inspect the row behind a location, vehicle, property, or claim?
• Explicit absence — does it distinguish missing, blank, illegible, not applicable, and contradicted?
• Source evidence — can every material fact open the page or region that supports it?
• Review handoff — does the queue explain the next question without making the underwriting decision?

The answers reveal whether a product reads documents or helps a team review a submission. The difference is the packet boundary.

A form starts the submission

An ACORD form gives a submission a useful spine. It does not contain every fact an underwriter needs, and it cannot reconcile the documents that surround it. The submission becomes reviewable when the application, loss runs, schedules, and supporting evidence are linked, compared, and traced back to their sources.

Build intake around that relationship. Extract the form, preserve the row, identify the missing document, surface the contradiction, and return the evidence with the question. The form starts the submission; the packet makes the next decision possible.