Why the IDP you bought in 2019 can’t handle submissions

If you run intake for a P&C carrier or MGA, you probably already own a document-processing tool. It was likely bought somewhere around 2019, it works, and it processes a lot of paper. So when someone suggests that automating submissions needs a different kind of engine, the fair reaction is skepticism: we already have IDP. The honest answer is that classic IDP is excellent at what it was designed for — and a submission is not that. The mismatch isn’t a matter of tuning or more templates; it’s architectural.

Template-based IDP was built for a world of high-volume, fixed-layout documents. The canonical use cases — accounts-payable invoices, a lending institution’s standard application, a single ACORD form filed the same way every quarter — share three traits: the layout is stable, the same document type arrives thousands of times, and the value you need is in a predictable place on the page. Under those conditions, defining a template, drawing zones, and writing extraction rules is exactly the right engineering. You amortize the setup cost over enormous volume, and the accuracy is superb.

A submission breaks all three assumptions at once. It is not a document — it’s a packet of a dozen loosely related files, each from a different author. The layouts drift constantly because every broker, every carrier’s loss run, and every exposure workbook looks different. And the volume per variant is low: you might see a hundred loss-run formats a year and only a handful of each. That is the precise inverse of what template IDP was built to exploit.

The three assumptions that make template IDP fast are exactly the three a submission violates.

Where template IDP hits the ceiling

None of what follows is a knock on the category. These are the predictable failure modes that appear when you point a template-and-rules engine at documents it was never meant to see. If you run submissions through legacy IDP today, you are almost certainly living with some combination of them.

Template sprawl and the maintenance tax

The first thing that happens is that one template becomes fifty. Every new broker loss-run format, every carrier’s statement of values, every re-versioned ACORD needs its own template and its own zone map. Someone has to build each one, and someone has to keep it working. The tool that promised to remove manual effort quietly relocates it into a template-maintenance backlog — and that backlog never shrinks, because the long tail of formats never stops arriving.

Brittleness to layout drift

Zones are coordinates. Move a column, add a header row, let a table spill onto a second page, and the coordinates no longer point at the right thing. A loss run that a carrier reformats slightly — a new column, a merged cell, a wrapped address — can silently start pulling the wrong values, or pulling nothing. The engine has no idea what a “total incurred” is; it only knows what’s at row 14, column C. When that moves, extraction breaks, and it often breaks quietly.

The “unsupported document” long tail

Because coverage depends on a template existing, anything without one falls through. A broker’s cover email describing the ask, a one-off exposure spreadsheet, a schedule in an unfamiliar layout — these land in an “unsupported” bucket and go straight to a human. In submission intake the long tail is not an edge case; it is a large share of the actual mail. A tool that only handles the formats you pre-built for leaves the hardest, most variable documents exactly where they started.

No cross-document reasoning

This is the deepest limitation. Template IDP reads one document at a time and returns a flat list of fields per document. But the questions that matter in a submission live between documents: does the underlying tower on the schedule actually support the attachment point in the broker’s ask? Does the fleet count on the vehicle schedule line up with the exposure workbook? Is the insured on the ACORD the same legal entity as the one on the loss run? A per-document extractor cannot answer any of these, because it has no concept of the account the documents jointly describe.

No real confidence or validation

Classic IDP reports OCR character confidence — how sure it is that it read the ink correctly. That is not the same as knowing whether the value is right. “I’m 99% sure those pixels say $1,000,000” tells you nothing about whether a $1M attachment is plausible given the underlying limits, or whether a loss date falls inside the policy term. Without semantic validation against business rules and reference data, the numbers arrive confident and unchecked.

Heavy exception queues

Add these up and you get the symptom everyone recognizes: the exception queue. Unsupported documents, drifted layouts, low-confidence reads, and anything requiring cross-document judgment all route to people. The automation rate looks good on the documents that fit a template and collapses on everything else — which, for submissions, is most of the interesting work.

A different shape of engine: the agentic approach

The alternative isn’t “better OCR” or “more templates.” It’s an engine built around the assumption that every document is different and meaning has to be understood, not located. Instead of matching pixels to zones, an agentic pipeline runs a sequence that mirrors how an experienced intake analyst actually works: classify → reason → extract → validate, adapting to each document rather than requiring the document to match a pre-built map.

Layout-independent: identify the document, understand what it should contain, extract by meaning, then validate and consolidate.

Because extraction is driven by what a field means rather than where it sits, a loss run that gets reformatted still works — “total incurred” is found because the model understands the concept, not because it’s at a fixed coordinate. Because the pipeline classifies before it extracts, a never-before-seen document doesn’t fall into an “unsupported” bucket; it gets identified and handled. And because the record is consolidated across documents, the cross-document questions template IDP can’t touch become the normal output: one account record, every value cited back to its source page, validated against your rules and reference data.

Template IDP vs. the agentic approach, dimension by dimension

Neither is universally “better” — they’re optimized for opposite document profiles. The question is which profile your work actually looks like. For high-volume fixed forms, template IDP still wins on cost. For submissions, the trade goes the other way.

Dimension	Template / zone IDP	Agentic extraction
Best-fit document	High-volume, fixed layout — one form, one invoice type	High-variability, multi-document packets
New / unseen layout	Needs a new template first	Handled without setup — classify then extract
Layout drift	Breaks — zones point at moved values	Robust — extraction is by meaning
How a field is found	Coordinates / zone on the page	Semantic understanding of the field
Cross-document reasoning	None — one document at a time	Consolidates a packet into one account record
Confidence signal	OCR character confidence	Business-rule & reference-data validation
Maintenance model	Ongoing template building per variant	Configuration of fields, rules, and schema
Where the effort goes	Exception queues + template backlog	Review of genuinely ambiguous cases only

Why it matters to the business

This isn’t an abstract architecture debate — the mismatch shows up directly in the numbers ops and underwriting leaders care about:

• Automation rate that doesn’t stall. When coverage no longer depends on a template existing, the long tail of broker formats and one-off schedules gets processed instead of routed to people — the exception queue stops being where the real work hides.
• Lower total cost of ownership. The invisible line item in template IDP is the team maintaining templates. Replacing that with configuration — fields, rules, and schema — removes a backlog that otherwise grows with every new broker.
• Fewer silent errors. Semantic validation against business rules and reference data catches implausible values that OCR confidence never would — a loss dated outside the term, an attachment that doesn’t match the underlying.
• Underwriters get a record, not a pile. Consolidation across documents means an underwriter opens one cited, validated account record instead of reassembling a dozen extracted forms by hand.
• Capacity without headcount. The combined effect — more of the mail handled, fewer exceptions, cleaner data — is more submissions processed per person, which is the whole point of automating intake in the first place.

Have you outgrown template IDP? A checklist

A quick self-test. The more of these you recognize, the more likely your document problem has changed shape underneath the tool you bought to solve it. None of these are failures of your team — they’re symptoms of using a fixed-layout engine on variable-layout work.

Sign you’ve outgrown it	What it really means	Severity
Your template count keeps climbing and a person maintains them	The maintenance tax has become a standing cost that scales with broker count, not value	Structural
A broker reformats a loss run and extraction quietly breaks	Brittleness to layout drift — zones can’t survive a moved column	Structural
A large share of documents land in “unsupported”	The long tail is most of your submission mail, and it isn’t covered	High
You still manually reconcile fields across documents	No cross-document reasoning — the account-level questions fall to people	High
“Confidence” scores don’t catch wrong values	You have OCR confidence, not semantic validation	High
Your exception queue is where the real work lives	Automation covers the easy forms and defers the hard, valuable ones	Symptom
Onboarding a new document type takes weeks	Setup cost per variant is too high for low-volume formats to ever pay back	Symptom

If most of that list feels familiar, the takeaway isn’t that your IDP was a bad purchase — it’s that the job changed. A tool optimized for a million copies of one form was never going to be optimized for one copy each of a thousand forms that must be understood together. Submissions are the second problem, and they need an engine designed around variability, meaning, and the connections between documents — not around templates and zones.