Acceptance Testing and UAT Clauses in Software Contracts

What is User Acceptance Testing in a software contract?

User Acceptance Testing (UAT) is the process by which the client confirms that the software meets the agreed specification. It is a critical milestone in any development project. By the time a project reaches UAT, significant time and money have usually been invested, and the clause that governs acceptance often determines whether the closing stage of the project runs smoothly or becomes a source of dispute.

UAT is not just a technical exercise. It is a validation that the software works in the context of the client’s real operations: that the workflows match how the business actually runs, that the data behaves as expected, and that the people who will use the system day to day can do their jobs with it. That is why the clause matters as much as the testing itself.

Who is responsible for UAT?

UAT is primarily the client’s responsibility. The client tests the software against the agreed requirements and either accepts it or provides written feedback on where it does not conform. The development partner supports this process by triaging defects, diagnosing issues, and delivering fixes, but the testing itself is performed by the client’s team.

This division of responsibility is important because the client knows their business processes better than anyone. The development partner can confirm that the software behaves as specified, but only the client can confirm that the specification reflects how the business needs to operate. A contract that tries to shift the testing burden entirely onto the development partner misunderstands what UAT is for: it is the client’s opportunity to validate the software against their own operations before they rely on it.

In practice the two roles work in tandem. The client runs test scenarios drawn from real business cases, records where the software does not conform, and submits that feedback in writing. The development partner then triages each item, diagnoses the cause, and delivers fixes. The cycle repeats until the software is accepted.

What counts as acceptance and what counts as rejection?

One of the first things to confirm in a UAT clause is a clear definition of what constitutes acceptance and what constitutes rejection. Without it, the closing stage of a project can drift, because neither party agrees on when the software is finished.

Acceptance is normally the client’s written confirmation that the software conforms to the agreed specification. Rejection is written feedback identifying where it does not conform. The key word is conformance: rejection should point to a specific requirement the software fails to meet, described in enough detail for the development partner to triage and diagnose the issue. Feedback such as ‘this does not feel right’ gives the partner nothing actionable and makes the acceptance test impossible to apply objectively.

Most contracts also address two practical points. The first is a review window: the client has a defined period to test and respond, after which silence may be treated as deemed acceptance. The second is live use: if the client puts the software into live operational use, that is often treated as acceptance in itself, because the software is clearly fit for the purpose it was built for.

Reasonable endeavours or an absolute obligation to fix defects?

One of the most important distinctions in UAT clauses is whether the development partner’s obligation to fix defects is qualified by ‘reasonable endeavours’ or is an absolute obligation.

Under reasonable endeavours, the development partner must take reasonable steps to fix the issue but is not guaranteeing a specific outcome within a specific timeframe. Under an absolute obligation, the development partner must achieve the fix regardless of the circumstances.

This matters because not all defects are within the development partner’s control. A bug that stems from a third-party integration, such as a payment provider, a content management system, or a hosting service, may depend on that third party releasing a fix. An absolute obligation with a fixed deadline could put the development partner in breach for something entirely outside their control, no matter how diligently they work the problem.

Reasonable endeavours is usually the more balanced standard. It still requires the partner to act diligently and in good faith to resolve defects, but it does not penalise them for outcomes they cannot guarantee. For the related question of how financial responsibility for defects is allocated once the software is live, see the sibling guide on liability caps and indemnities.

What about defects caused by third parties or client data?

Following directly from the point above, a fair UAT clause carves out the defects the development partner cannot reasonably be held to fix on a fixed timescale.

The clearest example is a defect caused by a third-party service. If a payment provider’s API changes, or a hosting platform suffers an outage, or a content management system contains its own bug, the development partner can investigate and raise the issue, but the resolution depends on the third party. Holding the partner to an absolute deadline in that situation is neither fair nor realistic.

A second category is defects caused by client-provided data or by the specification itself. If the software behaves exactly as specified but the specification turns out to be incomplete, that is a change rather than a defect, and it belongs in change control rather than in remediation. Similarly, if client-supplied data is malformed or incomplete, the resulting behaviour is not a fault in the development partner’s work. Recognising these distinctions in the contract keeps remediation focused on genuine non-conformance with the agreed specification.

Can repeated UAT failure lead to termination?

Some contracts include escalation mechanisms where repeated UAT failures can ultimately lead to termination. A client understandably wants protection against a product that does not work, and an escalation path is a legitimate way to provide it. But tying termination to UAT outcomes requires careful thought, because a poorly drafted escalation clause can turn ordinary back-and-forth into a termination trigger.

A balanced escalation mechanism should do three things:

• Account for the cause of the failure. Was the failure the development partner’s responsibility, a third party’s, or the result of unclear requirements? Termination should follow only where the partner is genuinely at fault.
• Allow sufficient time for genuinely complex issues. Some defects are hard to diagnose and fix. A mechanism that escalates too quickly punishes complexity rather than poor performance.
• Include a dispute resolution step before termination becomes an option. A structured discussion, escalation to senior stakeholders, or a defined dispute resolution process gives both parties a chance to resolve the matter before the most severe remedy is invoked.

With those safeguards, the escalation clause protects the client without exposing the development partner to termination for matters outside their control.

What to look for in your contract

When reviewing the acceptance testing and UAT provisions in a bespoke software contract, look for the following:

• A clear definition of what constitutes acceptance and what constitutes rejection.
• Reasonable timeframes for both client review and development partner remediation.
• Reasonable endeavours on the remediation obligation, rather than an absolute obligation.
• Exclusions for defects caused by third parties or by client-provided data.
• An escalation mechanism that includes a dispute resolution step before termination.
• Confirmation that UAT relates to conformance with the agreed specification, not subjective quality.

Where to go from here

Acceptance testing is one of the ten areas covered in our pillar guide, the practical guide to software development contracts, which puts UAT in the context of capped investment, IP licensing, liability, exit rights, and the other clauses that shape a bespoke build. For the closely related question of who carries the financial risk when defects cause loss, see the guide on liability caps and indemnities.

If you are reviewing a software development contract and would like to discuss how acceptance and UAT terms should be structured, book a consultation.

This guide explains how acceptance testing and UAT clauses commonly work in UK bespoke software contracts, in plain English. It is not legal advice. For advice specific to your circumstances, consult a solicitor qualified in technology and commercial contracts. It reflects common UK market practice as at June 2026.