Acceptance Criteria In Software Development Contracts

Priya runs a small ecommerce brand in Manchester and hires a software agency to build a custom stock management tool. The demo looks promising, the launch date is close, and the agency sends the final invoice.

Then the problems start. Priya says the tool isn't ready because the reporting dashboard is slow and two integrations don't work properly. The agency says those issues are minor and the work is complete. Nobody can point to a clear contract clause that says when the software is accepted, when payment is due, or what level of bugs is acceptable at launch.

This is exactly where software acceptance criteria in a contract earn their keep. They turn a subjective argument about whether something is "finished" into a practical process your business can follow.

What Are Acceptance Criteria In A Software Development Contract?

Acceptance criteria are the agreed standards the software must meet before the client has to accept the work and pay the relevant invoice.

In a software development agreement, acceptance criteria usually sit alongside the scope of work, project milestones, testing process and payment schedule. They explain what the developer is building and how both sides will decide whether each deliverable is ready.

Good acceptance criteria are specific enough that you can test them. For example, instead of saying "the app must be user-friendly", you might say:

• Users can create an account using email and password.
• The checkout page processes payment through the agreed payment provider.
• Order confirmation emails are sent within two minutes of payment.
• The admin dashboard displays orders by date, customer and payment status.
• The system supports 500 concurrent users in the test environment without material performance issues.

That level of detail helps both sides. If you're the client, you know what you're paying for. If you're the developer, you have a clearer path to sign-off and can avoid open-ended requests that were never part of the agreed build.

Why Do Software Development Agreement Acceptance Testing Clauses Matter?

Acceptance testing clauses matter because they set the process for checking the software before it's treated as accepted.

Without a written testing process, you can end up with awkward gaps. The client might keep testing for weeks and withhold payment. The developer might treat the work as complete as soon as it's delivered to a staging environment. Neither position is helpful if the contract doesn't say what should happen next.

An acceptance testing clause usually covers:

• Who is responsible for testing the software.
• When testing starts.
• How long the client has to test each deliverable.
• What test environment, devices, browsers or data sets will be used.
• How the client must report defects.
• How quickly the developer must fix rejected work.
• When the deliverable is accepted or deemed accepted.

For many projects, a testing period of 5 to 10 business days is common, but the right timeframe depends on the size and complexity of the build. A simple website development feature may only need a few days. A SaaS implementation that affects customer billing or operational workflows may need longer and may need staged testing.

Example: Acceptance Testing In Practice

Say you run a software agency building a booking platform for a chain of fitness studios. You deliver Milestone 2, which covers class scheduling, trainer profiles and member booking.

Your contract could say the client has 7 business days to test that milestone against the agreed acceptance criteria. If the client finds defects, they must log them in the project management tool with screenshots, steps to reproduce and the relevant acceptance criterion. You then have a set period to fix material defects and resubmit the milestone for testing.

That process keeps everyone focused on the agreed deliverables rather than vague comments like "it doesn't feel ready" or "we expected it to work differently".

How Should Software Contract Milestones Work?

Software contract milestones should break the project into clear stages, with each stage linked to deliverables, acceptance criteria and payment.

This is usually much safer than waiting until the end of a project to decide whether everything is acceptable. Long builds can shift over time. Team members change, priorities move and assumptions get forgotten. Milestones give you regular sign-off points.

A milestone structure might look like this:

• Milestone 1: Discovery, technical specification and wireframes.
• Milestone 2: Core user account and login functionality.
• Milestone 3: Payment, subscription and invoicing features.
• Milestone 4: Admin dashboard and reporting.
• Milestone 5: User acceptance testing, bug fixes and production launch support.

Each milestone should have its own acceptance criteria. Payment can then be tied to acceptance of that milestone, delivery of that milestone, or a mix of both. Which approach is right depends on your bargaining position, cash flow needs and project risk.

Milestone Payments For Developers

If you're the developer, you don't want to fund a large build for months and only get paid if the client signs off everything at the end. A staged payment model can protect your cash flow.

You might ask for:

• An upfront deposit before work starts.
• Milestone payments when each stage is delivered for testing.
• A final payment on final acceptance or launch.
• Separate rates for out-of-scope changes.

You may also want the contract to say that a client can't withhold payment for an accepted milestone because of an issue in a later milestone, unless the earlier work is genuinely defective.

Milestone Payments For Clients

If you're the client, you want enough control to avoid paying in full for software that doesn't meet the agreed requirements. Acceptance-linked milestones can help.

You might ask for:

• Clear deliverables for each milestone.
• A testing period before payment is due.
• A right to reject work that has material defects.
• A requirement for the developer to fix defects at no extra charge where they relate to the agreed scope.
• A holdback for final fixes or launch support, if the project risk justifies it.

The key is balance. If payment only happens after perfect software is delivered, the developer may carry too much risk. If payment happens before any meaningful testing, the client may carry too much risk.

What Should An App Development Acceptance Clause Include?

An app development acceptance clause should include the test process, acceptance criteria, defect rules, sign-off method and the consequences of acceptance.

Mobile app projects are especially prone to disputes because there are often several moving parts: iOS, Android, APIs, app store requirements, analytics tools, push notifications and third-party services. A clear acceptance clause helps you separate a development issue from a third-party delay or a change in app store review requirements.

Your clause should usually deal with:

• Test devices and platforms: For example, the current and previous major iOS versions, selected Android devices, and agreed browsers for any admin portal.
• App store submission: Whether acceptance happens before submission, after submission, or after approval by Apple or Google.
• Third-party dependencies: What happens if a payment gateway, mapping provider or CRM integration changes its API or causes downtime.
• Security and data handling: How personal data will be used in testing, whether penetration testing is planned, and whether dummy data should be used.
• Performance requirements: Load times, crash rates, response times or other measurable standards.
• Change requests: How new ideas discovered during testing will be priced and approved.

If personal data is used during testing, you'll also need to think about UK GDPR and the Data Protection Act 2018. In many cases, using anonymised or dummy data is safer. If real customer or employee data is used, your contract should clearly cover security, access controls, data processing roles and what happens to the data after testing.

Can A Client Refuse To Accept Work Because Of Bugs?

Yes, a client can usually refuse to accept work because of bugs if the bugs mean the software doesn't meet the agreed acceptance criteria, but not every bug should justify rejection.

This is where bug severity levels are very useful. Software is rarely completely free of defects at first delivery. If your contract treats every typo, layout issue or low-priority bug as a reason to reject the whole milestone, you may create unnecessary friction.

A practical contract will usually sort bugs into categories, such as:

• Critical: The software can't be used for its main purpose, causes data loss, creates a serious security issue or blocks launch.
• High: A key feature doesn't work, but there may be a temporary workaround.
• Medium: A feature works, but not exactly as specified, or there's a noticeable usability problem.
• Low: Minor visual issues, small text errors or issues that don't affect core functionality.

The contract can then say what happens at each level. For example, a milestone might be rejected if it contains any critical bugs or more than a set number of high severity bugs. Low severity bugs might be logged and fixed within an agreed warranty or support period, without delaying acceptance or payment.

Be Careful With "Perfect" Standards

It can be tempting to say software is only accepted when it is "fully working" or "free of defects". Those phrases sound protective, but they can create arguments because they don't explain what standard is actually required.

For most commercial projects, it's better to focus on whether the software materially meets the specification and whether any remaining issues stop the business from using it for the agreed purpose.

How Does Deemed Acceptance Work In A Software Contract?

Deemed acceptance works by treating the software as accepted if the client doesn't reject it properly within the agreed testing period, or if the client starts using it in a way that shows acceptance.

This kind of clause can feel a little tough at first, but it's often fair when drafted sensibly. It prevents a project from sitting in limbo because nobody has signed a formal acceptance form.

A deemed acceptance clause might say that a deliverable is accepted if:

• The client confirms acceptance in writing.
• The client doesn't provide a valid rejection notice within 7 business days after delivery for testing.
• The client uses the software in a live environment, other than for agreed testing.
• The client asks the developer to start the next milestone, where that depends on the previous milestone being accepted.

If you're the client, you may want safeguards. For example, deemed acceptance should only apply after the developer has delivered the relevant materials and told you the testing period has started. You may also want the right to reject if you discover a hidden critical defect that couldn't reasonably have been found during normal testing.

If you're the developer, you may want rejection notices to be specific. A notice that simply says "we're not happy" isn't very helpful. The contract can require the client to identify the failed acceptance criteria, describe the defect and provide reasonable evidence such as screenshots, logs or steps to reproduce the issue.

What Should SaaS Implementation Acceptance Criteria Cover?

SaaS implementation acceptance criteria should cover configuration, integrations, data migration, user access, training and any go-live requirements agreed in the contract.

SaaS projects are a little different from custom builds because the core software may already exist. The dispute is often about whether the implementation services have been completed properly, not whether the whole product has been built from scratch.

Your SaaS implementation services agreement might include acceptance criteria for:

• Configuration: The system is set up with the agreed workflows, approval rules, fields and templates.
• Data migration: The agreed data sets have been imported, with error reports reviewed and material issues resolved.
• Integrations: The platform connects to agreed systems such as accounting software, CRM tools, HR software or payment providers.
• User permissions: Admins, managers and standard users have the right access levels.
• Reporting: Agreed reports and dashboards generate the expected outputs.
• Training: Training sessions, guides or recorded walkthroughs have been delivered if they form part of the scope.
• Go-live support: The provider is available during agreed launch windows and responds to priority issues within agreed times.

It's also worth separating implementation acceptance, software licence terms and ongoing service levels. Acceptance might confirm the setup is complete, while a separate service level agreement covers uptime, support response times, maintenance and future updates.

Common Mistakes To Avoid

The most common mistake is leaving acceptance to trust and goodwill, then trying to work it out when money and launch pressure are already on the table.

Here are some practical traps to watch for:

• Using vague acceptance criteria: Words like "intuitive", "modern" and "best practice" may be useful in a design conversation, but they're hard to test in a contract.
• Forgetting out-of-scope changes: Testing often reveals new ideas. Your contract should say how those are quoted, approved and scheduled.
• No deadline for testing: If the client can test indefinitely, payment and project completion can drift.
• No deemed acceptance: Without it, a developer may struggle to close off a milestone where the client goes quiet.
• No bug severity rules: Minor issues can be used to block acceptance if the contract doesn't draw sensible lines.
• No process for third-party issues: APIs, hosting services, payment gateways and app stores can all affect delivery, even when the developer has done their part.
• No link between acceptance and payment: If the payment clause and acceptance clause don't work together, you may still end up arguing about invoices.

Templates can be a helpful starting point, but software projects vary a lot. A fixed-price app build, an agile development retainer and a SaaS implementation all need different acceptance wording. Your contract will work best when it's tailored to how your project is actually being delivered.

Key Takeaways

• Acceptance criteria explain when software is good enough to be accepted and when payment should become due.
• Acceptance testing clauses should set out who tests, how long they have, how defects are reported and what happens next.
• Milestone sign-off helps stop payment disputes from building up until the end of a project.
• Bug severity rules let you separate launch-blocking defects from minor issues that can be fixed later.
• Deemed acceptance clauses can protect projects from drifting, but they should include fair safeguards.
• SaaS implementations need criteria for configuration, integrations, data migration, permissions and go-live support.

If you'd like help with your software development agreement, app acceptance clauses, SaaS implementation terms or milestone payment structure, you can reach us at 08081347754 or team@sprintlaw.co.uk for a free, no-obligations chat.