A failed IT project does not automatically entitle you to a refund of every invoice. First, it must be established what the supplier was required to deliver, which components fall short and whether an appropriate opportunity to remedy is needed. Preserve technical evidence and protect business continuity before you terminate the agreement or let a new supplier overwrite everything.
Nederlands: Lees dit artikel in het Nederlands: IT-project mislukt: wat kunt u doen tegen uw softwareleverancier?
Türkçe: Bu makaleyi Türkçe okuyun: BT projesi başarısız oldu: yazılım tedarikçinize karşı ne yapabilirsiniz?
Written by Onur Arslan, attorney at Arslan Advocaten. Registered in the specialisation register of the Netherlands Bar for employment law and personal injury. Last updated: 17 September 2026.
For SMEs, a software problem often affects day-to-day operations. Orders pile up, data is entered twice or a new system cannot be put into use. At the same time, the supplier may argue that the specifications were changed, that information was provided too late or that additional work has not been paid for.
A workable approach therefore combines legal and technical analysis. This article deals with business software development, implementation and IT services. For standard software, SaaS, hardware, hosting or personal data, additional contracts and rules may apply.
Start with the agreed performance
Gather the quotation, agreement, functional specifications, project schedule, general terms and conditions and any later amendments. What was the system supposed to do, when was it to be delivered and what contributions were required from your own organisation?
An agreement may contain both best-efforts and result-based obligations. The supplier may, for example, have to deliver a specific integration, while a broader improvement of the business is not a guaranteed result. The label “best-efforts obligation” does not release a supplier from the duty to work with due care.
Also look at order-of-precedence clauses between documents. A brochure may create expectations, but the final contract may contain limitations or different specifications. Conversely, a standard clause is not always the complete answer to expressly negotiated commitments.
Make the problem technically specific
A complaint that “the system does not work” is too general for a proper remediation process. For each problem, record which action you perform, what the expected outcome is, what actually happens and how the problem can be reproduced. Add versions, times and relevant screenshots.
Distinguish between bugs, missing features, performance speed, security issues and new requirements. A feature that was never agreed is not automatically a defect. Equally, an essential agreed feature that is missing may not be dismissed as a paid extension without explanation.
Classify the impact. Does the problem block the entire go-live, is there a temporary workaround or does it affect only a limited component? This classification helps with remediation periods, priorities and any assessment of suspension or termination.
Preserve evidence before you have changes made
Ensure you have a lawful copy of relevant project documents, tickets, test results, communications and configuration data. Where possible, retain versions and log files together with their context. A stand-alone screenshot without a date or system version is less useful.
Do not let a new supplier replace the existing environment without preparation if essential evidence would be lost as a result. First make arrangements about recording, access and investigation. In a substantial dispute, an independent expert can help to describe the state of affairs.
Take personal data, trade secrets and third-party access into account. Do not give an expert more data than necessary and put appropriate arrangements in place. Preserving evidence does not mean you may freely access the other party’s accounts or systems.
Acceptance and going live
Many IT contracts contain an acceptance procedure with testing periods, defect categories and the consequences of going live. Check whether that procedure was actually followed. A formal acceptance notice can be important evidence, but its scope depends on the arrangements made and any reservations.
Putting a system into use does not automatically mean that every defect discovered later has been accepted. At the same time, prolonged use without clear complaints may affect your position. Therefore record why you are using a system temporarily and which defects remain outstanding.
With phased delivery, acceptance of one component may have different consequences from acceptance of the entire project. Draw up an overview per module or milestone. A failed final integration does not automatically mean that all earlier work was worthless, but it can affect the usability of the whole.
Agile working and changing requirements
In agile projects, details are often worked out during sprints. That does not mean there are no agreements. The product backlog, sprint planning, demos, priorities and budget arrangements can together determine what the parties were entitled to expect.
Record who was authorised to approve changes and how the consequences for costs and schedule were discussed. An oral request from an employee is not automatically an unlimited instruction for additional work. Conversely, a series of demonstrably approved changes may affect the original delivery date.
Prepare a comparison between the initial scope and the current status. For each change, note the request, approval, price and effect on the schedule. For a separate pricing dispute, see also additional work not paid.
Your own cooperation may be relevant
An implementation often requires data, access, decision-making and testing from the client. Check which obligations your organisation had and whether they were fulfilled on time. A supplier cannot be held responsible for every delay caused by missing input.
That does not release the supplier from all responsibility. A professional service provider may, for example, be required to warn about unusable data, an unrealistic schedule or insufficient cooperation. The contractual allocation of tasks and the actual communications are decisive.
Draw up a joint timeline showing dependencies. This makes visible which delay is linked to which cause. A file containing only the other party’s mistakes does not provide a reliable basis for a litigation strategy.
Report defects in good time and allow an opportunity to remedy where necessary
The duty to complain may be relevant in the case of defective performance. Report specific problems as soon as you discover them or ought reasonably to have discovered them, taking the circumstances into account. Keep records of the receipt of your reports and the follow-up.
For damages or termination on account of a shortcoming that can still be remedied, default (verzuim) may be required. A notice of default must then make sufficiently clear which performance is required and within what reasonable period. A general email venting frustration is not always sufficient.
A reasonable remediation period depends on the problem, previous attempts and the work required. Two days may be too short for a complex integration; waiting months may be too long in the case of a critical outage. Have the period substantiated both technically and legally.
Example of a targeted remediation letter
Subject: remedying shortcomings in project [name]
Under our agreement of [date] and specification [version], the system must be able to perform [specific function]. During tests on [dates] it was established that [factual deviation]. The steps to reproduce the problem, the results and the relevant files are enclosed.
We request you and, to the extent required, give you formal notice to remedy this shortcoming no later than [reasonable date], so that [measurable acceptance criterion] is met. We will provide the necessary access and cooperation [manner and times]. We would like to receive a specific remediation plan no later than [date].
The other outstanding points are set out in annex [number], with their priority and intended outcome. We reserve our rights to performance and, if the conditions are met, further legal remedies. This letter does not constitute agreement to additional paid work without a separate arrangement.
Check whether your contract prescribes a specific escalation or notification procedure. The letter must fit those arrangements and the actual possibility of remedy. For the general structure, read the business notice of default.
May you temporarily withhold payment of invoices
Suspension may be possible under certain conditions, but its extent must be proportionate to the shortcoming and the agreement. A malfunction in one module does not automatically justify withholding all hosting and maintenance invoices. A fundamentally unusable whole may be assessed differently.
Check whether a prohibition on set-off or suspension has been agreed and whether that clause holds up in the specific relationship. Record the disputed amount and the legal basis in writing. An unjustified payment stop may in fact give the supplier a claim of its own.
Also consider the practical risk that the supplier blocks access. That does not make your rights any less important, but it does call for preparation regarding continuity and data availability. See suspending work or payment for the separate conditions.
When can you terminate
Article 6:265 of the Dutch Civil Code in principle provides a right to terminate in the event of a shortcoming, unless the shortcoming, given its special nature or minor significance, does not justify termination and its consequences. If performance is not permanently or temporarily impossible, default plays an important role.
Assess whether full or partial termination is appropriate. A usable stand-alone module may be treated differently from a project that fails to achieve its purpose as a whole. The financial settlement and the value of work already performed must also be examined.
A letter of termination (ontbinding) is not an ordinary notice of termination. Terminating incorrectly may lead to a counterclaim. Therefore have the legal basis, previous remediation attempts and desired consequences assessed before you definitively declare the agreement terminated.
Will you get back all amounts paid
After termination, obligations to undo performance may arise, but with services and software work, restitution is not always literally possible. The value of the work performed and the applicable statutory rules may then be relevant. The answer is not automatically that every euro paid will come back.
Distinguish between licences, development, implementation, maintenance and hardware. Some components may remain usable or have a stand-alone value. Others may be worthless precisely because the agreed coherence is missing.
Substantiate why you are claiming a particular refund or damages. A total amount without a breakdown makes the discussion more difficult. Make sure tax corrections and any credit notes are consistent with the chosen legal settlement.
Damages and limitations of liability
Possible heads of damage include reasonable remediation costs, replacement services, additional internal costs or loss of profit. Not every item is automatically recoverable. The shortcoming, attribution, causation, foreseeability and mitigation of loss must be assessed.
IT contracts often contain liability caps and exclusions for certain types of damage. Examine applicability, interpretation and enforceability. Without a contractual definition, the term “indirect damage” does not have the same meaning in every contract.
A warranty, indemnity or penalty may further affect the allocation of risk. See also limiting liability in a business contract. Do not present a cap as automatically invalid as soon as the damage turns out to be higher.
Data, source code and switching
The end of the relationship does not automatically give you ownership of all source code. Examine licences, copyrights, arrangements on custom work and any escrow. Access to data and the possibility of exporting it must also be arranged in concrete terms.
Draw up a handover list of data files, documentation, configurations, accounts, domain names and dependencies. Determine which data your business may lawfully take with it and which third-party rights exist. A working export often requires more than a zip file of raw tables.
Record arrangements on temporary support, security and deletion of data. Where personal data is involved, data processing agreements and statutory obligations may continue to apply. A payment dispute is no reason to disregard necessary security or a careful wind-down.
Fictional example of a failed implementation
A wholesaler has a stock and ordering system implemented. The stock integration does not work reliably, while the supplier says that the customer supplied incomplete product data. The customer wants all invoices refunded and is considering having another supplier start immediately.
First, the specifications, test results and data deliveries are secured. A technical investigation distinguishes between faults in the integration and problems in the source data. This is followed by a remediation plan with clear responsibilities and acceptance criteria.
If the remedy does not materialise, it can be assessed which legal remedies are appropriate. Perhaps replacing one component is sufficient; perhaps the problem affects the entire project. The example shows why a legal claim becomes stronger with a concrete technical diagnosis.
Choosing a settlement or proceedings
A settlement may consist of remediation under supervision, a price adjustment, a handover to a new supplier or termination with a financial settlement. Record measurable delivery criteria and the consequences of failure. A new general promise that everything will soon be fine is not enough.
In urgent cases, interim relief may be needed, for example regarding access to data or continuity. A definitive assessment of damages may require an expert investigation. Check the dispute resolution clause: some IT contracts refer to arbitration or a specific body.
Through business law for entrepreneurs you can have your legal position assessed. Bring the technical file and indicate which systems are business-critical. This makes it possible to determine first what must be secured and then which solution is feasible.
Make a technical handover verifiable
When switching, establish in advance what the new supplier needs to start responsibly. This often involves more than the source code: documentation, dependencies, configuration, database descriptions, licences and access to build or hosting environments. Record which components are missing and who must supply them.
Where possible, run a test with a copy in a separate environment. This allows you to check whether an export is complete and usable without immediately changing the production environment. Take security and personal data into account; a full copy is not necessary or permitted in every situation.
Prepare a handover report with the date, files, versions and the outcome of the check. A statement that “everything has been handed over” may be too broad if the new supplier has not yet been able to test access. Use concrete acceptance criteria and identify any remaining issues.
Watch for overlap with insurance and privacy
In the event of an incident, professional liability, cyber or legal expenses insurance may be relevant. Report the matter in accordance with the policy conditions and, where necessary, coordinate any admissions or settlements. An insurance notification does not replace the complaint or notice of default to the supplier.
If personal data has been affected, separate obligations may also exist regarding security, investigation and any notifications. That is a different assessment from the question of who must pay the implementation invoice. Do not let an acute data problem wait for the outcome of the contractual dispute.
Keep a separate overview of technical remediation actions, legal correspondence and any incident measures. This keeps visible which costs arise from which problem and which information has been shared with which party. That structure helps both with the settlement and with any later calculation of damages.
Frequently asked questions
Can I stop immediately if the software does not work?
Not without an assessment. The arrangements, the seriousness of the shortcoming and any remedy and default requirements are important. An unjustified termination may itself give rise to liability. Preserve evidence and protect continuity first.
Does putting the system into use mean I accept all defects?
Not automatically. The contract, the acceptance procedure and any reservations determine its significance. Report outstanding defects clearly and record why you are using the system temporarily. Prolonged use without complaints may affect your position.
Must the supplier always meet a fixed end date?
That depends on the agreement and the circumstances. A firm delivery obligation is different from an indicative schedule. Agreed changes and necessary cooperation from the client may also be relevant.
Will I get all invoices refunded on termination?
That is not a given. Restitution, the value of work performed and the coherence between components must be assessed. Break down development, licences, maintenance and other items for a verifiable settlement.
Do I own the source code I have paid for?
Payment alone does not automatically mean a transfer of copyright or an unlimited right of use. Check the licence, transfer arrangements and any escrow. Rights to third-party software used may also play a role.
Can I have a new supplier change everything straight away?
That may affect evidence and options for remedy. First carefully record the existing state and assess contractual rights and access authorisations. For urgent continuity measures, it must be documented why postponement was not responsible.
Sources and legal basis
- Dutch Civil Code, Book 6: including Articles 74, 81–89, 98, 101, 248 and 265–272.
- Amsterdam Court of Appeal, 16 April 2024, on a software dispute: example of the assessment of contract, acceptance and performance; no general guarantee of outcome.
- Dutch Copyright Act (Auteurswet): rights in software and requirements for transfer.
