Software Acceptance Testing: The Clause That Decides When You Lose the Right to Say No
Most software contracts promise very little about quality. The supplier will not guarantee the software is error-free, and it will not guarantee it meets requirements you never wrote down.
That makes acceptance testing the main point where the customer can say: this does not work, fix it or give the money back.
Once software is accepted, that leverage largely disappears. Get the acceptance clause wrong and you can be paying for software that never worked properly.
What acceptance testing is for
Acceptance testing is how the customer checks that software does what was agreed before it goes live and before the final payment is made.
It usually tests the software against a written specification. If something fails, the supplier fixes it and the software is tested again. Final payment is often tied to passing.
For customers, it is a quality gate. For suppliers, it is the moment the project is signed off and the invoice can be raised.
Waterfall and agile projects test differently
On a traditional waterfall project, the software is built in full and then tested at the end. This is often called user acceptance testing (UAT). On a fixed-price project, if the software fails, the supplier usually bears the cost of fixing it.
On an agile project, work is delivered in short sprints, typically two to four weeks, and each sprint's output is tested as you go.
The risk with agile is that each piece passes on its own but the full system does not work together. If you are the customer, make sure accepting individual sprints does not count as accepting the whole system. Your contract should still require a final end-to-end test once everything is in place.
Minor bugs should not stop the project
Suppliers will push back on any clause that lets the customer reject software over a small or cosmetic bug.
The usual compromise is:
- the customer must accept the software if it passes in all material respects
- the supplier fixes the minor defects after acceptance, within an agreed timeframe
That is fair to both sides, provided the contract is clear about what counts as material. Severity levels, such as critical, major and minor, with examples, avoid arguments later.
Deemed acceptance: where customers get caught out
Many contracts treat the software as accepted automatically if:
- the customer starts using it live, other than for testing
- the customer does not finish testing, or does not report problems in writing, within the testing window
Once that happens, the customer generally cannot reject the software or hold back payment. Its only remedies are whatever warranty or support commitments the contract provides, often with tighter limits.
For customers, two things matter most:
- the testing window must be realistic for the size of the project
- "live use" must be clearly defined, so a short trial or a workaround during testing does not trigger acceptance by accident
What happens when the software fails
Contracts usually set out a step-by-step process:
- Fix and retest. The supplier has a set period to correct the problems and resubmit for testing.
- Accept with a discount. The customer can choose to accept the software as it is, with a reduction in price.
- Walk away. If the software keeps failing, often after two attempts, the customer can reject it, end the contract, and get a refund.
Whether the customer can also claim damages on top depends on the contract, including any cap on liability. Check that the refund route is not the only remedy unless you have agreed that deliberately.
A case that shows how strict this is
A small stockbroking firm licensed back-office software. The contract set out an acceptance process: 30 days of testing, a further 30 days to retest any fixes, and a right to reject for a refund if the software still failed within 90 days of delivery. Without written notice in that time, the software would be deemed accepted.
The software had problems from go-live. The firm kept using it for about a year, then moved its back-office work elsewhere and refused to pay the balance.
The court found the software was defective and had never worked properly. But the firm had not used the rejection process within the time allowed. It lost the right to reject, had no other remedy, and had to pay the outstanding fees.
The lesson: a defect is not enough. If you do not follow the acceptance process on time, you can lose your remedy entirely.
What to focus on
If you are buying software:
- make sure a failed test leads to a fix, then a right to reject and get a refund
- on agile projects, insist on a final end-to-end test
- define live use tightly, so deemed acceptance cannot be triggered by accident
- diarise the testing window and put any rejection in writing
If you are supplying software:
- tie acceptance to objective criteria in a written specification
- include a materiality threshold, so minor bugs do not block sign-off
- set a clear testing window and a deemed acceptance trigger, so projects do not stay open indefinitely
Summary
Acceptance testing decides when the customer loses the right to say no. Customers need enough time and clear rejection rights. Suppliers need objective criteria and a firm end point. Either way, the clause only works if the process is followed on time.
If your software contracts were drafted for a different kind of project, or you are about to sign one, book a free 20-minute call with the Ethiqs team.