Insurance requirements are extracted from contracts automatically by software that locates the insurance clause in a contract or lease, reads the coverage types, limits, endorsements and named parties it demands, and converts them into structured requirements a person validates. The output is a checklist that certificates and endorsements can be verified against.
Why is requirement extraction the bottleneck?
Every compliance review is a comparison between what a document shows and what a contract demands. The document side has been automated for years. The contract side has not: someone reads the insurance section of a subcontract or lease, interprets it, and types the requirements into a system. On a portfolio with hundreds of leases or a project with dozens of subcontracts, that is weeks of work, and the requirements drift from the contract as amendments arrive.
Brokers face the same problem from the other direction. A client forwards a contract and asks whether their policies comply. The broker has to find the clause, read it against the client’s program and answer, often under a deadline set by a project start.
Step 1: Ingest the contract and locate the clause
The contract or lease is uploaded as a PDF or scanned document. The software converts it to text, then locates the insurance provisions, which rarely sit in one place: a main insurance article, exhibits with limits, indemnity sections that define who must be named, and amendments or riders that change the original terms.
Locating the clause is harder than it sounds. Insurance language appears under headings like “Insurance,” “Indemnification,” “Risk of Loss” and in exhibits labeled only with a letter. Extraction has to read the whole document, not search for a heading.
Step 2: Extract the requirements into structured fields
From the located text, the software pulls the elements a compliance review needs:
- Coverage types required, such as general liability, auto, workers’ compensation, umbrella or excess, and specialty lines like pollution or professional liability.
- Limits per coverage, including per-occurrence and aggregate, and whether the aggregate must apply per project or per location.
- Required endorsements: additional insured for ongoing and completed operations, waiver of subrogation per line, primary and noncontributory wording, notice of cancellation.
- Parties to be named: the owner, manager, lender, construction manager or other entities the clause lists, often by reference to defined terms elsewhere in the contract.
- Conditions: carrier rating minimums, deductible or retention caps, delivery deadlines and renewal obligations.
Each element becomes a field with a value and a pointer back to the contract text it came from.
Step 3: Normalize into a verifiable requirement set
Contracts say the same thing many ways. “Owner and its affiliates shall be named as additional insureds on a primary and non-contributory basis” and “Contractor’s CGL shall include Owner as an additional insured, with such coverage primary to any insurance maintained by Owner” describe the same requirement. Normalization maps both to the same structured fields so the verification step compares like with like.
Normalization also resolves references. “Owner” has to resolve to the legal entity defined in the preamble, because additional insured status attaches to the exact entity the endorsement names, and a requirement that says “Owner” cannot be verified against a schedule that names an LLC.
Step 4: Validate with a person
Extraction is a draft until a reviewer confirms it. The reviewer checks the fields against the highlighted contract text, corrects misreads, resolves ambiguities the software flagged and decides how to handle clauses that are unusual or internally inconsistent. This step is what makes the output defensible: the requirement set carries a human confirmation and a link to the source language.
Validation is also where the client or risk team makes decisions the software should not: whether to accept a lower limit, whether an alternative endorsement form is acceptable, whether an affiliate list is complete.
Step 5: Verify documents against the extracted requirements
Once requirements exist as structured data, certificates and endorsements can be verified against them automatically. Because a certificate confers no rights and cannot alter the policy, the comparison has to reach the endorsements: does the additional insured form name the entities the contract requires, does the waiver apply to each required line, does the primary wording exist. Gaps are reported against the specific contract requirement they fail, which is what the broker or the subcontractor needs to fix them.
How is this done in practice?
For brokers, the workflow is contract in, checklist out, with the checklist compared to the client’s program to produce a gap report before the project starts. For owners, general contractors and property managers, extraction is the first step of the compliance program: the requirement set per lease or subcontract becomes what every certificate is checked against, and amendments are re-extracted so the requirements stay current.
Jones includes extraction in its platform: a lease or contract is uploaded, the requirements are extracted and confirmed, and every certificate and endorsement for that record is then verified against them, with unlimited extractions included in per-record pricing. Brokers interact with the result through the free submission portal, where the deficiency notice tells them exactly which contract requirement is unmet.
FAQs
Can software read any contract format?
Modern extraction handles PDFs, scans and Word documents, including exhibits and amendments, as long as the text is legible. Heavily redacted or handwritten documents still need a person to read them.
How accurate is automated requirement extraction?
Accurate enough to replace the first read, not the review. Extraction produces a structured draft with each field linked to the contract text; a reviewer confirms it before verification begins. Treat any vendor’s accuracy claim as something to test on your own contracts.
What is the difference between extraction and verification?
Extraction turns the contract’s insurance clause into a requirement set. Verification compares certificates and endorsements against that requirement set. Extraction has to come first, because a review without a specific requirement is a review against nothing.
Why do requirements need to be re-extracted?
Because amendments, assignments and change orders alter limits, entities and coverage types. A requirement set extracted once drifts from the contract; re-extracting on each amendment keeps verification tied to the current terms.
How do brokers use extracted requirements?
To answer “does my client comply” before the project starts, by comparing the extracted checklist to the client’s policies and endorsements and producing a gap report, and to fix deficiencies faster when a GC or owner’s compliance platform tells them exactly which contract requirement is unmet.
Jones extracts insurance requirements from leases and contracts, confirms them with a reviewer and verifies every certificate and endorsement against them, so compliance is measured against the contract rather than a generic standard. See how the Jones Platform handles requirements.
