The six statuses that should stay separate

Use the most conservative supported status. If an email was sent but no reply or platform confirmation exists, “submitted—no receipt” is accurate. If the portal says “uploaded,” do not rewrite that as “approved.” If a person says “received,” preserve the message and wait for a distinct review outcome.

What delivery evidence should identify

• The same neutral project or vendor reference used in the package.
• The sender, destination, and approved transmission route.
• The actual timestamp, including time zone when timing is material.
• The package version and exact outgoing filenames.
• The portal transaction, confirmation, or message reference when available.
• Any system warning, failed file, size rejection, or incomplete upload.
• The next status-check date and internal owner.

Keep the record proportional. A delivery log usually does not need a policy number, Social Security number, tax identifier, personal address, or confidential contract passage. Follow the organization’s access, security, retention, and legal-hold requirements for the actual source records.

Consistent filenames make the receipt more useful because the submitted snapshot can be matched to the package inventory. The National Archives recommends descriptive, consistent, meaningful naming and fixed positions for date or version elements. This site adapts that general records principle for contractor package control; it does not treat federal naming guidance as a private-company mandate.

A controlled delivery-to-review workflow

1. Freeze the package. Assign a version and stop replacing files inside the staged snapshot.
2. Open every file. Confirm content, project, entities, dates, and type against the manifest.
3. Create the cover record. List included items, disclosed questions, and evidence still pending.
4. Transmit through the approved route. Follow current client instructions for portal categories, recipients, file size, and format.
5. Record actual submission. Capture the timestamp and transaction evidence rather than relying on the planned date.
6. Verify receipt. Look for an acknowledgment or destination record. If none exists, schedule a specific follow-up.
7. Record review separately. Preserve the exact reviewer response and its relationship to the package version.
8. Start a new version for corrections. Do not silently replace the already-submitted snapshot.
9. Close with the exact outcome. Use the reviewer’s observable status and keep it distinct from a policy or coverage conclusion.

Exceptions and failure paths

Email message sent, attachment missing

Record a failed or incomplete delivery rather than a received package. Prepare a new controlled transmission and identify it clearly so the recipient does not review the empty message.

Portal shows files but no confirmation number

Preserve the visible filenames, categories, and timestamp if allowed. Mark receipt only to the level supported by the portal. If the portal merely shows a local selection before final submission, that is still preparation.

One file failed while others uploaded

Record the package as incomplete and identify the failed component. Do not let a general success banner erase a file-level failure.

Automated email acknowledgment

An automated reply may support delivery to an inbox or intake system, but not substantive review. Keep the status at receipt recorded unless it explicitly communicates another authorized state.

Reviewer accepts with a future renewal condition

Preserve acceptance exactly as stated and separately create the renewal checkpoint. Do not remove a future evidence obligation from the active-project plan.

The University of California states that contracts commonly require insurance limits and certificate evidence, while its own issuing responsibilities sit with designated risk-management offices. That distinction illustrates why the contractor’s delivery log should document its own handoff without claiming authority over issuance or professional review.

A simple audit test

A colleague who did not perform the submission should be able to answer five questions from the record: Which requirement version was used? Which package version left? What exact files were included? What proves the destination received them? What is the latest separately documented review status? If any answer depends on memory, the record needs a clearer connection.

Frequently asked questions

Is a screenshot enough?

It may be one useful record if permitted, but preserve the underlying transaction information and follow organizational rules. A screenshot can be incomplete or taken before a final submit action.

Should I use read receipts?

Use only approved features and do not treat a mail-client signal as substantive acceptance. A direct recipient acknowledgment or portal transaction is clearer when available.

What if the client never acknowledges receipt?

Keep “submitted—no receipt,” preserve transmission evidence, and follow the client’s escalation route on a specific date.

Can the status be edited later?

Add a dated event or controlled update. Avoid rewriting history so that a later accepted state appears to have existed at submission.

How long should delivery evidence be retained?

Follow the contract, company policy, applicable law, legal holds, and the authorized records schedule. This guide does not set a retention period.

Sources and scope

• U.S. National Archives: Consistent electronic-record naming
• University of California: Certificate evidence and responsibilities
• Texas Department of Insurance: Certificate statements and limits

The status framework is original administrative guidance. It does not authenticate a receipt, decide whether a contract was satisfied, or verify insurance coverage.