Certificate of Insurance Tracking Software: Why Does the Claim Land on Your Policy Anyway?

The certificate is not the insurance, and that is the whole problem

A tenant improvement contractor drops a pipe wrench off a mezzanine and injures a warehouse worker. Eighteen months later the claim is being tendered and your risk manager pulls the file. There is a certificate on the standard ACORD form, in date at the time of loss, with the additional insured box ticked and your entity typed into the description of operations. It looks perfect. Your carrier declines the tender anyway, because the certificate is an informational document that confers no rights, and no additional insured endorsement was ever attached to the contractor's policy. The claim comes back onto your programme, your loss run, and eventually your renewal pricing.

Every experienced risk manager knows this. Almost no tracking process is built around it. The industry default is a spreadsheet of expiry dates plus an administrator who emails brokers, which solves the easiest twenty percent of the problem and leaves the eighty percent that actually determines whether a claim sticks to you.

The scale makes it worse. A general contractor with 600 active subcontractors, or a property operator with 4,000 vendors across a portfolio, receives certificates from hundreds of different brokerage offices, each with its own layout, its own habits about attaching endorsement forms, and its own idea of how much wording to include. The volume guarantees that a human review process degrades into a date check.

Problem 1: expiry tracking is not compliance tracking

What a real requirement set demands goes well past coverage in force. It asks whether general liability includes additional insured status for both ongoing and completed operations, whether that status is granted by endorsement rather than asserted on the certificate, whether coverage is primary and non contributory, whether waiver of subrogation applies, whether the general aggregate is per project rather than shared across every job the contractor is running, whether the umbrella follows form or brings its own terms, and whether the carrier meets your minimum financial strength rating.

Not one of those questions is answered by an expiry date. Several are answered only by the endorsement forms, which arrive as separate pages, or as a form number and edition date typed into a box, or not at all. Reading them is the job, and it is a slow, specialised job that a spreadsheet cannot absorb.

Problem 2: requirement sets are not one set

A landscaper needs different limits than a crane subcontractor. A roofer needs completed operations coverage that matters for years. A vendor working in an occupied hospital carries different requirements than the same vendor in a warehouse. A tenant's contractor is governed by the lease, not by your subcontract. A single global template either overinsures the low risk vendors, which makes onboarding slow and annoying, or underinsures the high risk ones, which is the expensive direction.

The requirement set has to be data: a template per trade, per contract type or per property, versioned so you know which version a given vendor was measured against and when it changed. Then variances become explicit. When a small vendor cannot meet a limit and somebody senior accepts the exposure, that decision should be a recorded approval with a name and an expiry, not an email that nobody can find later.

myCOI, Jones, TrustLayer, Evident ID and Ebix all handle requirement templates to a degree, and for a standard construction requirement set they do it well. The strain shows when your requirements come from a thousand different leases or a hundred amended contracts, because then the template library is genuinely yours and it changes constantly.

Problem 3: the documents are PDFs from a hundred brokers

This is the one place where document extraction earns its cost immediately. The certificate itself is structured enough to parse reliably: named insured, carriers with their identifiers, policy numbers, effective and expiry dates, limits by coverage line. Endorsements are messier, because a broker may attach the form, may reference the form number and edition, or may simply write descriptive wording into the description of operations box that has no contractual effect at all.

A serious build extracts what is there, identifies which endorsement forms are attached by form number and edition date, and then scores the submission against the requirement template with three outcomes rather than two: compliant, non compliant with a specific stated reason, or requires human review. The third category is the honest one, and it is what makes the system trustworthy. Reviewers who learn that flags are reliable act on them. Reviewers who learn that the tool cries wolf go back to checking dates.

The second useful piece of automation is broker correspondence. A non compliance should generate a specific request that says exactly which endorsement is missing on which policy, addressed to the producer on the certificate, with a deadline and automatic follow up. Generic please update your certificate emails are why compliance rates sit where they do.

Problem 4: nothing happens when a vendor is non compliant

Ask a risk manager what their compliance rate is and you will often get a number in the eighties. Ask what happens to the non compliant vendors and the answer is usually a report that goes to somebody. Meanwhile those vendors are on site, invoicing, and creating exposure.

The consequence has to be automated and it has to bite in the systems people actually use. In practice that means two hooks. A hold flag in accounts payable so invoices for a non compliant vendor do not release without a named override. And a status feed into site access so a lapsed vendor hits a locked gate rather than a polite reminder. Both of those are integrations into your own stack, which is precisely why organisations with a serious enforcement posture tend to end up building rather than buying. A third party portal can tell you a vendor is non compliant. It cannot stop your accounts payable run.

Problem 5: the evidence you need is the record as it stood on the date of loss

Claims arrive years later. The question is never what the vendor's insurance looks like today, it is what it looked like on 14 March two years ago, and what your organisation did about any gap at the time. If your system stores a current status per vendor and overwrites it at each renewal, that question cannot be answered.

A build keeps an immutable history: every document received with its receipt timestamp, every compliance determination with the requirement template version it was judged against, every exception approval with the approver, and every chase message sent. Then reconstructing the position on any date is a query. That archive also protects your own people, because it demonstrates that the organisation identified a gap and pursued it, which is a materially different position from having never looked.

What this costs and how long it takes

Across the 2,000 plus projects Digital Heroes has delivered, here is the honest shape. A first release covering requirement templates, certificate and endorsement extraction, compliance scoring with a human review queue, and automated broker chasing runs $50,000 to $120,000 and ships in 10 to 16 weeks. A full platform adding a broker and vendor portal, accounts payable and access holds, exception approval workflow, portfolio reporting and the point in time evidence archive runs $140,000 to $350,000 over 6 to 12 months.

What drives the number up: the breadth of your requirement library, since a portfolio driven by thousands of individual leases is a different exercise from a construction requirement set with four trade tiers. Integration with your ERP (Enterprise Resource Planning) or accounts payable system for holds, which is real work in Yardi, MRI, Viewpoint or Sage. A broker facing portal, because you are then supporting hundreds of external users. And endorsement wording analysis beyond form number matching, if your contracts demand specific language rather than standard industry forms.

What keeps it down: start with your highest risk trade or property type and the top four requirement checks. Extraction quality improves fastest on a narrow document set with real corrections flowing back in.

Build versus buy, and when buying is right

Buy if you have a few hundred vendors, one or two standard requirement sets, and no need to enforce holds inside your own systems. myCOI has genuine insurance expertise behind it, TrustLayer is a competent modern take on the workflow, and Jones is strong in property and tenant contexts. Any of them beats a spreadsheet by a distance, and the subscription cost is a fraction of a build.

Build when two or more of these are true. Your requirement sets are genuinely heterogeneous, driven by leases, amended contracts or client flow downs rather than a single standard. Non compliance must automatically hold payment or site access through systems you own. You operate at portfolio scale where a percentage point of compliance is worth more than the entire project cost. Your contracts demand endorsement wording that standard form matching does not confirm. Or you already run prequalification and safety systems and this data belongs in the same decision rather than a separate portal.

How to choose a developer for COI tracking software

Ask them what an additional insured endorsement is and why the box on the certificate is not sufficient. If they cannot explain that distinction, they will build a very good expiry tracker and you will still be tendering claims onto your own policy.

Ask how the system handles a document it cannot confidently parse. The right answer is a review queue with the uncertain fields highlighted, not a silent guess. Trust in the flags is the entire adoption question.

Ask how they reconstruct compliance status as at a past date, and make them show it. If the data model overwrites status at renewal, walk away.

Ask what the enforcement hook looks like in your accounts payable system by name, not in the abstract. And settle code ownership before kickoff: you should hold the repository, the infrastructure accounts and the right to bring in another firm. At Digital Heroes the client owns the code from the first commit, and on a system holding vendor insurance records that may be evidence in a coverage dispute, that ownership is not a formality.