Product

How Sealinn reads a certificate — and what happens when it isn't sure

Software that reads insurance paperwork is only worth having if it tells you when it is unsure. Here is exactly where the line sits, and what falls on each side of it.

The question underneath the question

When a contractor asks how accurate this is, they are rarely asking for a number. They are asking something sharper: on the day it reads a limit wrong, does that certificate quietly land in the approved pile, or does somebody get told? Because a wrong number you can see is an inconvenience, and a wrong number you cannot see is the thing that shows up later attached to a claim.

So this page describes the mechanism rather than advertising a percentage. We have not measured this against a labeled corpus of certificates, so we will not publish an accuracy figure — and you should treat any vendor's number with the same suspicion until they tell you what they measured it on.

It reads the form field by field, not as a blob

A certificate arrives as a PDF or a phone photo. Sealinn renders the page and reads the ACORD 25 the way you would: box by box. The named insured, and the insurer behind the general liability. The GL limits — per occurrence, general aggregate, products and completed operations — with the policy number and the effective and expiry dates. The workers' compensation limits and when that policy runs out. Auto and umbrella. Both narrow Y/N columns — ADDL INSD and SUBR WVD — and the additional insured named beside them. The certificate holder. Anything else clearly labeled on the form comes back too, as an extra rather than a field it went looking for.

The important part is what comes with each value: a confidence score for that field specifically, not one score for the document. A certificate can have a perfectly crisp expiry date and a general aggregate that has been faxed, scanned and re-scanned until the second digit is a smudge. One number for the whole page would average those together and tell you nothing useful about either.

Four fields carry the most weight

Not every field carries the same weight. Four are treated as critical — the general-liability per-occurrence limit, the general aggregate, the policy expiry date and the named insured. Those are the values that decide whether coverage exists, whether it is enough, and whether it is still in force.

  • Every field read at 95% or better, and no coverage violation — the certificate is approved without a person, and the subcontractor's status updates. That is stricter than the four above: those set the confidence score you are shown, while clearing without a human needs every value the reader returned.
  • Any field between 75% and 95% — the document goes to your review queue with that field flagged amber. It is probably right. Somebody should glance at it.
  • Any field below 75% — the document goes to the queue flagged red, and the least-confident fields are sorted to the top of the screen so the first thing you see is the thing most likely to be wrong.

In the review screen every value sits next to its own confidence and next to the original document. You can correct any field inline; corrections are saved to the document and the coverage is re-checked against your requirements immediately, so you see the consequence of the correction rather than having to work it out.

A W-9 never auto-approves, whatever the confidence

Tax paperwork always goes to a person. That is a deliberate exception to everything above, and it is not about read quality — it is that a document carrying someone's tax identity should not be filed by a machine on its own judgment. Sealinn also records only whether a TIN is present, never the number itself.

An unreadable endorsement blocks. It does not pass.

This is the design decision worth understanding, because it is the one that separates a compliance tool from a filing cabinet with opinions.

When your requirements say the sub must carry a waiver of subrogation, Sealinn can reach one of three conclusions: it is there, it is not there, or the certificate could not be read clearly enough to say. The third case is the interesting one. Treating "could not read it" as "fine" is how a certificate with an unreadable endorsement column ends up approved — and the more damaged the scan, the more likely it is to sail through.

So it goes the other way. An endorsement requirement that cannot be confirmed produces a blocking flag, worded as what it is — could not be read, verify it manually — rather than as a false negative. The same applies to additional insured and to primary and non-contributory. A blocking flag also suppresses auto-approval, so an unreadable certificate can never approve itself.

You will occasionally be asked to confirm something that was genuinely fine on a bad scan. We think that is the right trade for a document whose entire purpose is proving somebody else's insurance, and you can approve past it in one click — see what Sealinn checks for exactly which requirements behave this way.

What it flags that has nothing to do with confidence

Some problems are perfectly legible and still wrong. Sealinn raises these as warnings rather than blocks, because each has an innocent explanation often enough that refusing the document would be wrong:

  • The named insured does not match the subcontractor you contracted with. Usually a DBA or a parent entity — occasionally a certificate for a different company entirely. Either way it is worth a look before the crew arrives, because a policy covering a different legal entity covers nothing of yours.
  • The policy period is longer than thirteen months. Standard terms are twelve. A longer one is sometimes a genuine extended policy and sometimes a date that was typed rather than read off the policy.
  • The effective date is in the future. The coverage described has not started yet.

You can always overrule it, and it says so

Every automatic conclusion is reversible by a person with review permission. You can approve a document that carries blocking violations by recording why — the exception is stored with the approval, so a year later the file explains itself instead of looking like a mistake. You can reject a document with a reason and, if you want, send the sub a fresh upload link in the same action. You can edit any extracted value.

All of it is written to an append-only audit log. The application's database account has no permission to update or delete a row in that table — not as a policy, as a grant. That is described properly on the security page.

What it does not do

  • It does not read the policy. It reads the certificate, and the certificate is a summary someone else typed. Where it matters, you still want the endorsement — how to verify a certificate covers what to ask for and who to ask.
  • It does not contact the carrier. Nothing here confirms with the insurer that a policy is still in force today; it reads what the document says.
  • It does not rate the carrier. The insurer's name is read off the certificate, and the NAIC number too when it is legible — as an extra field rather than a standard one. No financial-strength judgment is made about either: the rating and the licensing status are separate lookups you run yourself.
  • It does not give you legal advice. Whether a given endorsement satisfies a given subcontract is a question for your counsel or your broker.

Upload one of your own certificates and see where it lands.

The worst one you have is the useful test — a phone photo of a fax of a scan. Free for up to 10 subcontractors, no card.