Software Acceptance Testing Clauses in UK Contracts

A software build can look finished in a demo but still fail when your team uses it with real workflows, data and integrations. The risk for a SaaS or software customer is paying the next invoice before the product has actually met the agreed brief.

Common mistakes include vague acceptance criteria, no fixed user acceptance testing period, unclear defect categories and silence on what happens if the customer does not respond in time. These gaps can turn a payment milestone into an argument about quality, scope and delay.

A well drafted software acceptance testing clause sets out what must be delivered, how it will be tested, when it is accepted and when payment becomes due. It should also separate true defects from new feature requests, so both sides know when the project has passed and when extra work needs a separate quote.

Software Acceptance Testing Clauses: Core Checklist

A software acceptance testing clause should connect the commercial bargain to a practical pass or fail process. For a customer, the clause is not just a quality control tool. It is the mechanism that decides whether a milestone has been completed and whether the supplier can invoice.

In a UK software development agreement, acceptance testing usually sits alongside the scope of work, project plan, service levels, intellectual property provisions, payment terms and warranties. The clause should be detailed enough to prevent debate, but not so technical that your project team cannot use it.

A strong clause usually answers these questions:

• What is being tested? For example, a specific release, module, integration, API, mobile app build, migration script or admin dashboard.
• What standard must it meet? This is where software development acceptance criteria become critical.
• Who carries out the testing? This may be the customer, the supplier, both parties, or nominated user representatives.
• How long does the customer have to test? A defined user acceptance testing period avoids open-ended delays.
• What evidence is needed for rejection? The clause should require clear written defect reports rather than general dissatisfaction.
• What happens if there are defects? The contract should set timeframes for fixes, retesting and escalation.
• When is acceptance deemed to occur? Deemed acceptance prevents silence or ordinary use from leaving the project in limbo.
• When is payment due? The clause should state whether payment follows delivery, testing, acceptance, deemed acceptance or another milestone.

For customers, the main commercial aim is to avoid paying as though the build has passed when material issues remain. For suppliers, the main aim is to avoid a customer withholding payment because they have changed their mind, expanded the scope or delayed internal sign-off.

The clause should be drafted around the type of software you are buying. A bespoke CRM for an SME sales team may need workflow-based testing, while a SaaS integration for payments may need security, performance, penetration testing and data handling tests. If personal data is used in test environments, the parties also need to think about UK GDPR and the Data Protection Act 2018, including whether live personal data is necessary and how access will be controlled.

The best acceptance process is operational, not theoretical. Your product owner, finance lead and technical contact should be able to follow it without needing to renegotiate the project at each milestone.

Acceptance Criteria and Delivery Milestones

Acceptance criteria should describe the required business outcomes, functional requirements and measurable standards for each delivery milestone. If the criteria are unclear, the customer may struggle to reject a defective build, and the supplier may struggle to know what counts as completion.

A software delivery milestones contract often breaks the project into stages such as discovery, prototype, minimum viable product, integrations, beta release, production release and post-launch support. Acceptance testing can apply to each stage, or only to major releases. The right structure depends on the project risk and payment profile.

For a customer, it is usually safer to tie substantial payments to accepted milestones rather than simple delivery. Delivery means the supplier has handed something over. Acceptance means the customer has tested it against the agreed criteria and confirmed it meets the required standard, or is deemed to have accepted it under the contract.

Good acceptance criteria tend to be:

• Specific: The login function must support named user roles, password reset and multi-factor authentication if required, rather than simply stating that login must work.
• Measurable: Page load times, API response times, error rates, data migration accuracy and supported browser versions should be capable of objective testing where relevant.
• Linked to the specification: Criteria should map back to the agreed statement of work, user stories, wireframes, product requirements document or technical specification.
• Prioritised: Critical functions should not be treated the same way as minor formatting issues.
• Version-controlled: If requirements change, the parties should be able to identify which version of the criteria applies to the milestone.

Consider a UK retailer commissioning a stock management platform.

A vague milestone might say: The supplier will deliver the inventory module. A clearer milestone would say that the supplier must deliver an inventory module that allows authorised staff to create product records, update stock quantities, receive low-stock alerts, export CSV reports and sync stock movements with the ecommerce platform within the agreed time interval.

The acceptance criteria should also identify dependencies. If the supplier cannot complete a payment gateway integration until the customer provides account credentials, sandbox access or third-party documentation, the contract should say so. Otherwise, both parties may blame each other for missing the milestone.

For SaaS customers, acceptance criteria often need to cover configuration as well as custom development. If the supplier is configuring an existing platform, the contract should distinguish between standard platform limitations and bespoke commitments. A supplier should not promise to make its SaaS product do something that the underlying platform cannot support unless custom development is clearly included.

Some customers include a final catch-all requirement that the software must be fit for the purpose described in the specification. That can be helpful, but it should not replace detailed criteria. English contract law generally looks closely at the words the parties agreed. A broad purpose statement may not solve a dispute if the detailed deliverables are thin or inconsistent.

Payment wording should be equally clear. For example, a contract might state that 30 percent is payable on signature, 30 percent on acceptance of the beta release, 30 percent on acceptance of the production release and 10 percent after a defined warranty or support period. Another project might require monthly payments, with acceptance testing used only for key deliverables. What matters is that the invoicing trigger cannot be confused with a mere progress update.

Testing Periods, Evidence and Deemed Acceptance

A testing period gives the customer a defined window to approve or reject the build, while deemed acceptance stops the process from remaining open forever. Both are needed for a balanced acceptance testing agreement in the UK.

The testing period should start from a clear event. Common triggers include delivery of the relevant build to a test environment, written notice that the milestone is ready for testing, provision of release notes, or access to required documentation. A customer should avoid a clause where the clock starts before it actually has access to a working build.

The length of the testing period depends on the size and complexity of the milestone. A small feature update may only need a few business days. A new platform with integrations, data migration and user permissions may need longer. The contract should also say whether weekends and public holidays count, and whether the period pauses if the software cannot be tested due to supplier-side issues.

A practical UAT clause in a software agreement should state what the customer must do during the testing period. This may include running agreed test scripts, checking the software against acceptance criteria, recording results and notifying the supplier of any defects. If the customer simply says that the system is not right, the supplier may not have enough information to fix it.

Defect notices should usually include:

• the affected feature, module or user journey;
• steps to reproduce the issue;
• screenshots, screen recordings, logs or test data where available;
• the expected result and actual result;
• the customer's proposed severity level; and
• whether the defect blocks acceptance of the milestone.

The clause should also say what happens if the customer approves the build in writing. Written acceptance might be an email from the authorised project owner, a signed acceptance certificate or approval in a project management tool. The contract should identify who is authorised to accept, especially where multiple stakeholders are involved.

Deemed acceptance is often the most negotiated part of a software acceptance testing clause. From a supplier's perspective, it is unfair if a customer receives the deliverable and then stays silent for weeks while payment is withheld. From a customer's perspective, deemed acceptance can be risky if the period is too short or if internal testing depends on busy staff.

Common deemed acceptance triggers include:

• the customer does not issue a valid rejection notice within the testing period;
• the customer uses the software in a live production environment for ordinary business purposes;
• the customer instructs the supplier to move to the next milestone without reserving its rights; or
• the customer makes only minor comments that do not prevent the software meeting the acceptance criteria.

Customers should narrow deemed acceptance so it does not occur accidentally. For example, using a test environment should not count as acceptance. Limited use for beta testing or pilot testing should not count as live operational use unless the contract says it does. Acceptance should also be limited to the specific milestone tested, not the entire project.

Suppliers may reasonably ask for deemed acceptance where the customer controls testing resources or internal sign-off. A balanced position is to allow deemed acceptance only after the supplier has given proper notice that the milestone is ready, provided access and documentation, and allowed the full testing period to run.

Payment clauses should align with this timing. If payment is due on acceptance, the invoice should be payable after written acceptance or deemed acceptance. If payment is due on delivery, the customer has less leverage during testing. If a retention is used, part of the fee can be held until final acceptance or post-launch defect resolution.

Defect Severity, Fixes and Change Requests

Defect severity categories decide whether a bug blocks acceptance, requires a fix before go-live or can be dealt with later. Without severity levels, a minor display issue can be used to delay payment, or a serious operational fault can be minimised as a small bug.

Many software contracts use categories such as critical, high, medium and low severity. The labels matter less than the definitions. Each category should describe the business impact and the required response.

A customer-friendly severity framework might look like this in plain English:

• Critical defect: The software, or a core function, is unavailable or unusable, with no reasonable workaround. This should block acceptance.
• High severity defect: A key function does not work properly or a serious security, data integrity or compliance issue exists. This will usually block acceptance unless the customer agrees otherwise.
• Medium severity defect: A function is impaired, but a reasonable temporary workaround exists and core operations can continue. Acceptance may depend on the number and nature of these defects.
• Low severity defect: A cosmetic issue, minor inconvenience or documentation error that does not affect core use. These are often recorded for later correction without blocking acceptance.

The contract should say whether one critical defect is enough to reject a milestone, whether a certain number of medium defects can block acceptance, and whether low severity defects must be fixed before payment. This prevents both over-rejection and under-reaction.

Fix timeframes should be realistic. A critical issue may need immediate attention, while a low severity issue may be handled in the next scheduled release.

The agreement should set out the cycle: the customer reports defects, the supplier investigates, the supplier fixes valid defects, the customer retests, and the milestone is accepted or rejected again based on the remaining issues.

For customers, a key protection is the right to reject again if the fix creates new defects or does not resolve the original issue. For suppliers, a key protection is that repeated retesting should focus on the reported defects and related areas, not reopen every accepted requirement unless there is a genuine reason.

The contract should also deal with disputed defects. The supplier may say an issue is caused by customer misuse, third-party systems, unsupported hardware, incomplete data, or a requirement that was never agreed. The customer may say the issue is within the agreed scope. A useful process is to require the parties to review the specification, test evidence and dependencies, then escalate to senior project contacts if they cannot agree.

Change requests are different from defects. A defect is a failure to meet the agreed requirements. A change request is new or different functionality, design, workflow, integration or data handling that was not included in the agreed scope. Confusing the two is one of the fastest ways for a software project to overrun.

Your contract should say how change requests are handled. A typical process includes:

1. The customer submits a written change request describing the requested change and business reason.
2. The supplier assesses the impact on price, timing, acceptance criteria, support, security and existing milestones.
3. The supplier provides a written quote or change order.
4. The parties approve the change before work begins.
5. The specification, milestones and acceptance criteria are updated to reflect the agreed change.

Customers should be careful about informal approvals in calls or chat tools. A product manager may say yes to a design tweak without realising it affects development time and payment milestones. Suppliers should avoid doing extra work without written approval, then trying to recover the cost later.

Security and data issues deserve special attention. If the software processes personal data, an acceptance test may need to check access controls, audit logs, data deletion, data export and role-based permissions. UK GDPR and the Data Protection Act 2018 do not prescribe an acceptance testing process, but they do make data protection obligations commercially significant. If testing uses live personal data, the contract should address confidentiality, security controls, permitted use and deletion after testing.

Intellectual property should also be aligned with acceptance and payment. Under UK copyright law, software code is generally protected as a literary work, but ownership and licence rights depend on the contract. Some customers want ownership of bespoke code on payment. Others only need a licence to use the software. If rights transfer only on full payment, the customer should know what happens under the software licence if a milestone is rejected but parts of the work are useful.

Limitation of liability clauses should be reviewed alongside acceptance wording. In business-to-business contracts, liability limits and exclusions may be subject to the Unfair Contract Terms Act 1977 where standard terms are used or certain types of liability are limited. A liability cap that is too low may leave the customer exposed if a failed build causes major operational disruption. A cap that is too high may be commercially unacceptable to the supplier. The acceptance clause should not be looked at in isolation.

FAQs

What Is a Software Acceptance Testing Clause?

A software acceptance testing clause is a contract term that sets out how a customer tests delivered software, what standards it must meet, and when it is treated as accepted. It usually links acceptance to milestone completion and payment.

Should Payment Be Due on Delivery or Acceptance?

For customers, payment is often safer when tied to acceptance or deemed acceptance rather than delivery alone. Suppliers may ask for staged payments to manage cash flow, so many contracts use deposits, accepted milestones and final retention.

How Long Should a UAT Period Be?

The UAT period should match the complexity of the release and the customer's testing resources. A minor feature may need only a short period, while a business-critical platform, data migration or integration may need a longer, clearly planned testing window.

Can a Customer Reject Software for Minor Bugs?

A customer should usually only reject a milestone for defects that prevent the software meeting the agreed acceptance criteria. Minor cosmetic or low severity issues are often logged for later fixing unless the contract says they block acceptance.

What Is Deemed Acceptance in a Software Agreement?

Deemed acceptance means the software is treated as accepted if a defined event occurs, such as no valid rejection within the testing period or ordinary live use. Customers should ensure the trigger is fair and does not apply before real testing is possible.

Key Takeaways

• A software acceptance testing clause should define the deliverable, testing process, acceptance criteria, rejection process and payment trigger.
• Clear software development acceptance criteria reduce disputes by linking each milestone to measurable business and technical outcomes.
• Testing periods should start only when the customer has access to the build and enough information to test it properly.
• Deemed acceptance can be fair, but it should not occur accidentally through limited testing, pilot use or unclear internal sign-off.
• Defect severity levels help separate acceptance-blocking issues from minor bugs and later fixes.
• Change requests should be documented, priced and approved separately so new scope is not confused with defects.

If you need help drafting or reviewing your software development agreement, UAT wording, milestone payment terms, defect process or data protection provisions, Sprintlaw UK's legal team can help. Call 08081347754 or email team@sprintlaw.co.uk for a free, no-obligations chat.