Contract Acceptance Testing: Clear Acceptance Criteria for Software & SaaS

Software deals often go wrong at the same point: the supplier says the product is ready, the customer says it is not, and the contract does not clearly say who is right. For UK businesses buying or supplying software, that gap can become expensive fast. Teams start workarounds, invoices are disputed, deadlines drift, and everyone points back to vague wording like “fit for purpose” or “industry standard”.

Common mistakes are easy to spot. Businesses sign contracts with no measurable acceptance criteria, rely on demos or sales promises that never make it into the written terms, or treat user testing as an informal exercise instead of a contractual milestone. The result is confusion about payment, handover, fixes and whether the software has actually been accepted.

Contract acceptance testing is the part of the deal that decides whether the software or SaaS service meets the agreed standard. This guide explains what contract acceptance testing means in practice, what UK businesses should check before they sign, where founders often get caught out, and how to set acceptance criteria that are realistic, measurable and legally useful.

Overview

Contract acceptance testing sets the rules for how software will be tested, when it will be treated as accepted, and what happens if it fails. A clear clause can prevent arguments about whether the project is complete, whether payment is due, and whether the supplier must keep fixing issues before go live or rollout.

For most software and SaaS deals, the acceptance process should be tied to practical business outcomes, not general promises or assumptions.

• Define exactly what is being tested, such as a custom build, implementation, integration, migration or configuration.
• Set measurable acceptance criteria, including required functions, performance standards, security points and compatibility needs.
• State who will run the tests, where they will happen, what data or environments will be used, and how long the testing period lasts.
• Explain how defects are classified, what counts as a failure, and how retesting works after fixes.
• Make it clear when acceptance is deemed to happen, including whether use in production, delay in responding, or payment can trigger deemed acceptance.
• Link acceptance to payment milestones, service commencement, warranty periods and ongoing support obligations.
• Record any assumptions, dependencies and customer responsibilities, especially where the supplier needs access, approvals or third party systems.

What Contract Acceptance Testing Means For UK Businesses

Contract acceptance testing is the contractual process for deciding whether software meets the agreed requirements. It is not just a technical checklist, it is the legal mechanism that often determines whether the supplier has delivered what it promised.

In a software development agreement, acceptance testing usually applies to a build or project deliverable. In a SaaS agreement, it may apply to implementation work, onboarding, integrations, data migration, customisation or a pilot environment. Even where the core platform is standard, the acceptance process can still matter if the customer is paying for configuration or rollout work.

Why acceptance testing matters so much

The main reason is simple: if the contract is vague, both sides may be acting on completely different expectations. A founder may expect software that matches the sales demo, supports a specific workflow and integrates neatly with finance tools. The supplier may think its job is done once the system is accessible and the listed features broadly work.

A well drafted acceptance clause narrows that gap. It gives both sides a shared method for answering practical questions such as:

• What does “delivered” actually mean?
• Which defects must be fixed before acceptance?
• Can the supplier still invoice if the customer has not signed off?
• What happens if the customer delays testing?
• Does using the system in live operations count as acceptance?

What acceptance criteria should cover

Acceptance criteria should be specific enough that someone outside the sales process could apply them. If a clause only says the software must be satisfactory or fit for purpose, there is a lot of room for dispute.

Better acceptance criteria usually cover a mix of technical and business points, such as:

• Core functions that must work.
• Required integrations with named systems.
• Data migration accuracy or reconciliation thresholds.
• User access, permissions and audit trail needs.
• Performance measures, such as response times or transaction volumes.
• Security features or compliance-related controls.
• Browser, device or operating system compatibility.
• Reporting outputs and export functions.

For UK businesses in regulated or data-heavy sectors, acceptance criteria may also need to reflect privacy, security and record keeping expectations. If the system will process personal data, your contract should align with your wider privacy notice and data protection obligations. Acceptance testing is not a replacement for a proper data protection review, but it can help ensure the product actually supports the compliance features you need.

Different models for software and SaaS

Not every deal uses the same testing model. A custom software project may have staged acceptance for each development phase. A SaaS implementation may have one testing period after configuration and migration. An enterprise rollout may use pilot acceptance before wider deployment.

The right model depends on the deal, but most contracts should answer the same practical points:

• When does the testing period begin?
• How long does it last?
• Who prepares the test scripts or test plan?
• Who approves the test results?
• What level of failure allows rejection?
• What cure period does the supplier get?
• How many rounds of retesting are allowed?

This is where founders often get caught. They assume the testing process will be worked out later by the project team, but by then the legal leverage has changed. Before you sign, you still have room to insist on objective acceptance criteria and a fair remedy if the software does not meet them.

How acceptance links to payment and risk

Acceptance is often tied to money. A supplier may want payment on delivery, on completion of implementation, or automatically if the customer does not reject within a short period. A customer may want to hold back a final milestone until successful testing.

Neither approach is automatically right or wrong. The issue is whether the payment structure matches the actual project risk. If most of the fee is payable before meaningful testing happens, the customer may have little practical leverage if serious issues appear. If payment is held too late without a fair sign-off process, the supplier may be carrying open-ended risk for delays outside its control.

The contract should also deal with what happens after acceptance. For example, does the warranty period start on acceptance? Do support service levels only begin once the system is live? Are minor defects pushed into the support process rather than blocking sign-off? These points need to line up.

Legal Issues To Check Before You Sign

Before you sign a software or SaaS contract, make sure the acceptance testing clause matches the deal you actually think you are making. The legal drafting should convert sales discussions into measurable obligations, not leave the key standard to argument later.

Scope of the deliverables

The contract should clearly identify what is subject to acceptance testing. That sounds obvious, but many disputes start because the parties never pinned down whether testing applies to the software itself, implementation services, migrated data, integrations or training.

If the supplier is delivering several workstreams, list them separately and say whether each one has its own acceptance stage.

Objective and measurable criteria

Acceptance criteria should be capable of being passed or failed. A good test is whether an operations manager or project lead could apply the criteria without having sat in the original sales meetings.

Vague wording creates risk. Stronger wording often includes:

• Named features and workflows that must operate successfully.
• Specific interfaces or third party systems that must connect.
• Defined error rates or uptime-related metrics during testing.
• Security controls that must be present before deployment.
• Required documentation, training materials or admin access.

Testing procedure and timing

The contract should say how testing happens in practice. If it does not, the parties may disagree about whether the customer tested properly, whether the supplier had a fair chance to observe failures, or whether the deadline for rejection has passed.

The clause should usually cover:

• The start date for testing.
• The length of the testing window.
• The test environment and any required sample data.
• Who supplies test scripts or scenarios.
• Who attends or supervises testing.
• The method for reporting defects.
• The timetable for fixes and retesting.

Defect severity and rejection rights

Not every issue should let a customer reject the system. The contract should separate material failures from minor defects. Otherwise, a project can stall over small issues that do not stop normal use.

Many contracts classify defects by severity, for example critical, major and minor. The key legal point is to define what each category means and what the consequence is. A sensible structure may allow rejection for critical defects, conditional acceptance for major defects with a fix plan, and acceptance with a snag list for minor items.

Deemed acceptance

Deemed acceptance means the software is treated as accepted even without a formal sign-off. This often happens if the customer does not reject within a stated period, uses the software in production, or confirms a payment milestone.

Deemed acceptance is common, but it needs careful drafting. For customers, the risk is being treated as having accepted software that has not really been tested. For suppliers, the risk is leaving acceptance open forever because no formal sign-off is ever given.

Before you accept the provider's standard terms, check exactly what triggers deemed acceptance and whether those triggers are fair in the real project timeline.

Dependencies and customer responsibilities

Suppliers often say they cannot be responsible for delays or failed tests caused by the customer’s systems, data or decisions. That can be reasonable, but the contract should state those dependencies clearly.

Look for assumptions such as:

• The customer will provide access to key staff.
• The customer will supply accurate source data.
• Third party vendors will cooperate on integrations.
• The customer will review deliverables within a set time.
• Infrastructure or licences will be ready by a stated date.

If these assumptions matter, they should be written down. Otherwise each side may later blame the other for test failures.

Warranties, liability and remedies

Acceptance testing does not deal with every legal remedy on its own. The wider contract should also cover warranties, liability clauses, service credits where relevant, termination rights and the process for fixing defects after acceptance.

Customers should be careful where the contract says acceptance is the sole remedy for non-conformity. Suppliers should be careful where warranties are drafted so broadly that they create ongoing obligations far beyond the agreed acceptance criteria.

If a statement made during procurement really matters, put it into the contract as a clear promise, specification or warranty. Before you rely on a verbal promise, ask whether it appears anywhere in the signed document.

Common Mistakes With Contract Acceptance Testing

Most acceptance disputes are caused by drafting shortcuts, not unusual legal principles. The common pattern is that the parties move quickly to get the deal signed and leave the hard detail for later.

Using sales language instead of testable requirements

Words like intuitive, market leading, scalable or suitable for your business sound reassuring, but they are hard to test. If the software must support a particular workflow, volume or control feature, say that directly.

A contract should not leave the real requirements hidden in slide decks, emails or demo calls.

Copying a clause from another deal

A standard acceptance clause from a different project can create the wrong result. A custom build, SaaS onboarding and data migration exercise all carry different risks. A generic clause may ignore implementation dependencies, security checks, or the fact that live use starts before every minor issue is resolved.

This is especially common where a small business signs an enterprise supplier’s paper without tailoring the testing process to the actual rollout.

Making the testing period too short

A five day testing window may look neat in a contract, but it can be unrealistic where multiple users, departments or integrations are involved. If the timeline is too short, the customer may miss serious issues or be forced into a premature sign-off. If it is too long, the supplier may be left waiting indefinitely for acceptance and payment.

The answer is not just a longer period. The answer is a period that reflects the actual test scope and internal approval process.

Failing to align acceptance with real business use

Some projects technically pass scripted tests but still fail in day to day operations. That usually happens when acceptance criteria focus only on narrow system functions and ignore the practical workflow the business actually needs.

For example, a finance system may produce reports but not in a format the finance team can use. A CRM integration may connect successfully but duplicate customer records. A support platform may accept logins but fail role-based permissions needed for compliance or management oversight.

Acceptance criteria should reflect the founder moment that matters: can the business rely on this software for the purpose discussed before the contract was signed?

Ignoring data migration and third party integrations

Plenty of software projects fail at the edges, not in the core platform. Data migration, payment gateways, ERP links, single sign-on and reporting exports often create the biggest operational risk.

If those pieces matter, they should not be left as assumptions. The contract should state whether they are included, what standard they must meet, and who is responsible if a third party system causes problems.

Treating UAT as purely operational, not contractual

User acceptance testing, often called UAT, is frequently run by operational teams without much legal input. That is understandable, but the contract still matters. If the project team informally signs off a workaround, or starts live use because the business is under pressure, that may affect legal rights under the acceptance clause.

Internal teams should know what contractual acceptance means, who has authority to confirm it, and how defects must be recorded. Otherwise a business can accidentally waive points it intended to preserve.

Not matching acceptance to support and change control

Another common issue is mixing up project defects with future changes. Suppliers are usually responsible for fixing failures to meet the agreed scope. They are not usually required to deliver new features for free just because the customer expected more.

The contract should separate:

• Defects that stop the software meeting the agreed specification.
• Minor post-acceptance issues handled through support.
• New requirements handled through change control and extra fees.

If that line is unclear, every disagreement becomes a debate about whether the issue is a bug or a variation.

FAQs

Is contract acceptance testing only relevant for custom software projects?

No. It is often most obvious in custom development, but it can also be important for SaaS implementation, onboarding, integrations, migration work and configured solutions where the customer is relying on a supplier to deliver a working setup.

Can a UK business reject software for any defect found during testing?

Usually not. The contract should say what level of defect allows rejection. Many agreements only allow rejection for material or critical failures, while minor defects are fixed after conditional or full acceptance.

What is deemed acceptance in a software contract?

Deemed acceptance means the software is treated as accepted even without formal sign-off, usually because the customer did not reject it in time, started using it live, or triggered another contractual milestone. The wording needs careful review because it can shift risk quickly.

Should payment be linked to acceptance testing?

Often yes, at least in part. Linking some payment to successful acceptance can help align incentives, but the structure should still be fair to both sides and reflect the supplier’s work done before final sign-off.

Do sales promises count if they are not written into the contract?

They may not help much if a dispute arises. If a feature, integration or outcome matters to the deal, ask for it to be included in the contract, specification or statement of work before you sign.

Key Takeaways

• Contract acceptance testing is the contractual process for deciding whether software or SaaS implementation work meets the agreed standard.
• Clear acceptance criteria should be measurable and tied to the functions, integrations, performance and business outcomes that actually matter.
• Before you sign, check the testing procedure, defect classifications, rejection rights, deemed acceptance triggers, payment milestones and customer dependencies.
• Many disputes start because businesses rely on demos, emails or verbal assurances instead of putting key requirements into the contract.
• User acceptance testing should be treated as both an operational and legal milestone, with clear authority, records and escalation paths.
• The best acceptance clause aligns with warranties, support, change control and the practical way the software will be used in the business.

If you want help with acceptance criteria, software contract drafting, SaaS implementation terms, and defect and payment risk allocation, you can reach us on 08081347754 or team@sprintlaw.co.uk for a free, no-obligations chat.