How Construction COI Tracking Still Lives
in Emails and Spreadsheets

The COI Spreadsheet Is a Universal Rite of Passage — and Nobody Brags About It

On Reddit's r/ConstructionManagers, a new project coordinator posted six months ago: "I'm basically spending my entire day chasing subs over email to get their new COI before one expires. This feels completely insane and incredibly high-risk. A single missed date on this spreadsheet could cost the company millions. Is this really how everyone does it?"

The replies formed a collective shrug: yes, this is how everyone does it, and yes, it is a nightmare. One PM described their system as "spreadsheets and phone calls." Another noted fear of "tracking the lapsed license until the county inspector showed up." In a third thread, a small GC straightforwardly asked: "Is it normally a hassle?"

What these threads reveal is not that construction professionals are bad at compliance. What they reveal is that COI tracking occupies a blind spot in the industry's technology stack — a task that falls between project management software and accounting systems, claimed by neither, solved by no one.

The default tool is always the same: a master spreadsheet. Columns for subcontractor name, policy type, carrier, policy number, coverage limits, effective date, expiration date, additional insured status, waiver of subrogation, and a notes field that grows longer every renewal cycle. When the spreadsheet stays under 30 rows, it works. At 50 subcontractors with four policy lines each, you are maintaining 200 data points across a matrix where a single stale cell can mean an uninsured sub performing work on an active site.

A Certificate of Insurance Is Not the Policy — and the Spreadsheet Cannot Tell the Difference

The ACORD 25 Certificate of Liability Insurance — the industry-standard COI form used across US construction — contains a statement in bold capital letters that most people skip: "THIS CERTIFICATE IS ISSUED AS A MATTER OF INFORMATION ONLY AND CONFERS NO RIGHTS UPON THE CERTIFICATE HOLDER. THIS CERTIFICATE DOES NOT AFFIRMATIVELY OR NEGATIVELY AMEND, EXTEND OR ALTER THE COVERAGE AFFORDED BY THE POLICIES BELOW."

These are not fine-print disclaimers. They are the legal architecture of the document. A certificate of insurance summarizes what an insurance agent believes a policy says. It does not bind the insurer. It does not guarantee that the listed coverage exists. It does not prove that the general contractor has been added as an additional insured, even if that phrase appears in the certificate holder box.

Dig into what those failures look like, and you see why a spreadsheet cannot catch them. The COI lists a $2 million general liability aggregate — but the actual policy contains an exclusion for the specific trade work the sub is performing. The certificate shows the GC named as additional insured — but only on a CG 20 10 endorsement covering ongoing operations, not the CG 20 37 covering completed operations, leaving a gap after the sub finishes work that takes months to discover. The waiver of subrogation box is checked — but the endorsement was never actually filed with the carrier.

An ACORD 25 form, according to the Independent Insurance Agents & Brokers of America, is vulnerable to three major problems: certificate fraud by agents who indicate coverages that do not exist so a sub can secure a job; onerous contractual insurance requirements that available marketplace policies simply cannot satisfy; and the persistent issue of certificate holders never receiving actual notice of cancellation despite what the certificate promises. The spreadsheet sees none of this. It records what the PDF says and moves on.

Every COI tracking spreadsheet in construction is therefore built on a foundation of systematically unreliable data. The data entry bottleneck — the five minutes per certificate spent typing fields from a PDF into Excel — is real, but it is the second-worst problem. The worst problem is that the data being typed is wrong 90% of the time and the spreadsheet has no mechanism to detect it.

The Four-Party Relay Race Nobody Designed and Nobody Wins

To understand why email and spreadsheets remain the default COI workflow, trace the path a single certificate travels.

The general contractor sends a contract to the subcontractor specifying required insurance: general liability at $2 million per occurrence / $4 million aggregate, workers' compensation at statutory limits, commercial auto at $1 million, umbrella at $5 million, with additional insured and waiver of subrogation endorsements. The subcontractor forwards these requirements to their insurance agent. The agent pulls policy information from the carrier's system and populates an ACORD 25 form — a process that, as the IRMI audit showed, has a 90%+ error rate against the contract terms.

The agent emails the COI PDF to the subcontractor, who forwards it to the GC's project coordinator. The coordinator opens the PDF, reads each field — policy number, carrier name, coverage types, limits, effective date, expiration date, additional insured Y/N, waiver of subrogation Y/N — and types them into the master spreadsheet. The PDF goes into a shared network folder with a filename convention that varies by who saved it last. The spreadsheet gets updated. The coordinator sets a calendar reminder for 30 days before expiration.

Four parties, four handoffs, zero verification of underlying policy terms. The coordinator at the end of this chain is transcribing data that originated from a document that was itself compiled from a carrier system by an agent working from a forwarded email — four degrees of separation from the source of truth. At each step, data degrades. A wrong digit in a policy number. A coverage limit that got transposed. An additional insured endorsement that was discussed on a phone call but never filed.

This is not a broken process that could be fixed with better discipline. It is a multi-party workflow where every participant has different incentives. The sub wants to get on site and get paid — insurance paperwork is friction. The sub's agent wants to retain the account — issuing a certificate that says what the contract wants, even if the policy doesn't deliver, serves that goal. The GC's coordinator wants to check a box and move to the next sub. The carrier's actual policy language is the only thing that matters in a claim, and it is the one thing nobody in the chain except the agent's underwriter ever reads.

Insurance policy renewals compound this exponentially. A subcontractor's general liability policy renews annually, but not on the same date as their workers' compensation. Their umbrella renews on a third date. Their auto on a fourth. Every renewal cycle triggers the full four-party relay for every policy line on every subcontractor — and every renewal creates a new opportunity for an error that lands in the spreadsheet as if nothing changed.

The Industry Bought the Software. The Spreadsheet Stayed.

Construction is not a technology-averse industry. The Associated General Contractors of America's 2025 Outlook Survey found that 66% of large contractors use project management software, 44% use estimating software, 40% use scheduling software. The average firm deploys 6.2 distinct digital tools. This is not an industry that refuses to adopt technology. It is an industry where the technology that was adopted was not designed to solve the COI problem.

Procore manages change orders, RFIs, submittals, punch lists. It does not verify whether a subcontractor's general liability policy actually covers the work they are performing. To get COI compliance tracking inside Procore, a GC must purchase a separate integration: Billy, myCOI, Jones, SmartCompliance, or TrustLayer. Each of these tools connects to Procore via API and syncs compliance status, but the fundamental data capture step — someone reading a COI PDF and extracting its fields — remains a manual step that happens before the software can do anything useful.

The Billy platform's Procore Side Panel, for instance, allows a compliance manager to see subcontractor insurance status without leaving Procore — but someone must first upload the COI PDF, and either the managed review team or the GC's internal staff must verify it against requirements. myCOI performs a similar function with a team of licensed insurance experts. Jones adds AI-powered verification that flags exclusionary language in the actual policies. These are valuable services. But they operate on top of the same data-capture bottleneck that the spreadsheet faces: a PDF arrives via email, and someone must decide what it says.

The reason the spreadsheet persists is not that contractors refuse to buy software. It is that the software they bought was designed to manage compliance status once the data is in the system — not to get the data into the system from the PDFs that arrive through email. That step — reading policy numbers, coverage limits, and expiration dates off a one-page ACORD form and entering them into a structured record — is the un-automated middle mile of the entire workflow. Until it is solved, every COI tracking platform is downstream of a manual transcription step, and every spreadsheet user who stays on the spreadsheet recognizes at some level that paying for a platform to manage data they still have to type in manually is not a clear improvement.

The Missing Layer: Getting Data From the PDF Into the Spreadsheet Without Typing

If the structural problem is that COI data lives inside PDFs and tracking tools need structured data, the most direct intervention is not to replace the spreadsheet or buy another platform. It is to collapse the manual transcription step — the five minutes per certificate, the transposed digits, the copied-and-pasted expiration dates — into something that happens automatically when the PDF arrives.

This is where document extraction changes the economics of COI tracking. Instead of reading fields off the ACORD 25 form and typing them into Excel, you define the columns you need — Policy Number, Carrier, Coverage Type, Occurrence Limit, Aggregate Limit, Effective Date, Expiration Date, Additional Insured (Y/N), Waiver of Subrogation (Y/N) — and let the AI locate each value on the COI PDF. The output is a row in your spreadsheet with every field populated, no typing involved. The PDF goes into a folder. The data goes into the tracker. The gap between receiving a certificate and having it logged closes to seconds.

This approach works because ACORD 25 forms, despite their standardization of layout, still arrive in practice as scanned images, flattened PDFs, digitally signed documents, and occasionally photographs of printed certificates taken from a job trailer — all formats where traditional OCR template matching fails because the pixel positions shift. ImageToTable.ai's column-name extraction bypasses this by understanding the semantic content of the form rather than matching coordinates: it identifies "Insurer A" and grabs the adjacent policy number based on what the text means, not where it sits.

What makes this approach sustainable is that it does not require you to abandon your existing workflow. You can keep using your spreadsheet. You can keep using your shared folder. You can keep using — or add — a COI tracking platform like Billy or myCOI downstream, because extracted data feeds into any system that accepts Excel or CSV. The email relay still runs — subcontractors still get policies from their agents and forward COIs to the GC — but the coordinator no longer spends their day transcribing those PDFs into cells. The spreadsheet becomes a dashboard fed by extraction, not a data entry terminal.

The same extraction layer works across the broader document compliance puzzle that construction project coordinators face. Subcontractor invoices arrive in 15 different formats, but the AP team needs the same fields from every one. Lien waivers, W-9s, and business licenses each have their own data that someone currently types into a separate tracker. Column-name extraction treats them all as the same operation: define the columns, upload the documents, get structured data — regardless of which compliance category they belong to.

This is not a replacement for dedicated COI tracking platforms. Those platforms verify policy language, flag exclusionary endorsements, track compliance across projects, and provide audit trails — functions that a spreadsheet cannot replicate and an extraction tool does not attempt. Extraction solves the problem one step upstream: getting the data out of the PDF and into whichever system will use it next. It is the layer that was missing from the beginning — the reason the spreadsheet became the default and stayed the default even after the industry adopted every other software category.

Frequently Asked Questions

Why doesn't Procore or Sage handle COI tracking?

Procore and Sage 300 CRE are project management and accounting platforms — they organize financial and operational data once it is in the system. Neither was designed to read a COI PDF, extract insurance fields, or verify that the coverage listed on a certificate matches the underlying policy. Procore's App Marketplace lists third-party add-ons (Billy, myCOI, Jones, SmartCompliance) that connect COI compliance status back into the Procore dashboard, but the initial data capture step — reading an ACORD 25 form — still requires a human or a separate extraction tool. The gap is not in Procore's feature set. It is in the architectural assumption that COI data arrives pre-digested.

Why can't we just require all subcontractors to submit COIs through a portal?

Portals shift the data entry burden from you to the subcontractor or their insurance agent — but they do not eliminate it. Someone still has to read the ACORD 25 form and populate fields. The friction of requiring every sub's insurance agent to log into yet another platform is the reason portal-based COI tracking tools report low vendor adoption rates. A subcontractor who works for six different GCs cannot be expected to maintain accounts on six different compliance portals. This is why email persists: it is the only communication channel with 100% adoption across every subcontractor, every insurance agent, and every GC coordinator. The more effective intervention is to make the receiving end capable of processing whatever format arrives through that universal channel.

Is a certificate of insurance legally binding?

No. An ACORD 25 certificate of insurance is, by its own terms, issued "as a matter of information only" and "confers no rights upon the certificate holder." It does not amend, extend, or alter the insurance policy it describes. The only legally binding documents are the insurance policy itself and any endorsements attached to it. If a certificate lists the GC as an additional insured but the endorsement was never actually filed with the carrier, the GC has no coverage — regardless of what the certificate says. This is the single most dangerous misunderstanding in construction compliance, and it is why IRMI's audit finding that 90%+ of contractor insurance fails to meet contract requirements is not a paperwork problem — it is an uninsured exposure problem.

What's the difference between ACORD 25 and ACORD 28?

ACORD 25 is a Certificate of Liability Insurance — it summarizes liability coverages (general liability, auto, workers' compensation, umbrella) that protect against third-party claims. This is the form subcontractors submit to GCs. ACORD 28 is an Evidence of Commercial Property Insurance — it documents property coverage (building, contents, equipment) for first-party losses. In construction, the ACORD 25 is the form GCs receive 95% of the time; the ACORD 28 appears when a project owner needs proof that the GC or a subcontractor carries builder's risk or equipment coverage. Both carry the same legal disclaimers: neither is a policy, and neither confers rights on the certificate holder.

Does an AI extraction tool verify whether the coverage is adequate?

No. An extraction tool populates structured data from a COI PDF — policy numbers, coverage limits, expiration dates — but it does not verify whether those numbers satisfy the contract's insurance requirements, whether the listed endorsements actually exist on the policy, or whether the coverage described on the certificate matches the carrier's actual policy language. That verification step requires either a human compliance specialist reading the policy or a dedicated COI tracking platform with policy-level verification capabilities. Extraction simplifies the data entry layer. Compliance verification is a separate and necessary step downstream.