Use caseDocument AIWorkflow automation
Commercial insurance submissions assembled from proposal forms, loss runs and property schedules
Proposal forms, loss runs and schedules of values extracted, reconciled and built into per-insurer submissions, each one checked by an account handler first.
A blueprint, not a client story. The business described is illustrative; the architecture, integrations and trade-offs are real, and this is how I would build it. By Ergini, .
The short version
A document workflow for commercial insurance brokers. It collects a client's proposal or ACORD forms, loss runs and schedules of values, extracts and reconciles the data, and drafts a submission for each insurer whose appetite fits the risk. It runs beside the broker management system (Acturis, Applied Epic, Vertafore, or BiPRO-connected tools in Germany) and builds the quote comparison. An account handler checks every submission before it goes to market, and advice and placement stay with the broker.
- Best for
- Independent commercial brokers placing mid-market property, liability and fleet risks with a panel of insurers, by email and portal.
- Connects to
- Broker management system (Acturis, Applied Epic, Vertafore), Outlook, Excel schedules of values, Insurer portals and e-trading, BiPRO interfaces (Germany)
- The AI does
- Reads every document the client sends, maps messy spreadsheets and loss runs to one schema with page references, and drafts each insurer's submission and the quote comparison.
- People do
- Release every submission after checking it, raise sensitive gaps with the client, adjust the insurer shortlist, and advise on which quote to take.
- Built as
- AI Workflow Automation, usually $15K - $30K
Renewal season at a fifteen-handler broker
Picture an independent commercial broker in the English Midlands: fifteen account handlers, a book of mid-market property, liability and fleet risks, and a panel of around twenty insurers. The broker runs on Acturis. Renewals start about three months out, and new business arrives whenever a competitor's client gets tired of waiting for answers.
Every risk arrives as the same pile, and the pile is never complete. There is the client's proposal form or fact-find, a schedule of values in Excel with the client's own column names, several years of claims experience (loss runs, in US terms) from each previous insurer, and a survey report. Last year's policy schedule is often missing, because clients rarely send it. What does arrive rarely agrees: the schedule lists five sites, the proposal form six, and one loss run was printed eight months ago.
Then comes the re-keying. Each insurer wants the same facts in its own shape: one portal asks for construction in its own codes, another wants a presentation by email, a third sends a supplementary questionnaire about cladding or hot work. A mid-sized renewal can disappear into carrier-portal admin before any underwriter sees it, and the questions that come back ('what is the sprinkler status at site 3?') are usually about data the client did send, in a document nobody had time to read.
Speed is only half the problem. A submission with a wrong sum insured or a claim left out is an errors and omissions exposure for the broker, and in the UK the Insurance Act 2015 puts a duty of fair presentation on the client that the broker is there to help them meet. Faster is only worth building if it is also more accurate.
Six documents, six sets of checks
Extraction pulls the fields; the checks are where the value is. This is the starting schema for a property and liability risk, which I extend per class of business, built on the approach in the AI document extraction guide.
| Document | What is extracted | What code checks |
|---|---|---|
| Proposal form or fact-find (ACORD 125 and 140 in the US) | Insured, trade, turnover, wage roll, sites, claims declared, answers to underwriting questions | Every site on the form exists in the schedule of values; declared claims reconcile with the loss runs |
| Schedule of values (Excel) | Per site: address, construction, occupancy, year built, protections, building, contents and business interruption values | Totals match the declared total insured value; subtotal rows are excluded; values unchanged from last year are flagged |
| Loss runs or claims experience | Per claim: date, cause, status, paid, outstanding and incurred, plus the report's valuation date | Paid plus outstanding equals incurred on every line; the valuation date is inside each insurer's freshness rule |
| Survey report | Recommendations and their status, fire and security protections | Open recommendations are listed for the handler; none is marked complete unless the client confirms it |
| Last year's policy schedule | Insurer, limits, excesses, sums insured, endorsements | Year-on-year changes in sums insured, limits and sites are shown side by side |
| Fleet and driver schedule | Vehicles and values, drivers, dates of birth, driving license endorsements | Conviction details are criminal offense data under GDPR Article 10: visible to the handler, sent only to insurers being approached |
The route a renewal file takes to market
The model reads and drafts. It never chooses which insurers see the risk, never fills a gap in the client's answers, and never sends anything on its own.
01 Trigger · Acturis or Epic, Microsoft Graph
A renewal comes due or an inquiry lands
The broker management system flags a renewal entering its window, or a new-business email arrives. Either opens a case with a checklist built from the risk's classes: property adds a schedule of values, fleet a driver schedule.
02 AI model · Vision model, structured output
Classify and extract every attachment
Each file is sorted (proposal form, schedule, loss run, survey, policy schedule) and extracted into a fixed schema, with a page or cell reference behind every value.
03 Plain code
Reconcile the documents against each other
Sites are matched across the form, the schedule and last year's policy after addresses are normalized and geocoded. Loss run arithmetic is checked, valuation dates are compared with each insurer's rule, and totals are recomputed. None of this needs a model.
04 Decision
Ready for market?
Rules per class of business decide, not the model.
- All required documents are present, reconciled and recent enough then build the submissions
- Gaps only the client can fill: values for a site, an updated loss run then draft a request to the client for the handler to send
- Documents contradict each other, or a claim on a loss run is missing from the proposal form then stop, and show the handler both sources side by side
05 Plain code
Shortlist insurers from the panel's appetite
Appetite is kept as rules the placing team maintains: classes written, value ranges, territories, loss history limits, excluded trades. The shortlist is computed and every exclusion is explained, and the handler can add or remove markets before anything is drafted.
06 AI model · Model with insurer templates
Draft one submission per insurer
The presentation or email is written from the reconciled data, in each insurer's preferred order and format. Supplementary questions are answered only where a document contains the answer, with the source attached; everything else is written as 'to confirm with client'.
07 Person
The account handler checks and releases
The review screen shows each value beside its source, every reconciliation warning and the draft. Nothing reaches an insurer until a handler releases it, and each release is logged against their name.
08 System · Microsoft Graph, insurer portals
Send, track and log
Released submissions leave from the handler's mailbox or go into the insurer's portal. A send that fails stays 'released, not sent' and retries, and it is only marked sent once the mail server or portal confirms. Quotes, declinatures and questions coming back are matched to the case and logged in the broker management system.
09 Result
A quote comparison the broker can advise from
Premium, excesses, limits, notable exclusions and subjectivities are extracted from each quote into one table, each linked to its page. The broker writes the recommendation and the demands-and-needs statement.
Five sites, two loss runs and a handwritten sixth address
Extraction is the easy half. The time comes back through reconciliation, because that is where the questions an underwriter would ask get found before the submission goes out.
Renewal case R-2291, food manufacturer, 94 days to renewal
- classify_documents(case: "R-2291")schedule of values, 1 sheet, 6 data rows / loss run, insurer A, 3 pages / loss run, insurer B, 1 page / proposal form, 11 pages, handwriting on p. 4
- map_schedule(file: "SOV 2026 final v3.xlsx")'Bldg Sum' to building_value, 'Stock & Contents' to contents_value, 'Constr' to construction (2025 mapping reused) / row 6 is a subtotal, excluded / 5 sites
- extract_loss_run(file: "insurer_A_loss_run.pdf")valued 14 Jan 2026 / 7 claims, 6 closed / open: escape of water, site 3, paid 18,400, outstanding 22,000, incurred 40,400
- shortlist(case: "R-2291")panel of 21 / 6 write food manufacturing / 4 within the value range / 1 excluded: open escape-of-water claim above its limit / shortlist of 3
- reconcile(case: "R-2291")sites: form 6 (one added by hand on p. 4, 'Unit 9, Riverside Way'), schedule 5: MISSING FROM SCHEDULE / insurer A loss run older than the freshness rule of 2 of 3 shortlisted insurers / building values at 4 sites identical to 2025 / claims declared on form 6, on loss runs 8
Submission workflow · Review queue
R-2291 is not ready for market. 1) Unit 9, Riverside Way is on p. 4 of the proposal form, added by hand, but not in the schedule: values needed. 2) Insurer A's loss run is valued 14 January: request an update. 3) Two claims on the loss runs are not declared on the proposal form. 4) Building values at four sites are unchanged since 2025. Draft client email for 1, 2 and 4 attached.
Account handler · Review queue
Sent the client email. I'll call their finance director about the two undeclared claims myself before anything goes to market.
- The undeclared claims are a disclosure question, so the workflow raised them and left the conversation to the handler.
Stale loss runs, phantom sites and other traps
Loss runs in a dozen formats, some of them stale
Insurers print claims experience differently: reserves split by head of claim, incurred only, or a one-line letter saying there are no known losses. The schema keeps paid, outstanding and incurred apart with the valuation date, and a report older than a shortlisted insurer's rule produces a drafted request for a fresh one instead of a submission sent with an apology.
A site that exists in one document only
Sites get added by hand, sold without anyone updating the schedule, or renamed. Addresses are normalized and geocoded so 'Unit 9, Riverside Way' and 'Riverside Wy U9' count as one site, and a site present in one source but missing from another stops the file until a person resolves it.
Values nobody has updated
A sum insured left alone for years while rebuild costs rose is the classic underinsurance trap, and where the policy carries an average condition a claim can be cut in proportion. The workflow flags unchanged values and prompts a conversation about a valuation. It never changes a figure itself: only the client can declare what their buildings are worth.
The insurer question the documents cannot answer
The dangerous failure is a model answering 'no' to 'any composite panels?' because nothing said yes. Every answer carries its source, an answer without one is written as 'to confirm with client', and the review screen counts the open answers so none slips through by accident.
Portals that do not want to be automated
Some insurers take data by API or over BiPRO, many only through a web portal, and some portal terms forbid automated access. Where automation is allowed, a browser step pre-fills the portal for the handler to check and submit, the pattern described in legacy system automation. Where it is not, the system produces a keying sheet in the portal's own question order.
The same risk sent twice
Every market approach has an ID built from the case, the insurer and the renewal date, so a retry or a double click cannot put the same risk in front of an underwriter twice with different figures. Changes after a submission go out as a marked update in the same thread, never as a fresh submission.
The broker's liability decides the split
Anything that represents the risk or shapes advice is a person's call. The human-in-the-loop patterns write-up covers how to design that boundary.
The AI model
Sort attachments and extract fields with page and cell references
Varied layouts, handwriting and client spreadsheets are where a model beats a template.
Map a client's schedule headers to the site schema
Proposed once per client, confirmed by a handler, reused at every renewal.
Draft submissions, client requests and the quote comparison
Writing to each insurer's format is slow for people and quick to check.
Plain code
Reconcile documents, loss run arithmetic and valuation dates
Arithmetic and date rules should give the same answer every time.
Shortlist insurers from the appetite rules
Appetite is the placing team's knowledge, kept where they can read and change it.
A person
Release a submission to market
It is the broker's representation of the risk, with E&O exposure attached.
Raise undisclosed claims or underinsurance with the client
A conversation that needs judgment and a relationship.
Recommend a quote and place the risk
Advice is the broker's job, recorded against the client's demands and needs under the IDD.
Is your broker platform about to do this for you?
Start with what your platform is shipping. Applied Systems has announced an Epic Submissions Manager, and if your agency runs on Epic it is worth seeing what that covers before commissioning anything. Further along the chain, FurtherAI (a $25M Series A) and Sixfold (a $30M Series B) sell submission intake and underwriting support to carriers and MGAs. FurtherAI cites one MGA going from about 32 minutes to about 1 minute per submission, which is the vendor's own figure. Those tools sit where submissions arrive, not where a broker assembles them.
For small commercial business that trades on insurers' e-trading platforms through Acturis, quoting is already electronic, and a custom build adds little beyond reading documents at the front. A build earns its cost on mid-market and specialty risks placed by presentation and email, where every insurer wants a different shape, client documents are messy, and the broker's own panel, appetite knowledge and templates are the value. Most insurance AI products I see are aimed at carriers, MGAs and large brokers; independent brokers are mostly left with their inboxes.
The hybrid I would suggest keeps the broker management system as the record, puts this workflow beside it reading and writing through whatever access your platform allows, and gives handlers a review screen built for reconciliation instead of their inbox. In Germany the same design reads insurer data over BiPRO wherever it exists, rather than parsing a PDF of data that is already structured somewhere.
How you would know it is working
A blueprint has no results to report, so here is what I would measure from the first week instead, on your own data.
- Time from complete file to first submission out
- From the moment reconciliation passes to the first insurer approach, per class of business, against the same renewals last year.
- Underwriter questions per submission
- Information requests from insurers, tagged by whether the answer was already in the client's documents. This is the most direct measure of submission quality.
- Field accuracy on reviewed values
- Every correction in the review screen is recorded by field and document type, so extraction quality is tracked on the broker's own paperwork.
- Problems caught before market
- Missing sites, stale loss runs and undeclared claims found by reconciliation, counted per renewal and followed through to how each was resolved.
- Edits per draft, by insurer template
- How much of each draft handlers rewrite before release. A high number points at a template to fix, not a handler to retrain.
What a build like this costs
This is built as AI Workflow Automation, which runs $3.5K - $60K overall. A build like this one usually lands in the multi-step workflow tier: $15K - $30K, 3-5 weeks. The first working version runs on your real data well before the end of that window.
What it costs to run
Model costs follow page counts: reading and drafting a mid-market renewal file of a few hundred pages typically costs somewhere between well under a euro and a few euros, small next to a handler's time. Document storage is a minor monthly cost, and browser automation for insurer portals adds compute per submission.
What moves the price
- Classes of business at launch: property alone, or liability, fleet and specialty lines too, each with its own documents
- How many insurers need their own submission format or portal, and whether their portal terms allow pre-filling
- What access the broker management system gives you: an API, scheduled exports, or neither
- Turning the placing team's appetite knowledge into rules, and how often that knowledge changes
- The share of handwritten and scanned material, which sets how much review the extraction needs
Who this is for
- Independent commercial brokers whose account handlers disappear into re-keying every renewal season
- UK brokers on Acturis placing mid-market property and liability by presentation rather than e-trading
- US agencies re-keying ACORD 125, 126 and 140 data into carrier portals and chasing loss runs
- German commercial brokers combining BiPRO data with insurers' own risk questionnaires
Questions people ask about this
Can AI extract data from ACORD forms and loss runs?
Yes. Typed ACORD forms and most loss runs extract reliably, and handwriting and poor scans are routed to review with the image beside the value. The harder part comes afterwards: checking that sites, claims and values agree across documents, and that loss runs are recent enough for each insurer. Those checks are plain code, and they catch the questions an underwriter would otherwise send back.
How do I stop re-keying quote data into every insurer's portal?
Enter the data once, in a schema you own, and generate each insurer's version from it. Where an insurer accepts data by API or BiPRO, it is sent that way. Where only a portal exists and its terms allow automation, a browser step pre-fills it for the handler to check. Where automation is not allowed, a keying sheet in the portal's own question order removes most of the typing.
How do I automate commercial insurance submissions without adding E&O risk?
Keep the model away from anything that represents the risk. It reads and drafts; code checks the numbers and applies appetite rules; a handler releases every submission after seeing each value beside its source. Insurer questions the documents do not answer stay visibly open instead of being guessed. E&O exposure comes from wrong data going out unchecked, so the design makes checking fast rather than optional.
Does it work with Acturis, Applied Epic or Vertafore?
It works beside them. The broker management system stays the record of clients, policies and renewals; the workflow reads renewal dates and client data from it and writes back every market approach and quote. How that connection is made depends on the API access or exports your platform and contract allow, which is the first thing I check when scoping.
What does a submission intake workflow cost to build?
It usually lands in the multi-step tier of AI workflow automation shown on this page: three to five weeks for a first class of business with reconciliation, drafting and the review screen. The number of insurer formats and portals, and the access your broker management system allows, move it most. Running costs are mainly model usage per renewal file.
Sources