Correction tracking
How to Keep a COI Resubmission Log After a Rejection
A rejected certificate can create several files, emails, portal events, and reviewer comments. A short resubmission log connects those events so the next person can see what changed, what was sent, and what remains unresolved.
Reviewed September 2026 · Educational information, not insurance or legal advice
What a resubmission log does—and does not do
A resubmission log is an administrative history. It should identify the original rejection, distinguish one attempt from the next, record the delivery route, preserve the response, and show the current open item. It does not decide whether insurance complies with a contract. It also does not replace the issued certificate, endorsement, policy, broker correspondence, or portal record.
This distinction matters because a certificate generally summarizes insurance information and does not itself amend coverage. The Texas Department of Insurance certificate FAQs explain that a certificate cannot change the policy and should not contain false or misleading information. A correction request therefore needs to go to the authorized issuer or agent rather than being edited by the contractor.
The log is most useful when several people touch the same job: a contractor administrator receives the rejection, an agent prepares replacement evidence, a project manager uploads it, and a client reviewer replies later. Without one event history, each person may hold only part of the story.
The nine fields worth recording
| Field | What to capture | Why it matters |
|---|---|---|
| Project reference | A neutral job, client, or vendor reference | Keeps events attached to the correct submission |
| Original rejection | Date and a concise, faithful summary | Prevents the correction from drifting away from the stated issue |
| Attempt | A sequential label such as V1, V2, or V3 | Separates replacement packages |
| Event date | When the version was prepared, sent, or answered | Builds a usable chronology |
| Channel | Portal, email, secure link, agent delivery, or other route | Shows where evidence and receipts should exist |
| Package summary | Non-sensitive names of the evidence categories included | Identifies what the reviewer actually received |
| Change summary | The exact administrative correction made | Explains why this version differs |
| Receipt or response | A neutral receipt reference or short reviewer response | Separates sending from confirmed receipt and review |
| Status and next action | Prepared, submitted, received, needs correction, or accepted | Makes the current owner and unresolved work visible |
Do not write “fixed” when the agent has only been asked to review something. Use language that describes the actual event: “agent request sent,” “replacement certificate received,” “portal upload completed,” or “reviewer requested a new holder address.” Precise verbs stop an intention from being confused with completed evidence.
A six-step resubmission workflow
1. Freeze the original rejection
Save the date, channel, and reviewer wording before replying. Summarize it faithfully in the log and retain the original message in the authorized project record. Do not overwrite the first rejection with a later interpretation.
2. Break the request into separate issues
One message may mention the named insured, holder address, limits, and endorsements. Treat each as a separate check. Route identity and portal-record questions to the client; route policy and issued-evidence questions to the agent or broker.
3. Assign a version before delivery
Use one version label across the outgoing package and the log. A version should represent a complete submission attempt, not every intermediate draft exchanged internally.
4. Recheck the entire package
Confirm the corrected item and also review names, policy periods, coverage rows, limits, requested parties, and attachments. Fixing one field does not guarantee that an older file or a new omission has not entered the package.
5. Record delivery separately from review
An email sent time or portal upload confirmation proves only a delivery event. It does not prove that the reviewer opened the file, accepted the format, or approved the evidence. Record these states independently.
6. Close only with a defined outcome
Use “accepted” only when the authorized reviewer or system indicates acceptance. If the project proceeds without an explicit acceptance message, record the observable fact rather than inventing an approval.
Build the timeline
Keep every correction attempt in one private event log.
Create version labels, statuses, delivery notes, and open actions in your browser, then copy, print, or export the result.
Example: a two-attempt correction
| Attempt | Event | Status | Next action |
|---|---|---|---|
| V1 | Submitted certificate and requested endorsement; portal receipt saved | Needs correction | Confirm exact holder address with client |
| V2 | Submitted replacement certificate with client-confirmed address; receipt saved | Received | Wait for reviewer response by the internal follow-up date |
The example does not say the second package “complies.” It records what changed and the last observable status. If the reviewer later accepts it, acceptance becomes a new event rather than a rewrite of V2.
Common logging mistakes
- Deleting the rejected file and losing the comparison baseline.
- Calling every attachment “COI” even when the package includes endorsements or other issued evidence.
- Using identical filenames for multiple attempts.
- Recording the submission date but not the channel or receipt.
- Combining “sent,” “received,” and “accepted” into one status.
- Writing sensitive policy data into a broadly shared tracker.
- Closing the record because no response arrived.
Frequently asked questions
Should the full rejection email be pasted into the log?
Usually a concise faithful summary is safer and easier to scan. Retain the original message in the authorized project system and use a neutral reference in the log.
Is a portal confirmation the same as acceptance?
No. It normally confirms an upload or receipt event. Acceptance is a later review outcome unless the portal explicitly states otherwise.
Who should update the log?
Assign one administrative owner for the event history, while letting the client and agent remain responsible for the facts within their roles.
How long should the record be kept?
Follow the organization’s contract, legal-hold, records-management, and privacy requirements. This guide does not prescribe a retention period.
Sources and scope
- Texas Department of Insurance: Certificates of Insurance FAQs
- King County: Insurance requirements for contractors
- California State University, Stanislaus: Certificate of Insurance and Additional Insured Endorsement
These sources support the separation between certificate information, policy-backed endorsements, and client evidence requirements. The suggested log structure is an original administrative workflow and must be adapted to the applicable contract, portal, and records policy.