AI for Data Entry in Insurance

An endorsement instruction arrives as two sentences buried in a reply chain: add the new location, uplift the contents sum insured, effective from the date the lease completed. Somebody in policy administration opens the record, works out which fields those sentences touch, keys the change, and moves to the next email. None of it is difficult. It is relentless, and it is how a book of record gets built.

That is the desk this article is about: the operations team keying risks, endorsements, bordereaux and statements into the policy administration system. Nobody here sets appetite or price. The job is to make the systems reflect decisions taken elsewhere, accurately.

Why the book of record deserves its own project

An insurer's book of record is assembled by people retyping other people's documents. Everything the business believes about itself comes from that keying: what exposure it holds, what it has ceded, what it owes brokers, what it must report.

The defining feature of errors here is their delay. A wrong expiry date, a sum insured keyed an order of magnitude too high, a commission rate taken from the previous agreement: none of these complain at the moment of typing. They surface in a reinsurance calculation, a return that has to be resubmitted, a claim on a policy that should have lapsed, or an aggregate position nobody knew they held. By then the documents are scattered and whoever keyed the record has moved teams. Data quality is the real deliverable here, and speed on its own is the wrong thing to buy.

New business setup, when the documents disagree

An accepted risk arrives for keying as documents that do not quite match. The submission form gives one version of the insured's legal name, the quote sheet another, and the covering email adds a condition that appears in neither. The inception date in the email is the date the client wanted, not the date agreed.

An agent extracts each field from each document, maps them onto the fields your system requires, and reports where the sources disagree rather than silently picking one. That disagreement list is the valuable output. Set the precedence rules explicitly before you build: which document wins for legal entity, which for limits, which for dates.

Endorsements are prose that has to become fields

Mid-term adjustments are the purest form of this problem. The instruction is written in ordinary English by somebody not thinking about your data model. Remove the vehicle. Add the subsidiary. Increase the limit for the duration of the exhibition, backdated to when the works started.

Turning that into structured change means identifying the affected records, the fields, the new values and the effective date, then letting the system calculate. An agent can propose that change set and show the sentence it came from: the machine reads and maps, the human confirms the interpretation.

Instructions touching several records at once are routinely half applied by humans under pressure, so an agent that enumerates every affected record earns its place. Anything genuinely ambiguous about the effective date should stop.

Bordereaux, and the shape that changes without warning

Delegated authority is where keying volume concentrates. Partners send spreadsheets in whatever shape their own systems produce, and the shape drifts between months. A coverholder renames a field, splits a column in two, or starts reporting gross where they previously reported net, and tells nobody.

An agent that maps by meaning rather than by column position survives most of that: it recognises that an unfamiliar heading carries content it knows, and flags what it cannot place rather than loading it into the nearest field. The discipline that keeps this safe is refusing to be clever when money is involved. Premium, commission, limits and dates map explicitly or queue.

When the risk and premium views do not reconcile

Risk and premium bordereaux from the same partner for the same month frequently disagree: policies present in one and absent from the other, premiums that do not sum, cancellations reflected in one view only. That reconciliation is mechanical comparison, which an agent does well. What it cannot do is decide which version is true. It produces the exception list; somebody asks the partner.

Broker statements, cash and the missing reference

Payments arrive against statements never designed for machine matching. A remittance covers many policies in one figure, the reference is missing or refers to the broker's internal number rather than yours, and commission deductions are applied inconsistently.

Matching cash to policies is pattern work across several signals: amount, timing, the statement lines and that broker's past behaviour. An agent proposes allocations with evidence attached and queues the rest. Clearing the ordinary allocations frees your team for the residue, where the recoverable money sits.

Reading the issued document back against the record

This is the highest value use of extraction on this desk and the most commonly skipped, because it runs in the opposite direction. Instead of reading a document to create a record, you read the document you issued and check it against what was keyed.

The schedule, certificate or endorsement confirmation the customer received is the version that counts in a dispute. If the system holds an excess the document does not show, or the document names an entity the record does not, you want to know now, not when a claim tests it. An agent can compare every issued document against its record and produce a short list of mismatches, and it is the cheapest thing to deploy, because it writes nothing.

Renewals, where last year's record is the draft

At renewal the previous record is the starting point, which makes the failure mode obvious: whatever was wrong last year carries forward, and whatever changed during the year is buried in correspondence nobody reads again.

The useful agent builds the difference. It reassembles the year's endorsements, the changes agreed in email and the notes about entities added or sites closed, then shows what the renewal record should look like against a straight roll forward.

The fields that fail quietly

Some fields punish small errors out of all proportion. Dates are the obvious set: cancellations, reinstatements and lapses all turn on effective dates, and a return premium is only as good as the dates underneath it. A cancellation keyed to the wrong day produces a refund nobody queries when the error favours the customer.

Commission and brokerage terms are the other set, agreed per broker and keyed by hand from an agreement stored somewhere else. A rate keyed slightly wrong does not error. It leaks, on every transaction, until a broker audit or a margin review finds it. Treat both sets as a separate tier, with tighter thresholds and mandatory review.

Master data in an insurance book

The same insured, broker or group entity accumulates several times over: spelling variants, trading names, a subsidiary keyed as a parent, an entity that changed name at renewal. Deduplication is harder here than in a supplier master because the duplicates are often legitimate. Two entities with nearly identical names may be separate insureds in the same group, with separate policies and limits, and merging them corrupts aggregate exposure where you need it accurate.

So give an agent wide authority to propose matches and narrow authority to create or merge, with a human confirming anything touching group structure.

Confidence thresholds and the post or queue decision

Every extracted field carries a confidence, and every record needs a decision: post it or hold it. One global threshold is the common mistake, because consequence is not evenly distributed. A wrong correspondence address costs a letter. A wrong sum insured, effective date or commission rate changes money and exposure.

Set thresholds per field, tied to consequence rather than to how confident the model feels. Premium bearing and exposure bearing fields get a high bar and human review; descriptive fields can post at ordinary confidence. Start with a queue for everything, because reviewing a prefilled record is far faster than keying one, so the saving arrives immediately.

The trail that makes a correction possible

For every field written, record the document it came from, the page, the confidence, the rule applied and the human who approved it. When an audit or a reinsurance query reaches back to a record keyed months ago, that trail is the difference between an answer and an excavation. The fields humans correct most often also map where the system is weak.

Evaluating it on records you have already corrected

You do not need a pilot to find out whether this works, because you already have the test set. Take records your team keyed and later corrected, and use the corrections as ground truth.

Run the agent against the original documents in shadow and compare, field by field, against both the first keying and the corrected version. You learn two things at once: whether it matches your corrected output, and whether it catches the errors your own process caught late. Look hardest at the contested cases, because agreement on the easy records tells you nothing.

Where AI fails here

A genuine contradiction between two source documents cannot be resolved by reading harder. When the quote sheet and the email disagree about a limit, somebody has to ask, and an agent that picks the more plausible value has manufactured a fact.

Entity identity has the same character. The agent cannot know which of two spellings is the real legal entity, or tell a trading name from a subsidiary, without information the documents do not contain.

Silent wrong keying is worse than a queue. A queue is visible and gets worked. A confidently posted wrong effective date propagates into premium, exposure and reporting, and is found by whatever process later depends on it.

Partner formats change without notice, and a bordereau in a new shape will break something. Monitor mapping failures and keep a manual path open.

Undocumented convention stalls this work more often than model quality does. If your precedence rules live only in the heads of two experienced people, writing them down is the project.

Where to start

Pick the narrowest thing with real volume. Reading issued documents back against the record is a strong first deployment, because it writes nothing and finds errors immediately. Bordereaux from a single partner is a good second.

Measure the manual baseline first, run into a review queue, and widen straight through posting only where evidence from your own contested records supports it. For a plain view of which part of your keying is automatable now and which is not, describe it to Adopt AI Partners at hello@adoptaipartners.com.