Wanneer een IT-leverancier en een afnemer met elkaar in zee gaan, lijkt op het eerste gezicht duidelijk wat partijen van elkaar mogen verwachten: de leverancier levert een dienst of product en de afnemer betaalt daarvoor. In de praktijk blijkt echter telkens weer dat juist over die wederzijdse verwachtingen geschillen ontstaan, vaak pas op het moment dat een project mislukt, uitloopt of een dienst niet naar behoren functioneert. Pas dan grijpen partijen terug op het contract, met de vraag: wat is er nu eigenlijk afgesproken? En, juridisch gezien nog belangrijker: was de leverancier slechts verplicht zich in te spannen, moest hij een bepaald resultaat leveren, of heeft hij zelfs een garantie afgegeven?
In dit blog bespreek ik de drie typen verplichtingen die je in vrijwel elk ICT-contract terugziet en leg ik uit waarom het onderscheid juridisch en financieel verstrekkende gevolgen kan hebben.
Waarom doet dit onderscheidt ertoe?
De wet bepaalt dat iedere tekortkoming in de nakoming van een verbintenis de schuldenaar verplicht tot vergoeding van de schade die de schuldeiser daardoor lijdt, tenzij die tekortkoming hem niet kan worden toegerekend. Voordat een afnemer zijn leverancier dus succesvol aansprakelijk kan stellen, moet dus onder meer worden vastgesteld dat er sprake is van een tekortkoming. Precies daar ontstaat vaak de discussie: is de leverancier zijn verplichtingen daadwerkelijk niet nagekomen? Om die vraag te beantwoorden, moet gekeken worden naar de aard van de verplichtingen die op de leverancier rusten.
De inspanningsverplichting
De inspanningsverplichting is de lichtste variant van de drie. De leverancier verplicht zich om zich in te spannen om een bepaald doel te bereiken, maar staat juridisch niet in voor het bereiken van dat doel zelf. Of het beoogde resultaat daadwerkelijk wordt behaald, is voor de vraag of er sprake is van een tekortkoming dus niet doorslaggevend.
De resultaatsverplichting
Een trede zwaarder is de resultaatsverplichting. Hierbij verplicht de leverancier zich om een concreet, in het contract omschreven resultaat te leveren. Wordt dat resultaat niet behaald, dan staat de tekortkoming in beginsel vast, ongeacht hoeveel inspanning de leverancier heeft geleverd. De afnemer hoeft dan niet te bewijzen dat de leverancier onvoldoende heeft gedaan; hij hoeft slechts aan te tonen dat het afgesproken resultaat ontbreekt.
Dat betekent overigens niet dat de leverancier dan automatisch schadeplichtig is. De wet biedt namelijk nog een escape: als de tekortkoming hem niet kan worden toegerekend (overmacht), blijft schadevergoeding achterwege.
De garantieverplichting
De garantie is de zwaarste verbintenis die een leverancier kan aangaan en gaat verder dan de resultaatsverplichting. Wie een garantie geeft, neemt het risico dat de gegarandeerde afspraak niet wordt nagekomen in beginsel voor eigen rekening, ook als de oorzaak daarvan normaal gesproken niet aan hem zou kunnen worden toegerekend. Anders gezegd: met een garantie kan de leverancier zijn mogelijkheid om zich op overmacht te beroepen verliezen.
Valkuil 1: Het label belangrijker maken dan de inhoud
In ICT-contracten wordt vaak gedacht dat de gekozen term doorslaggevend is. Staat er “garantie” boven een bepaling, dan denkt men dat er sprake is van een garantie. En staat ergens algemeen dat “alle verplichtingen van de leverancier gelden als inspanningsverplichting”, dan lijkt daarmee het risico van resultaatverplichtingen afgedekt.
Zo eenvoudig is het niet. De kwalificatie van een verplichting wordt niet alleen bepaald door het gekozen label, maar vooral door de inhoud en context van de afspraak. Een algemene inspanningsclausule helpt bijvoorbeeld weinig als elders concreet wordt toegezegd dat een koppeling, migratie of implementatie op een bepaalde datum werkend wordt opgeleverd. In dat geval kan de inhoud van de afspraak zwaarder wegen dan het etiket dat partijen eraan hebben gegeven.
Aandachtspunt is dus: zorg dat het gekozen label aansluit bij de inhoud van de afspraak. Als een verplichting als inspanningsverplichting is bedoeld, vermijd dan formuleringen die toch een concreet resultaat beloven. En als er wél een resultaat of garantie wordt afgesproken, leg dan precies vast waarop die verplichting ziet, wanneer daaraan is voldaan en welke uitzonderingen gelden.
Valkuil 2: Onderschatten wat je moet bewijzen
Bij een inspanningsverplichting draait het geschil niet om de vraag of het gewenste resultaat is behaald, maar om de vraag of de leverancier zich voldoende heeft ingespannen. Dat wordt door afnemers vaak onderschat. Zij wijzen dan op het mislukte project of de niet-werkende oplossing. Zij moeten echter aantonen dat de leverancier niet heeft gehandeld zoals overeengekomen en zoals van een redelijk bekwaam en redelijk handelend vakgenoot mocht worden verwacht.
Dat bewijs is lastig, omdat veel werkzaamheden voor de afnemer niet zichtbaar zijn en de technische expertise vaak bij de leverancier ligt. Wel kan van de leverancier worden verlangd dat hij inzicht geeft in wat hij heeft gedaan en waarom die inspanningen voldoende waren. De formele bewijslast verschuift daarmee niet zonder meer, maar de leverancier kan wel een zwaardere toelichtingsplicht hebben.
Aandachtspunt is dus: leg bij inspanningsverplichtingen vast hoe de leverancier zijn inspanningen inzichtelijk maakt, bijvoorbeeld via voortgangsrapportages, overlegmomenten, documentatie en afspraken over medewerking en escalatie.
Valkuil 3: Een resultaat afspreken zonder meetlat
Een resultaatsverplichting heeft alleen waarde als duidelijk is welk resultaat precies moet worden behaald. Juist daar gaat het in ICT-contracten vaak mis. Partijen spreken bijvoorbeeld af dat een systeem, koppeling of migratie “werkend” moet worden opgeleverd, zonder vast te leggen wat “werkend” concreet betekent.
Daardoor blijft onduidelijk welke functionaliteiten worden geleverd, aan welke technische en functionele eisen de oplossing moet voldoen, welke prestatie-eisen gelden en wanneer het resultaat uiterlijk moet zijn opgeleverd. Als bovendien concrete acceptatiecriteria en een gestructureerd acceptatieproces ontbreken, ontstaat al snel discussie over de vraag of het resultaat daadwerkelijk is behaald.
Aandachtspunt is dus: maak het afgesproken resultaat meetbaar. Leg vast welke functionaliteiten, specificaties, deadlines, prestatie-eisen en acceptatiecriteria gelden. Zonder die meetlat wordt een resultaatsverplichting in de praktijk moeilijk afdwingbaar.
Valkuil 4: Garanties te ruim formuleren
In ICT-contracten wordt het woord “garantie” vaak gebruikt om vertrouwen uit te stralen of een commerciële belofte kracht bij te zetten. Denk aan formuleringen als: “wij garanderen dat de software werkt”, “wij garanderen een snelle implementatie” of “wij garanderen volledige compatibiliteit met uw bestaande systemen”. Dat klinkt geruststellend, maar kan juridisch verder gaan dan bedoeld.
Een garantie kan namelijk meebrengen dat de leverancier het risico van niet-nakoming voor eigen rekening neemt, ook wanneer de oorzaak daarvan normaal gesproken niet aan hem zou kunnen worden toegerekend. Daarmee kan een beroep op overmacht worden beperkt of zelfs uitgesloten. Dat maakt een garantie aanzienlijk zwaarder dan een gewone resultaatsverplichting.
Aandachtspunt is dus: gebruik het woord “garantie” alleen bewust en baken de garantie scherp af. Leg vast waarop de garantie precies ziet, hoe lang zij geldt, welke uitzonderingen gelden en wat het rechtsgevolg is als de garantie niet wordt gehaald.
Conclusie
Het onderscheid tussen een inspanningsverplichting, resultaatsverplichting en garantie is geen juridisch detail, maar heeft verstrekkende gevolgen voor de risicoverdeling, de bewijslast en de uiteindelijke aansprakelijkheid. De besproken valkuilen zijn slechts enkele voorbeelden van wat er in de praktijk mis kan gaan. Ze maken duidelijk hoe belangrijk het is om het type verplichting bewust te kiezen en consistent in het contract vast te leggen. Wie dat bij het sluiten van het contract goed doet, voorkomt later onnodige discussies en potentieel kostbare verrassingen.
Benieuwd naar de andere delen? Lees ook de andere blogs in deze reeks. Heb je hulp nodig bij het opstellen van je ICT-contracten of wil je zekerheid dat je het juist aanpakt? Volg onze cursus.
