Certificate of Insurance Tracking Software Problems: The 6 That Put Claims Back on Your Policy, and How to Avoid Them

Why does a COI project get scoped as an expiry tracker so often?

Because the expiry date is the one field on the certificate that every reviewer understands and every developer can validate without learning insurance. It parses cleanly, it sorts, it makes a dashboard. So the first release ships as a renewal chaser, everybody agrees it is better than the spreadsheet, and the actual exposure is untouched.

The compliance question was never whether coverage is in force. It is what the policy grants you. Does general liability extend additional insured status for both ongoing and completed operations, and is that status granted by an endorsement rather than asserted in a text box. Is the coverage primary and non contributory. Is there a waiver of subrogation. Is the general aggregate per project or shared across every job that contractor is running this year. Does the umbrella follow form or bring its own terms. Does the carrier meet your minimum financial strength rating. Not one of those is answered by a date.

The fix is to make the requirement set data rather than a policy document, with each of those checks expressed as a rule that a submission passes, fails or cannot be assessed. Three outcomes, not two. The third one is what makes the system honest: compliant, non compliant with a stated reason, or requires human review. Reviewers who learn the flags are reliable act on them. Reviewers who learn the tool cries wolf quietly go back to checking dates, and you have paid for a renewal chaser after all.

What goes wrong when you migrate years of certificates and vendor records?

The certificates are the easy part. The vendor master is where the migration actually fails. The same contractor appears four times under a legal name, a trading name, a slightly different legal name after a restructure, and a misspelling somebody typed into accounts payable in 2019. Merge them wrongly and a compliant vendor inherits a lapsed record. Leave them separate and your compliance rate is measured against a denominator that is not real.

The second problem is that historical determinations cannot be reproduced. Somebody approved this vendor in 2023, but nobody recorded which version of which requirement template they were judged against, so the file says approved and cannot say approved for what. If a claim from that period is contested, that gap is the finding.

What works is narrow. Migrate only certificates that are currently in force, and treat everything older as a read only archive attached to the vendor rather than as data you try to score retrospectively. Resolve vendor identity against whichever system already owns the vendor key, normally your enterprise resource planning (ERP) or accounts payable system, and make that system the authority rather than inventing a second one. Then backfill the live population in waves ordered by risk rather than alphabetically, starting with the trades and properties where a claim would hurt most. Expect the first wave to report a compliance rate materially lower than your spreadsheet claimed. That gap is the finding, not a defect in the software, and it is worth telling your leadership before the number appears rather than after.

Why do accounts payable and site access integrations break after launch?

Because they are the only two integrations with teeth, which makes them the two that people route around. A report that a vendor is non compliant changes nothing. An invoice that will not release, and a badge that will not open a gate, change behaviour immediately, and behaviour that changes generates pressure.

Three failures recur. The first is identity drift: the COI system and the finance system disagree about which vendor record is which, so a hold lands on the wrong entity or fails to land at all, and after two of those finance asks for the integration to be switched off. The second is the untraceable override. Somebody senior tells accounts payable to pay it anyway, the payment goes out, and there is no record tying that decision to a person. Six months later nobody can explain why a non compliant vendor was paid on a job where an injury occurred. The third is the silent feed. Site access status is pushed once at onboarding and never again, so a vendor whose policy lapsed in March is still badging in during August and the system reports full compliance because nothing errored.

The fixes are specific. Take the vendor key from the system that already owns it, in Yardi, MRI, Viewpoint, Sage or whatever you run, and never let the COI system mint its own. Make every override a first class object with a named approver, a reason and an expiry date, so it lapses rather than becoming permanent. And make status feeds heartbeat, meaning the receiving system expects an update on a schedule and raises an alarm when it stops arriving, because the dangerous integration failure is not the one that throws an error, it is the one that goes quiet while everyone assumes it is working.

What happens when point in time evidence and exception approvals are not covered?

Claims arrive years after the loss. The question is never what a vendor's insurance looks like today. It is what it looked like on a specific afternoon two years ago and what your organisation did about any gap at the time. A data model that holds a current status per vendor and overwrites it at each renewal cannot answer that, and the answer is the entire reason the system exists.

What has to be preserved is a chain, not a status: every document with its receipt timestamp, every determination with the requirement template version it was judged against, every exception approval with the approver and the expiry, and every chase message actually sent. Then reconstructing your position on any date is a query rather than an archaeology project across email archives and a shared drive.

The exception path deserves particular attention because it is where organisations lose control quietly. A small vendor cannot meet a limit, somebody senior accepts the exposure, and the acceptance lives in an email nobody can find. That is fine right up until it is not. Recorded properly, the same decision protects the person who made it, because the file shows a deliberate, documented, time limited acceptance rather than an oversight. That distinction is the difference between a defensible programme and one where the only evidence is that nobody looked.

Should you build custom or configure what you already own?

If you have a few hundred vendors on one or two standard requirement sets, and you have no need to hold payment or access inside your own systems, buy. myCOI has genuine insurance expertise behind the review workflow, TrustLayer is a competent modern take on the same process, and Jones is strong where the requirements come from leases and tenant contexts. Any of them beats a spreadsheet by a wide margin, and the subscription is a small fraction of a build. Configure the requirement templates properly, insist that your team reads endorsements rather than certificates, and put the difference into your broker relationship.

Build when two or more of these are true. Your requirement sets are genuinely heterogeneous because they come from thousands of individual leases, heavily amended contracts or client flow down clauses rather than one standard. Non compliance has to hold payment or site access automatically through systems you own. You operate at portfolio scale where a percentage point of compliance is worth more than the whole project. Your contracts demand specific endorsement wording that matching a form number and edition date does not confirm. Or you already run prequalification and safety systems and this data belongs inside the same decision rather than in a separate portal your team logs into once a month.

How do hidden costs get into the quote?

The requirement library is the first and largest. A construction programme with four trade tiers is a different exercise from a property portfolio where every lease sets its own terms, and a quote that does not ask how many distinct requirement sets you have is priced for the first case.

The second is the enforcement integration, named rather than abstract. A line reading accounts payable integration covers one system, one environment and one vendor key convention. If you run two property management systems because of an acquisition, that is two integrations and a reconciliation problem between them.

The third is the broker portal, which converts an internal tool into a product with hundreds of external users, password resets, access requests and a support burden that lands on your team rather than the developer. The fourth is the review queue itself, because extraction quality only improves if corrections flow back, and somebody has to be funded to work that queue in the early months. The fifth is your own people: writing down requirement sets that currently exist as institutional knowledge is your risk manager's time and your counsel's time, both on the critical path and neither in any developer's number. The sixth is backfilling the existing vendor population, which is a real project measured in months and is almost always presented as a data load.

What separates a build that works from one that fails here?

Sequence decides it. The builds that work ship requirement templates, document extraction and a human review queue first, then add enforcement hooks once the flags are trusted, then add the broker portal last. The ones that fail start with the portal, because it is the visible part, and end up with an attractive vendor experience feeding a review process that is still a person checking dates.

Pick one high risk trade or property type and four requirement checks for release one. Extraction accuracy improves fastest on a narrow document set with real corrections behind it, and a system that is right about four things is more useful than one that is uncertain about twenty.

Name the person who owns enforcement before you build the enforcement. A hold in accounts payable is an operational policy with a human consequence, and if nobody has agreed who overrides it and on what grounds, the integration will be disabled within a quarter.

Insist that every determination stores the rule version it used, from the first commit. Retrofitting that later means restating history, and restated history is precisely what a coverage dispute will attack.

Finally, settle ownership in writing before kickoff: the repository, the cloud accounts and the right to bring in another firm. At Digital Heroes the client owns the code from the first commit. On a system whose archive may be read years later in a coverage dispute, being unable to reach your own records without a vendor's cooperation is a governance problem rather than a commercial inconvenience.