{"id":61279,"date":"2023-12-08T20:54:57","date_gmt":"2023-12-08T11:54:57","guid":{"rendered":"https:\/\/monolith.law\/no\/?p=61279"},"modified":"2025-12-17T13:30:52","modified_gmt":"2025-12-17T04:30:52","slug":"system-development-contract","status":"publish","type":"post","link":"https:\/\/monolith.law\/no\/it\/system-development-contract","title":{"rendered":"Kan en systemutviklingskontrakt etableres uten en kontrakt?"},"content":{"rendered":"\n<p>I systemutvikling er det ikke uvanlig at utvikleren g\u00e5r i gang med arbeidet f\u00f8r en kontrakt er utformet. Imidlertid er denne fremgangsm\u00e5ten i praksis &#8220;farlig&#8221;. Hvis en kontrakt ikke er utformet, er det en risiko for at bestilleren senere kan hevde at &#8220;kontrakten er enn\u00e5 ikke inng\u00e5tt, og derfor er det ikke n\u00f8dvendig \u00e5 betale honoraret&#8221; hvis det oppst\u00e5r problemer. I faktiske tvister knyttet til systemutvikling, er det ikke uvanlig at selve kontraktsinng\u00e5elsen blir bestridt, og at det blir tatt avgj\u00f8relser som er ugunstige for utvikleren. Som utvikler er det en risiko for at du ikke vil motta betaling hvis bestilleren avbryter prosjektet eller bytter til en annen leverand\u00f8r. Som nevnt senere, er det ogs\u00e5 tilfeller der kontraktsinng\u00e5elsen blir nektet selv om en kontrakt er utformet.<\/p>\n\n\n\n<p>Her vil jeg forklare om suksess eller fiasko i systemutviklingskontrakter, og den juridiske strukturen for \u00e5 kreve penger hvis kontraktsinng\u00e5elsen ikke blir anerkjent.<\/p>\n\n\n\n<div id=\"ez-toc-container\" class=\"ez-toc-v2_0_53 counter-hierarchy ez-toc-counter ez-toc-grey ez-toc-container-direction\">\n<div class=\"ez-toc-title-container\">\n<span class=\"ez-toc-title-toggle\"><\/span><\/div>\n<nav><ul class='ez-toc-list ez-toc-list-level-1 ' ><li class='ez-toc-page-1 ez-toc-heading-level-2'><a class=\"ez-toc-link ez-toc-heading-1\" href=\"https:\/\/monolith.law\/no\/it\/system-development-contract\/#Inngaelse_av_kontrakt\" title=\"Inng\u00e5else av kontrakt\">Inng\u00e5else av kontrakt<\/a><ul class='ez-toc-list-level-3'><li class='ez-toc-heading-level-3'><a class=\"ez-toc-link ez-toc-heading-2\" href=\"https:\/\/monolith.law\/no\/it\/system-development-contract\/#Inngaelse_av_systemutviklingskontrakt\" title=\"Inng\u00e5else av systemutviklingskontrakt\">Inng\u00e5else av systemutviklingskontrakt<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-3'><a class=\"ez-toc-link ez-toc-heading-3\" href=\"https:\/\/monolith.law\/no\/it\/system-development-contract\/#Krav_om_betaling_ved_avbestilling_etter_inngaelse_av_systemutviklingskontrakt\" title=\"Krav om betaling ved avbestilling etter inng\u00e5else av systemutviklingskontrakt\">Krav om betaling ved avbestilling etter inng\u00e5else av systemutviklingskontrakt<\/a><\/li><\/ul><\/li><li class='ez-toc-page-1 ez-toc-heading-level-2'><a class=\"ez-toc-link ez-toc-heading-4\" href=\"https:\/\/monolith.law\/no\/it\/system-development-contract\/#Suksess_eller_fiasko_i_systemutviklingskontrakter\" title=\" Suksess eller fiasko i systemutviklingskontrakter \"> Suksess eller fiasko i systemutviklingskontrakter <\/a><ul class='ez-toc-list-level-3'><li class='ez-toc-heading-level-3'><a class=\"ez-toc-link ez-toc-heading-5\" href=\"https:\/\/monolith.law\/no\/it\/system-development-contract\/#Spesifisitet_av_systeminnhold\" title=\"Spesifisitet av systeminnhold \">Spesifisitet av systeminnhold <\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-3'><a class=\"ez-toc-link ez-toc-heading-6\" href=\"https:\/\/monolith.law\/no\/it\/system-development-contract\/#Leverandoren_presenterer_estimater_og_spesifikasjoner_og_brukeren_godkjenner_og_bestiller\" title=\"Leverand\u00f8ren presenterer estimater og spesifikasjoner, og brukeren godkjenner og bestiller\">Leverand\u00f8ren presenterer estimater og spesifikasjoner, og brukeren godkjenner og bestiller<\/a><ul class='ez-toc-list-level-4'><li class='ez-toc-heading-level-4'><a class=\"ez-toc-link ez-toc-heading-7\" href=\"https:\/\/monolith.law\/no\/it\/system-development-contract\/#Etter_forhandlinger_om_spesifikasjonsbekreftelse_mellom_leverandoren_og_brukeren\" title=\"Etter forhandlinger om spesifikasjonsbekreftelse mellom leverand\u00f8ren og brukeren\">Etter forhandlinger om spesifikasjonsbekreftelse mellom leverand\u00f8ren og brukeren<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-4'><a class=\"ez-toc-link ez-toc-heading-8\" href=\"https:\/\/monolith.law\/no\/it\/system-development-contract\/#Leverandoren_presenterer_spesifikasjoner_og_estimater_og_brukeren_godkjenner_og_bestiller\" title=\"Leverand\u00f8ren presenterer spesifikasjoner og estimater, og brukeren godkjenner og bestiller\">Leverand\u00f8ren presenterer spesifikasjoner og estimater, og brukeren godkjenner og bestiller<\/a><\/li><\/ul><\/li><li class='ez-toc-page-1 ez-toc-heading-level-3'><a class=\"ez-toc-link ez-toc-heading-9\" href=\"https:\/\/monolith.law\/no\/it\/system-development-contract\/#Oppgjorsavtale\" title=\"Oppgj\u00f8rsavtale\">Oppgj\u00f8rsavtale<\/a><\/li><\/ul><\/li><li class='ez-toc-page-1 ez-toc-heading-level-2'><a class=\"ez-toc-link ez-toc-heading-10\" href=\"https:\/\/monolith.law\/no\/it\/system-development-contract\/#Den_juridiske_strukturen_for_a_kreve_penger_nar_en_kontrakt_ikke_er_anerkjent\" title=\"Den juridiske strukturen for \u00e5 kreve penger n\u00e5r en kontrakt ikke er anerkjent\">Den juridiske strukturen for \u00e5 kreve penger n\u00e5r en kontrakt ikke er anerkjent<\/a><ul class='ez-toc-list-level-3'><li class='ez-toc-heading-level-3'><a class=\"ez-toc-link ez-toc-heading-11\" href=\"https:\/\/monolith.law\/no\/it\/system-development-contract\/#Uaktsomhet_ved_inngaelse_av_kontrakt\" title=\"Uaktsomhet ved inng\u00e5else av kontrakt\">Uaktsomhet ved inng\u00e5else av kontrakt<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-3'><a class=\"ez-toc-link ez-toc-heading-12\" href=\"https:\/\/monolith.law\/no\/it\/system-development-contract\/#Artikkel_512_i_den_japanske_handelsloven\" title=\"Artikkel 512 i den japanske handelsloven\">Artikkel 512 i den japanske handelsloven<\/a><\/li><\/ul><\/li><li class='ez-toc-page-1 ez-toc-heading-level-2'><a class=\"ez-toc-link ez-toc-heading-13\" href=\"https:\/\/monolith.law\/no\/it\/system-development-contract\/#Oppsummering\" title=\"Oppsummering\">Oppsummering<\/a><\/li><\/ul><\/nav><\/div>\n<h2 class=\"wp-block-heading\"><span class=\"ez-toc-section\" id=\"Inngaelse_av_kontrakt\"><\/span>Inng\u00e5else av kontrakt<span class=\"ez-toc-section-end\"><\/span><\/h2>\n\n\n\n<p>En kontrakt blir i prinsippet inng\u00e5tt n\u00e5r begge parter er enige om kontraktens elementer (samsvar mellom tilbud og aksept). <\/p>\n\n\n\n<p>N\u00e5r en kontrakt er inng\u00e5tt, er begge parter bundet av den. Hvis den ene parten ikke oppfyller kontraktens innhold, kan den andre parten tvinge gjennom oppfyllelse ved hjelp av rettslige skritt, eller kreve erstatning for manglende oppfyllelse. &#8220;Kontraktens elementer&#8221; m\u00e5 v\u00e6re spesifisert eller konkret nok til \u00e5 kunne tvinge gjennom oppfyllelse og fastsl\u00e5 manglende oppfyllelse. <\/p>\n\n\n\n<figure class=\"wp-block-image size-full is-resized\"><img decoding=\"async\" loading=\"lazy\" width=\"735\" height=\"490\" src=\"https:\/\/monolith.law\/no\/wp-content\/uploads\/sites\/27\/2025\/12\/system-development-contract-2.jpg\" alt=\"\" class=\"wp-image-75505\" style=\"aspect-ratio:1.5;width:840px;height:auto\" srcset=\"https:\/\/monolith.law\/no\/wp-content\/uploads\/sites\/27\/2025\/12\/system-development-contract-2.jpg 735w, https:\/\/monolith.law\/no\/wp-content\/uploads\/sites\/27\/2025\/12\/system-development-contract-2-300x200.jpg 300w, https:\/\/monolith.law\/no\/wp-content\/uploads\/sites\/27\/2025\/12\/system-development-contract-2-250x167.jpg 250w\" sizes=\"(max-width: 735px) 100vw, 735px\" \/><figcaption class=\"wp-element-caption\">Inng\u00e5else av kontrakt er et sv\u00e6rt viktig sp\u00f8rsm\u00e5l<\/figcaption><\/figure>\n\n\n\n<h3 class=\"wp-block-heading\"><span class=\"ez-toc-section\" id=\"Inngaelse_av_systemutviklingskontrakt\"><\/span>Inng\u00e5else av systemutviklingskontrakt<span class=\"ez-toc-section-end\"><\/span><\/h3>\n\n\n\n<p>En systemutviklingskontrakt er hovedsakelig en kontrakt for arbeid og en quasi-mandatkontrakt. En kontrakt for arbeid er en avtale om \u00e5 fullf\u00f8re et arbeid og betale for det. En betalt quasi-mandatkontrakt er en avtale om \u00e5 utf\u00f8re en oppgave og betale for det.<\/p>\n\n\n\n<p><a href=\"https:\/\/monolith.law\/corporate\/contract-and-timeandmaterialcontract\" target=\"_blank\" rel=\"noreferrer noopener\">https:\/\/monolith.law\/corporate\/contract-and-timeandmaterialcontract[ja]<\/a><\/p>\n\n\n\n<p>Derfor, hvis det er enighet mellom partene om kontraktens elementer, &#8220;innholdet i arbeidet eller oppgaven&#8221; og &#8220;betalingen&#8221;, vil kontrakten bli ansett som inng\u00e5tt.<\/p>\n\n\n\n<p>Det skal bemerkes at en kontrakt kan inng\u00e5s med bare muntlige l\u00f8fter, og det er ikke n\u00f8dvendig med en skriftlig kontrakt.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\"><span class=\"ez-toc-section\" id=\"Krav_om_betaling_ved_avbestilling_etter_inngaelse_av_systemutviklingskontrakt\"><\/span>Krav om betaling ved avbestilling etter inng\u00e5else av systemutviklingskontrakt<span class=\"ez-toc-section-end\"><\/span><\/h3>\n\n\n\n<p>Hvis en systemutviklingskontrakt er inng\u00e5tt og brukeren ensidig avbryter den, vil det juridisk sett bli ansett som en oppsigelse av kontrakten.<\/p>\n\n\n\n<p>Hvis en kontrakt for arbeid er inng\u00e5tt, kan leverand\u00f8ren bli oppsagt av brukeren n\u00e5r som helst f\u00f8r arbeidet er fullf\u00f8rt, men det er fastsatt at leverand\u00f8ren har rett til erstatning (Japansk sivillov \u00a7 641). Derfor, hvis brukeren ikke betaler erstatning, kan leverand\u00f8ren kreve erstatning for &#8220;skade&#8221;, som er bel\u00f8pet som leverand\u00f8ren har brukt og den betalingen de kunne ha mottatt, minus kostnadene som ble spart ved \u00e5 unng\u00e5 \u00e5 fullf\u00f8re systemet.<\/p>\n\n\n\n<p>Hvis en quasi-mandatkontrakt er inng\u00e5tt, kan mottakeren kreve betaling basert p\u00e5 andelen av oppdraget som er utf\u00f8rt n\u00e5r oppdraget avsluttes midt i utf\u00f8relsen (revidert Japansk sivillov \u00a7 648, paragraf 3). Derfor kan leverand\u00f8ren kreve betaling for arbeidet som allerede er utf\u00f8rt.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\"><span class=\"ez-toc-section\" id=\"Suksess_eller_fiasko_i_systemutviklingskontrakter\"><\/span> Suksess eller fiasko i systemutviklingskontrakter <span class=\"ez-toc-section-end\"><\/span><\/h2>\n\n\n\n<h3 class=\"wp-block-heading\"><span class=\"ez-toc-section\" id=\"Spesifisitet_av_systeminnhold\"><\/span>Spesifisitet av systeminnhold <span class=\"ez-toc-section-end\"><\/span><\/h3>\n\n\n\n<p>Vanligvis, i transaksjoner mellom selskaper, spesielt kontrakter med store bel\u00f8p, blir skriftlige dokumenter brukt. Derfor, hvis en kontrakt er opprettet, er det lett \u00e5 anerkjenne etableringen av kontrakten.<\/p>\n\n\n\n<p>Systemet som er under utvikling blir gradvis konkretisert gjennom forskjellige prosesser. Derfor er det forst\u00e5tt at spesifisiteten av systeminnholdet, som er &#8220;innholdet i arbeidet&#8221; i en kontraktskontrakt, er tilstrekkelig spesifikt til \u00e5 forst\u00e5 omfanget og oversikten over det systemet som skal systematiseres.<\/p>\n\n\n\n<p>I rettspraksis, det var ingen tvist om inng\u00e5elsen av grunnkontrakten og konfidensialitetsavtalen. Selv om det var en beskrivelse i den grunnleggende kontrakten om \u00e5 &#8220;delegere e-handelsvirksomhetsteknisk st\u00f8tte, WEB-sidekonstruksjonsst\u00f8tte og relaterte tjenester&#8221;, ble etableringen av kontrakten nektet i en sak der det spesifikke innholdet i e-handelsvirksomheten, omfanget av delegerte tjenester, og omfanget av systemutvikling og design ikke var klart angitt.<\/p>\n\n\n\n<p>Selv om du har opprettet en grunnleggende systemutviklingskontrakt, vil det v\u00e6re vanskelig \u00e5 anerkjenne etableringen av kontrakten hvis jobb- eller arbeidsinnholdet er abstrakt og ikke spesifikt. Etableringen av en kontrakt kan anerkjennes ved hjelp av kontrakter og lignende som beskriver jobb- eller arbeidsinnhold og bel\u00f8p for kompensasjon i detalj, til det punktet at de kan tvinge utf\u00f8relse og bekrefte mislighold.<\/p>\n\n\n\n<p>For \u00f8vrig forklarer vi i detalj om ting \u00e5 v\u00e6re oppmerksom p\u00e5 i kontrakter mellom individuelle ingeni\u00f8rer og selskaper i artikkelen nedenfor.<\/p>\n\n\n\n<p><a href=\"https:\/\/monolith.law\/corporate\/engineer-joint-enterprise-contract\" target=\"_blank\" rel=\"noreferrer noopener\">https:\/\/monolith.law\/corporate\/engineer-joint-enterprise-contract[ja]<\/a><\/p>\n\n\n\n<h3 class=\"wp-block-heading\"><span class=\"ez-toc-section\" id=\"Leverandoren_presenterer_estimater_og_spesifikasjoner_og_brukeren_godkjenner_og_bestiller\"><\/span>Leverand\u00f8ren presenterer estimater og spesifikasjoner, og brukeren godkjenner og bestiller<span class=\"ez-toc-section-end\"><\/span><\/h3>\n\n\n\n<p>Vanligvis, i bedriftstransaksjoner, blir skriftlige dokumenter brukt, s\u00e5 hvis en kontrakt ikke er opprettet, blir det vanskelig \u00e5 anerkjenne etableringen av en kontrakt. I systemutvikling er det ofte tilfelle at arbeidet begynner f\u00f8r en kontrakt er opprettet, men hvordan tenker man p\u00e5 suksessen eller fiaskoen i kontrakten i slike tilfeller?<\/p>\n\n\n\n<p>I en rettsavgj\u00f8relse (Nagoya District Court, 28. januar 2004 (Heisei 16)) om etableringen av en systemutviklingskontrakt, er det uttalt som f\u00f8lger:<\/p>\n\n\n\n<ul>\n<li> Etter forhandlinger om spesifikasjonsbekreftelse mellom leverand\u00f8ren og brukeren, <\/li>\n\n\n\n<li> Leverand\u00f8ren presenterer spesifikasjoner og estimater, <\/li>\n\n\n\n<li> Dette blir godkjent og bestilt av brukeren, og kontrakten er etablert. <\/li>\n<\/ul>\n\n\n\n<p>I denne rettsavgj\u00f8relsen hadde leverand\u00f8ren blitt betrodd av brukeren, en lokal myndighet, for \u00e5 innf\u00f8re et finansielt regnskapssystem, og et RFP med tittelen &#8220;Foresp\u00f8rsel om forslag til innf\u00f8ring av et generelt administrativt informasjonssystem&#8221; ble presentert. Leverand\u00f8ren presenterte et forslag og et estimat i samsvar med dette, og en &#8220;adopsjonsmelding&#8221; ble levert fra brukeren. Leverand\u00f8ren hadde ikke grundig vurdert brukerens forretningsinnhold osv. ved \u00e5 m\u00f8te brukeren, og det ble ikke anerkjent at innholdet og kostnadene for tilpasningen ble konkret vurdert internt av brukeren. Innholdet i leverand\u00f8rens forslag var ikke konkret, det var ikke klart hva brukeren hadde godkjent, og etableringen av kontrakten ble ikke anerkjent.<\/p>\n\n\n\n<p>Jeg vil gi en tilleggsforklaring p\u00e5 kontraktsdannelsen som er nevnt i rettsavgj\u00f8relsen, med tanke p\u00e5 andre rettsavgj\u00f8relser osv.<\/p>\n\n\n\n<h4 class=\"wp-block-heading\"><span class=\"ez-toc-section\" id=\"Etter_forhandlinger_om_spesifikasjonsbekreftelse_mellom_leverandoren_og_brukeren\"><\/span>Etter forhandlinger om spesifikasjonsbekreftelse mellom leverand\u00f8ren og brukeren<span class=\"ez-toc-section-end\"><\/span><\/h4>\n\n\n\n<p>Ut fra det faktum at det er &#8220;etter forhandlinger&#8221;, hvis du er &#8220;i forhandlinger&#8221; om kontraktselementer som systeminnhold og kompensasjonsbel\u00f8p, vil det v\u00e6re vanskelig \u00e5 anerkjenne etableringen av en kontrakt fordi du ikke har n\u00e5dd enighet.<\/p>\n\n\n\n<p>Imidlertid, i en kontrakt, kan du ogs\u00e5 bestemme kompensasjonen til markedsprisen, s\u00e5 det er rettsavgj\u00f8relser som har anerkjent at en kontrakt er etablert med markedsprisen som kompensasjon, fra det faktum at brukeren har godkjent systeminnholdet og &#8220;omtrent&#8221; kompensasjonsbel\u00f8pet.<\/p>\n\n\n\n<p>For at leverand\u00f8ren skal kunne si at de &#8220;har forhandlet&#8221;, b\u00f8r de registrere det faktum at de har grundig vurdert brukerens forretningsinnhold, systeminnhold osv. ved \u00e5 m\u00f8te brukeren, i e-poster, m\u00f8tereferater osv.<\/p>\n\n\n\n<h4 class=\"wp-block-heading\"><span class=\"ez-toc-section\" id=\"Leverandoren_presenterer_spesifikasjoner_og_estimater_og_brukeren_godkjenner_og_bestiller\"><\/span>Leverand\u00f8ren presenterer spesifikasjoner og estimater, og brukeren godkjenner og bestiller<span class=\"ez-toc-section-end\"><\/span><\/h4>\n\n\n\n<ul>\n<li> Hvis brukeren utsteder en bestillingsordre eller bestillingsformular, vil det v\u00e6re lettere \u00e5 anerkjenne etableringen av en kontrakt. Hvis leverand\u00f8ren sender inn en foresp\u00f8rsel eller utf\u00f8rer arbeid basert p\u00e5 en bestillingsordre, vil det v\u00e6re lettere \u00e5 anerkjenne at det er enighet, og det vil v\u00e6re lettere \u00e5 anerkjenne etableringen av en kontrakt. <\/li>\n\n\n\n<li> Brukerens interne dokumenter er ofte innholdet i fremtidige kontrakter, og det er vanskelig \u00e5 anerkjenne etableringen av en kontrakt. Imidlertid, hvis det ikke er en slik beskrivelse, og kontraktselementene, som innholdet i systemutviklingen og kompensasjonsbel\u00f8pet, er beskrevet s\u00e5 konkret som mulig, vil det bidra til \u00e5 anerkjenne etableringen av en kontrakt. <\/li>\n\n\n\n<li> Det er vanskelig \u00e5 anerkjenne etableringen av en kontrakt hvis en memo, avtale, bekreftelsesbrev osv. er forutsetningen for \u00e5 inng\u00e5 en separat kontrakt, eller hvis innholdet er abstrakt. <\/li>\n\n\n\n<li> Hvis kontraktutkastet ikke er stemplet, er det vanskelig \u00e5 anerkjenne etableringen av en kontrakt fordi stemplingen betyr konklusjon. <\/li>\n\n\n\n<li> Et estimat er bevis for \u00e5 bekrefte kompensasjonsbel\u00f8pet som er avtalt mellom partene. <\/li>\n<\/ul>\n\n\n\n<p>Forresten, i systemutvikling, n\u00e5r prosessen har g\u00e5tt til en viss grad, er det en detaljert forklaring i f\u00f8lgende artikkel om hvorvidt det er mulig \u00e5 kreve en \u00f8kning i det opprinnelige estimatbel\u00f8pet i tilfelle av en etterf\u00f8lgende spesifikasjonsendring eller en foresp\u00f8rsel om \u00e5 legge til funksjoner.<\/p>\n\n\n\n<p><a href=\"https:\/\/monolith.law\/corporate\/increase-of-estimate\" target=\"_blank\" rel=\"noreferrer noopener\">https:\/\/monolith.law\/corporate\/increase-of-estimate[ja]<\/a><\/p>\n\n\n\n<h3 class=\"wp-block-heading\"><span class=\"ez-toc-section\" id=\"Oppgjorsavtale\"><\/span>Oppgj\u00f8rsavtale<span class=\"ez-toc-section-end\"><\/span><\/h3>\n\n\n\n<p>Hvis arbeidet utf\u00f8res basert p\u00e5 instruksjoner fra brukeren med forutsetning om \u00e5 inng\u00e5 en kontrakt, kan det v\u00e6re tillatt med en &#8220;oppgj\u00f8rsavtale&#8221; som avregner betaling for arbeidet utf\u00f8rt til det tidspunktet arbeidet stoppes. For \u00e5 gj\u00f8re det lettere \u00e5 godta denne avtalen, kan det v\u00e6re lurt \u00e5 f\u00e5 brukeren til \u00e5 skrive ned metoden for \u00e5 avregne betaling i tilfelle kontrakten ikke blir inng\u00e5tt, i et internt notat eller lignende dokument, eller \u00e5 f\u00e5 godkjennelse fra en autorisert person hos brukeren for et dokument som leverand\u00f8ren har opprettet.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\"><span class=\"ez-toc-section\" id=\"Den_juridiske_strukturen_for_a_kreve_penger_nar_en_kontrakt_ikke_er_anerkjent\"><\/span>Den juridiske strukturen for \u00e5 kreve penger n\u00e5r en kontrakt ikke er anerkjent<span class=\"ez-toc-section-end\"><\/span><\/h2>\n\n\n\n<figure class=\"wp-block-image size-full is-resized\"><img decoding=\"async\" loading=\"lazy\" width=\"735\" height=\"490\" src=\"https:\/\/monolith.law\/no\/wp-content\/uploads\/sites\/27\/2025\/12\/system-development-contract-3.jpg\" alt=\"\" class=\"wp-image-75506\" style=\"aspect-ratio:1.5;width:840px;height:auto\" srcset=\"https:\/\/monolith.law\/no\/wp-content\/uploads\/sites\/27\/2025\/12\/system-development-contract-3.jpg 735w, https:\/\/monolith.law\/no\/wp-content\/uploads\/sites\/27\/2025\/12\/system-development-contract-3-300x200.jpg 300w, https:\/\/monolith.law\/no\/wp-content\/uploads\/sites\/27\/2025\/12\/system-development-contract-3-250x167.jpg 250w\" sizes=\"(max-width: 735px) 100vw, 735px\" \/><figcaption class=\"wp-element-caption\">Hva skjer hvis en kontrakt ikke blir anerkjent?<\/figcaption><\/figure>\n\n\n\n<h3 class=\"wp-block-heading\"><span class=\"ez-toc-section\" id=\"Uaktsomhet_ved_inngaelse_av_kontrakt\"><\/span>Uaktsomhet ved inng\u00e5else av kontrakt<span class=\"ez-toc-section-end\"><\/span><\/h3>\n\n\n\n<p>N\u00e5r forhandlinger om \u00e5 inng\u00e5 en kontrakt starter, har partene en gjensidig forpliktelse til \u00e5 unng\u00e5 \u00e5 skade den andres eiendom i henhold til prinsippet om god tro (Artikkel 1, paragraf 2 i den japanske sivile lovboken). Hvis en kontrakt ikke blir inng\u00e5tt, kan du kreve erstatning for skade hvis det er objektive omstendigheter og skyld som har gitt den andre parten forventning om at kontrakten ville bli inng\u00e5tt. Dette kalles uaktsomhet ved inng\u00e5else av kontrakt.<\/p>\n\n\n\n<p>Her er noen eksempler fra rettspraksis der uaktsomhet ved inng\u00e5else av kontrakt ble anerkjent:<\/p>\n\n\n\n<ul>\n<li>En leverand\u00f8r hadde fullf\u00f8rt kravspesifikasjonen p\u00e5 foresp\u00f8rsel fra en bruker og hadde ogs\u00e5 utf\u00f8rt deler av grunnleggende og detaljert design. Brukeren forklarte at handlingen med \u00e5 invitere andre selskaper til \u00e5 by var en formell handling for \u00e5 f\u00e5 godkjenning fra presidenten, men rett f\u00f8r kontrakten skulle inng\u00e5s, ble et annet selskap valgt, og kontrakten ble ikke inng\u00e5tt.<\/li>\n\n\n\n<li>En leverand\u00f8r hadde g\u00e5tt frem med arbeidet etter \u00e5 ha blitt bedt av brukeren om \u00e5 overholde leveringstiden, og datoen for kontraktsinng\u00e5elsen var ogs\u00e5 fastsatt. Imidlertid ble det gjort forberedelser for egenutvikling innad i brukerens selskap, noe som ble holdt hemmelig, og kontrakten ble ikke inng\u00e5tt.<\/li>\n\n\n\n<li>En leverand\u00f8r ble informert av brukeren om at de hadde blitt valgt som systembygger, og det var ingen sp\u00f8rsm\u00e5l om tilbudet. Basert p\u00e5 m\u00f8ter med brukeren, utf\u00f8rte leverand\u00f8ren arbeid som \u00e5 bekrefte spesifikasjonene, og brukeren var klar over utgiftene. Imidlertid ble kontrakten avvist p\u00e5 grunn av at de ikke kunne bli enige om tilbudsprisen.<\/li>\n<\/ul>\n\n\n\n<p>Derimot, i tilfeller der uaktsomhet ved inng\u00e5else av kontrakt ikke ble anerkjent, var det tilfeller der muligheten for \u00e5 velge et annet selskap eller betingelsene for \u00e5 inng\u00e5 en kontrakt var tydelig angitt.<\/p>\n\n\n\n<p>Hvis du har g\u00e5tt frem med arbeidet i henhold til brukerens foresp\u00f8rsel, og kontraktsforhandlingene blir brutt uten forvarsel fordi det ikke ble gitt noen indikasjon p\u00e5 muligheten for \u00e5 velge et annet selskap eller avtalebetingelsene, kan du ha rett til \u00e5 kreve erstatning for skade.<\/p>\n\n\n\n<p>Det er ingen tvil om at utgiftene som er p\u00e5l\u00f8pt til n\u00e5, er inkludert i &#8220;skaden&#8221; i dette tilfellet. I tillegg er det rettsavgj\u00f8relser som inkluderer fortjenesten fra det faktiske arbeidet som er utf\u00f8rt. Hvis du kan bevise at du har lidd skade tilsvarende fortjenesten du kunne ha tjent hvis du hadde fortsatt \u00e5 jobbe etter \u00e5 ha avvist en s\u00f8knad fra et annet selskap, kan det ogs\u00e5 v\u00e6re inkludert.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\"><span class=\"ez-toc-section\" id=\"Artikkel_512_i_den_japanske_handelsloven\"><\/span>Artikkel 512 i den japanske handelsloven<span class=\"ez-toc-section-end\"><\/span><\/h3>\n\n\n\n<p>Hvis en leverand\u00f8r har utf\u00f8rt handlinger relatert til systemutvikling for en bruker, kan de kreve en rimelig betaling i henhold til Artikkel 512 i den japanske handelsloven.<\/p>\n\n\n\n<p>N\u00e5r du starter forhandlinger om systemutvikling, er det en god id\u00e9 \u00e5 s\u00f8rge for at begge parter forst\u00e5r systeminnholdet og betalingsbel\u00f8pet ved hjelp av e-post eller m\u00f8tereferater, og \u00e5 bevare bevis som bekrefter at kontrakten var sikker p\u00e5 \u00e5 bli inng\u00e5tt og at elementene i kontrakten var konkretisert.<\/p>\n\n\n\n<p>Faktisk, selv om du blir nektet betaling p\u00e5 grunn av at du ikke har inng\u00e5tt en kontrakt, kan du som nevnt ovenfor ha rett til \u00e5 kreve penger.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\"><span class=\"ez-toc-section\" id=\"Oppsummering\"><\/span>Oppsummering<span class=\"ez-toc-section-end\"><\/span><\/h2>\n\n\n\n<p>Som vi har sett, er det vanlig at domstolene har en &#8220;negativ&#8221; holdning til kontraktsforhold der det ikke finnes en skriftlig kontrakt, spesielt sammenlignet med hvordan det oppfattes av selskapet som har p\u00e5tatt seg oppdraget. Fra selskapets perspektiv, vil de gjerne hevde at &#8220;vi begynte \u00e5 jobbe f\u00f8rst, og kontrakten skulle bli inng\u00e5tt i etterkant, s\u00e5 kontrakten er faktisk gyldig&#8221;. Men denne p\u00e5standen blir ikke alltid akseptert.<\/p>\n\n\n\n<p>I tillegg, hvis kontrakten blir avvist, er det tilfeller der du kan kreve penger basert p\u00e5 juridiske strukturer som kontraktsbrudd eller den japanske handelsloven (Japanese Commercial Code) artikkel 512, men dette er heller ikke en &#8220;sikker&#8221; sak.<\/p>\n\n\n\n<p>Hvis du m\u00e5 starte arbeidet f\u00f8r kontrakten er inng\u00e5tt, b\u00f8r du:<\/p>\n\n\n\n<ul>\n<li>Vurdere om det er verdt \u00e5 bruke tid p\u00e5 prosjektet, tatt i betraktning risikoen det inneb\u00e6rer. Dette er spesielt relevant for sm\u00e5 og mellomstore bedrifter eller oppstartsselskaper. Hvis de tar p\u00e5 seg et prosjekt fra et stort selskap, kan de f\u00f8le seg tvunget til \u00e5 &#8220;handle f\u00f8rst&#8221; for \u00e5 f\u00e5 handelserfaring med det store selskapet. Dette kan v\u00e6re en akseptabel forretningsbeslutning, s\u00e5 lenge risikoen er tatt i betraktning.<\/li>\n\n\n\n<li>Vurdere om det er mulig \u00e5 inng\u00e5 en avtale om oppgj\u00f8r, i tilfelle kontrakten ikke blir inng\u00e5tt.<\/li>\n<\/ul>\n\n\n\n<p>Det kan sies at det er n\u00f8dvendig \u00e5 tenke p\u00e5 denne m\u00e5ten.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>I systemutvikling er det ikke uvanlig at utvikleren g\u00e5r i gang med arbeidet f\u00f8r en kontrakt er utformet. Imidlertid er denne fremgangsm\u00e5ten i praksis &#8220;farlig&#8221;. Hvis en kontrakt ikke er utf [&hellip;]<\/p>\n","protected":false},"author":32,"featured_media":75504,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[16],"tags":[19,31],"acf":[],"_links":{"self":[{"href":"https:\/\/monolith.law\/no\/wp-json\/wp\/v2\/posts\/61279"}],"collection":[{"href":"https:\/\/monolith.law\/no\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/monolith.law\/no\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/monolith.law\/no\/wp-json\/wp\/v2\/users\/32"}],"replies":[{"embeddable":true,"href":"https:\/\/monolith.law\/no\/wp-json\/wp\/v2\/comments?post=61279"}],"version-history":[{"count":3,"href":"https:\/\/monolith.law\/no\/wp-json\/wp\/v2\/posts\/61279\/revisions"}],"predecessor-version":[{"id":75508,"href":"https:\/\/monolith.law\/no\/wp-json\/wp\/v2\/posts\/61279\/revisions\/75508"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/monolith.law\/no\/wp-json\/wp\/v2\/media\/75504"}],"wp:attachment":[{"href":"https:\/\/monolith.law\/no\/wp-json\/wp\/v2\/media?parent=61279"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/monolith.law\/no\/wp-json\/wp\/v2\/categories?post=61279"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/monolith.law\/no\/wp-json\/wp\/v2\/tags?post=61279"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}