Wat als uw softwareproject mislukt? Juridische opties en preventie

Gepubliceerd op 22 september 2026

Een softwareproject dat vastloopt, is voor beide partijen een zware klap. De opdrachtgever investeerde in een systeem dat de bedrijfsvoering moest verbeteren en ziet deadlines verstrijken zonder werkend resultaat. De leverancier ziet vaak een ander beeld: een opdrachtgever die steeds nieuwe wensen inbrengt, besluiten uitstelt of te weinig informatie aanlevert.

Wie draait er dan op voor de schade? Vier punten vooraf:

• Een mislukt softwareproject is niet automatisch een tekortkoming van de leverancier.
• Ook de medewerking van de opdrachtgever kan juridisch van belang zijn.
• Goede projectdocumentatie en contractuele afspraken beperken het procesrisico.
• Een deskundigenonderzoek kan doorslaggevend zijn voor de technische beoordeling.

Hieronder bespreken wij achtereenvolgens de veelvoorkomende oorzaken, de juridische beoordeling, de medewerkingsplicht van de opdrachtgever, het deskundigenonderzoek, de mogelijke uitkomsten van een procedure, wat praktijkvoorbeelden laten zien en welke maatregelen een geschil kunnen voorkomen.

Veelvoorkomende oorzaken

In de praktijk keren enkele oorzaken steeds terug.

• Scope creep, oftewel het geleidelijk uitdijen van de opdracht. De eisen aan het systeem, de requirements, blijven groeien zonder formele wijzigingsprocedure met gevolgen voor planning en budget.
• Onduidelijke of onvolledige functionele specificaties. Is vooraf niet scherp vastgelegd wat het systeem moet doen, dan volgt later discussie over de vraag of het opgeleverde voldoet.
• Gebrekkig systeemontwerp. De architectuur is niet berekend op de werkelijke belasting, de koppelingen met andere systemen of toekomstige uitbreiding.
• Onderschatting van complexiteit en doorlooptijd, vooral bij projecten waarin meerdere bestaande systemen moeten worden gekoppeld.
• Te late of te beperkte medewerking van de opdrachtgever.

Deze oorzaken staan zelden op zichzelf. Vaak versterken zij elkaar. Een project dat aanvankelijk slechts vertraging oploopt, kan daardoor volledig vastlopen.

Juridische beoordeling: tekortkoming en eigen schuld

De eerste juridische vraag is of de leverancier toerekenbaar is tekortgeschoten. Artikel 6:74 BW verplicht de schuldenaar de schade te vergoeden die de schuldeiser lijdt door een tekortkoming in de nakoming, tenzij die tekortkoming hem niet kan worden toegerekend.

Voor een geslaagd beroep daarop moet dus vaststaan dat de leverancier niet heeft geleverd wat was overeengekomen, bijvoorbeeld omdat de software niet aan de vastgelegde functionele specificaties voldoet. En het tekortschieten moet aan hem toe te rekenen zijn, wat betekent dat geen sprake is van overmacht.

In de praktijk zijn de verantwoordelijkheden vaak verdeeld. De opdrachtgever gaf pas laat duidelijkheid over bepaalde eisen, wijzigde tussentijds zijn wensen zonder de gevolgen voor planning en kosten te aanvaarden, of stelde geen bruikbare testomgeving beschikbaar.

In dat geval kan de rechter de vergoedingsplicht van de leverancier verminderen op grond van artikel 6:101 BW, naar de mate waarin omstandigheden die aan de opdrachtgever zijn toe te rekenen aan de schade hebben bijgedragen. Dit leerstuk van eigen schuld kan een schadevergoeding aanzienlijk verminderen, en in uitzonderlijke gevallen volledig doen afwijzen.

Praktisch advies voor beide partijen: documenteer gedurende het project wie welke besluiten neemt, welke wijzigingen worden doorgevoerd en welke informatie op welk moment is aangeleverd. Die vastlegging maakt in een procedure vaak het verschil tussen volledige aansprakelijkheid en een sterk gematigde uitkomst.

De medewerkingsplicht van de opdrachtgever

Een software-implementatie is een gezamenlijke inspanning. De leverancier bouwt en configureert, maar is daarbij voortdurend afhankelijk van de opdrachtgever: tijdige en volledige specificaties, bruikbare testgegevens, snelle besluitvorming over openstaande vragen en tijdige acceptatie van opgeleverde onderdelen.

Blijft die medewerking uit, dan kan de leverancier zijn werk niet doen. Het recht verbindt daaraan gevolgen. Artikel 6:58 BW en volgende regelen het schuldeisersverzuim: dat treedt in wanneer de nakoming door de schuldenaar wordt verhinderd doordat de daarvoor benodigde medewerking van de schuldeiser uitblijft.

Vertaald naar de praktijk: raakt de leverancier vertraagd doordat de opdrachtgever niet tijdig levert wat nodig is, dan komt hij niet in verzuim en is hij voor die vertraging niet aansprakelijk. De opdrachtgever kan dan juist zelf in verzuim raken. Omdat softwareprojecten doorgaans iteratief verlopen, waarbij elke fase voortbouwt op feedback en goedkeuring uit de vorige, wordt uitblijvende input in de rechtspraak regelmatig gebruikt om vertraging mede of geheel aan de opdrachtgever toe te rekenen.

Voor opdrachtgevers is dit een aandachtspunt: kritiek op de voortgang overtuigt weinig wanneer de eigen besluitvorming stroef verloopt. Voor leveranciers geldt het omgekeerde: signaleer vertraging die aan de opdrachtgever te wijten is direct en schriftelijk, bijvoorbeeld met een duidelijke waarschuwing of een ingebrekestelling zodra noodzakelijke input uitblijft. Gebeurt dat niet, dan valt achteraf vaak niet meer te reconstrueren wie welke vertraging veroorzaakte.

Het deskundigenonderzoek

Softwareprojecten zijn technisch van aard. Voldeed de geleverde software aan de specificaties? Lag de vertraging bij de leverancier of bij de opdrachtgever? Was het gefactureerde meerwerk gerechtvaardigd? Vragen over architectuur, broncode, de traceerbaarheid van eisen door het ontwikkelproces heen en de inhoud van testverslagen vergen technische kennis die van een rechter niet kan worden verwacht.

Daarom wordt in dit soort geschillen vaak een gerechtelijk deskundigenbericht gelast, op grond van de artikelen 194 tot en met 207 Rv. Een onafhankelijke deskundige beoordeelt dan of de software aan de afspraken voldeed, waar de vertraging is ontstaan en of de gemaakte kosten redelijk waren. De uitkomst weegt in de praktijk zwaar mee in het oordeel van de rechter.

Een deskundige heeft daarvoor doorgaans de volgende stukken nodig:

• de overeenkomst en de bijlagen daarbij;
• de functionele en technische specificaties;
• de wijzigingsverzoeken;
• de projectplanning en de voortgangsrapportages;
• de testverslagen;
• de correspondentie over vertragingen en acceptatie;
• de broncode en de documentatie.

Ontbreekt een deel hiervan, dan kan de deskundige de vraag vaak niet beantwoorden. Dat werkt door in de bewijspositie van de partij die zich op die feiten beroept. Het loont dus om dit dossier tijdens het project op orde te houden, niet pas wanneer het geschil er is.

Mogelijke uitkomsten van een procedure

Is slechts een deel van de overeenkomst misgelopen, bijvoorbeeld omdat één module niet functioneert terwijl de rest wel bruikbaar is, dan kan de rechter overgaan tot gedeeltelijke ontbinding op grond van artikel 6:265 in samenhang met artikel 6:270 BW. Het geslaagde deel blijft dan in stand.

Daarnaast kan schadevergoeding worden toegewezen op grond van artikel 6:74 BW, die vervolgens kan worden verminderd wegens eigen schuld op grond van artikel 6:101 BW. Ten slotte kan de rechter de schadevergoeding matigen op grond van artikel 6:109 BW, bijvoorbeeld wanneer het gevorderde bedrag in geen verhouding staat tot de oorspronkelijke contractwaarde. Rechters passen dat matigingsrecht terughoudend toe.

In de praktijk eindigt een mislukt softwareproject vaak met een doorstart bij een andere leverancier. Ook dat verloopt zelden zonder discussie. Wie krijgt de broncode? Bij wie liggen de intellectuele-eigendomsrechten op het gebouwde systeem? Is er een escrowregeling, waarbij de broncode is gedeponeerd bij een onafhankelijke derde? Wie daarover bij aanvang niets heeft geregeld, merkt dat juist op dit moment.

Wat praktijkvoorbeelden laten zien

Naast de gewone rechter speelt de Stichting Geschillenoplossing Automatisering (SGOA) een belangrijke rol in de IT-sector. Dit onafhankelijke geschilleninstituut bestaat sinds 1989 en biedt mediation, arbitrage, arbitraal kort geding, bindend advies, deskundigenbericht en conflictpreventie. De arbiters zijn vakgenoten, wat verklaart waarom veel IT-geschillen deze route volgen in plaats van een procedure bij de rechter.

Uit de gepubliceerde uitspraken van de SGOA komen enkele terugkerende lessen naar voren die ook buiten een procedure bruikbaar zijn:

• de verantwoordelijkheid wordt zelden volledig bij één partij gelegd; de verdeling volgt uit wat elk van beide feitelijk heeft gedaan en nagelaten;
• gaandeweg wijzigende specificaties zijn een van de meest voorkomende twistpunten, en het ontbreken van een formele wijzigingsprocedure valt doorgaans uit in het nadeel van de partij die zich op de oorspronkelijke afspraak beroept;
• de kwaliteit van de projectdocumentatie is vaak doorslaggevend, omdat zij bepaalt welke feiten nog kunnen worden vastgesteld.

Voor wie een contract opstelt zijn dat nuttige signalen: het zijn precies de onderwerpen die vooraf beter kunnen worden vastgelegd.

Preventieve maatregelen

Veel geschillen zijn met de juiste contractuele inrichting te voorkomen.

• Werk met gefaseerde contracten. Deel het project op in releases of mijlpalen, de milestones, elk met eigen acceptatiecriteria. Zo wordt niet pas na maanden beoordeeld of het geheel voldoet.
• Spreek formele acceptatietests af voordat wordt gefactureerd. Dan staat vast waaraan een opgeleverd onderdeel moet voldoen voordat betaling verschuldigd is.
• Leg een wijzigingsprocedure vast waarin staat wie een wijziging mag aanvragen, wie beslist en hoe de gevolgen voor planning en prijs worden verwerkt.
• Spreek een escalatieladder af: eerst overleg binnen de projectgroep, dan een stuurgroep op hoger niveau, dan een mediator, en pas daarna een procedure bij de rechter.
• Overweeg geschilbeslechting via de SGOA. Let daarbij op één praktisch punt: arbiters kunnen een zaak alleen behandelen wanneer partijen de stichting vooraf bevoegd hebben verklaard, dus die clausule moet in het contract staan. De SGOA stelt daarvoor modelclausules beschikbaar.

Een escalatieladder zorgt ervoor dat conflicten in een vroeg stadium en op het juiste niveau worden besproken, in plaats van pas wanneer de verhoudingen al zijn verstoord. Voor situaties waarin een project op een cruciaal punt stilvalt en één partij niet meewerkt, biedt het arbitraal kort geding van de SGOA bovendien een snelle voorziening.

Tot slot

Een mislukt softwareproject is zelden het gevolg van één fout. Meestal ontstaat het door een samenspel van onduidelijke specificaties, wijzigende wensen, technische onderschatting en gebrekkige samenwerking. Het Nederlandse recht biedt met wanprestatie, eigen schuld en schuldeisersverzuim een genuanceerd kader om vast te stellen wie de schade draagt, maar de toepassing daarvan vergt kennis van zowel het recht als de techniek.

Loopt uw softwareproject vast? Law & More adviseert opdrachtgevers en leveranciers over aansprakelijkheid, projectdocumentatie, contractuele preventie en geschilbeslechting. Neem contact op voor een beoordeling van uw overeenkomst en uw projectdossier.

Veelgestelde vragen

Hieronder beantwoorden wij de vragen die ons over dit onderwerp het vaakst worden gesteld.

Is mijn leverancier aansprakelijk als het softwareproject mislukt?

Niet automatisch. Vast moet staan dat hij niet heeft geleverd wat was overeengekomen en dat dit hem is toe te rekenen. In de praktijk zijn de verantwoordelijkheden vaak verdeeld over beide partijen.

Wat als ik als opdrachtgever zelf heb bijgedragen aan de vertraging?

Dan kan de rechter de vergoedingsplicht van de leverancier verminderen op grond van artikel 6:101 BW, naar de mate waarin uw eigen handelen aan de schade heeft bijgedragen. Dat kan een schadevergoeding aanzienlijk verlagen en in uitzonderlijke gevallen volledig doen afwijzen.

Wat houdt de medewerkingsplicht in?

U moet als opdrachtgever tijdig specificaties, testgegevens, besluiten en acceptaties aanleveren. Blijft dat uit en kan de leverancier daardoor niet presteren, dan raakt hij niet in verzuim en kunt u zelf in schuldeisersverzuim komen (artikel 6:58 BW en volgende).

Waarom wordt vaak een deskundige benoemd?

Omdat vragen over architectuur, broncode en testverslagen technische kennis vergen die van een rechter niet kan worden verwacht. Op grond van de artikelen 194 tot en met 207 Rv kan een gerechtelijk deskundigenbericht worden gelast, waarvan de uitkomst zwaar meeweegt.

Welke projectdocumenten moet ik bewaren?

De overeenkomst met bijlagen, de functionele en technische specificaties, de wijzigingsverzoeken, de projectplanning en voortgangsrapportages, de testverslagen, de correspondentie over vertraging en acceptatie, en de broncode met documentatie. Ontbreken die stukken, dan kan een deskundige de vraag vaak niet beantwoorden.

Waarom is een wijzigingsprocedure zo belangrijk?

Zonder formele procedure groeit de opdracht ongemerkt, terwijl planning en budget gelijk blijven. Bij een geschil valt dan niet meer vast te stellen wanneer en waarom de scope veranderde. Leg vast wie een wijziging mag aanvragen, wie beslist en hoe de gevolgen voor planning en prijs worden verwerkt.

Wat is het nut van acceptatiecriteria?

Zij bepalen objectief wanneer een opgeleverd onderdeel voldoet. Daarmee is helder wanneer betaling verschuldigd wordt en wordt discussie achteraf over de deugdelijkheid van de oplevering grotendeels voorkomen. Koppel ze bij voorkeur aan releases of mijlpalen met formele acceptatietests.

Wat gebeurt er met de broncode bij een doorstart naar een andere leverancier?

Dat hangt af van uw contract. Zonder afspraken over afgifte van de broncode, over de intellectuele-eigendomsrechten op het gebouwde systeem en over een eventuele escrowregeling, kan een doorstart aanzienlijk vertragen. Regel dit bij het aangaan van de overeenkomst, niet achteraf.

Welke uitkomsten kan een procedure hebben?

Gedeeltelijke ontbinding wanneer slechts een deel is misgelopen (artikel 6:265 in samenhang met 6:270 BW), schadevergoeding op grond van artikel 6:74 BW, vermindering wegens eigen schuld op grond van artikel 6:101 BW, en matiging op grond van artikel 6:109 BW. Rechters passen die matiging terughoudend toe.

Kan ik een geschil buiten de rechter om oplossen?

Ja. De SGOA biedt mediation, arbitrage, arbitraal kort geding, bindend advies en deskundigenberichten met vakgenoten als beslissers. Arbiters kunnen een zaak alleen behandelen wanneer partijen de stichting vooraf bevoegd hebben verklaard, dus neem die clausule in het contract op.

Hoe voorkom ik een langdurig geschil?

Werk met gefaseerde contracten en acceptatiecriteria per release, spreek formele acceptatietests af vóór facturering, leg een wijzigingsprocedure vast en spreek een escalatieladder af van projectgroep naar stuurgroep, mediator en pas daarna een procedure bij de rechter.

Heeft u een geschil met een IT-leverancier of wilt u een IT-contract laten toetsen? Onze advocaten IT-recht denken graag met u mee.