Acceptance checklist
Software acceptance checklist
Check a system before you accept it from a software house: 42 points in 7 groups - functionality, integrations, devices, security, data migration, handover and the period after launch. Fit the list to your project, track your progress and download an acceptance protocol template as a PDF.
Software acceptance protocol template
The protocol confirms what you accepted, with what result and which defects. Enter the system name and the vendor in the fields above and the template fills in with them and with the scope from the checklist.
Software acceptance protocol
Software acceptance protocol
Protocol number
Acceptance date
Place
1. Parties
Client: (company name, representative)
Vendor:
2. Subject of acceptance
System:
Version / release:
Scope: as per the contract and specification
Basis: contract no. dated
3. Type of acceptance
partial - stage: final
4. Testing
Acceptance tests were carried out on in the environment: test production
Checked points: the acceptance checklist (annex).
5. Defects found
| No. | Defect description | Severity | Fix by |
|---|---|---|---|
| 1 | |||
| 2 | |||
| 3 | |||
| 4 |
Severity: critical (blocks work), major (hinders work), minor (does not get in the way).
6. Items handed over
source codeuser documentationtechnical documentationadmin access
7. Result
accepted without reservations
accepted with reservations - defects from point 5 to be fixed by
acceptance refused - reason:
8. Signatures
Client (signature and date)
Vendor (signature and date)
An illustrative template, not legal advice. Adapt it to your contract, ideally with a lawyer.
How to carry out software acceptance
-
Agree acceptance criteria
Before testing, agree with the vendor what "works" means: the contract scope, the feature list and which bugs block acceptance.
-
Test on real data
User acceptance testing (UAT) is done by the people who will use the system, on company data. The vendor's own testing does not replace it.
-
Report defects with detail
What was done, what happened, what was expected, a screenshot. Plus severity: critical, major or minor.
-
Decide on the result
Minor defects need not block the launch - list them in the protocol with a fix date. Critical ones are a reason to refuse acceptance.
-
Sign and take over everything
Together with the protocol you take over the source code, documentation and admin access.
Frequently asked questions
What is user acceptance testing (UAT)?
Testing done by the client before acceptance: the people who will work with the system check on real data that it does what was agreed.
Can you accept a system with bugs?
Yes, if the bugs are minor and do not block work. You then sign an acceptance with reservations and list the defects with a fix date. Critical bugs are a reason to refuse acceptance.
Partial or final acceptance?
In longer projects each stage is accepted separately (partial acceptance) and the whole system at the end (final acceptance). The checklist works for both - for a partial acceptance select only the features of that stage.
Who should test before acceptance?
The people who will use the system day to day, plus someone who knows the process from the business side. If you lack the time or people, an independent QA team can run the tests before acceptance.
What about copyright in the code?
It depends on the contract: a transfer of rights or a licence, with defined fields of use. The checklist reminds you to check it, but it is not legal advice - have a lawyer review the contract and the protocol.
Are my ticks sent anywhere?
No. The list saves your progress only in your browser so you can come back later. Nothing is sent to a server.
Let's talk about your project
Describe in a few sentences what you want to build or improve: an app, a platform, an integration or a process. We reply within one business day. The first call is an analysis, not a sales pitch.