Defining Acceptance Criteria in Software

When you’re building software (or buying it), it’s easy to focus on the exciting parts - the features, the launch date, and what your product will do once it’s live.

But there’s a practical question that often gets missed until something goes wrong: how do you know the software is actually “done”?

That’s where acceptance tests and well-drafted acceptance criteria come in. For startups and SMEs, having a clear acceptance testing process can be the difference between paying for something that works for your business, and being stuck in an endless loop of “almost finished” deliverables, scope disputes, or a platform you can’t properly use.

In this guide, we’ll walk you through what acceptance tests are, how to define acceptance criteria in software and SaaS contracts, and what to include so you’re not relying on vague promises like “industry standard” or “best efforts”.

What Are Acceptance Tests (And Why Do They Matter In A Contract)?

Acceptance tests are structured checks used to confirm that a software deliverable meets agreed requirements before you “accept” it. In other words, they turn “Is it good enough?” into “Does it meet the measurable criteria we agreed to?”

This matters because most disputes in software projects aren’t about whether someone worked hard - they’re about:

what was included in scope (and what wasn’t)
whether the deliverable meets the agreed requirements
whether payment is due
who fixes defects, and by when
whether delays are justified

If your contract clearly sets out acceptance tests and acceptance criteria, you reduce the chance of disagreements and make it much easier to manage your risk (and your budget).

Acceptance Tests vs QA vs UAT: What’s The Difference?

These terms often get used interchangeably, but they’re not the same:

Quality assurance (QA) usually refers to the supplier’s internal process for checking quality during development.
User acceptance testing (UAT) is typically testing done by you (the customer) to confirm the deliverable works for real business use.
Acceptance tests is the broader contractual concept - the agreed process/criteria that determines whether the deliverable is accepted (often including UAT steps).

In a contract, the key is not the label. It’s making sure the test process and pass/fail rules are clear, measurable, and enforceable.

When Do You Need Acceptance Tests In Software And SaaS Contracts?

Not every tech arrangement needs a complex acceptance testing schedule. But startups and SMEs often benefit from acceptance tests in any contract where you’re paying for a deliverable and relying on it to run your business.

Acceptance tests are especially useful when you’re dealing with:

custom software builds (web apps, internal systems, integrations)
phased development (milestones or sprints)
complex integrations (payment gateways, CRMs, third-party APIs)
data migrations (moving legacy data into a new platform)
SaaS implementations with configuration and onboarding deliverables

Even in a SaaS arrangement where the provider is giving you an “off-the-shelf” service, acceptance criteria can still matter for things like onboarding, configuration, integrations, reporting, and any professional services component.

A Quick Reality Check For Startups

If you’re a startup, you might feel pressure to “move fast” and avoid slowing down delivery with legal detail. That’s fair - but the wrong kind of speed can be expensive.

Clear acceptance tests don’t slow your project down. They usually speed up decision-making, reduce rework, and stop the project getting stuck in an ambiguous final stage.

How To Define Acceptance Criteria (So “Done” Actually Means Done)

Good acceptance criteria are objective, testable, and aligned with business outcomes. They should be specific enough that a third party could read them and understand whether the deliverable passed or failed.

Here are the key components you’ll usually want to define.

1. Define The Deliverables With Enough Precision

Acceptance tests only work if the deliverables are defined clearly. For example:

What features must exist (and what is explicitly excluded)?
What platforms must be supported (web, iOS, Android)?
What browsers/devices must it work on?
What integrations must be included?
What documentation and training must be provided?

In practice, this often sits in a Statement of Work (SOW), proposal, or product specification attachment. Your contract should state which documents form part of the agreement and what happens if they conflict.

2. Use Clear Pass/Fail Criteria (Avoid “Reasonable” Where Possible)

Words like “reasonable”, “industry standard”, or “to your satisfaction” can sound helpful, but they can be hard to enforce if there’s a dispute.

Instead, try criteria like:

Functional: “User can reset password via email link within 2 minutes.”
Performance: “Dashboard loads in under 3 seconds for 95% of requests under X concurrent users.”
Availability: “Service uptime of 99.9% measured monthly (excluding scheduled maintenance).”
Security: “Data encrypted in transit using TLS; role-based access implemented for admin features.”
Integration: “Payments processed successfully via [payment provider] in test and production environments.”

The level of detail should match the size and risk of the project. But even a small project benefits from a few crisp acceptance criteria that everyone agrees on.

3. Separate “Defects” By Severity

One common trap is a contract that says “no defects” at acceptance. In real-world software development, that can be unrealistic - and it can create tension when minor cosmetic issues block launch.

A better approach is to define defect categories, for example:

Critical defect: system crash, data loss, payment failure, security vulnerability
Major defect: key feature unusable, but workaround exists
Minor defect: non-critical bug, UI issue, spelling, formatting

Then link acceptance to severity, such as:

acceptance is blocked by any critical defects
acceptance is allowed with minor defects if logged and fixed within an agreed period

This gives you leverage where it matters, without making acceptance impossible.

4. Set A Timeframe For Testing (And What Happens If You Don’t Respond)

Your acceptance testing clause should clearly state:

how long you have to test (e.g. 5, 10, or 15 business days after delivery)
how you must notify acceptance or rejection (email is common)
what evidence you must provide when rejecting (e.g. defect list, reproduction steps)
whether “deemed acceptance” applies if you don’t respond within time

Deemed acceptance clauses are often included in software and services contracts. They aren’t always unfair, but you should make sure the testing window is realistic for your team (and that the steps for rejection are clear).

If you’re time-poor, it may be better to negotiate:

a longer acceptance window, or
an option to extend once by notice, or
supplier support during your testing window

5. Tie Payment Milestones To Acceptance (Not Just Delivery)

One of the biggest commercial benefits of acceptance tests is being able to link payment to real outcomes.

For milestone-based projects, consider a structure like:

deposit to commence work
milestone payment on delivery for UAT
final payment on acceptance (or acceptance with agreed minor defects)

This reduces the risk of paying 100% for work that isn’t usable yet. It also encourages the supplier to address issues promptly.

Where you’re negotiating the broader commercial deal, it can be helpful to align the acceptance approach with other key terms in your invoice payment terms.

What Should An Acceptance Testing Clause Include In Australia?

There’s no single “standard” acceptance testing clause that suits every business. But for most startups and SMEs, a solid clause will cover the points below (noting the right approach depends on the project, the parties, and the commercial deal).

Scope And Documentation Hierarchy

Make sure the contract clearly identifies what documents form the agreement (and which one wins if there’s a conflict). This might include:

the master services agreement (MSA)
statement of work (SOW)
proposal or quotation
technical specification
change requests

If you’re dealing with quotes and proposals, it’s also worth understanding when pricing documents become binding - a helpful concept to keep in mind is whether a quote is legally binding in your scenario.

Acceptance Process Steps

Spell out the process in a simple sequence, such as:

Supplier delivers milestone deliverable and supporting documentation.
Customer conducts acceptance tests within X business days.
Customer issues notice of acceptance or rejection (with defect list).
If rejected, supplier remedies defects within Y business days and resubmits.
Repeat until accepted or escalation/termination rights apply.

This sounds basic, but clarity here is what prevents “We thought it was approved” disputes.

Testing Environment And Data

Acceptance tests can fail for reasons unrelated to the supplier - for example, if the testing environment is unavailable or you can’t provide data needed to test.

Consider including who is responsible for:

providing a staging/UAT environment
test accounts and access credentials
test data or sample datasets
third-party vendor access (APIs, integrations)

Change Control (So Acceptance Tests Don’t Become “Scope Creep”)

Acceptance testing is not the time to request entirely new functionality. If you add new requirements during testing, you risk disputes over whether the supplier must implement them without extra cost.

A good contract will include a change control process that states:

how changes are requested
how pricing/time impacts are assessed
when changes become binding (signed change request, updated SOW, etc.)

This can also reduce arguments about making amendments to contracts mid-project.

Warranty Period After Acceptance

Acceptance shouldn’t mean “we found a bug, tough luck”. Depending on the contract, it’s common to include a warranty or defect liability period after acceptance (often around 30–90 days) where the supplier fixes defects discovered in real use.

You’ll want to define:

what is covered (defects vs enhancements)
response and resolution timeframes
whether fixes are included in fees or billed separately

Common Acceptance Testing Traps For Startups And SMEs (And How To Avoid Them)

Even sophisticated founders get caught by a few recurring issues. Here are the big ones we see in practice.

Trap 1: Vague Requirements Like “Works As Expected”

If your requirements are vague, acceptance tests become subjective. Subjective acceptance leads to disputes, delays, and surprise costs.

Fix: write acceptance criteria that can be demonstrated, measured, or reproduced.

Trap 2: No Clear Remedy Cycle

If the contract doesn’t say what happens when acceptance tests fail, you can end up with:

endless back-and-forth with no deadlines
pressure to accept “as is”
unclear responsibility for fixes

Fix: include a defect remediation loop with timeframes and escalation rights.

Trap 3: Paying Too Much Upfront

Paying most (or all) fees before acceptance reduces your leverage to ensure issues are addressed quickly.

Fix: structure milestone payments so meaningful amounts are tied to acceptance, not just delivery.

Trap 4: “Deemed Acceptance” With An Unrealistic Testing Window

A deemed acceptance clause combined with a short testing window can be risky - especially if you’re a small team and the testing falls on the founder’s shoulders.

Fix: negotiate a realistic acceptance period and define what information you need to provide for rejection.

Trap 5: Not Aligning Acceptance Tests With Liability And Limitations

Acceptance tests don’t sit in isolation. They interact with limitation of liability clauses, warranties, and termination rights.

For example, if the contract heavily limits the supplier’s liability, but also forces you to accept quickly, you could be left carrying most of the risk.

If you’re reviewing a contract, it’s worth paying attention to limitation of liability clauses and how they work in practice.

What Other Legal Documents Should Support Acceptance Tests In Tech Deals?

Acceptance tests are usually one important part of a bigger contract framework. Depending on how your tech project is structured, you may also want to consider the documents below.

Master Services Agreement (MSA) or Services Agreement: sets the core legal terms, ownership, liability, confidentiality, and how disputes are handled.
Statement of Work (SOW): details what’s being built, timelines, milestones, and acceptance tests for each phase.
IP clauses (ownership and licensing): critical if custom code is being created. Your business needs clarity on whether you own the deliverables, or just get a licence to use them.
Privacy terms: if personal information is collected or processed, you may need a Privacy Policy and contract clauses addressing data handling, security, and breach processes.
Confidentiality protection: useful early in discussions and throughout the build, often handled through a mutual NDA.
Website or platform terms: if you’re launching a SaaS product to customers, having clear Platform Terms and Conditions can help set expectations around availability, support, and acceptable use.

If your business has co-founders or investors involved in decision-making around the product, it can also be helpful to clarify who has authority to approve deliverables and accept milestones - this often ties into governance documents like a shareholders agreement and internal approval processes.

Key Takeaways

Acceptance tests help you objectively confirm that software deliverables meet agreed requirements before you accept them and pay.
Strong acceptance criteria should be specific, measurable, and testable - not vague promises like “industry standard” or “works as expected”.
A practical acceptance clause covers the testing period, pass/fail rules, defect severity, remediation timeframes, and deemed acceptance.
For milestone projects, tying payments to acceptance (not just delivery) can reduce the risk of paying for work that isn’t usable.
Acceptance testing should align with the rest of your contract - especially warranties, IP ownership, and limitation of liability terms.

This article is general information only and isn’t legal advice. If you’d like help setting up or reviewing acceptance tests and acceptance criteria in your software or SaaS contracts, you can reach us at 1800 730 617 or team@sprintlaw.com.au for a free, no-obligations chat.

Defining Acceptance Criteria In Software And SaaS Contracts