Een mislukt IT-project geeft niet automatisch recht op terugbetaling van alle facturen. Eerst moet worden vastgesteld wat de leverancier moest leveren, welke onderdelen tekortschieten en of een passende herstelmogelijkheid nodig is. Bewaar technisch bewijs en bescherm de bedrijfscontinuïteit voordat u de overeenkomst beëindigt of een nieuwe leverancier alles laat overschrijven.
Voor mkb-bedrijven raakt een softwareprobleem vaak de dagelijkse bedrijfsvoering. Orders blijven liggen, gegevens worden dubbel ingevoerd of een nieuw systeem kan niet in gebruik worden genomen. Tegelijk kan de leverancier stellen dat specificaties zijn gewijzigd, informatie te laat is aangeleverd of extra werk niet is betaald.
Een bruikbare aanpak combineert daarom juridische en technische analyse. Dit artikel gaat over zakelijke softwareontwikkeling, implementatie en IT-dienstverlening. Bij standaardsoftware, SaaS, hardware, hosting of persoonsgegevens kunnen aanvullende contracten en regels gelden.
Begin met de afgesproken prestatie
Verzamel de offerte, overeenkomst, functionele specificaties, projectplanning, algemene voorwaarden en latere wijzigingen. Wat moest het systeem kunnen, wanneer moest het worden opgeleverd en welke prestaties van uw eigen organisatie waren nodig?
Een overeenkomst kan zowel inspannings- als resultaatsverplichtingen bevatten. De leverancier kan bijvoorbeeld een concrete koppeling moeten opleveren, terwijl een bredere bedrijfsverbetering geen gegarandeerd resultaat is. Het etiket “inspanningsverplichting” ontslaat een leverancier niet van de plicht zorgvuldig te werken.
Kijk ook naar rangordebepalingen tussen documenten. Een brochure kan verwachtingen wekken, maar het definitieve contract kan beperkingen of andere specificaties bevatten. Andersom is een standaardclausule niet steeds het volledige antwoord op uitdrukkelijk onderhandelde toezeggingen.
Maak het probleem technisch concreet
Een klacht dat “het systeem niet werkt” is te algemeen voor een goed hersteltraject. Leg per probleem vast welke handeling u uitvoert, wat de verwachte uitkomst is, wat werkelijk gebeurt en hoe het probleem reproduceerbaar is. Voeg versies, tijdstippen en relevante schermafbeeldingen toe.
Maak onderscheid tussen fouten, ontbrekende functies, prestatiesnelheid, beveiligingsproblemen en nieuwe wensen. Een functie die nooit is afgesproken, is niet vanzelf een gebrek. Een essentiële afgesproken functie die ontbreekt, mag evenmin zonder uitleg als betaalde uitbreiding worden weggezet.
Classificeer de impact. Blokkeert het probleem de gehele ingebruikname, is er een tijdelijke omweg of raakt het slechts een beperkt onderdeel? Deze indeling helpt bij hersteltermijnen, prioriteiten en een eventuele beoordeling van opschorting of ontbinding.
Bewaar bewijs voordat u veranderingen laat uitvoeren
Zorg voor een rechtmatige kopie van relevante projectdocumenten, tickets, testresultaten, communicatie en configuratiegegevens. Bewaar waar mogelijk versies en logbestanden met hun context. Een losse schermafbeelding zonder datum of systeemversie is minder bruikbaar.
Laat een nieuwe leverancier niet zonder voorbereiding de bestaande omgeving vervangen wanneer daarmee essentieel bewijs verloren gaat. Maak eerst afspraken over vastlegging, toegang en onderzoek. Bij een omvangrijk geschil kan een onafhankelijke deskundige helpen om de toestand te beschrijven.
Houd rekening met persoonsgegevens, bedrijfsgeheimen en toegang van derden. Geef een deskundige niet meer gegevens dan nodig en zorg voor passende afspraken. Bewijs bewaren betekent niet dat u onbeperkt accounts of systemen van de wederpartij mag binnengaan.
Acceptatie en ingebruikname
Veel IT-contracten bevatten een acceptatieprocedure met testtermijnen, foutcategorieën en gevolgen van ingebruikname. Controleer of die procedure daadwerkelijk is gevolgd. Een formeel acceptatiebericht kan belangrijk bewijs zijn, maar de reikwijdte ervan hangt af van de afspraken en eventuele voorbehouden.
Ingebruikname betekent niet automatisch dat ieder later ontdekt gebrek is aanvaard. Tegelijk kan langdurig gebruik zonder duidelijke klachten uw positie beïnvloeden. Leg daarom vast waarom u een systeem tijdelijk gebruikt en welke gebreken nog openstaan.
Bij gefaseerde oplevering kan acceptatie van één onderdeel andere gevolgen hebben dan acceptatie van het hele project. Maak een overzicht per module of mijlpaal. Een mislukte eindintegratie betekent niet vanzelf dat alle eerdere prestaties waardeloos waren, maar kan wel de bruikbaarheid van het geheel raken.
Agile werken en wijzigende wensen
Bij agile projecten worden details vaak tijdens sprints uitgewerkt. Dat betekent niet dat geen afspraken bestaan. De product backlog, sprintplanning, demo’s, prioriteiten en budgetafspraken kunnen samen bepalen wat partijen mochten verwachten.
Leg vast wie wijzigingen mocht goedkeuren en hoe gevolgen voor kosten en planning werden besproken. Een mondeling verzoek van een medewerker is niet automatisch een onbeperkte opdracht voor meerwerk. Omgekeerd kan een reeks aantoonbaar goedgekeurde wijzigingen invloed hebben op de oorspronkelijke opleverdatum.
Maak een verschiloverzicht tussen de initiële scope en de huidige stand. Noteer per wijziging het verzoek, akkoord, prijs en planningseffect. Zie bij een afzonderlijk prijsconflict ook meerwerk niet betaald.
Uw eigen medewerking kan relevant zijn
Een implementatie vraagt vaak om data, toegang, besluitvorming en tests van de opdrachtgever. Controleer welke verplichtingen uw organisatie had en of die tijdig zijn uitgevoerd. Een leverancier kan niet verantwoordelijk worden gehouden voor iedere vertraging die door ontbrekende input is veroorzaakt.
Dat ontslaat de leverancier niet van alle verantwoordelijkheid. Een professionele dienstverlener kan bijvoorbeeld moeten waarschuwen voor onbruikbare data, onrealistische planning of onvoldoende medewerking. De contractuele taakverdeling en feitelijke communicatie zijn bepalend.
Maak een gezamenlijke tijdlijn met afhankelijkheden. Daarmee wordt zichtbaar welke vertraging aan welke oorzaak wordt gekoppeld. Een dossier dat alleen de fouten van de ander bevat, geeft geen betrouwbare basis voor een processtrategie.
Meld gebreken tijdig en geef een herstelkans waar nodig
De klachtplicht kan relevant zijn bij gebrekkige prestaties. Meld concrete problemen zodra u ze ontdekt of redelijkerwijs behoort te ontdekken, rekening houdend met de omstandigheden. Bewaar de ontvangst en opvolging van uw meldingen.
Voor schadevergoeding of ontbinding wegens een nog herstelbare tekortkoming kan verzuim vereist zijn. Een ingebrekestelling moet dan voldoende duidelijk maken welke prestatie wordt verlangd en binnen welke redelijke termijn. Een algemene frustratiemail is niet altijd voldoende.
Een redelijke hersteltermijn hangt af van het probleem, de eerdere pogingen en de benodigde werkzaamheden. Twee dagen kan te kort zijn voor een complexe koppeling; maanden wachten kan bij een kritieke storing te veel zijn. Laat de termijn technisch en juridisch onderbouwen.
Voorbeeld van een gerichte herstelbrief
Onderwerp: herstel van tekortkomingen in project [naam]
Volgens onze overeenkomst van [datum] en specificatie [versie] moet het systeem [concrete functie] kunnen uitvoeren. Tijdens tests op [data] is vastgesteld dat [feitelijke afwijking]. De stappen om het probleem te reproduceren, de resultaten en relevante bestanden zijn bijgevoegd.
Wij verzoeken u en, voor zover vereist, sommeren u deze tekortkoming uiterlijk op [redelijke datum] te herstellen, zodat aan [meetbaar acceptatiecriterium] wordt voldaan. Wij bieden de noodzakelijke toegang en medewerking op [wijze en momenten]. Graag ontvangen wij uiterlijk [datum] een concreet herstelplan.
De overige openstaande punten zijn opgenomen in bijlage [nummer], met prioriteit en beoogde uitkomst. Wij behouden onze rechten op nakoming en, indien aan de voorwaarden is voldaan, verdere rechtsmiddelen voor. Deze brief bevat geen akkoord op aanvullend betaald meerwerk zonder afzonderlijke afspraak.
Controleer of uw contract een specifieke escalatie- of kennisgevingsprocedure voorschrijft. De brief moet passen bij die afspraken en bij de werkelijke herstelmogelijkheid. Lees voor de algemene structuur de zakelijke ingebrekestelling.
Mag u facturen tijdelijk niet betalen
Opschorting kan onder voorwaarden mogelijk zijn, maar de omvang moet passen bij de tekortkoming en de overeenkomst. Een storing in één module rechtvaardigt niet automatisch het achterhouden van alle hosting- en onderhoudsfacturen. Een fundamenteel onbruikbaar geheel kan anders worden beoordeeld.
Controleer of een verrekenings- of opschortingsverbod is overeengekomen en of dat beding in de concrete verhouding standhoudt. Leg het betwiste bedrag en de grondslag schriftelijk vast. Een onterechte betalingsstop kan de leverancier juist een eigen aanspraak geven.
Onderzoek ook het praktische risico dat de leverancier toegang blokkeert. Dat maakt uw rechten niet minder belangrijk, maar vraagt om voorbereiding van continuïteit en gegevensbeschikbaarheid. Zie werkzaamheden of betaling opschorten voor de afzonderlijke voorwaarden.
Wanneer kunt u ontbinden
Artikel 6:265 BW geeft bij een tekortkoming in beginsel een ontbindingsmogelijkheid, tenzij de tekortkoming gezien haar bijzondere aard of geringe betekenis de ontbinding met haar gevolgen niet rechtvaardigt. Als nakoming niet blijvend of tijdelijk onmogelijk is, speelt verzuim een belangrijke rol.
Beoordeel of gehele of gedeeltelijke ontbinding passend is. Een bruikbare zelfstandige module kan anders worden behandeld dan een project dat als geheel zijn doel mist. Ook de financiële afwikkeling en de waarde van reeds verrichte prestaties moeten worden onderzocht.
Een ontbindingsbrief is geen gewone opzegging. Verkeerd beëindigen kan tot een tegenclaim leiden. Laat daarom de grondslag, eerdere herstelpogingen en gewenste gevolgen beoordelen voordat u definitief verklaart dat de overeenkomst is ontbonden.
Krijgt u alle betaalde bedragen terug
Na ontbinding kunnen ongedaanmakingsverplichtingen ontstaan, maar bij diensten en softwareprestaties is teruggave niet altijd letterlijk mogelijk. De waarde van verrichte prestaties en de toepasselijke wettelijke regels kunnen dan relevant zijn. Het antwoord is niet automatisch dat elke betaalde euro terugkomt.
Maak onderscheid tussen licenties, ontwikkeling, implementatie, onderhoud en hardware. Sommige onderdelen kunnen bruikbaar blijven of een zelfstandige waarde hebben. Andere kunnen juist waardeloos zijn omdat de afgesproken samenhang ontbreekt.
Onderbouw waarom u een bepaalde terugbetaling of schadevergoeding verlangt. Een totaalbedrag zonder uitsplitsing maakt het debat moeilijker. Laat fiscale correcties en eventuele creditfacturen aansluiten op de gekozen juridische afwikkeling.
Schade en aansprakelijkheidsbeperkingen
Mogelijke schadeposten zijn redelijke herstelkosten, vervangende dienstverlening, extra interne kosten of gederfde winst. Niet iedere post is automatisch verhaalbaar. De tekortkoming, toerekening, causaliteit, voorzienbaarheid en schadebeperking moeten worden beoordeeld.
IT-contracten bevatten vaak aansprakelijkheidslimieten en uitsluitingen voor bepaalde schade. Onderzoek toepasselijkheid, uitleg en houdbaarheid. Het woord “indirecte schade” heeft zonder contractuele definitie niet in ieder contract dezelfde betekenis.
Een garantie, vrijwaring of boete kan de risicoverdeling verder beïnvloeden. Zie ook aansprakelijkheid beperken in een zakelijk contract. Presenteer een cap niet als automatisch ongeldig zodra de schade hoger uitvalt.
Data broncode en overstappen
Het einde van de samenwerking geeft niet automatisch eigendom van alle broncode. Onderzoek licenties, auteursrechten, maatwerkafspraken en eventuele escrow. Ook toegang tot data en de mogelijkheid van export moeten concreet worden geregeld.
Maak een overdrachtslijst met databestanden, documentatie, configuraties, accounts, domeinnamen en afhankelijkheden. Bepaal welke gegevens uw onderneming rechtmatig kan meenemen en welke rechten van derden bestaan. Een werkende export vraagt vaak meer dan een zipbestand met ruwe tabellen.
Leg tijdelijke ondersteuning, beveiliging en verwijdering van gegevens vast. Bij persoonsgegevens kunnen verwerkersafspraken en wettelijke verplichtingen doorlopen. Een betalingsconflict is geen reden om noodzakelijke beveiliging of zorgvuldige afwikkeling te negeren.
Fictief voorbeeld van een mislukte implementatie
Een groothandel laat een voorraad- en bestelsysteem invoeren. De voorraadkoppeling werkt niet betrouwbaar, terwijl de leverancier zegt dat de klant onvolledige productdata heeft aangeleverd. De klant wil alle facturen terug en overweegt een andere leverancier direct te laten beginnen.
Eerst worden specificaties, testresultaten en data-aanleveringen veiliggesteld. Een technisch onderzoek maakt onderscheid tussen fouten in de koppeling en problemen in de brondata. Daarna volgt een herstelplan met duidelijke verantwoordelijkheden en acceptatiecriteria.
Als herstel uitblijft, kan worden beoordeeld welke rechtsmiddelen passen. Misschien is vervanging van één onderdeel voldoende; misschien raakt het probleem het hele project. Het voorbeeld laat zien waarom een juridische claim sterker wordt door een concrete technische diagnose.
Een regeling of procedure kiezen
Een regeling kan bestaan uit herstel onder toezicht, een prijsaanpassing, overdracht aan een nieuwe leverancier of beëindiging met een financiële afrekening. Leg meetbare oplevercriteria en gevolgen van mislukking vast. Een nieuwe algemene belofte dat het binnenkort goedkomt is onvoldoende.
Bij spoed kan een voorlopige voorziening nodig zijn, bijvoorbeeld rond toegang tot data of continuïteit. Voor een definitieve schadebeoordeling kan een deskundigenonderzoek nodig zijn. Controleer de geschillenregeling: sommige IT-contracten verwijzen naar arbitrage of een specifieke instantie.
Via bedrijfsrecht voor ondernemers kunt u de juridische positie laten beoordelen. Neem het technische dossier mee en benoem welke systemen bedrijfskritisch zijn. Daarmee kan eerst worden bepaald wat veiliggesteld moet worden en daarna welke oplossing haalbaar is.
Maak een technische overdracht controleerbaar
Stel bij een overstap vooraf vast wat de nieuwe leverancier nodig heeft om verantwoord te beginnen. Dat omvat vaak meer dan de broncode: documentatie, afhankelijkheden, configuratie, databasebeschrijvingen, licenties en toegang tot bouw- of hostingomgevingen. Leg vast welke onderdelen ontbreken en wie ze moet aanleveren.
Voer waar mogelijk een test uit met een kopie in een afgescheiden omgeving. Daarmee kunt u controleren of een export volledig en bruikbaar is zonder meteen de productieomgeving te wijzigen. Houd rekening met beveiliging en persoonsgegevens; een volledige kopie is niet in iedere situatie noodzakelijk of toegestaan.
Maak een overdrachtsverslag met datum, bestanden, versies en de uitkomst van de controle. Een verklaring dat “alles is overgedragen” kan te ruim zijn als de nieuwe leverancier nog geen toegang heeft kunnen testen. Gebruik concrete acceptatiecriteria en benoem eventuele restpunten.
Let op samenloop met verzekering en privacy
Bij een incident kan een beroepsaansprakelijkheids-, cyber- of rechtsbijstandsverzekering relevant zijn. Meld de kwestie volgens de polisvoorwaarden en stem erkenningen of regelingen waar nodig af. Een verzekeringsmelding vervangt de klacht of ingebrekestelling aan de leverancier niet.
Als persoonsgegevens zijn geraakt, kunnen daarnaast afzonderlijke verplichtingen bestaan rond beveiliging, onderzoek en eventuele meldingen. Dat is een andere beoordeling dan de vraag wie de implementatiefactuur moet betalen. Laat een acuut dataprobleem daarom niet wachten op de uitkomst van het contractgeschil.
Bewaar een gescheiden overzicht van technische herstelacties, juridische correspondentie en eventuele incidentmaatregelen. Zo blijft zichtbaar welke kosten voortkomen uit welk probleem en welke informatie met welke partij is gedeeld. Die structuur helpt zowel bij de afwikkeling als bij een latere schadeberekening.
Veelgestelde vragen
Kan ik direct stoppen als de software niet werkt?
Niet zonder beoordeling. De afspraken, ernst van de tekortkoming en eventuele herstel- en verzuimvereisten zijn belangrijk. Een onterechte beëindiging kan zelf tot aansprakelijkheid leiden. Bewaar bewijs en bescherm eerst de continuïteit.
Betekent ingebruikname dat ik alle fouten accepteer?
Niet automatisch. Het contract, de acceptatieprocedure en eventuele voorbehouden bepalen de betekenis. Meld openstaande gebreken duidelijk en leg vast waarom u het systeem tijdelijk gebruikt. Langdurig gebruik zonder klachten kan uw positie beïnvloeden.
Moet de leverancier altijd een vaste einddatum halen?
Dat hangt af van de afspraak en omstandigheden. Een harde opleververplichting is iets anders dan een indicatieve planning. Ook overeengekomen wijzigingen en noodzakelijke medewerking van de opdrachtgever kunnen relevant zijn.
Krijg ik bij ontbinding alle facturen terug?
Dat is niet vanzelfsprekend. Ongedaanmaking, de waarde van verrichte prestaties en de samenhang tussen onderdelen moeten worden beoordeeld. Splits ontwikkeling, licenties, onderhoud en andere posten uit voor een controleerbare afrekening.
Ben ik eigenaar van de broncode die ik heb betaald?
Betaling alleen betekent niet automatisch overdracht van auteursrechten of een onbeperkt gebruiksrecht. Controleer de licentie, overdrachtsafspraken en eventuele escrow. Ook rechten op gebruikte software van derden kunnen een rol spelen.
Kan ik een nieuwe leverancier meteen alles laten aanpassen?
Dat kan bewijs en herstelmogelijkheden beïnvloeden. Leg de bestaande toestand eerst zorgvuldig vast en beoordeel contractuele rechten en toegangsbevoegdheden. Bij urgente continuïteitsmaatregelen moet worden gedocumenteerd waarom uitstel niet verantwoord was.
Bronnen en juridische basis
- Burgerlijk Wetboek Boek 6: onder meer artikelen 74, 81–89, 98, 101, 248 en 265–272.
- Gerechtshof Amsterdam 16 april 2024 over een softwaregeschil: voorbeeld van beoordeling van contract, acceptatie en uitvoering; geen algemene uitkomstgarantie.
- Auteurswet: rechten op software en vereisten voor overdracht.
