Payment runs

Verify subcontractor insurance before the payment releases.

Certificate tracking tells you the state of your paperwork. Verification at payment time changes behavior: a payment either releases or holds. Four steps, in order, with the failure mode of each.

2026-09-28 · Kernos team

The only moment insurance verification changes behavior is the moment money moves. A verification done at onboarding is a snapshot; a verification done at each payment run is a control. This is the procedure — four steps, in order, each with the failure mode that skips it.

Step one: pull the requirements out of the prime contract

Start where the obligations actually live: the subcontract. Extract every insurance requirement into an explicit list — coverage types, minimum limits per line, additional insured status, required endorsement forms, and the period each requirement covers. If this list exists only as prose inside a fifty-page agreement, it will be applied inconsistently. The output of this step is a checklist with a source: every line traceable back to the clause that demands it. Failure mode: requirements stay in prose, and every reviewer compares against a different memory of the clause.

Step two: compare the certificate, field by field

Put the certificate next to the requirements and compare deliberately: general liability, auto, workers compensation and employers liability, umbrella — each limit against the contract minimum; the policy period against the work window; the certificate holder and additional insured boxes against the contract's named parties. A certificate is a summary written by the subcontractor's broker. It is evidence, not a conclusion — the comparison is the conclusion. Failure mode: the document is filed unread, and presence gets mistaken for coverage.

Step three: handle every discrepancy as a tracked exception

Most payment runs will surface gaps: an expired certificate, a limit below the requirement, a missing additional insured endorsement. The failure mode here is informal handling — an email to the broker, a verbal assurance, a mental note. Each discrepancy needs three things attached to it: an owner, a deadline, and a resolution path, whether that is a corrected certificate, a policy change, or a documented, approved waiver. An exception without an owner is just a delay with better handwriting.

Step four: hold the payment until the gate clears

Verification only has teeth if its outcome controls the release. Tie the payment to the compliance state: when requirements are met and exceptions are resolved, the payment proceeds; when they are not, it holds — as a rule, not as a judgment call at the end of a long week. Two properties make the hold trustworthy: the person who raised an exception is not the person who clears it, and the record shows what was known at the moment the decision was made.

Where Kernos fits

Kernos implements this procedure as a governed workflow. Contract requirements are objects; certificates are parsed from the PDFs you receive and compared field by field by a rules engine; discrepancies become exceptions with owners and deadlines inside a seven-state approval flow where the initiator cannot approve their own proposal — enforced by the server, not by policy. Every decision lands in an append-only audit chain, and the payment stays staged until the gate clears: compliance enforced at the only moment it matters, the moment money moves. Start from the platform overview, or run the payment-run checklist against your next cycle.