Terminating a Software Project Midway: How to Settle the Bill

Three months in, both sides realise the project is not going to work. Maybe the requirements never converged, maybe the vendor lost key people, maybe the client's business direction changed. In a software project termination, what freezes first is rarely the technology — it is the money. Half the fee is paid, half the system exists, and nobody knows how to settle up.

Settling a software project termination is something most companies never consider at signing, yet it happens routinely. We address it in every contract with a dedicated termination clause — not to prepare for a fight, but because clear rules in advance make both sides less suspicious during delivery. Below is how the settlement logic works, where disputes actually occur, and what the contract should say.

Four termination scenarios, four different settlements

One premise gets confused constantly: the nature of the termination determines the settlement mathematics. These four scenarios cannot share a single rule.

Scenario one: the client terminates. Business direction shifts, budget is cut, priorities change. The vendor's committed labour needs compensation, usually settled as completed work plus costs already incurred that cannot be recovered, possibly plus a contractual cancellation fee.

Scenario two: the vendor terminates. Serious delay, quality failure, loss of core staff. The client generally has grounds to recover part of what was paid and claim damages, per the breach clause.

Scenario three: mutual agreement. The most common and calmest route. Settle on completed work, stop the remainder, sign a termination agreement and close out.

Scenario four: force majeure or third-party causes. Policy shifts, an upstream licence not granted, hardware supply interrupted. These usually allocate incurred costs on a fair basis, per whatever force majeure clause exists.

The root of most disputes is that each side assumes a different scenario: the client thinks "you did not finish, refund everything", the vendor thinks "you pulled the plug, pay for what was built". That divergence was removable at signing. The method is simply stating the settlement rule for each of the four scenarios.

Settling by progress: the most common and most argued method

Settling by percentage complete sounds fairest and generates the most conflict, because "60% done" has no objective definition.

Take a concrete case. A custom project contracted at 400,000 CNY net, with 30% prepaid — 120,000 CNY — and a milestone payment at mid-project. It terminates halfway, and the two sides disagree sharply on completion.

• By feature count: 12 of 20 modules coded equals 60%, so 400,000 × 60% = 240,000 is payable; with 120,000 already paid, a further 120,000 is owed.
• By labour input: 120 person-days consumed at 1,300 CNY per day is roughly 156,000 CNY of cost, which is what the vendor thinks should be settled.
• By deliverable value: the 12 modules exist in code but interfaces are not integrated and testing has not run, so the runnable portion may be worth only 30% — 120,000 CNY, exactly matching what was paid, and the sides are square.

One event, three methods, three answers of 120,000, 156,000 and 240,000 — a spread of double. This is why a termination clause cannot simply say "settle according to progress completed". It must state the yardstick by which progress is measured.

We recommend a verifiable-deliverable yardstick: divide the project into milestones, each tied to a runnable, demonstrable output and a payment. On termination, only accepted milestones count; unfinished ones are discounted at rework cost. The benefit is that both sides reconcile throughout delivery instead of discovering the disagreement at termination.

The vendor's view: why input does not equal progress

Understanding the vendor's cost structure keeps the negotiation rational. Software investment is uneven: discovery and architecture concentrate labour with invisible output; development produces visible output but is not the whole; testing and integration consume heavily while the interface barely changes.

When a project stops halfway, the vendor typically holds three categories of unrecoverable cost:

• Labour already spent whose output cannot be delivered separately — architecture design, database design, technology validation;
• Third-party resources already purchased — an annual cloud server fee, an SMS package, a certificate already applied for;
• Capacity held in reserve for this project and left idle by the termination, typically two to four weeks.

Without corresponding clauses, these can only be negotiated after the fact. A sensible approach sets a termination compensation cap in the contract — say, no more than 10% of the contract value — and defines how unrecoverable cost is evidenced: by invoice, by cloud billing statement, by staffing schedule.

The client's view: how not to pay and still get nothing

The worst outcome of termination is not overpaying. It is paying and receiving no code, leaving the project impossible for anyone else to inherit. To prevent that, three things belong in the contract.

Continuous source ownership. Require a repository snapshot at each milestone acceptance, and unconditional handover of the latest code and documentation on termination. Even if the project dies, the company retains an asset it can continue developing.

Milestones tied to payment. Payment nodes should attach to verifiable outputs, not to calendar time. Monthly billing contracts are the weakest position at termination, because money has flowed on schedule while output may not have.

A handover obligation after termination. Specify within how many working days the vendor must transfer code, documentation, accounts, and environments, and link that obligation to the final payment or termination compensation.

Eight items a termination agreement must contain

When terminating by agreement, sign a standalone termination agreement rather than leaving it as a sentence in a chat thread. Eight items, none optional:

• Effective termination date and the treatment of the original contract — rescinded, partly rescinded, or surviving to a specified milestone;
• The agreed basis for measuring completed work and the corresponding amount, with acceptance records attached;
• Amounts paid, outstanding, and refundable, with payment timing;
• An itemised list of unrecoverable costs, each with supporting evidence;
• A handover inventory and schedule for source code, documentation, database, account credentials;
• Confirmation of IP ownership, stating that copyright in delivered portions belongs to the client;
• Survival of confidentiality obligations, unaffected by termination;
• Dispute resolution, plus an acknowledgement that this agreement is the final settlement with no outstanding matters.

Items five and six are the ones most often skipped and most critical. Many termination agreements discuss only money and never assets — so the client pays the settlement and still holds no runnable system. The project sinks entirely.

When to terminate, and when to continue

Not every stalled project should be killed. We apply three tests.

Is the problem fixable? If the divergence comes from requirement misunderstanding, communication rhythm, or temporary staffing, all of it can be addressed with tighter requirement confirmation, a different project manager, or added capacity. Terminating usually costs more than repairing.

Can the vendor still deliver? If the core team has dispersed, no one knows the stack, and two consecutive milestones failed, further spending is likely to be additional loss.

Can a third party inherit the work? With documentation, commit history, and a clean architecture, switching is affordable. With unreadable code and no documentation, someone pays a rebuild cost regardless of the decision — at which point "terminate and rebuild" and "continue" must be compared side by side.

Terminating mid-project is not failure; it is stopping a wrong investment in time. What actually destroys value is continuing to pay monthly for something already known to be undeliverable. So the most important part of a software project termination is not negotiation technique — it is writing the exit into the contract at the start. Get that clause right and every conversation during the project becomes more candid, because both sides know the exit has rules.