What is a software acceptance protocol?

A written record of the handover: what was delivered, what was tested, which defects remain and whether the client accepts it. What the signature means, for example for payment or the start of the warranty, is set by your contract with the vendor.

How is it different from user acceptance testing (UAT)?

UAT is the testing: the people who will use the system try it on real cases. The acceptance protocol is the signed record of the result, with the scenarios, the defect list and the decision.

When should I accept with reservations?

When the main process works and only serious or minor defects (B and C) remain, each with an agreed fix date. Our rule: a defect A means not accepted, and a reservation without a fix date is no reservation. It is a recommendation, not legal advice.

Is anything I fill in sent anywhere?

No. The protocol is filled in only in your browser and is not sent anywhere. Print it or save it as a PDF. For edits with your team, download the Word version.

Template to fill in

Software acceptance testing template: 15 checks and a sign-off protocol

A software acceptance protocol records that the client has taken over the software, and with which defects. Sign it only after testing on your own data: below are 15 things to check and a protocol with a defect list you fill in right here. It is a template, not legal advice.

Downloaddocx Downloadpdf

What you fill in and tick stays in this browser window only. We do not store or send anything. It is gone when you close the page, so print your result.

For owners, operations leads and founders whose vendor just said: "It's done, please sign the protocol." The signature often decides payment, the start of the warranty and who pays for fixes. Your contract says exactly what.

A demo on prepared data always works. That is why it makes sense to sign only after a test on your real data, with the people who will use the system every day.

Part A: What to test before you sign

Data

1. Test on real data. On a copy of your real records, not on the vendor's demo data.
2. The migration adds up. The number of customers, orders or invoices is the same before and after. Check five random records in detail too.
3. Edge cases from your daily work. A cancellation, a credit note, a customer with two addresses, accents in a name, a large attachment.

People and access

4. Each role sees only what it should. Log in as a normal user, not as an admin.
5. Adding and removing a user works. A removed person can no longer log in.
6. The main admin account belongs to your company, not to the vendor.

Processes

7. The whole process end to end is run by the person who does it daily. Without the vendor's help.
8. Bad input. What happens with a missing field, a wrong format or a double click?
9. Emails, notifications and exports reach the right person in the right form.
10. Connections to your systems (accounting, e-shop, warehouse) work on the real connection or a copy of it, not only in test mode.

Operations

11. Backups exist and a restore has been tried. "We back up" is not enough. Ask for the date of the last restore test.
12. Speed with your volume of data. An empty system is always fast.
13. The devices people actually use. A phone in the warehouse, an older laptop, a weak signal.

Handover

14. Code, domains, hosting and service accounts are in your name. A repository on your account, not just a zip file.
15. Documentation: how to run the system, where the logs are, whom to call when it is down.

Write every point that failed into the defect list in Part B. Do not sign "without reservations" just so the project finally ends.

Part B: Acceptance protocol

Basic details

Project
Client
Vendor
Contract
Version / release
Environment
Testing
Tested by

Scope delivered

#	Feature or requirement (from the brief)	Delivered (yes / partly / no)	Note
1
2
3
4
5

Test scenarios

#	Scenario	Data (real / copy / test)	Tested by	Result (pass / fail)	Note
1
2
3
4
5
6

Defect list

Severity: A critical = a main process does not work and there is no workaround. B major = works with a workaround or extra effort. C minor = looks, text, convenience.

#	Defect description	Severity (A / B / C)	Fix by	Status
1
2
3
4

Handed over

Access to the code repository on the client's account
Access to hosting, domains and third-party services
Documentation (running, operations, backups)
Data export in a readable format (CSV, Excel or a database backup)

Acceptance result

Accepted without reservations.
Accepted with reservations. The vendor fixes the B and C defects on the list by [date]. No A defect.
Not accepted. The list contains an A defect. New acceptance date: [date].

The rule we recommend: an A defect means not accepted. A reservation without a fix date is not a reservation.

Signatures

	For the client	For the vendor
Name
Role
Date
Signature

How we do it

Code, data and infrastructure belong to the client from day one, not only after the protocol is signed.

Frequently asked questions

What is a software acceptance protocol?: A written record of the handover: what was delivered, what was tested, which defects remain and whether the client accepts it. What the signature means, for example for payment or the start of the warranty, is set by your contract with the vendor.
How is it different from user acceptance testing (UAT)?: UAT is the testing: the people who will use the system try it on real cases. The acceptance protocol is the signed record of the result, with the scenarios, the defect list and the decision.
When should I accept with reservations?: When the main process works and only serious or minor defects (B and C) remain, each with an agreed fix date. Our rule: a defect A means not accepted, and a reservation without a fix date is no reservation. It is a recommendation, not legal advice.
Is anything I fill in sent anywhere?: No. The protocol is filled in only in your browser and is not sent anywhere. Print it or save it as a PDF. For edits with your team, download the Word version.

Where to next

Custom software

One system you own, not scattered spreadsheets

Your vendor wants a signature and you are not sure?

Tell us what the vendor is handing over and what does not add up. We get back to you within two business days, and together we pick what to fix first.

Let's get rid of your manual work Or a 15-minute intro call

Who we help

Services

Know-how

What is an AI agent? Plain answer, business examples

When is Excel no longer enough for a business?