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.
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.

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.

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.