A contract dispute in the context of a web application, CRM build, portal development or legacy-modernisation project is not simply a disagreement about taste. It is a situation where the parties genuinely differ on what was agreed, what has been delivered, what is owed, or who holds which rights. The distinction matters because it changes how you should respond: a conversation can resolve a misunderstanding, but a dispute may require formal steps defined in the contract itself.
Decision summary: Preserve the contract record, follow notice and escalation procedures, protect service continuity and obtain advice before prejudicing rights.
Most software development contracts include a dispute resolution clause. This clause typically sets out a sequence: informal negotiation first, then formal mediation or another form of alternative dispute resolution, and finally litigation or arbitration as a last resort. The clause will also state the governing law and jurisdiction — for UK businesses, this is usually English law and the courts of England and Wales, but you should not assume that without checking the actual document.
Common sources of disputes in business-system projects include disagreements over whether acceptance criteria have been met, what constitutes a change to scope, whether the delivered system is fit for its stated purpose, who owns the source code and intellectual property, and what happens to data and access if the relationship breaks down. Each of these has a different character: a scope dispute is often about documentation and communication, whereas an IP or data-access dispute can become urgent quickly because it affects your ability to continue operating.
The immediate priority when a dispute arises is not to win the argument but to protect your position. That means preserving evidence, understanding what the contract actually says rather than what you remember agreeing, and avoiding actions that could weaken your legal standing — such as continuing to make payments under protest without clearly recording your objection, or publicly disparaging the other party.
| Contract area | Risk if unclear | What to record |
|---|---|---|
| Preserve the record before anything else | Before you send a strongly worded email or make a phone call, secure the evidence. | Record the requirement and remedy in the contract and relevant schedule. |
| Read the contract with fresh eyes | Re-read the entire contract, not just the section you think is relevant. | Put the agreed position, evidence and remedy in the signed documents. |
| Assess the dispute internally before escalating | Before you involve the other party formally, work out exactly what you are disputing and what outcome you actually need. | Put the agreed position, evidence and remedy in the signed documents. |
| Engage the other party in writing | When you are ready to raise the issue formally, do so in writing and in a way that complies with any notice provisions in the contract. | Record the requirement and remedy in the contract and relevant schedule. |
How to use this guidance safely
For “What to Do When a Contract Dispute Arises”, this is commercial guidance, not a substitute for advice on a particular contract. Definitions, schedules, governing law and the interaction between clauses can materially change the outcome. Record the operational requirement first, then have the wording reviewed for the actual transaction.
Preserve the record before anything else
Before you send a strongly worded email or make a phone call, secure the evidence. Export or copy all relevant communications: emails, messages on project-management platforms, meeting notes, change-request logs, and any recorded calls. Take screenshots of the system in its current state, including error logs or incomplete features, with visible timestamps. If you have access to version-control history, export what you can. This is not about preparing for court at this stage; it is about ensuring that the factual record cannot be altered or deleted once the other party knows a dispute exists.
Read the contract with fresh eyes
Re-read the entire contract, not just the section you think is relevant. Dispute resolution clauses, limitation-of-liability provisions, termination rights, and intellectual-property clauses interact in ways that are not always obvious. For example, the contract may limit your ability to claim for indirect losses even if you can prove the supplier was at fault. It may require you to give written notice of a dispute within a specific period — if you miss that window, you may lose certain rights. Check what constitutes "notice" and where it should be sent; an email to your project manager may not count if the contract specifies a registered address.
Assess the dispute internally before escalating
Before you involve the other party formally, work out exactly what you are disputing and what outcome you actually need. Write this down in one paragraph. Common outcomes in software disputes include: a corrected delivery at the supplier's cost, a partial refund, transfer of source code and access credentials, or simply a clean termination with your data returned. Being clear about your required outcome prevents the dispute from expanding into unrelated grievances and helps any adviser give you focused guidance.
Also assess your own exposure. If you have not paid an invoice, the supplier may have a right to suspend work or even terminate. If you have already accepted the work in writing — for example, by signing off a phase or making a final payment — your ability to argue that it was defective may be constrained. These are uncomfortable questions, but answering them honestly now is far cheaper than discovering the answers during formal proceedings.
Engage the other party in writing
When you are ready to raise the issue formally, do so in writing and in a way that complies with any notice provisions in the contract. State the facts as you understand them, reference the specific contract clauses you believe are relevant, and set out what you are asking for. Avoid emotive language and personal criticism. The letter should read as if it might one day be shown to a mediator or judge, because it might be.
Give the other party a reasonable deadline to respond. What counts as reasonable depends on the complexity of the issue, but two to four weeks is typical for an initial substantive response in a commercial dispute. If the contract specifies a response period, use that instead.
When to involve legal counsel
You do not need a solicitor for every contract disagreement. Many disputes are resolved through direct conversation once both parties understand the other's position. However, you should seek legal advice early if the financial exposure is material, if the dispute involves intellectual-property ownership or data access that could affect your business operations, if the other party has engaged solicitors, or if the contract contains an arbitration clause that requires specific procedural steps within fixed timeframes.
A solicitor can also help you understand whether the contract terms are enforceable as written. Some clauses in software contracts — particularly very broad limitation-of-liability provisions or attempts to exclude liability for data loss — may be subject to challenge under UK law. This is a specialist area and you should not rely on general business advice in place of proper legal counsel.
Typical dispute scenarios in business-system projects
Acceptance and quality disputes. The supplier says the system meets the acceptance criteria; you say it does not. The contract's acceptance-testing provisions and any signed-off test results become central. If acceptance was based on subjective criteria or informal sign-off, the dispute is harder to resolve. This is why clear, testable acceptance criteria matter at the specification stage.
Scope and change-control disputes. You asked for something the supplier considers outside the original scope; the supplier considers it a chargeable variation. The question turns on what the specification or statement of work actually covers, whether there is a written change-control process, and how previous requests were handled. If you have been accepting changes without formal variation orders, the supplier may argue you have established a pattern of informal scope changes.
Payment disputes. You are withholding payment because you believe the work is incomplete or defective; the supplier says payment is due regardless. The contract's payment milestones, any links between payment and acceptance, and any right to withhold payment on reasonable grounds will determine the position. Withholding payment without a contractual basis can itself be a breach.
Ownership and access disputes. The supplier will not release source code, credentials, or data. This often intersects with termination and exit rights, which are covered separately in detail. In a dispute context, the immediate question is whether the contract grants you those rights unconditionally, on payment of outstanding fees, or only in specific circumstances such as a material breach.
Common mistakes
- Continuing to act as if nothing is wrong. If you keep using the system, requesting new features, or making payments without clearly reserving your rights, you may be seen as having accepted the situation. Any communication should state, in writing, that you are reserving all your rights under the contract.
- Public criticism. Posting about the dispute on social media or industry forums can expose you to a defamation claim and makes settlement harder. It also signals to the other party that you are acting emotionally rather than strategically.
- Refusing to engage at all. Ignoring the other party's communications or refusing to mediate can be used against you if the dispute progresses. Most contracts require parties to attempt good-faith resolution before escalating.
- Assuming the contract says what you think it says. Many business owners sign contracts without reading the small print, then discover that key protections they expected — such as source-code escrow, warranty periods, or specific service levels — are absent or worded differently from what was discussed verbally.
- Delaying action. Some contractual rights are time-barred. In England and Wales, the ordinary limitation period for a simple contract claim is commonly six years, but different rules can apply to deeds, particular claims and other UK jurisdictions. Contractual notification periods may also be much shorter. If the contract requires you to notify a defect within 30 days and you wait six months, you may lose the right to claim for that defect even if it is genuine.
Limitations
Contract disputes have practical limits that are worth understanding early. Even if you are clearly in the right, litigation is expensive, slow, and uncertain. An arbitration clause may be faster but can still cost tens of thousands of pounds in fees. The limitation-of-liability cap in the contract may mean that your maximum recovery is far lower than your actual loss — for example, capped at the total fees paid under the contract, which may be a fraction of the business disruption caused by a failed system.
Mediation is often the most pragmatic path, but it requires both parties to participate in good faith. If the other party is insolvent, no amount of legal rights will recover your money or your data. Checking the supplier's financial position early — through Companies House filings, credit reports, or simply observing whether they are still paying their own staff — can inform how hard you push and whether you should prioritise securing your data and code over pursuing a financial claim.
Key checks to perform on the contract
- Dispute resolution clause: What sequence of steps is required? Is mediation mandatory before litigation? Is arbitration specified instead of court proceedings?
- Governing law and jurisdiction: Which law applies, and which courts or arbitration body has authority?
- Notice provisions: How must notice be given, to whom, and at what address? Are there time limits for raising specific types of claim?
- Limitation of liability: What is the cap? Does it exclude consequential or indirect losses? Is there a minimum level of liability that cannot be excluded?
- Acceptance provisions: What constitutes acceptance? Is there an automatic-deemed-acceptance clause if you do not respond within a set period?
- Termination rights: On what grounds can you terminate, and what are the consequences? (Detailed treatment of this is covered in the neighbouring article on termination clauses.)
- Intellectual property and data: Do you have a clear right to your data and, where agreed, the source code on termination or dispute?
- Entire agreement clause: Does the contract state that it supersedes all prior discussions? If so, verbal promises made during sales conversations may not be enforceable.
When to seek specialist input
This article provides practical guidance for navigating a contract dispute in a business-software context. It is not legal advice. Disputes involving significant financial exposure, intellectual-property rights, data-protection obligations under UK GDPR, or potential insolvency of the other party require proper legal counsel from a solicitor qualified in English commercial and technology law. For regulatory questions about data protection, the Information Commissioner's Office publishes current guidance on its website. For general guidance on resolving commercial disputes, the UK government's official information on alternative dispute resolution is a useful starting point.
The most effective thing you can do before a dispute arises is to ensure your contracts are clear, your acceptance criteria are testable, your change-control process is followed, and your rights to data, code and access are explicitly documented. Once a dispute is live, the focus shifts to evidence, contract terms, and measured communication — not to winning the argument in the moment.
Contract points to settle before signature
- Identify which signed document controls if schedules, proposals or emails conflict.
- Make the contract, schedules, statement of work and change-control process consistent with one another.
- Distinguish ownership, licence rights, practical access and third-party restrictions.
- Define acceptance evidence, remedies, liability allocation, exit assistance and governing law explicitly.
Primary guidance checked for this edition
Sources for “What to Do When a Contract Dispute Arises” were checked on 22 July 2026. Recheck the applicable rules, product documentation and contractual terms before implementation because these can change after the review date.