Project sign-off template

Published 19 October 2026

A project sign-off is the client’s written confirmation that a project, or one phase of it, delivered what was agreed and can be closed. Below are a free template, a filled-in example, the email that asks for it, phase sign-off, a closure checklist, and what to do when the client will not sign.

If the client doesn’t have a good spec, you’ll be haggling whether it’s done or not.

— A freelancer on Hacker News, 2015

What project sign-off means

A client software project can have three sign-offs. Project sign-off is the last:

The requirements sign-off and the UAT sign-off have their own templates. This page is the third.

What a project sign-off document includes

• The contract it closes: the statement of work or contract, with its date.
• Every deliverable, each with when and how it was accepted — a UAT sign-off, a review, a training session held.
• The changes delivered: each approved change request, and which ones were declined or moved to later.
• Open items, each marked as a warranty fix or new work, with a date.
• The handover: code, documents, accounts and passwords, training, a support contact.
• What follows: the warranty period, support, and the final invoice.
• The decision of each person signing, with a date.

Project sign-off template

Copy it into Word, Google Docs or Confluence. Square brackets are yours to fill in.

PROJECT SIGN-OFF

Project:   [project name], [phase]
Contract:  [statement of work], [date]
Client:    [company]
Supplier:  [company]

1. DELIVERABLES
   [D-n]  [deliverable]
     Accepted:  [date], by [UAT sign-off
                / review / session]

2. CHANGES
   [CR-n]  [title]:  [delivered /
                     declined / moved]

3. OPEN ITEMS
   [id]  [what]
     Handled as:  [warranty fix / change
                  request]
     By:          [date]

4. HANDOVER
   [ ] Code and deployment scripts
   [ ] Documents and guides
   [ ] Accounts, domains, passwords
   [ ] Training given
   [ ] Support contact named

5. AFTER SIGN-OFF
   Warranty:       [from] to [to]
   Support:        [contract or none]
   Final invoice:  [milestone], [date]

6. DECISION   (one block per person)
   Name:      [   ]
   Role:      [   ]
   Decision:  [accepted / accepted with
              the open items / not
              accepted, because ...]
   Date:      [   ]

Project completion sign-off example

The customer portal from the other templates, at the end of phase 1:

PROJECT SIGN-OFF

Project:   Customer portal, phase 1
Contract:  Statement of work, 2 February

1. DELIVERABLES
   D1  Portal, release 2
     Accepted:  16 May, UAT sign-off
   D2  Admin and support guide
     Accepted:  19 May, review
   D3  Training, accounts team
     Accepted:  20 May, session held
   D4  Code, scripts, accounts
     Accepted:  21 May, handover list

2. CHANGES
   CR-5  CSV export:  delivered
   CR-6  Blog:  declined, 22 Feb
   CR-7  Google sign-in, option B:
         delivered
   CR-8  Push notifications:  moved
         to phase 2

3. OPEN ITEMS
   DEF-34  CSV export shows US dates
           to German users
     Handled as:  warranty fix
     By:          6 June
   Invoices in French (asked 22 May)
     Handled as:  change request CR-9,
                  phase 2

4. HANDOVER
   [x] Code and deployment scripts
   [x] Documents and guides
   [x] Accounts, domains, passwords
   [x] Training given
   [x] Support contact named

5. AFTER SIGN-OFF
   Warranty:       21 May to 19 July
   Support:        monthly retainer
   Final invoice:  M3, on signature

6. DECISION
   Role:      Product owner (client)
   Decision:  accepted with the open
              items
   Date:      23 May

The two open items show the line that matters after sign-off. The date format is a defect: the signed-off requirements say dates appear in the customer’s format, and they do not. French invoices were never in the requirements, so they are new work, whatever the timing of the request.

Project sign-off email

Subject: Project sign-off: [project],
[phase], by [date]

Hi [name],

[Phase] of [project] is complete. Every
deliverable in the statement of work of
[date] has been delivered and accepted:

- [D1]: accepted [date], [how]
- [D2]: accepted [date], [how]

Changes delivered: [CR numbers].
Moved to later: [CR numbers].

Open items:
- [id]: [what]; [warranty fix / change
  request]; by [date]

The handover list is attached. The
warranty runs from [date] to [date].

Please reply by [date] with "Accepted",
"Accepted with the open items above", or
"Not accepted" and what is missing.

On acceptance we send the final invoice
for [milestone].

Thanks,
[name]

Phase sign-off

On a project delivered in phases, sign off each phase before the next one starts: discovery, then design, then each release. A phase sign-off is shorter — the phase’s deliverables, the open items, and what the next phase starts from — but it does the same job: it closes what was agreed for that phase, so the next one starts from a known point.

It also keeps payments simple. When each milestone payment in the statement of work is tied to the acceptance of a phase, the phase sign-off is what releases it.

Project closure checklist

With the client:

• Every deliverable accepted in writing, with a date.
• Every change request closed: delivered, declined or moved.
• Open items listed, each a warranty fix or a change request.
• Handover done: code, documents, accounts, domains, passwords, training.
• Warranty and support terms confirmed.
• Project sign-off received; final invoice sent.

Inside the team:

• Access to client systems removed where it is no longer needed.
• Documents, decisions and the final version of the requirements archived where they can be found.
• A lessons-learned session held, and its notes kept.
• People released to other work.

Project sign-off vs closure report vs handover

A project can have all three. The sign-off is the one with a decision in it.

When the client won’t sign off

The end of a project is where an unclear agreement costs the most. One commenter, on fixed-price contracts: “Some clients will withhold final payment until you do lots of extra things.” (Hacker News, 2014). What helps:

1. Ask for a decision, with a date and three options: accepted, accepted with open items, or not accepted and what is missing. A list of what is missing is something you can work through; silence is not.
2. Check against the agreement, not memory. Each deliverable is accepted against the acceptance criteria in the statement of work and the requirements version that was signed off.
3. Split new requests out. Anything the signed-off requirements do not say becomes a change request — it does not hold up acceptance of what was agreed.
4. Accept with open items. A short list of small open items, each with a date, is a normal sign-off, not a failure.
5. Know what the contract says about silence. Some contracts have a deemed acceptance clause. Sprintlaw, a UK law firm, explains: “Deemed acceptance means the software is treated as accepted if a defined event occurs, such as no valid rejection within the testing period or ordinary live use” (Sprintlaw, 2026). Whether such a clause applies to your contract is a question for your lawyer.

After sign-off: warranty or change request?

After sign-off, everything the client reports is one of two things. If the software does not do what the signed-off requirements say, it is a defect, fixed under the warranty. If it does what they say and the client wants something else, it is a change request, quoted and approved like any other.

A warranty period agreed up front helps both sides. One commenter, replying to the claim that a fixed price leaves a supplier no reason to fix problems after sign-off: “If you give a fixed price contract that includes bug fixes for a period, then your incentives are well aligned.” And: “You want to release robust code (to avoid warranty bug fixes), and your client wants that too.” (Hacker News, 2024).

This only works if everyone can find what was signed: which version of the requirements, with which change requests. Without that, every report after go-live becomes an argument about what was agreed.

Where Specroot fits

This is the problem Specroot works on: a last sign-off that points to the same record as the ones before it — the requirements version signed at the start, every change approved since, and what was tested — so that “was this agreed?” has one answer after the project closes. Specroot for agencies and consultancies.