Reading what the broker actually sent

You already know what a submission is and you have opened more of them than we have. The problem was never the definition.

The problem is that one risk arrives as a covering email, a slip, three versions of a schedule and a photograph, and exactly one of those is machine-readable.

How SnapLine takes a submission in

Extraction runs over the whole bundle, in whatever shape it turned up.

  • Email bodies, including the ones carrying material terms that never made it into an attachment
  • PDF slips, native and scanned
  • Excel schedules of values, across tabs and across versions
  • Scanned documents and photographs

Extraction runs over the bundle rather than document by document, which matters because the same field often appears in four places with three different values. SnapLine keeps the disagreement visible instead of picking a winner off-screen. Where a required field is genuinely absent, it goes to the outreach view and becomes a request back to the broker, not a guess.

01Bundle
One pass over the bundle
02Classify
03Read
04Reconcile
05Record
Illustrative: the documents and values shown are fictional. Classifying, reading and reconciling happen in one pass over the bundle rather than document by document, which is why a field appearing in four places with three values can be carried as a disagreement. Amber marks a field a person has to settle; green, one read without conflict.

It opens where the submission already is

The add-in runs inside the underwriter's own Outlook. Nothing is forwarded to a portal, and no one is asked to adopt a second inbox, which is the step most intake tools lose people at.

By the time the email is open, clearance has run, the bundle has been read, and the panel on the right is already saying which fields came out of it and what is standing between the risk and a quote. Opening it in full gives you the queue and the detail view.

A broker submission open in Outlook with the SnapLine add-in beside it, showing clearance passed, a sufficiency score of two out of six, the fields read from the attachments, and four blockers to raise before the risk can be quoted.
Intake starts in the inbox, not in another system. Illustrative data throughout: the insured, broker and carrier are invented.

Why London Market documents are hard

Document AI trained on invoices and contracts does acceptably on documents that announce what they are. A London Market submission does not announce anything. It assumes a reader who already knows the conventions.

The MRC slip is the clearest case. It is a sectioned instrument, not prose. Information is distributed across sections by convention rather than by label, fields are positional, and much of what matters is a cross-reference to something attached elsewhere in the bundle. A general-purpose model reading it linearly produces text that is technically accurate and underwriting-useless. It has read the words and missed the document.

The rest of the bundle is no kinder. Schedules of values come in whatever format the broker's client gave them. Scans are scans. The covering email frequently contains a term that contradicts the slip, usually the most recent and therefore the correct one.

Provenance is per field, not per document

Knowing a number came from somewhere in the bundle is not provenance. Every field links to the region of the document it was read from, with the confidence, the reason it was flagged, and anywhere else in the bundle the same figure appears.

The panel is where an underwriter settles a value without opening the attachment, and where a vendor audit finds out whether we can show our working.

An extracted field table with a panel open on total insured value, showing the spreadsheet row it was read from, a confidence score, why it is flagged for review, where else the figure appears, and the options to validate, correct or ask the broker.
Every field opens onto the cell or page it came from. Illustrative data throughout: the insured, broker and carrier are invented.

What separates this from generic extraction

Three more things, and none of them is model size.

An underwriter validates the record. The output is a draft that a person confirms or corrects, not an answer handed down. This matters less as a philosophical position than as an operational one: you are accountable for what you bind, and a system that cannot show its working cannot be used by someone who is.

The judgements are insurance judgements. Valuation adequacy flagging is not text extraction. Neither is vacancy detection across a portfolio. These are questions about the risk that happen to be answerable from the documents, which is a different problem from reading the documents well.

Absence is treated as information. A missing year built, a schedule that stops short, a loss run that stops short of the period that was asked for. Generic extraction returns null and moves on. SnapLine routes it to outreach, because the gap is the thing you need to act on.

The honest test

Our sample submissions are chosen to work. Yours are not. Bring three of your own into the demo and watch what the provenance view does with the awkward one.

If the result is a record you would be prepared to underwrite from, there is a fixed-scope Proof of Value across twenty of your live submissions, with a written report at the end. If it isn't, that's a short conversation and we'll have taken half an hour of your time.

Book a demo