COI Correction Version Control: Prevent Duplicate and Stale Submissions

File control

COI Correction Version Control: Prevent Duplicate and Stale Submissions

A corrected certificate can still fail administratively when an older attachment is uploaded, two “final” files circulate, or the package no longer matches the reviewer’s request. Simple version control makes the outgoing evidence reproducible.

Reviewed September 2026 · Educational information, not insurance or legal advice

Do not alter issued evidence. Contractors can organize and rename their own copies for filing, but certificate or endorsement content must come from an authorized issuer. Never edit a PDF to create the appearance of a correction.

Why stale files survive ordinary corrections

A COI rejection often starts an informal chain: the reviewer emails the contractor, the contractor forwards the request, the agent returns documents, and several people download copies. The corrected item may be accurate, yet an outdated certificate remains attached to an old draft email or selected in the portal upload dialog.

The underlying documents also serve different purposes. California State University, Stanislaus explains that a certificate and an additional-insured endorsement are separate items in its insurance evidence process. Treating every PDF as an interchangeable “COI” makes it easier to omit the document that actually answers the request.

Version control is not a coverage opinion. It is a way to answer four administrative questions: Which package is current? What changed? Who sent it? What outcome followed?

A lightweight version-control system

Use three folders or states

State Allowed contents Rule
Source Original rejection, written requirement, and issued files received Preserve; do not silently replace
Working Agent request, comparison notes, and candidate package Only the assigned owner assembles the outgoing set
Submitted Exact package delivered plus receipt and event note Read-only snapshot for that attempt

The folders can be locations in an approved document system rather than literal desktop folders. The important behavior is separation: issued source files remain distinguishable from working notes and from the exact submitted snapshot.

Use one attempt label

Choose a short sequential label such as V1, V2, and V3. Apply it to the log and package folder. Do not embed claims such as “approved,” “compliant,” or “complete” in the filename unless an authorized reviewer has actually provided that outcome and the organization’s naming policy allows it.

Add a human-readable date

A sortable date such as YYYY-MM-DD helps distinguish attempts. The date should describe the controlled package or delivery event, not the underlying policy effective date. Keep policy dates inside the issued evidence and the field-by-field review.

Keep document type visible

Use labels such as Certificate, GL Endorsement, Auto Evidence, Requirement, or Receipt. This helps the submitter compare the outgoing set with the checklist instead of counting undifferentiated PDFs.

The pre-submission package check

  1. Return to the rejection. Highlight each separate item without rewriting it into a broader assumption.
  2. Match the current written requirement. Confirm names, evidence roles, coverage lines, limits, dates, and requested supporting documents.
  3. Identify issued evidence. Confirm that every certificate and endorsement came from the authorized agent, broker, carrier, or issuing process.
  4. Remove stale candidates. Move older working files away from the upload or attachment location.
  5. Open every outgoing file. Check that it is readable and belongs to the correct project and current attempt.
  6. Create the submitted snapshot. Copy the exact outgoing set into the submitted state before or immediately after delivery.
  7. Record the receipt. Capture the portal confirmation, sent-message record, secure-link notice, or other permitted evidence of delivery.

King County’s contractor insurance guidance illustrates why a package may involve several evidence requirements and endorsements rather than a single generic file. The exact requirements vary by contract; the version system should preserve that specificity.

Control each attempt

Connect the version, change, package, delivery route, and result.

The local log creates a timeline and CSV without uploading certificate or policy data to COI Workbench.

Build a version timeline

A clean handoff between contractor, agent, and client

Party Owns Should not be assumed to own
Client or reviewer Exact evidence request, portal format, recipient, deadline, and review outcome Issuing or changing insurance documents
Agent or broker Accurate issued certificates, policy questions, and applicable endorsement evidence Changing the client’s contract or portal record
Contractor Accurate project facts, controlled package, delivery, and event history Editing issued evidence or declaring coverage

When a task crosses roles, log the handoff. “Asked agent to review holder wording” is different from “agent issued replacement certificate.” “Uploaded V2” is different from “client accepted V2.” These distinctions keep the timeline truthful.

When to start a new version

  • An issued certificate or endorsement in the outgoing package changes.
  • The client confirms a different legal entity, holder address, policy line, or evidence requirement.
  • A stale or incorrect attachment must be replaced.
  • The delivery package changes after a reviewer response.

Do not start a public-facing version merely because an internal spelling note changed. The label should help reconstruct actual submission attempts, not inflate every draft into an event.

Frequently asked questions

Can I rename a certificate PDF?

Follow the issuer’s, client’s, and organization’s file-handling rules. Renaming a local copy for filing must never alter its content or imply a status it does not have.

Should V2 contain only the corrected document?

Use the client’s current submission instructions. Some reviewers want a complete replacement package; others request only a specific item. Record what was actually sent.

What if the agent sends several revised files?

Keep the received source files distinguishable, select the correct current evidence through the authorized workflow, and snapshot the exact set submitted.

Is email “Sent” proof that the reviewer accepted the package?

No. It documents one delivery event. Receipt, review, and acceptance remain separate statuses.

Sources and scope

The file-control model is an original administrative framework. Adapt it to the client portal, issuer instructions, contract, privacy rules, and organizational records policy.