Kan een systeemontwikkelingsovereenkomst tot stand komen zonder een contract?

In systeemontwikkeling is het niet ongebruikelijk dat ontwikkelaars beginnen met werken voordat er een contract is opgesteld. Echter, deze werkwijze is in de praktijk ‘gevaarlijk’. Als er geen contract is opgesteld, loopt u het risico dat de opdrachtgever later problemen veroorzaakt door te zeggen dat er nog geen contract is gesloten en dat er daarom geen betaling nodig is. In feite zijn er in geschillen over systeemontwikkeling vaak gevallen waarin het bestaan van het contract zelf wordt betwist, en de ontwikkelaar krijgt vaak een nadelige uitspraak. Als ontwikkelaar loopt u het risico dat u niet betaald krijgt als de opdrachtgever het project stopzet of overstapt naar een ander bedrijf. Bovendien, zoals later zal worden uitgelegd, zijn er gevallen waarin het contract wordt ontkend, zelfs als er een contract is opgesteld.

Hier zullen we uitleggen over het succes of falen van systeemontwikkelingscontracten, en de juridische structuur voor het claimen van geld als het contract niet wordt erkend.

Contractvorming

Een contract wordt in principe gevormd wanneer beide partijen overeenstemming bereiken over de elementen van het contract (overeenstemming van de intentie om een aanbod te doen en de intentie om dit te accepteren).

Wanneer een contract is gevormd, zijn beide partijen gebonden aan het contract. Als een van de partijen de contractuele verplichtingen niet nakomt, kan de andere partij via de rechtbank afdwingen dat deze verplichtingen worden nagekomen, of schadevergoeding eisen voor het niet nakomen van de verplichtingen. De ‘elementen van het contract’ moeten specifiek of concreet genoeg zijn om naleving af te dwingen en niet-naleving vast te stellen.

Vorming van een systeemontwikkelingscontract

De aard van een systeemontwikkelingscontract is voornamelijk een contract voor werk en een quasi-mandaatcontract. Een contract voor werk belooft de voltooiing van het werk en de betaling ervoor. Een betaald quasi-mandaatcontract belooft de uitvoering van de taak en de betaling ervoor.

https://monolith.law/corporate/contract-and-timeandmaterialcontract[ja]

Daarom, als er overeenstemming is tussen de partijen over de ‘inhoud van het werk of de taak’ en het ‘bedrag van de vergoeding’, die de elementen van het contract zijn, wordt aangenomen dat het contract is gevormd.

Overigens, een contract kan ook worden gevormd door een mondelinge overeenkomst, een schriftelijk contract is niet verplicht.

Financiële claims bij annulering na de vorming van een systeemontwikkelingscontract

Als een systeemontwikkelingscontract is gevormd en de gebruiker eenzijdig aangeeft te willen stoppen, wordt dit juridisch gezien beschouwd als een kennisgeving van contractbeëindiging.

Als er een contract voor werk is gevormd, kan de leverancier op elk moment tijdens de voltooiing van het werk worden beëindigd door de gebruiker, maar het is bepaald dat de leverancier in een positie is om schadevergoeding te ontvangen (Artikel 641 van het Japanse Burgerlijk Wetboek). Daarom, als er geen schadevergoeding is betaald door de gebruiker, kan de leverancier schadevergoeding eisen voor de ‘schade’, dat is het bedrag van de kosten die de leverancier tot dat moment heeft gemaakt en het bedrag van de vergoeding die zou zijn ontvangen, minus de kosten die zijn bespaard door het niet voltooien van het systeem.

Als er een quasi-mandaatcontract is gevormd, kan de gemachtigde een vergoeding eisen op basis van het percentage van de uitvoering wanneer het mandaat halverwege de uitvoering eindigt (Artikel 648, lid 3, van het gewijzigde Japanse Burgerlijk Wetboek). Daarom kan de leverancier betaling eisen voor het werk dat al is gedaan.

Het succes of falen van systeemontwikkelingsovereenkomsten

Specificiteit van systeeminhoud

Normaal gesproken worden schriftelijke overeenkomsten gebruikt voor transacties tussen bedrijven, vooral voor contracten met grote bedragen. Als er een contract is opgesteld, wordt de totstandkoming van het contract gemakkelijk erkend.

Het systeem dat het onderwerp is van ontwikkeling wordt geleidelijk geconcretiseerd door verschillende processen. Daarom wordt aangenomen dat de specificiteit van de systeeminhoud, die een element is van het contract voor werk, voldoende is als de reikwijdte en het overzicht van het systeem dat men probeert te systematiseren, bekend zijn.

In rechtszaken is er geen geschil over het sluiten van de basisovereenkomst en de geheimhoudingsovereenkomst. Hoewel de basisovereenkomst vermeldt dat “ondersteuning voor e-commerce technologie, ondersteuning voor websiteconstructie en bijbehorende taken” worden uitbesteed, wordt de totstandkoming van het contract ontkend in gevallen waarin de specifieke inhoud van de e-commerce business, de reikwijdte van de uitbestede taken en de reikwijdte van de ontwikkeling en het ontwerp als systeem niet expliciet zijn gemaakt.

Zelfs als u een basisovereenkomst voor systeemontwikkeling opstelt, zal de totstandkoming van het contract moeilijk te erkennen zijn als het werk en de inhoud van de taken abstract zijn en niet specifiek zijn gemaakt. De totstandkoming van een contract kan worden erkend door contracten en dergelijke waarin de inhoud van het werk en de taken en het beloningsbedrag concreet zijn vermeld tot het punt waarop ze kunnen worden afgedwongen en niet-nakoming kan worden vastgesteld.

Let op, we hebben de aandachtspunten van contracten tussen individuele ingenieurs en bedrijven in detail uitgelegd in het volgende artikel.

https://monolith.law/corporate/engineer-joint-enterprise-contract[ja]

De leverancier presenteert offertes en specificaties, en de gebruiker keurt deze goed en plaatst een bestelling

Normaal gesproken worden schriftelijke documenten gebruikt in zakelijke transacties tussen bedrijven, dus als er geen contract is opgesteld, is het moeilijk om de totstandkoming van een contract te erkennen. In systeemontwikkeling wordt vaak met het werk begonnen voordat een contract is opgesteld, maar hoe wordt er dan gedacht over het al dan niet tot stand komen van een contract?

In een rechterlijke uitspraak (Nagoya District Court, 28 januari 2004 (Heisei 16)) over de totstandkoming van een contract voor systeemontwikkeling, wordt het volgende gezegd:

• Na onderhandelingen over specificaties, enz. tussen de leverancier en de gebruiker,
• Worden specificaties en offertes, enz. gepresenteerd door de leverancier, en
• Wordt het contract gesloten door de goedkeuring en bestelling van de gebruiker.

In dit rechtszaak had de leverancier, op verzoek van de gebruiker, een lokale overheid, een voorstel en offerte ingediend in reactie op een RFP getiteld “Verzoek om voorstel voor de introductie van een geïntegreerd administratief informatiesysteem”. De gebruiker diende een “adoptie kennisgeving” in. De leverancier had echter niet voldoende overlegd met de gebruiker over de inhoud van het werk van de gebruiker, enz., en er was geen bewijs dat de inhoud en kosten van de aanpassing intern door de gebruiker waren besproken. De inhoud van het voorstel van de leverancier was ook niet specifiek, en het was niet duidelijk wat de gebruiker had goedgekeurd, dus de totstandkoming van het contract werd niet erkend.

Ik zal een aanvullende uitleg geven over de totstandkoming van het contract zoals vermeld in de rechterlijke uitspraak, rekening houdend met andere rechterlijke uitspraken, enz.

Na onderhandelingen over specificaties, enz. tussen de leverancier en de gebruiker

Vanuit het feit dat er “onderhandelingen” zijn, als de inhoud van het systeem en het bedrag van de vergoeding “onderhandeld” worden, is het moeilijk om de totstandkoming van een contract te erkennen als er geen overeenstemming is bereikt.

Echter, in een contract voor werk kan de prijs worden bepaald op basis van de marktwaarde, dus er zijn rechterlijke uitspraken die erkennen dat een contract voor werk is gesloten op basis van een prijs die overeenkomt met de marktwaarde, vanuit het feit dat de gebruiker de inhoud van het systeem en “ongeveer” het bedrag van de vergoeding heeft goedgekeurd.

Om te kunnen zeggen dat er “onderhandelingen” zijn geweest, is het goed voor de leverancier om voldoende overleg en overweging te hebben gehad met de gebruiker over de inhoud van het werk van de gebruiker, de inhoud van het systeem, enz., en dit vast te leggen in e-mails, notulen, enz.

Specificaties en offertes, enz. worden gepresenteerd door de leverancier, en deze worden goedgekeurd en besteld door de gebruiker

• Als er een bestelformulier of bestelling wordt uitgegeven door de gebruiker, is het gemakkelijker om de totstandkoming van een contract te erkennen. Als de leverancier een aanvraagformulier indient of werkzaamheden uitvoert op basis van een bestelformulier, enz., zal het gemakkelijker zijn om te erkennen dat er “overeenstemming” is en dat een contract is gesloten.
• Interne documenten van de gebruiker zijn vaak bedoeld om een contract te sluiten in de toekomst, en het is moeilijk om de totstandkoming van een contract te erkennen. Echter, als er geen dergelijke vermelding is en de inhoud van de systeemontwikkeling en het bedrag van de vergoeding, die elementen van het contract zijn, zo specifiek mogelijk worden vermeld, zal dit bijdragen aan de erkenning van de totstandkoming van een contract.
• Het is moeilijk om de totstandkoming van een contract te erkennen als een memorandum, overeenkomst, bevestigingsbrief, enz. zijn opgesteld op basis van de veronderstelling dat er een apart contract zal worden gesloten, of als de inhoud abstract is.
• Als er geen zegel is aangebracht op het contractvoorstel, wordt het afdrukken van het zegel beschouwd als het sluiten van het contract, en is het moeilijk om de totstandkoming van het contract te erkennen.
• Een offerte dient als bewijs voor het vaststellen van het vergoedingsbedrag dat tussen de partijen is overeengekomen.

Overigens, in systeemontwikkeling, als het proces tot op zekere hoogte is gevorderd en er wordt gevraagd om specificatiewijzigingen of toevoeging van functies achteraf, zijn er gedetailleerde uitleg over of het mogelijk is om extra kosten bovenop de oorspronkelijke schatting in rekening te brengen, enz. in het volgende artikel.

https://monolith.law/corporate/increase-of-estimate[ja]

Afrekenovereenkomst

Als er werkzaamheden worden uitgevoerd op instructie van de gebruiker met het vooruitzicht op het sluiten van een contract, kan het zijn dat een ‘afrekenovereenkomst’ wordt toegestaan, waarbij de vergoeding voor het tot dan toe uitgevoerde werk wordt afgerekend bij stopzetting van het werk. Om deze overeenkomst gemakkelijker te laten accepteren, is het raadzaam om de gebruiker te vragen de methode voor het afrekenen van de vergoeding in het geval dat er geen contract wordt gesloten, op te nemen in een schriftelijke kennisgeving of iets dergelijks, of om de goedkeuring te verkrijgen van een bevoegde persoon van de gebruiker voor een document dat door de leverancier is opgesteld.

De juridische structuur voor het vorderen van geld in het geval dat een contract niet wordt erkend

Nalatigheid bij het sluiten van een contract

Wanneer onderhandelingen voor het sluiten van een contract beginnen, hebben de partijen de plicht om te proberen elkaars eigendom niet te schaden volgens de regel van goede trouw (Artikel 1, lid 2, van het Japanse Burgerlijk Wetboek). Als een contract niet tot stand komt, kan de andere partij schadevergoeding eisen als er objectieve omstandigheden zijn die de verwachting wekken dat het contract zeker zal worden gesloten en er sprake is van nalatigheid. Dit wordt nalatigheid bij het sluiten van een contract genoemd.

Hieronder volgen enkele voorbeelden van gevallen waarin nalatigheid bij het sluiten van een contract werd erkend door de rechtbank.

• De leverancier had op verzoek van de gebruiker de definitie van de vereisten voltooid en had ook een deel van het basisontwerp en het gedetailleerde ontwerp uitgevoerd. De gebruiker had uitgelegd dat het uitnodigen van andere bedrijven om een offerte uit te brengen een formele handeling was om goedkeuring van de directeur te krijgen, maar vlak voor het sluiten van het contract werd een ander bedrijf gekozen en werd het contract niet gesloten.
• De leverancier had op verzoek van de gebruiker de werkzaamheden voortgezet om de leveringsdatum te halen, en de geplande datum voor het sluiten van het contract was ook bijna vastgesteld. Binnen het gebruikersbedrijf werden echter voorbereidingen getroffen voor eigen ontwikkeling, maar dit werd verborgen gehouden en het contract werd niet gesloten.
• De leverancier was door de gebruiker op de hoogte gesteld dat hij was gekozen als de bouwer, en er waren geen vragen of opmerkingen over de offerte. Op basis van overleg met de gebruiker voerde de leverancier werkzaamheden uit zoals het bevestigen van specificaties, en de gebruiker was zich bewust van de uitgaven. Echter, het contract werd geweigerd omdat er geen overeenstemming kon worden bereikt over het offertebedrag.

Aan de andere kant, er zijn gevallen waarin nalatigheid bij het sluiten van een contract niet werd erkend, zoals wanneer de mogelijkheid van het kiezen van een ander bedrijf of de voorwaarden voor het sluiten van een contract duidelijk waren aangegeven.

Als de gebruiker verzoekt om de werkzaamheden voort te zetten en het contractonderhandelingen plotseling worden afgebroken zonder duidelijke indicatie van de mogelijkheid dat een ander bedrijf wordt gekozen of de voorwaarden voor overeenstemming, kan schadevergoeding worden toegekend.

Er is geen geschil over het feit dat de kosten die tot dan toe zijn gemaakt, inbegrepen zijn in het bereik van de “schade”. Daarnaast zijn er gevallen waarin de winst van het daadwerkelijk uitgevoerde werk is inbegrepen. Bovendien, als u bewijs kunt leveren dat u winst zou hebben gemaakt door het werk voort te zetten nadat u een aanbod van een ander bedrijf had afgewezen, kan dat ook worden opgenomen.

Artikel 512 van het Japanse Handelswetboek

Als de leverancier handelingen heeft verricht met betrekking tot systeemontwikkeling voor de gebruiker, kan hij op basis van artikel 512 van het Japanse Handelswetboek een redelijke vergoeding vorderen.

Als u begint te onderhandelen over systeemontwikkeling, is het een goed idee om de inhoud van het systeem en het bedrag van de vergoeding te erkennen met behulp van e-mails en notulen, en om bewijs te verzamelen dat de omstandigheden die doen vermoeden dat het contract zeker zal worden gesloten en de elementen van het contract zijn geconcretiseerd.

Zelfs als u wordt geweigerd betaling om redenen zoals het feit dat u geen contract heeft ondertekend, kan het zoals hierboven vermeld mogelijk zijn om geld te vorderen.

Samenvatting

Zoals we hebben gezien, is het veilig om te zeggen dat rechtbanken de neiging hebben om een ‘negatief’ oordeel te vellen over contractuele relaties waarvoor geen contract bestaat, vooral in vergelijking met de perceptie van het bedrijf aan de ontvangende kant. Vanuit het perspectief van het ontvangende bedrijf zou men willen beweren dat “het contract al is gesloten, omdat het de bedoeling was dat we eerst zouden beginnen met werken en het contract later zouden sluiten”, maar deze bewering wordt niet altijd erkend.

Bovendien, als de totstandkoming van een contract wordt ontkend, zijn er gevallen waarin men geld kan vorderen op basis van juridische structuren zoals nalatigheid bij het sluiten van een contract of de Japanse Handelswet artikel 512, maar dit is zeker geen ‘zekere’ zaak.

Als het noodzakelijk is om te beginnen met werken voordat een contract is gesloten, moet men:

• Overwegen of het de moeite waard is om tijd te besteden aan het project, ondanks de risico’s die aan deze actie verbonden zijn (vooral voor kleine en middelgrote bedrijven en startups, er kunnen situaties zijn waarin men geen andere keuze heeft dan ‘eerst te handelen’ om handelservaring op te doen met grote bedrijven. Dit kan een haalbare zakelijke beslissing zijn, mits de risico’s in overweging zijn genomen.)
• Overwegen of het mogelijk is om een afwikkelingsovereenkomst of iets dergelijks te sluiten voor het geval een contract niet tot stand komt

Men kan zeggen dat het noodzakelijk is om deze overwegingen te maken.