Enterprise software projects fail in public for many reasons. In the documents, they fail most often at acceptance. A contract that says the system will be “accepted when it meets the customer’s reasonable satisfaction” is not a commercial agreement; it is an opening submission. Our technology practice treats acceptance as the centre of gravity for implementation deals and for any SaaS arrangement with material configuration.
What good acceptance looks like
- Objective criteria. Testable conditions tied to a statement of requirements or user stories with pass/fail thresholds.
- A defined testing window with responsibilities for environment, data, and personnel on both sides.
- Severity classifications that distinguish deal-breakers from cosmetic defects, with a known path for each.
- Deemed acceptance triggers that prevent infinite delay, balanced by a right to reject for material failure.
- Post-acceptance warranty that does not pretend go-live is the end of all defects, but also does not reopen the entire price.
Liability follows acceptance
Limitation clauses in technology contracts only work if the parties know when risk transfers. Unlimited liability for IP infringement and data breach remains market-standard in many deals; unlimited liability for “failure to meet requirements” is not, and should not be. We structure caps around fees paid in a trailing period, with separate treatment for service credits (which are often an exclusive remedy for SLA failure) and for wilful default or abandonment of the project.
Agile is not an excuse for vagueness
Agile delivery is compatible with legal certainty. It requires a backlog governance process, change control that does not depend on goodwill, and a definition of done that finance and legal can recognise. Where a client insists on pure time-and-materials with no acceptance, we document that choice expressly and adjust the liability and termination regime accordingly. The risk has to live somewhere; the contract’s job is to say where.
Practical takeaway
Before you argue about liability caps, ask whether a neutral third party could determine from the contract whether the software has been accepted. If not, fix that first. Everything else in the technology schedule depends on it.
This note is for general information only. It is not legal advice and should not be relied upon as such. For advice on a specific matter, please contact the firm.