UAT sign-off template

Published 18 October 2026

UAT sign-off is the client’s written acceptance that the software passed user acceptance testing and can go live. Below is a free template, the email that asks for it, and the sign-off criteria — plus the line most UAT templates leave out: which version of the requirements the testing was against.

What UAT sign-off means

User acceptance testing (UAT) is the last check before go-live: the people who will use the software, or who paid for it, confirm that it does what was agreed. The sign-off closes it. It is not the same as the requirements sign-off at the start of the project:

The first is covered by the requirements sign-off template. This page is the second. The last, at the end of the project or a phase, is the project sign-off.

UAT sign-off criteria

Agree these before testing starts, not at the end — they are the exit criteria of the UAT test plan. Typical criteria:

• Every planned test case was run, and the results are recorded.
• Every acceptance criterion of the requirements in scope was checked.
• No critical or high-severity defect is open.
• Any other open defect is accepted in writing, with a workaround and a fix date.
• Testing ran on the agreed environment, with realistic data.
• Every approved change request in the release was tested too — and nothing that was not approved.

What a UAT sign-off document includes

• The release and build that was tested.
• The version of the requirements it was tested against — the one the client signed off, plus the change requests approved since.
• What was in and out of scope for testing.
• The results: test cases run, passed and failed; acceptance criteria met.
• Open issues accepted for go-live, each with its workaround and fix date.
• The decision of each person signing, with a date.
• What acceptance means for defects found later.

The template

Copy it into Google Docs, Word or your test tool. Everything in square brackets is yours to fill in.

UAT SIGN-OFF

Project:          [project name]
Release:          [release name or
                  number], build [id]
Tested against:   [requirements document],
                  version [x.y] signed off
                  on [date], with change
                  requests [CR numbers, or
                  none]
Environment:      [where it was tested,
                  with which data]
Testing period:   [from date] to [to date]

1. WHAT WAS TESTED
   In scope:      [features or
                  requirements tested]
   Out of scope:  [what was not tested,
                  and why]

2. RESULTS
   Test cases:    [n] run, [n] passed, [n]
                  failed
   Acceptance criteria met:  [n] of [n]
   Report:        [link to the test
                  results]

3. OPEN ISSUES ACCEPTED FOR GO-LIVE
   (none may be critical)
   Issue:         [id], [severity]
   What happens:  [   ]
   Workaround:    [   ]
   Fixed by:      [date]

4. DECISION
   (one block per person signing)
   Name:       [   ]
   Role:       [   ]
   Decision:   [accepted / accepted with
               the open issues / rejected]
   Date:       [   ]

5. WHAT ACCEPTANCE MEANS
   - The release meets the acceptance
     criteria of the version above, except
     the open issues in section 3.
   - Issues found after this date are
     handled as [warranty fixes / change
     requests], as the contract says.

The UAT sign-off email

Subject: UAT sign-off: [project] release
         [n], by [date]

Hi [name],

User acceptance testing of release [n]
finished on [date].
It was tested against the requirements,
version [x.y], that you signed off on
[date], with change requests [CR numbers].

Results: [n] of [n] test cases passed; [n]
of [n] acceptance criteria met. Full
report: [link]

Open issues we propose to go live with:
- [id]: [what happens]; workaround: [   ];
  fix by [date]

Please reply by [date] with one of:
"Accepted", "Accepted with the open issues
above", or "Rejected" (and what must
change before you accept).

Once accepted, we schedule go-live for
[date].

Thanks,
[name]

How to get UAT signed off without a fight

1. Agree the criteria before testing starts. Criteria written after the results arrive turn into a negotiation.

2. Name what it was tested against. “Tested against version 1.3, which includes change requests 5 and 7” ends most arguments before they start. If the requirements changed after sign-off and nobody updated them, testing will find it — that is spec drift, where the agreement moves.

3. Separate defects from changes. If the software does what the signed-off requirement says, a request to make it do something else is not a defect; it is a change request.

4. Name who signs, in advance — the business owner who can accept, not only the people who tested.

5. Get it in writing, whatever the channel. Acceptance given on a call is easy to give and hard to prove later:

   Each stage has its own version of “what was agreed.” The SoW says one thing, the delivery tool says another, acceptance often happens informally on a call, and by invoicing time nobody can point to a clean record of what’s actually owed or why.

   — r/projectmanagement, July 2026

It matters most when something goes wrong. Someone working at IBM described a client who “hadn’t signed off on this work being completed, so they claimed it wasn’t done according to the contract. A few weeks later we got a letter from their legal department” (Hacker News, 2016).

UAT sign-off in agile

Agile teams accept work continuously: the product owner accepts stories at the end of each sprint. A formal UAT sign-off still makes sense per release — especially when an outside client pays for it, or when the release goes to production users. Use the same template with the release’s scope, and list the stories and their acceptance criteria in section 1.

UAT sign-off checklist

• The criteria were agreed before testing started.
• The document names the requirements version it was tested against, and the change requests in it.
• Every acceptance criterion in scope was checked, and the results are linked.
• No critical issue is open; every other open issue has a workaround and a date.
• The business owner signed, with a decision word and a date.
• Everyone knows how issues found after acceptance are handled.

Where Specroot fits

This is the problem Specroot works on: an answer to “tested against what?” — acceptance criteria tied to the version that was signed off, and work tied to the version it was built from. Specroot for agencies and consultancies.