Every general contractor tracks certificates of insurance somewhere, and for most mid-market firms that somewhere is a spreadsheet. It has columns for each sub, each line of coverage, limits, and expiration dates, and the person who built it kept it accurate for a while. Then certificates kept arriving, projects multiplied, and the tracker quietly stopped being true. This article walks through the COI tracking lifecycle, the specific points where a spreadsheet fails, and what it takes to keep verification current without assigning someone to it full time.
What COI tracking actually involves
The work starts before the first certificate arrives. Each subcontract carries insurance requirements: minimum limits for general liability, auto, workers' compensation and employer's liability, sometimes umbrella coverage, plus endorsement requirements such as additional insured status and a waiver of subrogation. Those requirements differ by contract, by project, and often by owner, so "compliant" never means one fixed thing across your book of work.
Then the documents come in. Every broker formats its submissions differently, certificates arrive with or without the endorsements that matter, and a renewal certificate may quietly drop a coverage the expiring one carried. Policies expire mid-project, which means a sub who was compliant in March can be uncovered in August without anyone on your side doing anything wrong. Tracking all of this means reading each document against the specific requirements that apply to that sub on that project, recording the result, and rechecking whenever anything changes.
The three failure points
Spreadsheet trackers break down in predictable places.
The tracker records arrival, not adequacy. A row that says "COI received 4/12" tells you a PDF exists. It does not tell you whether the certificate names your entity correctly, whether the additional insured box is backed by an actual endorsement, or whether the limits match what the subcontract requires. Reading a certificate carefully takes minutes, and reading the endorsements behind it takes longer, so under deadline pressure the check often becomes "a document showed up." The spreadsheet then displays a green cell that means less than everyone assumes it means. (We cover what a real review looks at in what to check on a subcontractor's COI.)
Expiration monitoring depends on someone looking. The expiration date column only protects you if a person filters it regularly and sends the renewal requests. That person has other duties, and the week they're consumed by a project closeout is the week three policies lapse. Unlike an overdue invoice, a lapsed policy produces no signal of its own. Nothing happens, which is exactly the problem, because the exposure exists precisely during the quiet period nobody noticed.
Shared spreadsheets drift. When project accountants, risk staff, and PMs all touch the tracker, versions fork and edits overwrite each other. One person updates the copy on their desktop, another updates the shared drive, and reconciling them becomes its own recurring chore. The document that was supposed to be the single source of truth becomes a set of documents in partial agreement.
What the gap costs
The consequence of a stale tracker is subs working without verified coverage while the project moves on. Most of the time nothing comes of it, which is why the condition persists. When something does come of it, the sequence is unpleasant: a loss occurs, the claim reaches the sub's carrier, and coverage that everyone assumed was in place turns out to be missing an endorsement or to have lapsed at renewal. Whether that gap ultimately costs your firm money depends on facts and contract language that no blog post can predict, and your risk manager and broker are the right people to assess your particular program. What can be said generally is that the cheapest moment to catch a coverage gap is before the sub mobilizes, and a stale spreadsheet catches almost nothing at that moment.
What automated tracking changes
The spreadsheet's real defect is that it depends on scarce human attention for reading documents, comparing them to requirements, and noticing dates. Those are exactly the tasks that current AI handles well, provided the workflow keeps people in charge of judgment calls.
Bex Insurance works this way. Your requirements are configured in plain English, per project or per program. When a sub's certificate arrives, Bex reads the whole submission—certificate, endorsements, and policy documents together—and produces an assessment listing which of your requirements are satisfied, which are not, and which are ambiguous. When something is missing, Bex writes to the sub directly, names the specific deficiency, and continues the correspondence until the file is complete. Routine cycles run without your team touching them; unusual policy structures and conflicting endorsements are escalated to your people with Bex's analysis attached, because ambiguous coverage questions deserve human judgment. Since everything happens over email, the entire history of every exchange sits in your own mail system, which is a better audit trail than any spreadsheet tab (more on that design choice here).
The tracker doesn't disappear; it becomes an output instead of a chore. The current state of every sub's compliance is derived from documents that were actually read, not from cells that were last updated whenever someone had time.
Where to start
If your COI tracker has a "last verified" date more than a month old on any active sub, that's the gap worth measuring first. We're happy to take a stack of your real certificates and show you the assessment Bex produces against your actual requirements—the contact link is below.