Why no two submissions look alike — and why it breaks template OCR

If you have ever tried to automate submission intake, you already know the uncomfortable truth: the risk is standard, but the paperwork never is. A single mid-market general-liability account can arrive as a broker email with three attachments one week and, from a different broker, as a zipped folder of eleven files the next. The insured hasn’t changed. The coverage hasn’t changed. Only the shape of the input has — and that shape is where most intake automation quietly falls apart.

This post is about that problem, not any particular product. Understanding why submissions are so variable, and why that variability is structurally hard rather than merely annoying, is the single most useful thing an underwriting or operations leader can do before choosing how to automate. So let’s be concrete about what the variability actually looks like, why template-based OCR shatters on it, what it costs, and what a durable approach looks like instead.

The many shapes of a single risk

Start with the thing that makes P&C intake unlike, say, invoice processing: a submission is not a document, it is a loosely-bound bundle of documents that no one agreed on the format of. Each broker, each carrier, each software vendor, and each individual assistant assembles that bundle their own way. Here are the axes along which two submissions for essentially the same risk will differ.

Source of variability	Type	What it looks like in the real world
Bundle composition	Per-broker	One broker sends the whole ask in the email body; another attaches an ACORD 125 plus a cover letter; a third sends eleven files and no email context at all.
ACORD version & edition	Per-form	ACORD 125, 126, 140, 129 — each with multiple edition years (2011, 2016, 2022). Fields move, get renamed, get added, or get dropped between editions.
SOV / exposure workbooks	Per-file	Statement-of-values and exposure spreadsheets with different column names, column order, extra header rows, merged cells, and multiple tabs — one per location, or one giant sheet.
Scanned vs. born-digital	Per-page	A crisp PDF export on page 1, a phone photo of a signed form on page 3, and a faxed loss run on page 7 — often in the same file.
One risk, many documents	Per-account	The named insured is on the ACORD, the fleet on a workbook, the losses on three carrier loss runs, and the real ask in the email — nothing is complete on its own.
Free-form supplements	Ad hoc	Broker narratives, underwriting questionnaires, driver lists, and “see attached” notes that carry pricing-relevant facts in prose, not fields.
Naming & delivery	Per-message	Files named scan001.pdf or Final_v3_REALLY.xlsx, delivered by email, portal, shared drive, or an EDI feed — with no reliable clue to their contents.

None of these are edge cases. On any real book, all of them show up in the same week — and often in the same submission.

Why template OCR is the wrong tool for this

Template-based (or zonal) OCR works by assuming a fixed layout. You draw a box around where the “policy number” sits on a form, tell the engine to read whatever text falls inside that box, and repeat for every field. On a document that never changes — a single carrier’s dec page, a government form with a locked layout — this is fast, cheap, and accurate.

The problem is that the assumption at its core, “the field is always in the same place,” is precisely the assumption a submission violates. Move the field two centimetres, add a header row, switch to the 2022 edition of the form, or hand it a scan at a slight rotation, and the box now reads the wrong text — or nothing. The engine doesn’t know it’s wrong; it confidently returns the value from the wrong zone.

The instinctive fix is to build another template for the variant. And another. And another. This is where the approach stops scaling: variability isn’t a fixed set of a dozen layouts you can enumerate once. It is a long tail — a handful of common shapes and a nearly endless supply of rare ones. Every new broker, every form edition, every re-built spreadsheet is a new template you didn’t have. You are not maintaining a library; you are chasing a distribution that never closes.

Dimension	Template / zonal OCR	Layout-independent, agentic extraction
Core assumption	The field sits in a fixed location on a known layout.	The meaning of a field is understood from context, wherever it appears.
New form edition	Breaks silently; needs a new template.	Handled — the model reads it like a person would.
Reordered / renamed SOV columns	Mismaps columns; values land in the wrong field.	Columns matched by meaning, not position.
Scanned + born-digital mix	Zones drift with rotation and scan quality.	Robust to page quality; adapts per document.
One risk across many files	No concept of it — reads each file in isolation.	Consolidates documents into one account record.
The long tail of rare shapes	Each rare variant is an unbuilt template.	Rare shapes handled by the same general reasoning.
Cost to add a new source	Template design, testing, ongoing maintenance.	Configuration of what to extract, not how to find it.

The hidden costs that don’t show up in the demo

Template OCR usually demos beautifully, because a demo uses the clean, common form the template was built for. The costs arrive later, and they compound.

• Per-template maintenance. Every template is a small piece of software that has to be built, tested, and version-controlled. When a carrier reissues a form or a broker rebuilds a spreadsheet, something breaks — and someone has to notice, diagnose, and fix it before the errors reach an underwriter.
• The long tail eats the savings. The common shapes automate well; the rare ones don’t. But the rare shapes are a large fraction of total volume in aggregate, so the “80% automated” headline quietly becomes “the 20% we couldn’t template now consumes most of the team’s time.”
• Exception queues. Anything the templates can’t confidently handle lands in a manual review queue. These queues grow with every new broker and form edition, and they are where cycle time, backlog, and re-keying errors actually live.
• Silent mismaps. The most expensive failure isn’t the document that errors out — it’s the one that returns a plausible-but-wrong value from the wrong zone. A transposed limit or a mis-read attachment point can flow all the way to a quote before anyone catches it.
• Brittleness tax on the roadmap. Teams stop onboarding new brokers or lines because each one means more templates. The automation that was supposed to create capacity ends up constraining it.

What “good” looks like

The way out is to stop trying to predict where a value sits and instead extract based on what a value means. A layout-independent, agentic approach treats each document the way an experienced intake analyst does: figure out what kind of document this is, read it in context, pull the facts that matter regardless of where they appear, and reconcile everything into one coherent picture of the account.

Many varied inputs, one adaptive pipeline, one connected record — the layout never has to be known in advance.

Concretely, an approach built for variability has a few defining properties:

• It classifies before it extracts. A file named scan001.pdf could be an ACORD, a loss run, or a driver list. The pipeline identifies the document type first, then applies the right expectations — instead of assuming.
• It reads by meaning, not position. “Each-occurrence limit” is found whether it’s on line 4 of the 2016 edition or line 7 of the 2022 one, and an SOV column called “Bldg Value,” “TIV,” or “Total Insured Value” maps to the same field.
• It adapts per document. A born-digital PDF, a phone photo, and a multi-tab spreadsheet each get handled on their own terms — no single template has to fit all three.
• It consolidates across files. The insured from the ACORD, the fleet from the workbook, and the losses from three loss runs are merged into one account record, so the underwriter sees the risk, not the paperwork.
• It cites its sources. Every extracted value points back to the document and page it came from, so a reviewer can verify a number in seconds instead of re-opening the packet.
• It absorbs the long tail. Because the reasoning is general, a broker or form the system has never seen is handled by the same logic — not deferred to a template that doesn’t exist yet.

Why it matters

This is not an argument about accuracy on a clean form — every approach does well there. It is an argument about what happens across the full distribution of what brokers actually send, which is where the economics of an intake operation are decided.

• Capacity that scales with volume, not variety. When adding a broker or a form edition doesn’t require a new template, the team can take on more submissions without a proportional rise in maintenance or exceptions.
• Smaller, calmer exception queues. The long tail is handled by the same pipeline as the common cases, so the review queue reflects genuinely ambiguous documents — not merely unfamiliar layouts.
• Fewer silent errors. Extraction by meaning, with source citations, replaces confidently-wrong zone reads with values a reviewer can trust and check.
• Faster, more consistent triage. An underwriter opens one consolidated, coded record instead of reconciling a dozen files by hand — and gets the same structure every time, regardless of which broker sent it.
• A roadmap that isn’t hostage to formatting. New lines, new brokers, and new sources become business decisions again, not template projects.

The variability of submissions isn’t a temporary inconvenience to be engineered away one template at a time — it is a permanent property of how P&C business is placed. Brokers will keep building spreadsheets their own way, carriers will keep reissuing forms, and the same risk will keep arriving in a dozen different shapes. An intake approach earns its keep by treating that variability as the normal case, not the exception. The question to ask any automation isn’t “how accurate is it on this form?” but “what happens when the next submission looks nothing like this one?”