What’s actually printed on an ACORD 25, how software locates and reads each field, and why confirming the endorsement behind a checkbox is a different job than reading the form.
What information does a certificate of insurance actually contain?
A certificate of insurance is the ACORD 25, the standard Certificate of Liability Insurance form an insurance agent issues on a subcontractor’s behalf. The current edition is ACORD 25 (2025/12). It is not free text. It is a fixed layout, the same blocks and boxes in roughly the same place on every copy, which is exactly what makes it something software can read reliably.
The form carries several distinct groups of information. A producer block identifies the insurance agency that issued it. A named insured block identifies the entity being covered, its legal name and address. Below that, a grid lists each insurer by letter, A through F, with its NAIC number, next to the coverage types in force, typically commercial general liability, commercial auto, umbrella or excess liability, and workers’ compensation with employers liability. Each coverage line carries its own policy number and its own effective and expiration dates, because a subcontractor’s general liability policy and auto policy do not necessarily run on the same calendar.
Next to each coverage type sits a column of limits: each-occurrence limit, general aggregate, products-completed operations aggregate, personal and advertising injury, damage to rented premises, medical expense, and for auto, a combined single limit or split bodily-injury and property-damage figures. Two checkboxes sit near the general liability line, ADDL INSD for additional insured and SUBR WVD for waiver of subrogation. A description-of-operations block carries free text tying the certificate to a specific project or scope. A certificate holder field names who the certificate was issued to, and a certificate number and revision number track which version this is. Every one of those groups is a field a real reading has to locate, extract, and understand, not just a line to glance at.
How does AI actually read a certificate of insurance?
It locates each field by its position and label, reads what is there, and converts it into structured data the rest of the system can use, the same way a person scanning the form would, just faster and without skipping a line.
Because the ACORD 25 has a fixed, predictable layout, this is a semi-structured extraction problem, not open-ended reading. The software identifies the named insured block, the insurer grid, the limits column, and the checkboxes by their position and their labels, then reads the characters in each spot using optical character recognition, the underlying technology that turns a scanned image of text into machine-readable text. On a clean, typed certificate that step is close to solved. On a certificate with a handwritten date, a smudged scan, or a producer’s slightly different layout, it gets harder, and this is where AI-based extraction goes further than raw OCR: it uses the surrounding context, this number is directly under “EACH OCCURRENCE” on the general liability line, to classify what a recognized value actually means, not just what characters it contains.
The output of this step is not a wall of text. It is structured data: a named insured, a list of coverage types, a policy number and date range for each, a set of limits, and the state of two checkboxes. That structure is what makes the next step possible. Extraction turns a PDF into something a rule can be run against.
What does cross-referencing against a requirement standard actually mean?
It means comparing the extracted data against the specific coverage rules for that project, not just confirming the certificate exists. Extraction alone answers what is written on the form. It says nothing about whether that is enough.
Every subcontract or project sets its own requirements: a minimum general liability limit, whether additional insured status is required, whether completed operations coverage is required, whether a waiver of subrogation is required, sometimes a minimum umbrella limit on top of the primary policy. That set of rules, stored once per contract or per project, is the requirement standard. Cross-referencing runs the extracted certificate against it line by line: is the each-occurrence limit at or above the required figure, is the aggregate limit sufficient, is the policy still within its effective dates for the length of the project, is the ADDL INSD box checked where the contract requires it.
This is the step that turns a pile of extracted numbers into a compliance answer. Without a stored standard to check against, extraction produces a list of figures with no way to know whether any of them are correct for this particular job. The standard is what gives the extracted data meaning.
Why is a checked box not the same as an endorsement?
Because the ACORD 25 says so, in its own printed language: the certificate is issued as a matter of information only and confers no rights on the certificate holder. A checked ADDL INSD box is the producer’s claim that additional insured status applies. It is not the endorsement itself, and it does not amend or extend the coverage under the actual policy.
Additional insured status comes from a separate document, an endorsement attached to the subcontractor’s policy. The common ISO forms split the coverage in two: CG 20 10 covers ongoing operations, meaning liability arising while the work is in progress, and CG 20 37 covers completed operations, meaning liability arising after the work is finished. A certificate can show the box checked while only the ongoing-operations endorsement is actually on file, which leaves a gap the moment the project wraps if the contract required completed operations coverage too. The checkbox and the endorsement are two different things: one is a claim on a form, the other is a legal instrument attached to a policy, and only the second one actually extends coverage to a holder.
Why is endorsement verification the hard part, not the data extraction?
Because the proof lives somewhere the certificate does not show it, and because the same checkbox claim can be satisfied by different endorsement forms depending on what the contract actually requires.
Reading a name, a date, or a dollar figure off a standardized form is a largely solved problem today. Optical character recognition on a clean typed document routinely clears very high accuracy, and AI-based field classification handles the layout variation between producers reasonably well. That is table stakes, not the differentiator. What is genuinely hard is everything past the certificate: confirming that the endorsement behind an ADDL INSD claim actually exists as an attached document, confirming it is the right form for what the contract requires (ongoing operations only, or ongoing plus completed operations), and confirming a waiver of subrogation or primary-and-noncontributory claim is likewise backed by its own endorsement rather than just a checked box. None of that information sits inside the ACORD 25’s fields. The certificate only references it.
This is the line between simple document scanning and real compliance automation. A tool that extracts fields and checks them against limits is doing useful, real work, but it is still trusting the certificate’s claims at face value. A system that goes further, treating the checkbox as a claim to verify rather than a fact to record, and either confirming or flagging the endorsement behind it, is answering a fundamentally different question: not what does this certificate say, but is the coverage this certificate claims actually in force.
What does each part of a real certificate check actually verify?
The table below maps the field groups on an ACORD 25 to what a real read has to confirm about each one, and where the check commonly breaks down when it is done by eye instead of by rule.
| ACORD 25 field group | What’s on the form | What a real check verifies | Where it silently breaks |
|---|---|---|---|
| Named insured / producer | Who’s covered, who issued the certificate | The certificate matches the actual subcontractor on the contract, not a similarly named entity | An LLC vs. Inc. mismatch or a DBA name slips past a quick visual scan |
| Insurer letters + policy numbers | Which carrier and policy back each coverage line | Every required coverage type actually has a policy number attached, not a blank field | A blank or placeholder policy number is easy to miss at a glance |
| Policy types & limits | General liability, auto, umbrella/excess, workers’ comp figures | Each limit meets or exceeds the contract’s required figure, line by line | A limit correct in total but split wrong (aggregate met, per-occurrence short) reads fine on a skim |
| Effective & expiration dates | The window each policy is actually in force | Coverage stays active for the full length of the project, not just on the day it’s reviewed | A certificate current today can expire mid-project if nobody tracks the actual date |
| ADDL INSD / SUBR WVD checkboxes | A producer’s claim that additional insured or subrogation-waiver status applies | An actual endorsement exists behind the claim, not just the checked box | The box can be marked with no endorsement ever filed against the policy |
| Description of operations | Free text tying the certificate to a specific project or scope | The certificate was actually issued for this job, not reused from a prior one | A generic or blank description gets recycled across projects unnoticed |
Frequently asked questions
What is an ACORD 25 certificate of insurance?
The ACORD 25 is the standard Certificate of Liability Insurance form, the document an insurance agent issues to show a subcontractor’s coverage. The current edition is ACORD 25 (2025/12). It lists the named insured, the insurer for each coverage type, policy numbers, effective and expiration dates, coverage limits, and checkboxes for additional insured and waiver of subrogation status. The form states plainly that it is issued as a matter of information only and confers no rights on the certificate holder, meaning it shows a policy exists, it does not by itself prove the coverage it describes.
How does AI extract data from a certificate of insurance?
The ACORD 25 is a semi-structured document, a fixed layout where the same kind of data always lands in roughly the same place: named insured in one block, policy numbers and dates in a grid, limits in a column, checkboxes near the coverage lines. AI extraction locates each of those fields, reads the text or handwriting in that position using optical character recognition, and classifies what the value means, this dollar amount is the general liability each-occurrence limit, this date is the auto policy’s expiration. The output is structured data: a named insured, a set of coverage types, limits, and dates, ready to be checked against a rule rather than read by eye.
What is the difference between OCR and AI-based document extraction?
Optical character recognition (OCR) converts the image of text into machine-readable characters, it turns a scanned dollar figure into the digits 1,000,000. On its own, OCR does not know that figure is the general liability each-occurrence limit rather than the aggregate. AI-based extraction goes a step further: it reads the document’s layout and context to classify what each recognized value represents, then maps it to the right field. OCR answers what the text says. Field-level AI extraction answers what that text means on this specific form.
Does a checked additional insured box mean the endorsement is actually attached?
No. The ADDL INSD checkbox on the ACORD 25 is the producer’s claim that additional insured status applies, not proof of it. Additional insured status comes from an actual endorsement to the subcontractor’s policy, commonly the ISO CG 20 10 form for ongoing operations and the separate CG 20 37 form for completed operations, and the certificate itself states it confers no rights and does not amend the underlying policy. A box can be checked with no endorsement ever filed. Confirming the endorsement is a separate verification step from reading the certificate.
Why does AI need a stored requirement standard to check a certificate against?
Extracting the data on a certificate only tells you what is written on the page. It does not tell you whether that coverage is enough. Whether a $1M general liability limit is sufficient, whether additional insured status is required, whether completed operations coverage is required, all of that depends on the specific subcontract or project, not on the certificate. A stored requirement standard is the set of coverage rules for that contract, so the extracted data has something to be measured against. Without it, extraction produces a list of numbers with no way to know if any of them are correct.
What makes endorsement verification harder to automate than reading the certificate’s data fields?
Reading dates, dollar amounts, and names off a standardized form is a largely solved extraction problem. Endorsement verification is harder because the proof lives off the certificate entirely, in a separate policy document or endorsement page the certificate only references, and because the same checkbox claim can be satisfied by different endorsement forms depending on what the contract actually requires, ongoing operations only versus ongoing plus completed operations. A system has to know which form satisfies which requirement and confirm the underlying document exists, not just transcribe what the certificate says about it.
Related reading
- Best COI tracking software for general contractors
- AI COI review for general contractors
- ACORD 25 review checklist for federal projects
- Additional-insured endorsement verification checklist
Primary sources: ACORD certificate of insurance FAQ and FAR 52.228-5.
This is the check Contracts Connected runs on every certificate.
Field extraction, requirement cross-referencing, and endorsement verification, not just a reminder that a certificate exists. Our co-founder ran a large federal general contracting firm for 15 years, about 100,000 documents a year.