Deliverables register template

A deliverables register helps the receiving team locate the current version of each item and understand its review status. List documents, files or outputs that can be checked independently.

Reference the actual item

Give each deliverable a stable ID, a useful name, a location or version reference and a responsible owner. Record the acceptance evidence separately from the status so a reader can verify what “Accepted” means.

A file being present does not prove it has been accepted. Use the register alongside your team’s review or sign-off process.

Read the columns as a workflow

Give every row a stable ID and one responsible owner. Keep the same ID when the record moves to another week; this lets a reviewer trace a change instead of treating it as new work.

Location / version

Give the receiving reviewer an accessible reference and version.

Target date

Distinguish a planned submission from the date of actual acceptance.

Review status

Use Submitted, Ready for review or Accepted only when those descriptions are supported.

Acceptance evidence

Reference the review outcome and responsible reviewer. Do not treat an upload as approval.

One filled row, with context

This fictional Northstar example is a starting point for your own wording. Replace every placeholder, confirm the owner and agree the next review date.

Maintain the record after the first download

Keep one editable copy as the source. When an item changes, update the response, date and evidence together. If a record is closed, retain its ID and outcome instead of deleting the trail. These downloads do not sync, notify owners or validate acceptance.