AI & Insurtech

Machine Reading of Broking Agreements: Extracting Commission Terms at Scale

A broking firm with thirty insurer agreements accumulated over fifteen years cannot tell you what it is owed without opening files. Contract NLP can read the rate schedules, accrual triggers and set-off rights into a schema, but the arithmetic downstream must stay deterministic.

Sarvada Editorial TeamInsurance Intelligence
10 min read

Listen to this article

Audio version • 10 min read

contract-nlpbroking-agreementscommission-termsdocument-extractionbroker-operationsai-insurtech

Last reviewed: July 2026

The Document Nobody Has Read Since It Was Signed

Ask a mid-sized Indian broking firm what commission rate applies to a commercial package placed with a particular insurer under a policy incepted last month, and the honest answer is that somebody will have to look. Not at a system. At a file.

The firm has perhaps thirty insurer agreements. The oldest were signed fifteen years ago by people who have left. Each has been amended, sometimes formally through an addendum and sometimes informally through a side letter from a regional office that nobody circulated. The rates live in annexures, and the annexures have been replaced more often than the agreements have. At least one agreement's operative rate schedule exists only as a scanned PDF of a signed page.

This is not a filing failure. It is what happens when a long-lived relationship is documented incrementally by a firm busy placing business. But the consequence is expensive: the firm's revenue terms are unknown to the firm's systems. The broker management system holds a rate because somebody typed one in. Whether it still matches the operative agreement is a question the system cannot answer, because it has never read the agreement.

What the Schema Has to Hold

Extraction is only worth doing against a schema that captures what the firm needs to answer. Four families of term do most of the work.

The rate table. Commission by line of business, sometimes by product, sometimes split further by channel or by new versus renewal. Everyone thinks of it first and it is hardest to extract cleanly, because it is almost never prose. It is a table in an annexure, and tables are where extraction is least reliable. It also carries an implicit structure the document does not state: which dimension wins when a policy matches two rows, and what happens to one matching none.

The accrual trigger. The clause deciding when the firm has earned the commission. Policy inception, premium receipt by the insurer, premium realisation and policy issuance are not the same date. On a policy incepted in March against premium received in April, the trigger decides which financial year the revenue lands in. It is usually one sentence buried in a general payment provision, and it is the most consequential term in the document for the firm's accounting.

Set-off rights. Whether the insurer may net amounts it claims to be owed against commission it owes. Firms are most exposed and least aware here: a broad set-off right lets an insurer unilaterally reduce a payment and leaves the firm arguing after the money has already not arrived. The question is not just whether the right exists but what it reaches, only amounts under this agreement or under any agreement between the parties.

Survival. Whether commission on policies placed before termination keeps being paid on renewal after it. This decides whether a terminated agreement is a closed chapter or a decade-long receivable, and firms routinely do not know which they have. Notice periods and without-cause termination rights sit alongside it.

The schema must also be effective-dated at clause level rather than document level. One agreement will have a rate table that changed three times, a set-off clause amended once, and an accrual trigger untouched since signature. Storing "the agreement as at today" throws away the ability to answer what the rate was in FY2023, exactly what an audit or a dispute asks.

Amendments, Side Letters and the Assembly Problem

The difficulty that surprises firms is not reading any single document. It is working out which documents are in force together.

A language model handed a clean twelve-page broking agreement will pull the accrual trigger and the termination notice competently. But the operative terms are not in that document. They are the agreement, plus a 2019 addendum replacing Annexure B, plus a 2022 side letter varying the motor rate for one region, plus an email chain in which a regional head agreed something that may or may not bind the insurer, plus a 2024 addendum that replaced Annexure B again without mentioning the side letter.

Documents are named inconsistently and stored by whoever received them, so matching an addendum to its parent is itself an extraction task. Beyond that, assembling the operative position means resolving questions the documents do not answer:

  1. What is the ordering? Execution date, effective date and receipt date are three different things, and the effective date is the one that matters and the one most often absent.
  2. What does each instrument supersede? An addendum saying it replaces Annexure B is easy. One that restates a rate without saying whether it replaces or supplements is not, and this is common.
  3. Does the side letter survive the later addendum? A legal question, not an extraction question, and a system that answers it confidently is about to be wrong.

The honest response is that the pipeline should extract and structure, and surface conflicts rather than resolve them. When a motor rate can be sourced to two instruments giving different numbers, the correct output is not the model's best guess. It is a flagged conflict with both candidates, both provenance pointers, and a human decision before either becomes operative.

A system that silently picks a winner between conflicting instruments has done the most damaging thing available to it: produced a confident, wrong number and removed the signal that would have caused anyone to check. A firm is better served by a pipeline surfacing forty unresolved conflicts than by one resolving them invisibly and being right thirty-eight times.

Clause-Level Confidence, and the Rule That Should Not Bend

Extraction produces confidence. What matters is the granularity, and what the firm does with it. A document-level score is useless here. An agreement can extract with high overall fidelity while the one field that matters, the motor rate in the amended annexure, came off a scanned table at low confidence. The average hides the failure that costs money. Confidence has to attach to each extracted field, carry that field's provenance (which document, which page, which clause), and reach the downstream consumer as a first-class attribute rather than metadata nobody reads.

Insist on this because the fields carry different risk. A rate at low confidence, if it reaches the ledger, produces a wrong accrual across every policy it touches, silently, until a reconciliation catches it or an auditor does. A termination notice period at low confidence is a nuisance, checked when termination is contemplated, a deliberate moment with a lawyer present. A set-off clause at low confidence fails more subtly: the firm may not act on it until the insurer does, at which point the extraction was irrelevant.

Thresholds belong per field type, set by what happens when the field is wrong rather than by what the model reports about itself. A model's stated confidence is a claim about its own reliability, and needs validating against a held-out set the firm verified by hand.

The rule

An extracted commission rate below the threshold must not post to the ledger. Not with a warning flag. Not provisionally. It must not post.

A posted number acquires a life of its own. It appears in a receivables report, informs a producer's payout, flows into a management account and eventually a filing. Somebody decides on it. Reversing it is not correcting a field; it is a restatement, and restatements cost far more than the original error. Against that, the cost of not posting is that a human looks at a document.

The Machine Reads, the Arithmetic Does Not

The tension at the centre of this work decides whether the architecture is sound.

Extraction is probabilistic. Commission arithmetic is not.

A model reading a scanned annexure infers under uncertainty, and will sometimes be wrong. That is not a defect to engineer away; reading a document to find what it says is a perception problem, and perception problems have error rates. Computing what is owed is not. Given a rate, a premium, an accrual trigger and a date, the commission is determinate: exactly one right answer, obtainable by arithmetic. A system producing a distribution over it has made an engineering mistake, not an epistemic observation.

The conclusion follows: the probabilistic component must terminate at the schema boundary. The model's job ends when a rate, with a validity window and a provenance pointer, is written into a structured store, having passed a threshold or a human review. Everything downstream is deterministic code on structured values. No model sits between the stored rate and the computed commission, adjudicates a discrepancy, or estimates what a rate probably was. That is what lets a firm say its commission figures are computed rather than estimated, with the only judgement in the chain a human's, logged and dated.

It also clarifies what the pipeline is not. It does not tell the firm whether the insurer's statement is right; that is a matching problem against a different document with different pathologies, treated in automating commission statement reconciliation across insurers. Agreement extraction supplies the authoritative expectation the reconciliation compares against. Without it, a reconciliation matches a statement to a number somebody typed in years ago, which is agreement by coincidence.

Review Workflow, and Keeping the Extraction Current

A pipeline that extracts thirty agreements once and is never touched again is a project. One that stays true as agreements change is a system, and the difference is the workflow around it.

The review queue

Human review is not a fallback for when the model fails. It is a designed stage with its own throughput and quality bar. Two things make it work.

Route by consequence, not by score. A low-confidence termination clause and a low-confidence rate should not sit in one queue at one priority. Rates block the ledger; they go first.

Show the source, not the score. A reviewer given "rate: 12.5%, confidence 0.62" can do nothing with the second number. Shown the value beside the highlighted clause it came from, they resolve it in seconds. The unit of review is the document region, not the field.

Currency

Agreements change, and the change arrives as an email, not an event. The pipeline cannot know a side letter was signed last Tuesday unless new instruments have a path to reach it. Firms that get this right make the ingestion path the only sanctioned way an agreement is filed, so the pipeline sees everything by construction rather than by diligence. Periodic re-extraction is the cheap insurance: it catches documents that arrived out of band, and drift when a model upgrade quietly changes behaviour on scanned annexures. Model updates are change events, tested against a verified sample first, the same discipline that applies across the broker copilot stack.

The timing argument is not that the technology just arrived. It is that the terms are about to matter more. IRDAI is preparing an overhaul of commission rules, and as of the date of this post the consultation paper had not been published; it was reported in early July 2026 as expected by end-July. Everything discussed publicly, including staggered or trail structures and differentiated caps, is at proposal stage and none of it is a rule. But a firm that cannot state what its agreements say will be unable to assess whatever the paper proposes, having no baseline to measure against. Sarvada gives commercial insurance broking firms structured, searchable access to insurer documentation, so the terms a firm's revenue depends on are readable, comparable and current rather than sitting in a folder nobody has opened since signature. Request Access to see how it applies to your agreement set.

Frequently Asked Questions

How is extracting a broking agreement different from extracting a policy wording?
They are different documents solving different problems. A policy wording defines what is covered for the client, and extraction from it feeds renewal comparison memos and client advice, where an error is caught by a human reading the memo. A broking agreement defines what the firm is owed by the insurer, and extraction from it feeds the revenue ledger, where an error posts silently and may only surface at restatement. Agreements also arrive as a chain of amendments and side letters rather than as one document, so the assembly problem of working out what is operative has no equivalent on the wording side.
Why is the accrual trigger singled out as the most consequential clause?
Because it decides when the firm has earned the commission, and the candidates produce different answers. Policy inception, premium receipt by the insurer, premium realisation and policy issuance are four different dates. On a policy incepted in March against premium received in April, the accrual trigger determines which financial year the revenue lands in. The clause is usually a single sentence buried in a general payment provision rather than flagged, so it is easy for both a human reader and an extraction pipeline to pass over, and its effect on the accounts is larger than the rate table's in any period where the two dates straddle a year end.
Can the pipeline resolve conflicts between a side letter and a later addendum?
It should not try. Whether a side letter survives a later addendum that restates the same rate without mentioning it is a legal question about the parties' intent and the instruments' drafting, not an extraction question. A system that answers it confidently is a system that is about to be wrong in a way nothing downstream will catch. The correct output is a flagged conflict presenting both candidate values with pointers to the clause and document each came from, routed to a human whose decision is recorded as a dated act. A pipeline surfacing forty unresolved conflicts is safer than one resolving them invisibly.
What confidence threshold should a firm set for commission rates?
The threshold is less important than the rule it enforces, which is that a rate below it does not post to the ledger at all, not provisionally and not with a warning flag. A posted number acquires a life of its own through receivables reports, producer payouts and management accounts, and reversing it is a restatement rather than a correction. The threshold itself should be set from a calibration exercise against agreements the firm has manually verified, because a model's stated confidence is a claim about its own reliability that needs testing. If 0.9-confidence extractions are right 70 percent of the time, every threshold built on that score is wrong.
How do you stop the extracted store from going stale?
By making the ingestion path the only sanctioned way an agreement document is filed, so the pipeline sees new addenda and side letters by construction rather than by someone remembering to forward them. Agreements change through email, not through events, so a pipeline with no ingestion discipline describes the agreements as they stood on the day of the project. A periodic re-extraction against the full document set is the cheap backstop: it catches instruments that arrived out of band, and it catches drift when a model upgrade quietly changes behaviour on the firm's scanned annexures.

Related Glossary Terms

Related Insurance Types

Related Industries

Related Articles

Sarvada Intelligence

Ready to see Sarvada in action?

Explore the platform workflow or start a product conversation with our underwriting automation team.

Explore the platform