Kan en systemutviklingskontrakt etableres uten en kontrakt?

I systemutvikling er det ikke uvanlig at utvikleren går i gang med arbeidet før en kontrakt er utformet. Imidlertid er denne fremgangsmåten i praksis “farlig”. Hvis en kontrakt ikke er utformet, er det en risiko for at bestilleren senere kan hevde at “kontrakten er ennå ikke inngått, og derfor er det ikke nødvendig å betale honoraret” hvis det oppstår problemer. I faktiske tvister knyttet til systemutvikling, er det ikke uvanlig at selve kontraktsinngåelsen blir bestridt, og at det blir tatt avgjørelser 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ør. Som nevnt senere, er det også tilfeller der kontraktsinngåelsen blir nektet selv om en kontrakt er utformet.

Her vil jeg forklare om suksess eller fiasko i systemutviklingskontrakter, og den juridiske strukturen for å kreve penger hvis kontraktsinngåelsen ikke blir anerkjent.

Inngåelse av kontrakt

En kontrakt blir i prinsippet inngått når begge parter er enige om kontraktens elementer (samsvar mellom tilbud og aksept).

Når en kontrakt er inngått, 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. “Kontraktens elementer” må være spesifisert eller konkret nok til å kunne tvinge gjennom oppfyllelse og fastslå manglende oppfyllelse.

Inngåelse av systemutviklingskontrakt

En systemutviklingskontrakt er hovedsakelig en kontrakt for arbeid og en quasi-mandatkontrakt. En kontrakt for arbeid er en avtale om å fullføre et arbeid og betale for det. En betalt quasi-mandatkontrakt er en avtale om å utføre en oppgave og betale for det.

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

Derfor, hvis det er enighet mellom partene om kontraktens elementer, “innholdet i arbeidet eller oppgaven” og “betalingen”, vil kontrakten bli ansett som inngått.

Det skal bemerkes at en kontrakt kan inngås med bare muntlige løfter, og det er ikke nødvendig med en skriftlig kontrakt.

Krav om betaling ved avbestilling etter inngåelse av systemutviklingskontrakt

Hvis en systemutviklingskontrakt er inngått og brukeren ensidig avbryter den, vil det juridisk sett bli ansett som en oppsigelse av kontrakten.

Hvis en kontrakt for arbeid er inngått, kan leverandøren bli oppsagt av brukeren når som helst før arbeidet er fullført, men det er fastsatt at leverandøren har rett til erstatning (Japansk sivillov § 641). Derfor, hvis brukeren ikke betaler erstatning, kan leverandøren kreve erstatning for “skade”, som er beløpet som leverandøren har brukt og den betalingen de kunne ha mottatt, minus kostnadene som ble spart ved å unngå å fullføre systemet.

Hvis en quasi-mandatkontrakt er inngått, kan mottakeren kreve betaling basert på andelen av oppdraget som er utført når oppdraget avsluttes midt i utførelsen (revidert Japansk sivillov § 648, paragraf 3). Derfor kan leverandøren kreve betaling for arbeidet som allerede er utført.

Suksess eller fiasko i systemutviklingskontrakter

Spesifisitet av systeminnhold

Vanligvis, i transaksjoner mellom selskaper, spesielt kontrakter med store beløp, blir skriftlige dokumenter brukt. Derfor, hvis en kontrakt er opprettet, er det lett å anerkjenne etableringen av kontrakten.

Systemet som er under utvikling blir gradvis konkretisert gjennom forskjellige prosesser. Derfor er det forstått at spesifisiteten av systeminnholdet, som er “innholdet i arbeidet” i en kontraktskontrakt, er tilstrekkelig spesifikt til å forstå omfanget og oversikten over det systemet som skal systematiseres.

I rettspraksis, det var ingen tvist om inngåelsen av grunnkontrakten og konfidensialitetsavtalen. Selv om det var en beskrivelse i den grunnleggende kontrakten om å “delegere e-handelsvirksomhetsteknisk støtte, WEB-sidekonstruksjonsstøtte og relaterte tjenester”, 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.

Selv om du har opprettet en grunnleggende systemutviklingskontrakt, vil det være vanskelig å 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øp for kompensasjon i detalj, til det punktet at de kan tvinge utførelse og bekrefte mislighold.

For øvrig forklarer vi i detalj om ting å være oppmerksom på i kontrakter mellom individuelle ingeniører og selskaper i artikkelen nedenfor.

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

Leverandøren presenterer estimater og spesifikasjoner, og brukeren godkjenner og bestiller

Vanligvis, i bedriftstransaksjoner, blir skriftlige dokumenter brukt, så hvis en kontrakt ikke er opprettet, blir det vanskelig å anerkjenne etableringen av en kontrakt. I systemutvikling er det ofte tilfelle at arbeidet begynner før en kontrakt er opprettet, men hvordan tenker man på suksessen eller fiaskoen i kontrakten i slike tilfeller?

I en rettsavgjørelse (Nagoya District Court, 28. januar 2004 (Heisei 16)) om etableringen av en systemutviklingskontrakt, er det uttalt som følger:

• Etter forhandlinger om spesifikasjonsbekreftelse mellom leverandøren og brukeren,
• Leverandøren presenterer spesifikasjoner og estimater,
• Dette blir godkjent og bestilt av brukeren, og kontrakten er etablert.

I denne rettsavgjørelsen hadde leverandøren blitt betrodd av brukeren, en lokal myndighet, for å innføre et finansielt regnskapssystem, og et RFP med tittelen “Forespørsel om forslag til innføring av et generelt administrativt informasjonssystem” ble presentert. Leverandøren presenterte et forslag og et estimat i samsvar med dette, og en “adopsjonsmelding” ble levert fra brukeren. Leverandøren hadde ikke grundig vurdert brukerens forretningsinnhold osv. ved å møte brukeren, og det ble ikke anerkjent at innholdet og kostnadene for tilpasningen ble konkret vurdert internt av brukeren. Innholdet i leverandørens forslag var ikke konkret, det var ikke klart hva brukeren hadde godkjent, og etableringen av kontrakten ble ikke anerkjent.

Jeg vil gi en tilleggsforklaring på kontraktsdannelsen som er nevnt i rettsavgjørelsen, med tanke på andre rettsavgjørelser osv.

Etter forhandlinger om spesifikasjonsbekreftelse mellom leverandøren og brukeren

Ut fra det faktum at det er “etter forhandlinger”, hvis du er “i forhandlinger” om kontraktselementer som systeminnhold og kompensasjonsbeløp, vil det være vanskelig å anerkjenne etableringen av en kontrakt fordi du ikke har nådd enighet.

Imidlertid, i en kontrakt, kan du også bestemme kompensasjonen til markedsprisen, så det er rettsavgjørelser som har anerkjent at en kontrakt er etablert med markedsprisen som kompensasjon, fra det faktum at brukeren har godkjent systeminnholdet og “omtrent” kompensasjonsbeløpet.

For at leverandøren skal kunne si at de “har forhandlet”, bør de registrere det faktum at de har grundig vurdert brukerens forretningsinnhold, systeminnhold osv. ved å møte brukeren, i e-poster, møtereferater osv.

Leverandøren presenterer spesifikasjoner og estimater, og brukeren godkjenner og bestiller

• Hvis brukeren utsteder en bestillingsordre eller bestillingsformular, vil det være lettere å anerkjenne etableringen av en kontrakt. Hvis leverandøren sender inn en forespørsel eller utfører arbeid basert på en bestillingsordre, vil det være lettere å anerkjenne at det er enighet, og det vil være lettere å anerkjenne etableringen av en kontrakt.
• Brukerens interne dokumenter er ofte innholdet i fremtidige kontrakter, og det er vanskelig å anerkjenne etableringen av en kontrakt. Imidlertid, hvis det ikke er en slik beskrivelse, og kontraktselementene, som innholdet i systemutviklingen og kompensasjonsbeløpet, er beskrevet så konkret som mulig, vil det bidra til å anerkjenne etableringen av en kontrakt.
• Det er vanskelig å anerkjenne etableringen av en kontrakt hvis en memo, avtale, bekreftelsesbrev osv. er forutsetningen for å inngå en separat kontrakt, eller hvis innholdet er abstrakt.
• Hvis kontraktutkastet ikke er stemplet, er det vanskelig å anerkjenne etableringen av en kontrakt fordi stemplingen betyr konklusjon.
• Et estimat er bevis for å bekrefte kompensasjonsbeløpet som er avtalt mellom partene.

Forresten, i systemutvikling, når prosessen har gått til en viss grad, er det en detaljert forklaring i følgende artikkel om hvorvidt det er mulig å kreve en økning i det opprinnelige estimatbeløpet i tilfelle av en etterfølgende spesifikasjonsendring eller en forespørsel om å legge til funksjoner.

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

Oppgjørsavtale

Hvis arbeidet utføres basert på instruksjoner fra brukeren med forutsetning om å inngå en kontrakt, kan det være tillatt med en “oppgjørsavtale” som avregner betaling for arbeidet utført til det tidspunktet arbeidet stoppes. For å gjøre det lettere å godta denne avtalen, kan det være lurt å få brukeren til å skrive ned metoden for å avregne betaling i tilfelle kontrakten ikke blir inngått, i et internt notat eller lignende dokument, eller å få godkjennelse fra en autorisert person hos brukeren for et dokument som leverandøren har opprettet.

Den juridiske strukturen for å kreve penger når en kontrakt ikke er anerkjent

Uaktsomhet ved inngåelse av kontrakt

Når forhandlinger om å inngå en kontrakt starter, har partene en gjensidig forpliktelse til å unngå å 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ått, 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ått. Dette kalles uaktsomhet ved inngåelse av kontrakt.

Her er noen eksempler fra rettspraksis der uaktsomhet ved inngåelse av kontrakt ble anerkjent:

• En leverandør hadde fullført kravspesifikasjonen på forespørsel fra en bruker og hadde også utført deler av grunnleggende og detaljert design. Brukeren forklarte at handlingen med å invitere andre selskaper til å by var en formell handling for å få godkjenning fra presidenten, men rett før kontrakten skulle inngås, ble et annet selskap valgt, og kontrakten ble ikke inngått.
• En leverandør hadde gått frem med arbeidet etter å ha blitt bedt av brukeren om å overholde leveringstiden, og datoen for kontraktsinngåelsen var også fastsatt. Imidlertid ble det gjort forberedelser for egenutvikling innad i brukerens selskap, noe som ble holdt hemmelig, og kontrakten ble ikke inngått.
• En leverandør ble informert av brukeren om at de hadde blitt valgt som systembygger, og det var ingen spørsmål om tilbudet. Basert på møter med brukeren, utførte leverandøren arbeid som å bekrefte spesifikasjonene, og brukeren var klar over utgiftene. Imidlertid ble kontrakten avvist på grunn av at de ikke kunne bli enige om tilbudsprisen.

Derimot, i tilfeller der uaktsomhet ved inngåelse av kontrakt ikke ble anerkjent, var det tilfeller der muligheten for å velge et annet selskap eller betingelsene for å inngå en kontrakt var tydelig angitt.

Hvis du har gått frem med arbeidet i henhold til brukerens forespørsel, og kontraktsforhandlingene blir brutt uten forvarsel fordi det ikke ble gitt noen indikasjon på muligheten for å velge et annet selskap eller avtalebetingelsene, kan du ha rett til å kreve erstatning for skade.

Det er ingen tvil om at utgiftene som er påløpt til nå, er inkludert i “skaden” i dette tilfellet. I tillegg er det rettsavgjørelser som inkluderer fortjenesten fra det faktiske arbeidet som er utført. Hvis du kan bevise at du har lidd skade tilsvarende fortjenesten du kunne ha tjent hvis du hadde fortsatt å jobbe etter å ha avvist en søknad fra et annet selskap, kan det også være inkludert.

Artikkel 512 i den japanske handelsloven

Hvis en leverandør har utført handlinger relatert til systemutvikling for en bruker, kan de kreve en rimelig betaling i henhold til Artikkel 512 i den japanske handelsloven.

Når du starter forhandlinger om systemutvikling, er det en god idé å sørge for at begge parter forstår systeminnholdet og betalingsbeløpet ved hjelp av e-post eller møtereferater, og å bevare bevis som bekrefter at kontrakten var sikker på å bli inngått og at elementene i kontrakten var konkretisert.

Faktisk, selv om du blir nektet betaling på grunn av at du ikke har inngått en kontrakt, kan du som nevnt ovenfor ha rett til å kreve penger.

Oppsummering

Som vi har sett, er det vanlig at domstolene har en “negativ” holdning til kontraktsforhold der det ikke finnes en skriftlig kontrakt, spesielt sammenlignet med hvordan det oppfattes av selskapet som har påtatt seg oppdraget. Fra selskapets perspektiv, vil de gjerne hevde at “vi begynte å jobbe først, og kontrakten skulle bli inngått i etterkant, så kontrakten er faktisk gyldig”. Men denne påstanden blir ikke alltid akseptert.

I tillegg, hvis kontrakten blir avvist, er det tilfeller der du kan kreve penger basert på juridiske strukturer som kontraktsbrudd eller den japanske handelsloven (Japanese Commercial Code) artikkel 512, men dette er heller ikke en “sikker” sak.

Hvis du må starte arbeidet før kontrakten er inngått, bør du:

• Vurdere om det er verdt å bruke tid på prosjektet, tatt i betraktning risikoen det innebærer. Dette er spesielt relevant for små og mellomstore bedrifter eller oppstartsselskaper. Hvis de tar på seg et prosjekt fra et stort selskap, kan de føle seg tvunget til å “handle først” for å få handelserfaring med det store selskapet. Dette kan være en akseptabel forretningsbeslutning, så lenge risikoen er tatt i betraktning.
• Vurdere om det er mulig å inngå en avtale om oppgjør, i tilfelle kontrakten ikke blir inngått.

Det kan sies at det er nødvendig å tenke på denne måten.