Best Software Project Failed or Unpaid? IT Contract Arbitration Lawyer

Software and IT projects fail more often than other contracts, and when they do, the dispute is usually about what was promised. The client says the vendor never delivered a working system; the vendor says the client kept changing requirements, delayed sign-offs and refused to pay for work done. Subscription and licence disputes add questions about usage limits, renewals and data. Because most IT contracts contain arbitration clauses, and because these disputes need technical understanding, arbitration is often the right forum.

This page is for businesses that commission software and for IT vendors, developers and SaaS providers. In short: the scope of work, the acceptance clause and the change control process decide most disputes; the project's own records, such as trackers, emails, test reports and sign-offs, are the best evidence; limitation of liability clauses often cap what can be recovered; and urgent orders can secure source code, data or system access while the dispute is decided.

Keep the project records intact. In IT disputes, the side that can show what happened, step by step, usually wins.

Is this your situation?

Common IT disputes

Scope, acceptance and change control

The scope of work, usually in a statement of work or functional specification, defines what the vendor must deliver. The acceptance clause defines how the client decides whether it has been delivered: user acceptance testing against agreed criteria, within a set period, with a procedure for reporting defects. Many contracts provide for deemed acceptance if the client does not reject within the period, or if it uses the software in production.

Change control clauses require changes to scope to be documented in change requests, priced and approved before work starts. In practice, projects often run on informal requests by email or in meetings, without formal change orders. When the dispute comes, the vendor claims payment for extra work, and the client says it was within scope. Tribunals look at the original specification, the communications, and whether the client asked for and received the extra work. Even without a formal change order, a claim may succeed where the client clearly requested and used the work, under Section 70 of the Contract Act or as a variation agreed by conduct.

How we handle IT disputes

Time and typical cost range

Our fees are agreed in writing at the start, stage by stage, and are not linked to the outcome.

Documents needed

Typical clauses and their effect

Limitation of liability clauses

Almost every IT contract limits the vendor's liability, often to the fees paid in the 12 months before the claim, and excludes indirect or consequential losses such as lost profits, lost data or business interruption. A client whose project failed may find that its recoverable damages are capped at a fraction of its actual loss.

Indian courts generally enforce such clauses between commercial parties, as an allocation of risk agreed with open eyes. But a cap may not apply to all claims: many clauses exclude fraud, wilful misconduct, breach of confidentiality, data protection breaches or IP infringement from the cap. A claim for refund of fees paid for work never delivered may also be treated differently from a claim for damages. Read the clause closely and frame the claims with it in mind.

Source code, data and system access

When an IT relationship breaks down, the vendor often controls things the client needs to keep running: the source code, the hosting environment, administrator credentials, and the client's data. A vendor that is not being paid may stop support, withhold code, or suspend access. A client that terminates may need the code and data to move to a new vendor.

A Section 9 application can seek orders to preserve the source code and data, to hand over code that the contract says belongs to the client, to restore system access pending the arbitration, or to provide transition assistance, usually on terms such as payment of undisputed amounts into court. Courts recognise that a business's operations may depend on these systems, and act quickly where the contract supports the client's right. Where there is an escrow agreement, check the release conditions.

Laws that apply

How we work

We are a litigation and advisory practice led by Advocate BK Singh, with offices in Dwarka (New Delhi) and Vaishali (Ghaziabad). This is what you can expect:

• Record-led cases: trackers, logs and repositories used as evidence.
• Technical understanding: working with independent IT experts.
• Clause analysis: acceptance, change control and liability caps read closely.
• Business continuity: urgent orders for code, data and access.
• Written fee terms: agreed stage by stage, never linked to the outcome.

Mistakes in IT disputes

Electronic evidence in IT disputes

In IT disputes, almost all the evidence is electronic: emails, chat messages, ticketing system entries, code commits, deployment logs and test reports. Arbitral tribunals are not bound by the strict rules of the Evidence Act, under Section 19 of the Arbitration Act, but they expect electronic evidence to be reliable. A certificate under Section 63 of the Bharatiya Sakshya Adhiniyam, 2023 (the successor to Section 65B of the Evidence Act) is not strictly required in arbitration, but providing one, or a statement from the person who extracted the records, makes the evidence harder to dispute.

Export records in their native form where possible, with metadata such as dates and authors intact, and keep a copy that is not altered. For repositories, an export of the commit history shows who did what and when, which can be decisive on questions of delay and effort.

Agile projects and fixed-price contracts

Many IT contracts are written as fixed-price, fixed-scope contracts, but the project is run in an agile way, with requirements evolving sprint by sprint. When the project overruns, the vendor argues that the evolving requirements were changes, and the client argues that agile development was always meant to reach the agreed outcome for the agreed price.

Tribunals look at what the parties agreed and how they behaved. If the contract fixed the scope and price but the client repeatedly added features, the vendor has a case for extra payment. If the contract was outcome-based, describing the system's functions rather than specific features, the vendor may have to absorb more of the overrun. Sprint backlogs, product owner approvals and sprint review notes are often the key evidence.

SaaS agreements and service levels

Subscription agreements for software as a service usually promise availability, such as 99.5% uptime each month, with service credits if the target is missed. The service credit is often stated to be the client's sole remedy for downtime, which can limit damages. Disputes arise over how downtime is measured, what counts as scheduled maintenance, and whether repeated failures justify termination.

A client facing repeated outages should record each incident, the vendor's response, and the business impact, and claim credits in writing as the agreement requires. If the failures amount to a material breach, the client may be able to terminate and claim refund of prepaid fees despite the sole remedy clause, depending on its wording.

Licence audits and true-up claims

Enterprise software licences often allow the vendor to audit the client's use and charge for usage beyond the licensed number of users, cores or instances. Audit claims can be large, and are sometimes made at renewal to put pressure on the client. The client should check the audit clause: notice period, who conducts the audit, confidentiality, and how excess use is priced.

Challenge the methodology: how users or cores were counted, whether indirect access was counted correctly, and whether the licence terms actually cover the use claimed. Many audit claims are settled at a fraction of the initial demand, often as part of a renewal.

Data protection and confidentiality

The Digital Personal Data Protection Act, 2023 imposes obligations on data fiduciaries and their data processors, which in IT relationships are often the client and the vendor respectively. As its rules come into force, IT contracts increasingly contain data processing terms, breach notification obligations, and indemnities. A vendor's breach of these terms, or a data breach caused by its negligence, can lead to claims outside the usual liability cap.

In a dispute, the return and deletion of personal data on termination should be dealt with expressly. A tribunal can order the vendor to return the client's data in a usable format and certify deletion of copies, and a Section 9 application can seek this urgently.

Employee poaching and non-solicitation

IT contracts often include non-solicitation clauses that prevent the client from hiring the vendor's staff, or vice versa, during the contract and for a period after. When key developers move to the client, the vendor may claim damages or a fee stated in the contract. Under Section 27 of the Contract Act, restraints on trade after the contract ends are generally void, but courts have distinguished non-solicitation clauses between businesses from restraints on employees, and enforced some of them as reasonable. The outcome depends on the clause and the facts.

Termination and transition

When an IT contract ends, whether by expiry, termination for breach or termination for convenience, the client usually needs an orderly transition: handover of code, documentation, credentials and data, knowledge transfer to the new vendor, and sometimes continued support for a short period. Many contracts contain an exit management clause setting out these obligations and the fees for them.

If the contract has no exit clause, or the vendor refuses to cooperate, a Section 9 application can seek orders for handover and transition support, usually on condition that undisputed fees are paid. Clients should plan transition before terminating, so that the business is not left without a working system while the dispute runs.

Choosing the arbitrator in technical disputes

In software disputes, the tribunal's understanding of technology can shape the result. Parties sometimes agree on a three-member tribunal with one member who has an IT background, or on a sole arbitrator experienced in technology contracts. Where the tribunal is legally trained, a tribunal-appointed expert under Section 26 or party-appointed experts can explain the technical issues. Agree early on how technical evidence will be presented, such as a joint expert meeting to narrow the issues, which saves hearing time.