To put acceptance criteria in a software contract, write measurable requirements for each function, including speed, security, and availability. Then agree on an acceptance procedure: who tests, for how long, with which test set, which defects block acceptance, how the retest works, and when the software counts as accepted.
If the contract only says the system "processes invoices", the project manager, the buyer, and the development team will each picture something different. This article looks at acceptance from inside the project: what you record up front so that handover ends in a decision. It covers what you agree, and it isn't legal advice.
Why handover so often ends in an argument
Vague requirements are expensive, and they get more expensive the later you find them. In their Software Defect Reduction Top 10 List (IEEE Computer, 2001), Barry Boehm and Victor Basili wrote that finding and fixing a problem after delivery is often 100 times more expensive than during requirements and design. The same paper found that software projects spent 40 to 50% of their effort on avoidable rework, with hastily specified requirements as one of the two major sources.
The Project Management Institute reached a similar conclusion in its 2014 study of requirements management. When projects missed their original goals, inaccurate requirements management was the primary cause in 47% of cases. For every dollar spent on projects and programs, 5.1% was wasted on poor requirements management.
A handover dispute is usually about a requirement that could be read two ways.
What good acceptance criteria look like
An acceptance criterion is a condition the software has to meet before the client approves it. Two people should be able to check it independently and reach the same result. So a good criterion is:
- Measurable. It contains a threshold or a concrete outcome, such as a response time, an error message, or a calculated value.
- Tied to a function. Each criterion belongs to a named function or process in the design, so everyone knows what's being tested.
- Covering the negative case. It also says what happens with invalid input, missing permissions, or an integration that doesn't respond.
- Fixed in advance. Both parties know the criterion before the build starts.
Don't skip the non-functional requirements. Performance, availability, security, and maintainability often stay implicit, and that's where expectations drift apart. The ISO/IEC 25010 product quality model describes nine quality characteristics, which makes it a handy checklist for spotting the one you forgot. Make these requirements measurable too: state how many concurrent users a response time applies to and how much data you test with.
Wording like "user-friendly" or "fast" can't be tested. Turn it into something you can tick off, or drop it.
Acceptance criteria for a user story and for a delivery
The term acceptance criteria covers two different things. In a Scrum team, they belong to a user story. The International Software Testing Qualifications Board (ISTQB) defines them in its Foundation Level syllabus:
"Acceptance criteria for a user story are the conditions that an implementation of the user story must meet to be accepted by stakeholders."
They set the scope of the story, describe positive and negative scenarios, and form the basis for testing it. The two common formats are Given/When/Then scenarios and a rule-based checklist.
Accepting a delivery is a separate moment. Here the client formally decides whether a release, a partial delivery, or the whole system is approved. That decision has consequences: warranty or maintenance often starts from that point, and part of the payment can fall due.
The two levels connect. Together, the story criteria make up much of the test set for the delivery, and the end-to-end integration test and the non-functional requirements come on top. If you work iteratively, agree explicitly whether a story the product owner approved in a sprint also counts as contractually accepted, or whether a separate acceptance test follows at the end. ISTQB also names contractual and regulatory acceptance testing as a separate form of acceptance testing.
What the acceptance procedure should cover
The acceptance procedure describes how you get from a delivery to a decision. Record at least these points:
- Test period. How long testing takes, when it starts, and whether live use is allowed during that time.
- Test set and test data. Which test cases you run and with which data. If you use real records, make sure that's permitted.
- Test environment. A separate acceptance environment that mirrors production as closely as possible, with working integrations.
- Who tests. Names or roles, the hours they have available, and who signs the test report.
- Defect classification. Which categories exist and which of them block acceptance.
- Retest. How quickly the supplier fixes defects and what you test again.
- The moment of acceptance. When the software counts as accepted, including when nobody reports anything, and what going live means.
That last point is the one that tends to slip. Deemed acceptance means the software counts as accepted when the test period passes without a report, or as soon as you put it into production. A pilot that quietly turns into daily use can become an acceptance that way. Plan your own testing capacity as well, because the test period runs on whether your testers have time or not.
How published standard terms handle acceptance
Many contracts refer to standard terms. Two well-known sets in the Netherlands show how differently acceptance can be arranged. Under GIBIT, the default procedure in article 9 applies unless the contract, the implementation plan, or a test protocol says otherwise.
| Topic | GIBIT 2025, article 9 | NLdigital Voorwaarden 2025, article 44 |
|---|---|---|
| Test period | Test after each delivery, completed within five weeks | 14 days after delivery or installation |
| Live use | Putting it into production counts as acceptance, unless caused by supplier delay | Not allowed during testing. Going live counts as acceptance |
| End of test period | Both parties draw up and sign a test report | Accepted on the first day after the test period |
| Minor defects | Don't block if they don't prevent production use | Don't block, and neither do subjective aspects such as visual design |
| Partial deliveries | A full integrated acceptance follows the last partial delivery | Rejecting one phase doesn't affect earlier phases |
GIBIT 2025 holds the procurement conditions Dutch municipalities use for IT. After the test report, the supplier provides a repair schedule and submits the delivery for acceptance again. If it's rejected a second time, the client can choose between terminating, allowing repair, or accepting conditionally. Of one-off fees, 30% only falls due after the final integrated acceptance. Our article on GIBIT 2025 covers the conditions in more depth.
The NLdigital Voorwaarden 2025, the terms of the Dutch IT industry association, test against the functional or technical specifications expressly agreed in writing. An error has to be demonstrable and reproducible, and the client reports test results no later than the last day of the test period. When the parties use the iterative development method of article 50, most of article 44 no longer applies and the client accepts the software as it stands at the end of the last development phase. If test moments are agreed in that setup, testing is based only on objective, measurable criteria agreed in advance.
Which defects block acceptance
Without an agreed classification, every finding turns into a negotiation. The ISTQB syllabus includes both severity (the degree of impact) and priority to fix in a defect report. For acceptance, severity matters most. Three levels are often enough:
- Blocking. A core process can't be completed, data is lost, or a security requirement isn't met. Acceptance follows only after the fix and a retest.
- Major with a workaround. The function departs from its criterion. A temporary workaround keeps the work going. You agree whether this blocks and how soon it gets fixed.
- Minor. Work continues without hindrance. This doesn't block acceptance and goes on the fix list.
Record who decides the classification, what happens when the parties disagree, and how many major findings together hold up acceptance. GIBIT also lets the parties agree on a temporary workaround and deliver the fix later. In the test report, give every finding its category and a fix date.
How acceptance criteria connect to the functional design
You can only write solid acceptance criteria once it's clear what the software has to do. That description lives in the functional design: the processes, screens, rules, and integrations. Link every criterion to a part of that design. You'll then see which functions still lack a criterion.
When the design changes during the build, the criteria change with it, through the same change procedure and with a date. At handover you then test against the latest agreed version.
If you're commissioning custom software development, that line from design to criterion to test pays off from the first sprint.
We've been building software for more than 30 years, with 30+ engineers in Nijmegen and Sarajevo, and have delivered 100+ projects, from MRO software for aviation to a grant administration platform and RFID in the supply chain. We work to ISO 9001 and ISO 27001. Our QA and testing page explains how we combine manual and automated testing, and our cases show who we've built for. Book a conversation and we'll look at the acceptance criteria for your next project with you.
Frequently asked questions
What are acceptance criteria?
Acceptance criteria are the conditions, agreed in advance, that software has to meet before it's approved. Good criteria are measurable, belong to a named function, and also describe what happens with invalid input. They apply to functional requirements and to non-functional ones such as performance and security.
What is the difference between acceptance criteria and an acceptance test?
Acceptance criteria describe what the software has to meet. The acceptance test is the execution: the client runs a test set within an agreed period and establishes whether the criteria are met.
What is deemed acceptance in software projects?
With deemed acceptance, software counts as accepted without an explicit decision, for example because the test period ends without a report or because the client puts it into production. Both GIBIT 2025 and the NLdigital Voorwaarden 2025 contain a provision on going live.
Who writes the acceptance criteria?
The client owns the criteria, because they define when the result is usable. In practice you write them together, and the supplier checks whether they're measurable and feasible.
