Mislukt softwareproject: wanneer is de leverancier aansprakelijk?

Gepubliceerd op 22 september 2026 · Laatst bijgewerkt op 13 oktober 2026

Mislukt uw softwareproject, dan is de leverancier niet automatisch aansprakelijk. Bepalend is of hij niet leverde wat was afgesproken én of dat aan hem is toe te rekenen; droeg u als opdrachtgever zelf bij aan de vertraging, dan kan de rechter de schadevergoeding verminderen.

Vier punten vooraf:

• Een mislukt softwareproject is niet automatisch een tekortkoming van de leverancier.
• Ook uw eigen medewerking als opdrachtgever telt juridisch mee.
• Goede projectdocumentatie en heldere afspraken beperken het procesrisico.
• Een deskundigenonderzoek is vaak doorslaggevend voor de technische beoordeling.

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

Wat veroorzaakt een mislukt softwareproject meestal?

In de praktijk keren enkele oorzaken steeds terug. Vaak versterken zij elkaar, zodat een project dat aanvankelijk alleen vertraging oploopt, uiteindelijk volledig vastloopt.

• Scope creep: de eisen aan het systeem groeien geleidelijk, zonder formele wijzigingsprocedure. Dat raakt planning en budget.
• Onduidelijke of onvolledige functionele specificaties. Ligt vooraf niet scherp vast wat het systeem moet doen, dan ontstaat later discussie over de oplevering.
• Gebrekkig systeemontwerp. De architectuur is niet berekend op de werkelijke belasting, koppelingen met andere systemen of toekomstige uitbreiding.
• Onderschatting van complexiteit en doorlooptijd, vooral wanneer meerdere bestaande systemen moeten worden gekoppeld.
• Te late of te beperkte medewerking van de opdrachtgever.

Is de leverancier aansprakelijk als het project mislukt?

Niet automatisch. Volgens artikel 6:74 BW moet de leverancier de schade vergoeden die u lijdt door een tekortkoming in de nakoming, tenzij die tekortkoming hem niet is toe te rekenen.

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

In de praktijk zijn de verantwoordelijkheden vaak verdeeld. Gaf u als opdrachtgever pas laat duidelijkheid over bepaalde eisen, wijzigde u tussentijds uw wensen zonder de gevolgen voor planning en kosten te aanvaarden, of stelde u geen bruikbare testomgeving beschikbaar? Dan kan de rechter de vergoedingsplicht van de leverancier verminderen op grond van artikel 6:101 BW, naar de mate waarin dit aan de schade heeft bijgedragen. Dit leerstuk van eigen schuld kan een schadevergoeding aanzienlijk verlagen en in uitzonderlijke gevallen volledig doen afwijzen.

Praktisch advies voor beide partijen: documenteer tijdens 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. Wacht daarmee niet tot het geschil zich aandient; leg dit gaandeweg vast, bijvoorbeeld in projectverslagen en e-mailbevestigingen.

Wat houdt uw medewerkingsplicht als opdrachtgever in?

U moet tijdig specificaties, testgegevens, besluiten en acceptaties aanleveren. Blijft die medewerking uit, dan kan de leverancier zijn werk niet doen.

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

Artikel 6:58 en verder BW regelen het schuldeisersverzuim: dat treedt in wanneer de nakoming door de leverancier wordt verhinderd doordat de daarvoor benodigde medewerking van u als opdrachtgever uitblijft. Raakt de leverancier vertraagd doordat u niet tijdig levert wat nodig is, dan komt hij niet in verzuim en is hij voor die vertraging niet aansprakelijk. U kunt dan 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 aan de opdrachtgever toegerekend. Kritiek op de voortgang overtuigt dan ook weinig wanneer uw eigen besluitvorming stroef verloopt. Voor leveranciers geldt het omgekeerde: signaleer vertraging die aan de opdrachtgever te wijten is direct en schriftelijk, bijvoorbeeld met een ingebrekestelling zodra noodzakelijke input uitblijft. Gebeurt dat niet, dan valt achteraf vaak niet meer te reconstrueren wie welke vertraging veroorzaakte.

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.

Voldeed de geleverde software aan de specificaties? Lag de vertraging bij de leverancier of bij de opdrachtgever? Was het gefactureerde meerwerk gerechtvaardigd? Een onafhankelijke deskundige beoordeelt dit en zijn oordeel weegt in de praktijk zwaar mee bij 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. Houd dit dossier daarom tijdens het project op orde, niet pas wanneer het geschil er al is.

Welke uitkomsten zijn mogelijk in een procedure?

De rechter kan het contract gedeeltelijk ontbinden, schadevergoeding toewijzen, die verminderen wegens eigen schuld, of het bedrag matigen. Vaak volgt daarnaast een doorstart bij een andere leverancier.

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 niet in verhouding staat tot de oorspronkelijke contractwaarde. Rechters passen dat matigingsrecht terughoudend toe.

Een mislukt softwareproject eindigt in de praktijk 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, en is er een escrowregeling waarbij de broncode is gedeponeerd bij een onafhankelijke derde? Wie hierover bij aanvang niets regelde, merkt dat juist op dit moment.

Wat leren praktijkvoorbeelden ons?

Dat de verantwoordelijkheid zelden bij één partij ligt en dat goede projectdocumentatie vaak de doorslag geeft.

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, bindend advies, deskundigenbericht en conflictpreventie, met vakgenoten als arbiters.

Uit gepubliceerde uitspraken van de SGOA komen enkele terugkerende lessen naar voren:

• de verantwoordelijkheid wordt zelden volledig bij één partij gelegd; de verdeling volgt uit wat elk van beide feitelijk deed en naliet;
• 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: precies deze onderwerpen kunt u vooraf beter vastleggen.

Hoe voorkomt u een geschil?

Met de juiste contractuele inrichting voorkomt u veel geschillen. De belangrijkste maatregelen op een rij:

• Werk met gefaseerde contracten: deel het project op in releases of mijlpalen, elk met eigen acceptatiecriteria, zodat u niet pas na maanden beoordeelt of het geheel voldoet.
• Spreek formele acceptatietests af voordat wordt gefactureerd, zodat vaststaat waaraan een opgeleverd onderdeel moet voldoen voordat betaling verschuldigd is.
• Leg een wijzigingsprocedure vast: wie mag een wijziging aanvragen, wie beslist, en hoe worden de gevolgen voor planning en prijs verwerkt?
• Spreek een escalatieladder af: eerst overleg binnen de projectgroep, dan een stuurgroep, dan een mediator, en pas daarna een procedure bij de rechter.
• Overweeg geschilbeslechting via de SGOA. Arbiters kunnen een zaak alleen behandelen wanneer u dit vooraf in het contract heeft vastgelegd; 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 de SGOA bovendien een snelle voorziening om het geschil vlot te beslechten.

Waar let u als opdrachtgever op?

• Lever specificaties, testgegevens en besluiten binnen de afgesproken termijn aan en leg vast wanneer u dat deed.
• Laat elke wijziging via de wijzigingsprocedure lopen en bevestig de gevolgen voor planning en prijs schriftelijk.
• Stuur een ingebrekestelling met een redelijke termijn voordat u ontbindt of schadevergoeding vordert (artikel 6:82 BW).
• Controleer of de overeenkomst de afgifte van broncode of een escrowregeling regelt.

Waar let u als leverancier op?

• Meld vertraging door uitblijvende input van de opdrachtgever direct en schriftelijk (artikel 6:58 BW).
• Laat elk opgeleverd onderdeel formeel accepteren voordat u factureert.
• Breng meerwerk alleen in rekening na een schriftelijk akkoord op de wijziging.
• Controleer of uw aansprakelijkheidsbeperking in de algemene voorwaarden is overeengekomen en ter hand gesteld (artikel 6:233 en 6:234 BW).

Wat kunnen wij voor u doen bij een mislukt softwareproject?

Wij staan zowel opdrachtgevers als leveranciers bij, van de eerste analyse tot een procedure.

• Wij analyseren de overeenkomst, de specificaties en de wijzigingsverzoeken om vast te stellen wie waarvoor verantwoordelijk was.
• Wij stellen een ingebrekestelling op, of een reactie op een ingebrekestelling (artikel 6:82 BW).
• Wij beoordelen of eigen schuld of schuldeisersverzuim een rol speelt (artikel 6:101 en 6:58 BW).
• Wij formuleren de vragen voor een deskundigenbericht en begeleiden dat onderzoek (artikel 194 Rv).
• Wij voeren de procedure bij de rechter of de SGOA, of onderhandelen over een regeling.
• Wij regelen bij een doorstart de afgifte van de broncode en de intellectuele-eigendomsrechten.

Samengevat

• Een mislukt softwareproject leidt niet automatisch tot aansprakelijkheid van de leverancier; uw eigen medewerking als opdrachtgever telt mee.
• Blijft uw medewerking uit, dan kunt u zelf in schuldeisersverzuim raken en draait de aansprakelijkheid mogelijk om.
• Bij technische geschilpunten benoemt de rechter vaak een deskundige; goede projectdocumentatie is daarbij doorslaggevend.
• Mogelijke uitkomsten zijn gedeeltelijke ontbinding, schadevergoeding, vermindering wegens eigen schuld en matiging.
• Gefaseerde contracten, acceptatiecriteria, een wijzigingsprocedure en een escalatieladder voorkomen veel geschillen.
• Geschilbeslechting via de SGOA verloopt doorgaans sneller dan een gewone procedure, mits u dit vooraf in het contract heeft vastgelegd.

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 leverde 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 verder).

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, bindend advies en deskundigenberichten met vakgenoten als beslissers. Arbiters kunnen een zaak alleen behandelen wanneer u dit vooraf in het contract heeft vastgelegd, dus neem die clausule 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.

Meer over onze aanpak bij IT-geschillen en IT-contracten leest u bij onze advocaten IT-recht.