Software Specification Disputes: Who Is Responsible When the Software Does Not Meet Requirements?
A software system can be technically operational but still fail to deliver what the business expected. This is where many software specification disputes begin. A key workflow may be missing or incapable of operating as specified, an integration may not work properly, reports may be inaccurate, or the system may require manual workarounds that undermine the purpose of the project.
When this happens, the legal question is not simply whether the software meets the customer’s business needs. The central issue is what the supplier was contractually required to provide.
In a business-to-business software dispute, responsibility will usually depend on the agreed scope, the contractual documents, how requirements were developed, whether they changed during the project, and what happened during testing and acceptance. The supplier may be responsible, the business customer may have contributed to the problem, or responsibility may be shared.
What does it mean for software to meet the specification?
The specification is usually the contractual description of what the software is required to do. However, there may not be a single document called “the specification”.
The relevant requirements may be spread across a master services agreement, statement of work, functional specification, technical design, supplier proposal, project plan, user stories, acceptance criteria and agreed change requests.
The first task is therefore to identify:
- Which documents form the contract. A business expectation does not automatically become a contractual obligation. The business should review the contract to establish which documents the parties incorporated and which takes priority if different documents conflict.
- What the supplier actually promised to deliver. A broad requirement such as “integration with the accounting system” may leave important questions unanswered. The business may need to examine the contract to establish what information had to transfer, how the integration should operate and who was responsible for defining the detail.
This distinction is crucial. Software can fail to meet a customer’s expectations without necessarily breaching the contract.
When is the supplier responsible in software specification disputes?
A supplier may be in breach where the contract requires a defined function, deliverable or outcome and the software does not provide it.
However, whether that obligation is absolute will depend on the contract as a whole. The relevant requirement may be qualified by assumptions, customer dependencies, acceptance criteria or express customer responsibilities.
A separate issue arises where the supplier agreed to provide professional development, configuration or implementation services. Where the arrangement is a relevant contract for the supply of services and the supplier acts in the course of business, section 13 of the Supply of Goods and Services Act 1982 generally implies a term that the supplier will carry out those services with reasonable care and skill.
In a B2B contract, however, that implied obligation must be considered alongside the express contractual terms and any provisions seeking to exclude or limit liability. By express agreement, the parties can usually vary or exclude the implied term, but any exclusion or limitation of liability for breach of it must satisfy the reasonableness test in the Unfair Contract Terms Act 1977. The statutory term also does not displace any stricter duty that the law may impose, so, depending on the facts and the contract, a customer may sometimes argue for a more demanding standard than reasonable care and skill where the supplier undertook to design a system for a purpose it knew about.
The distinction can therefore matter between:
- failing to provide functionality expressly promised by the contract; and
- performing professional services without the required standard of reasonable care and skill.
The same project may involve both issues.
What if the requirements were unclear?
Many specification disputes arise because the parties thought they had agreed the same thing when they had not.
A supplier with responsibility for requirements gathering or solution design may be expected to understand the customer’s processes and translate them into a workable technical solution. If it overlooks information, produces a design inconsistent with an agreed requirement or ignores an ambiguity that a competent supplier in its position would have raised, that may support a claim, depending on the contract and the supplier’s role. There is no general legal duty on a supplier to resolve every ambiguity, so the contractual allocation of responsibility for requirements will matter.
Conversely, the customer may have contractual responsibilities to provide accurate information, make staff available, supply data or make timely decisions. A supplier may argue that the system could not be delivered as expected because the customer failed to meet those dependencies.
Where both parties knew that an important requirement remained unresolved but allowed development to continue, responsibility may be more difficult to determine. There is also a legal risk that a requirement the parties expressly left to be agreed later is too uncertain to be enforced as a binding obligation, although the courts are reluctant to reach that conclusion where the parties have gone on to perform the contract. Meeting notes, design decisions, emails and project records can then become particularly important.
What if the supplier said the software could do something before the contract was signed?
Pre-contract statements can become important where a key capability does not appear clearly in the final specification.
For example, a supplier may have stated during a tender, demonstration or sales process that its system could support a particular workflow or integrate with an existing platform.
Whether the business can rely legally on that statement will depend on its wording, importance and timing, whether it was incorporated into the contract and whether the customer relied on it when contracting.
A statement may have become an express contractual term, but this is less likely where it was made outside the signed documents and the contract contains an entire-agreement clause, because such a clause will usually prevent a pre-contract statement from taking effect as a collateral warranty or separate term. Alternatively, an untrue statement of fact or law that induced the customer to enter the contract may potentially give rise to a misrepresentation claim, subject to the contractual wording and available remedies.
Software and technology agreements commonly contain entire-agreement, non-reliance or exclusion clauses. These require careful analysis. An entire-agreement clause alone does not necessarily dispose of a misrepresentation claim, because clear wording is needed to exclude one. Express non-reliance wording is more likely to succeed, but non-reliance clauses, and other provisions excluding or restricting liability or remedies for pre-contract misrepresentation, are subject to statutory controls, including the reasonableness test under section 3 of the Misrepresentation Act 1967.
Businesses should therefore preserve proposals, tender responses, demonstrations and important pre-contract correspondence rather than reviewing only the signed agreement.
Is the missing functionality a defect or a change request?
This is frequently the central commercial dispute.
The customer may say, “This was always part of the project.” The supplier may say, “That is additional scope.”
The answer usually falls into one of three categories.
- A genuine change. If the customer has introduced a new process, changed its requirements or requested functionality that was never part of the original scope, the supplier may be entitled to charge for the additional work under the agreed change-control process. Many contracts require changes to be agreed in writing, and English courts will generally enforce such a clause, so informal agreement to extra scope or extra charges, whether by email or in a meeting, may not bind either party unless the contractual procedure is followed (although a party can sometimes be prevented by its own conduct from relying on the clause).
- Correction of defective work. If additional development is required because the supplier’s design or deliverable fails to meet an existing contractual requirement, calling the work a “change request” does not necessarily make the customer responsible for the cost. The contract’s defect-remedy provisions, assumptions, acceptance regime and responsibility matrix will still need to be considered.
- Clarification of an existing requirement. Sometimes the commercial requirement was always present, but the technical detail was not. Responsibility may then turn on which party was contractually responsible for translating that business requirement into a detailed solution.
A customer should therefore be cautious about signing a revised statement of work or agreeing additional charges before establishing whether the disputed work genuinely falls outside the original scope.
Does approving the design mean the customer accepted responsibility?
Not automatically.
Suppliers may argue that the customer approved a design document, specification or user story and should therefore bear responsibility for the outcome.
Approval is relevant evidence, but its effect depends on the contract.
A business customer with its own technical expertise, or an express responsibility for solution design, may have assumed greater responsibility than a customer contractually relying on the supplier’s specialist knowledge.
The agreement may also state that customer approval does not relieve the supplier from complying with its other obligations.
Whether a customer “signed off” a document therefore needs considering in context.
What remedies are available?
The appropriate response will depend on the seriousness of the problem and the commercial objective.
Possible outcomes can include requiring remedial work, agreeing a revised implementation plan, challenging, setting off or withholding disputed charges where contractually or otherwise legally available, recovering losses, renegotiating the project or ending the relationship.
Damages are not automatically equal to everything the customer has spent or lost. A claim may involve questions of causation, remoteness, mitigation and contractual limitations, including exclusions of particular categories of loss and liability caps.
Termination also requires particular care. Whether it is available may depend on the seriousness of the breach, express contractual rights and compliance with notice and cure procedures. Ending the contract without a valid right to do so can itself amount to a repudiatory breach by the customer, exposing it to a claim from the supplier.
Early legal advice can therefore be valuable before the business withholds payment, accepts a disputed deliverable, signs a change request or purports to terminate the contract.
Can software specification disputes be resolved without going to court?
Often, yes.
A specification dispute may arise from a genuine disagreement about the boundary between the original scope and new functionality. Litigation is therefore not always the most commercially useful first step.
A negotiated outcome might involve correcting agreed defects, revising the specification, sharing some development costs, adjusting charges, extending delivery dates or agreeing an orderly transition to another supplier.
Mediation may also assist where direct negotiations have stalled.
Even if proceedings ultimately become necessary, identifying the disputed requirements precisely can narrow the issues and improve the parties’ ability to assess the commercial value of the claim.
How can the Jonathan Lea Network help with software specification disputes?
Software specification disputes are rarely resolved simply by demonstrating that the finished system is disappointing. The key is to connect the technical problem to the contractual obligation, the evidence and the available remedies.
At The Jonathan Lea Network, our Technology, SaaS & IP Disputes team advises businesses on disputes involving software specifications, failed implementations, scope and change-control disagreements, acceptance testing, additional charges, termination and related contractual claims.
We can review the contractual and project documents, identify the parties’ respective obligations, assess potential claims and defences, prepare correspondence and assist with negotiations or mediation. Where a dispute cannot be resolved commercially, we can also advise on formal proceedings.
Obtaining advice at an early stage does not necessarily mean escalating matters. It can help your business protect its contractual position and decide whether the best outcome is to require the supplier to remedy the project, renegotiate the arrangement or plan an orderly exit.
If your business has received software that does not meet its agreed requirements, or you are facing a dispute about whether work falls within the original specification, contact our team to discuss the contract, project history and practical options available.
Frequently asked questions: software specification disputes
It depends on what the contract required the supplier to provide. Software can disappoint a customer without breaching the contract. The supplier may be responsible, the customer may have contributed to the problem, or both may share responsibility. The answer usually turns on the agreed scope, the contract documents and how the requirements changed. Testing and acceptance matter too. Start by identifying exactly what the supplier promised to deliver. There may not be a single document called “the specification”. The requirements may be spread across a master services agreement, a statement of work and a functional specification. A technical design, the supplier’s proposal, user stories, acceptance criteria and agreed change requests can count too. A business expectation does not automatically become a contractual obligation. Check which documents form the contract and which one takes priority if they conflict. Usually, yes, by express agreement. Where a business supplies services, the law generally implies a term that it will use reasonable care and skill. In a business contract, the parties can usually vary or exclude that term. However, any exclusion or limit on liability must pass the reasonableness test in the Unfair Contract Terms Act 1977. So read the exclusion and limitation clauses carefully alongside the implied term. It depends on who was responsible for the requirements. The law may expect a supplier responsible for requirements gathering or design to understand your processes. It may face a claim if it overlooked information or ignored an ambiguity that a competent supplier would have raised. However, there is no general duty on a supplier to resolve every ambiguity. The customer may also have had to provide information, data or timely decisions. Keep meeting notes, emails and project records. Not necessarily. An entire agreement clause usually stops a pre-contract statement from becoming a separate term. However, a clause needs clear wording to exclude a misrepresentation claim. Express non-reliance wording is more likely to succeed. Even then, clauses limiting this liability must pass a reasonableness test. This comes from section 3 of the Misrepresentation Act 1967. Keep proposals, tender responses, demonstrations and important pre-contract emails, not just the signed agreement. The answer usually falls into one of three categories. A genuine change is new functionality that was never in the original scope, so the supplier may charge for it. A defect is extra work needed because the supplier’s work fails an existing requirement. Calling it a change request does not make you pay. The third category is clarifying an existing requirement. Responsibility then depends on who had to turn it into detailed design. Be cautious. Do not sign a revised statement of work or agree extra charges yet. First check whether the work genuinely falls outside the original scope. Many contracts say the parties must agree changes in writing, and courts will generally enforce that. So informal agreement by email or in a meeting may not bind either party. Get early legal advice before signing a change request or agreeing to pay more. Not automatically. Approval is relevant evidence, but its effect depends on the contract. A customer with its own technical expertise, or an express duty for solution design, may have taken on more responsibility. A customer relying on the supplier’s specialist knowledge may not have. The contract may also say that approval does not relieve the supplier of its other obligations. So consider any sign-off in context before accepting responsibility. Possibly, but take care. Your right to terminate may depend on how serious the breach is. Your express rights and the notice and cure procedures matter too. Ending the contract without a valid right can itself be a repudiatory breach by you. That could expose your business to a claim from the supplier. Get early legal advice before you withhold payment, accept a disputed deliverable or try to terminate. Often, yes. Many disputes come from a genuine disagreement about where the original scope ends. A negotiated outcome might involve fixing agreed defects or revising the specification. It could also mean sharing some costs or adjusting charges. Extending delivery dates or an orderly move to another supplier are other options. Mediation may help if direct talks stall. Identify the disputed requirements precisely, as this narrows the issues.
Contact us
We provide most enquiries with an indicative scope of work and fee estimate, based on the information you share. We aim to respond within one working day.
In the same email you will be invited to arrange a 20-minute complimentary, no-obligation video consultation, should the proposed scope of work and fee estimate be of interest. This initial discussion is designed to better understand your requirements, refine the scope and ensure our approach is fully aligned with your objectives, at the end of which we will email you a definitive formal fee estimate to consider and approve.
Where you would prefer to receive initial advice and guidance from the outset, or where a short introductory call would not be the most appropriate starting point, we may instead recommend a 2.5-hour fixed-fee appointment, starting from £700 + VAT. This enables us to review the information you provide, discuss your situation with you and provide considered, tailored advice at an early stage.
To make an enquiry, please email us at wewillhelp@jonathanlea.net, complete our contact form, or call us on 01444 708640.
VAT is charged at 20%.
This article is intended for general information only, applies to the law at the time of publication, is not specific to the facts of your case and is not intended to be a replacement for legal advice. It is recommended that specific professional advice is sought before relying on any of the information given. © Jonathan Lea Limited.