Wat zijn de toepassingsgebieden van de acceptatie en de veronderstelde acceptatieclausule in systeemontwikkeling?

Een fase waarin juridische problemen gemakkelijk kunnen ontstaan bij systeemontwikkeling is de ‘acceptatie’ fase.

‘Acceptatie’ verwijst naar de inspectie- en controleverplichting die ontstaat aan de kant van de opdrachtgever wanneer de opdrachtnemer de resultaten levert. Als de opdrachtgever na levering de ‘acceptatie’ niet uitvoert, wordt de opdrachtnemer, de leverancier, in een juridisch onstabiele positie geplaatst.

Om dergelijke problemen op te lossen, worden contracten vaak voorzien van een ‘veronderstelde acceptatie’ clausule.

In dit artikel zullen we uitleggen wanneer ‘veronderstelde acceptatie’ van toepassing is, gebaseerd op daadwerkelijke rechtszaken.

Wat is acceptatie in systeemontwikkeling?

In de eerste plaats verwijst ‘acceptatie’ in een systeemontwikkelingsproject naar het proces waarbij de gebruiker, als opdrachtgever, de door de leverancier (in dit geval de IT-systeemontwikkelaar) geleverde producten inspecteert en controleert om te zien of ze voldoen aan de specificaties die zijn gesteld voor het beoogde doel.

Vanuit het perspectief van de ontwikkelaar kan dit worden gezien als een ‘controle of het echt klaar is’, en kan het worden gepositioneerd als een testproces.

Vanwege de aard van het werk van het ontwikkelen van IT-systemen, is er vaak veel ruimte voor discretie aan de kant van de leverancier, en er kunnen verschillen ontstaan tussen het daadwerkelijk geproduceerde product en wat de gebruiker heeft gevraagd.

In algemene termen betekent het slagen voor de acceptatie dat de gebruiker zelf heeft bevestigd dat het product dat daadwerkelijk is geleverd overeenkomt met wat de gebruiker wilde (of het doel van het verzoek om het systeem te ontwikkelen).

In de praktijk van contracten, hoewel het mogelijk is om rekening te houden met gevallen waarin later blijkt dat er gebreken zijn in het systeem, zijn er veel gevallen waarin het slagen voor de acceptatie wordt gesteld als een voorwaarde voor betaling.

Let op voor de ‘deemed acceptance’ clausule

Als er eenmaal problemen ontstaan in de acceptatiefase, kunnen zowel de gebruiker als de leverancier in een lastige situatie terechtkomen.

Stel bijvoorbeeld dat de leverancier het product heeft voltooid en al heeft gepresenteerd, maar de verantwoordelijke persoon aan de gebruikerskant kan om persoonlijke redenen de acceptatie niet bevestigen. Wat gebeurt er dan?

Om dergelijke situaties te voorzien, wordt er vaak een clausule genaamd ‘deemed acceptance’ opgenomen in het contract voor systeemontwikkeling.

Wat is een veronderstelde acceptatieclausule?

(Acceptatie van de betreffende software) Artikel 28
Van de geleverde goederen moet de koper de betreffende software inspecteren binnen de periode gespecificeerd in het individuele contract (hierna “inspectieperiode” genoemd) op basis van de inspectiespecificaties van het vorige artikel, en controleren of de systeemspecificaties en de betreffende software overeenkomen.

2. Als de betreffende software voldoet aan de inspectie van het vorige lid, zal de koper een ondertekend en gestempeld inspectiecertificaat aan de verkoper overhandigen. Als de betreffende software niet slaagt voor de inspectie van het vorige lid, zal de koper een document met de specifieke redenen voor het falen snel aan de verkoper overhandigen en correcties of aanvullingen eisen. Als de redenen voor het falen worden erkend, zal de verkoper de correcties gratis uitvoeren en aan de koper leveren binnen de overeengekomen termijn na overleg, en de koper zal de inspectie zoals bepaald in het vorige lid opnieuw uitvoeren indien nodig.

3. Zelfs als er geen inspectiecertificaat wordt overhandigd, als de koper geen bezwaar maakt met specifieke redenen in een schriftelijk document binnen de inspectieperiode, wordt de betreffende software beschouwd als geslaagd voor de inspectie zoals bepaald in dit artikel.

4. De acceptatie van de betreffende software wordt voltooid met de inspectie-goedkeuring zoals bepaald in dit artikel.

https://www.meti.go.jp/policy/it_policy/keiyaku/model_keiyakusyo.pdf

Let op, juridisch gezien is het gebruik van de term “beschouwd als” in paragraaf 3 een punt van aandacht. Als we het bekijken als een juridische term, hebben “beschouwen als” en “veronderstellen” in feite totaal verschillende betekenissen.

Beschouwen als…
→ Zelfs als het in werkelijkheid niet zo is, wordt het juridisch behandeld alsof het zo is.

(Voorbeeld) Als je tijdens een examen een smartphone bedient, wordt het beschouwd als “spieken”
→ Ongeacht of wat je daadwerkelijk deed met je smartphone spieken was of niet, dezelfde maatregelen worden genomen alsof het spieken was.

Veronderstellen…
→ Tenzij er specifiek bewijs is dat een feit ontkent, wordt het als een feit behandeld.

(Voorbeeld) Als je tijdens een examen naar een smartphone kijkt, wordt het verondersteld “spieken”
→ In principe wordt aangenomen dat er sprake was van spieken, maar als je kunt aantonen dat het voor een ander doel was dan spieken, kan die beslissing later worden teruggedraaid. (Hoewel je normaal gesproken zo’n aankondiging niet zou horen in een examenruimte.)

Met andere woorden, de drempel om “veronderstellen” en “beschouwen als” te weerleggen is enorm verschillend. De implicatie hier is “ongeacht of het feit van acceptatie waar is of niet, het wordt behandeld alsof het is geaccepteerd”.

Rechtszaken met betrekking tot de veronderstelde acceptatieclausule

Er zijn in het verleden gevallen geweest waarin de veronderstelde acceptatieclausule een cruciale rol speelde in de rechtszaak. Bijvoorbeeld, in het onderstaande geciteerde vonnis, heeft de gebruiker een rechtszaak aangespannen omdat de vereiste functies niet waren geïmplementeerd na de acceptatieperiode, en dit werd een rechtszaak. Echter, de rechtbank oordeelde dat de levering al was voltooid op basis van de veronderstelde acceptatieclausule.

In dit contract, was het bedrijf Y verplicht om het systeem onmiddellijk na levering te inspecteren en binnen 10 dagen schriftelijk te accepteren. Als er geen kennisgeving is binnen de bovengenoemde termijn, wordt aangenomen dat het is geaccepteerd. Omdat er geen kennisgeving was van niet-conforme punten in deze inspectie, kan de feiten van levering en acceptatie worden bevestigd.

Tokyo District Court, 29 februari 2012 (Heisei 24)

Aan de andere kant, zelfs als deze veronderstelde acceptatieclausule aanwezig was, zijn er rechtszaken waarin de toepassing ervan werd ontkend en de contractbreuk van de leverancier werd erkend.

Het geval in het onderstaande geciteerde vonnis verschilt van de bovengenoemde rechtszaak in die zin dat de leverancier, ondanks dat zijn medewerking nodig was om de acceptatie uit te voeren, deze medewerking heeft nagelaten.

De eiser (leverancier) beweert dat de verweerder (gebruiker), omdat hij niet binnen 10 dagen na de levering van het product de resultaten van de inspectie heeft gemeld, wordt geacht het product te hebben geaccepteerd volgens artikel 9, lid 4, van het softwareontwikkelingscontract. Echter, voor een dergelijk resultaat is de medewerking van de eiser essentieel, en de eiser heeft niet samengewerkt met de verweerder voor deze inspectie, dus in dit geval, zelfs als de verweerder niet binnen 10 dagen na de levering van het product de resultaten van de inspectie heeft gemeld, wordt niet aangenomen dat de verweerder de software heeft geaccepteerd volgens artikel 9, lid 4, van het softwareontwikkelingscontract.

Tokyo District Court, 23 juni 2004 (Heisei 16)

Het wordt aangenomen dat het doel van het systeem van de veronderstelde acceptatieclausule zelf is om de leverancier snel te bevrijden van een onstabiele positie waarin hij, ondanks dat hij snel wil doorgaan met de acceptatie, niet kan doorgaan vanwege de eenzijdige omstandigheden van de gebruiker, en om de relatie tussen beide partijen eerlijk te houden.

Daarom kan het niet zo zijn dat men ver afwijkt van dit doel en probeert om de acceptatie zelf uit te stellen door de veronderstelde acceptatieclausule als schild te gebruiken, en om op deze manier defecte producten of wat dan ook op te dringen.

Als de acceptatie wordt “verondersteld” te zijn geslaagd, moet de gebruiker de vergoeding voor de systeemontwikkeling betalen. Rekening houdend met deze ernst, wordt aangenomen dat de rechtbank streeft naar een eerlijk oordeel door ook de medewerking van de leverancier op te nemen.

Naast het contract kunnen de notulen van de voortgang van de systeemontwikkeling ook belangrijk bewijs zijn. Dit wordt in detail uitgelegd in het volgende artikel.

https://monolith.law/corporate/the-minutes-in-system-development[ja]

Overigens, voor wat betreft de vraag welke alomvattende verplichtingen de leverancier als expert in systeemontwikkeling heeft ten opzichte van het project, zie het volgende artikel.

Zelfs als de acceptatie in principe door de gebruiker moet worden uitgevoerd, is het natuurlijk dat de leverancier, als expert in systeemontwikkeling, verschillende vormen van medewerking aan de acceptatie moet verlenen. Dit zal duidelijk worden als u rekening houdt met de inhoud van het volgende artikel.

https://monolith.law/corporate/project-management-duties[ja]

Patronen waarin gebreken worden ontdekt bij acceptatie

Echter, het is mogelijk dat tijdens de acceptatiefase tekortkomingen in het systeem (in juridische termen vaak aangeduid als ‘gebreken’) aan het licht komen. Voor juridische kwesties in dit geval, zie het volgende artikel voor meer details.

https://monolith.law/corporate/defect-warranty-liability[ja]

Samenvatting

In systeemontwikkeling is de ‘acceptatie’ in principe een indicatie van de volledige uitvoering van de verplichtingen van de leverancier, en kan daarom als zeer belangrijk worden beschouwd voor zowel de gebruiker als de leverancier. Om ernstige problemen te voorkomen, is het raadzaam dat zowel de opdrachtgever als de opdrachtnemer goed begrijpen wat de ‘veronderstelde acceptatieclausule’ inhoudt.

Daarnaast, in het geval dat de acceptatie niet soepel verloopt, is het belangrijk om vanaf het contractstadium voorafgaand aan de situatie, een grondige afstemming van het bewustzijn te hebben, met name met betrekking tot bepalingen die betrekking hebben op de acceptatie, door beide partijen.