Hvad er loven, hvis betaling for systemudvikling ikke er blevet betalt?
For leverandører, der påtager sig systemudviklingsopgaver, er det måske i en vis forstand den største risiko, når “brugeren ikke betaler for det leverede produkt”. Omkostningerne ved systemudvikling består ofte hovedsageligt af dygtige medarbejdere, herunder programmører, hvilket ofte resulterer i høje personaleomkostninger. Manglende indtægtsopkrævning kan i nogle tilfælde blive et spørgsmål om liv eller død. I denne artikel vil vi diskutere de spørgsmål, som leverandøren bør overveje i tilfælde af, at brugeren ikke reagerer på betaling, fra et juridisk perspektiv.
Først og fremmest, bekræft om du er i stand til at anmode om betaling
- En situation, hvor leverandøren har leveret produktet til brugeren, men brugeren accepterer ikke leveringen, hvilket forårsager en forsinkelse i faktureringsprocessen.
- Trods opfattelsen af, at acceptprocessen var afsluttet, er der en eller anden form for misforståelse mellem brugerens opfattelse, og de nægter at betale.
Dette er situationer, der realistisk set kan opstå.
Desuden, i systemudviklingsterminologi, er det at brugeren inspicerer specifikationerne for det færdige system og accepterer leveringen kendt som “accept”. Betydningen af denne “accept” og de spørgsmål, der skal overvejes, når fremskridtene ikke er tilfredsstillende, er detaljeret forklaret i følgende artikel.
Relateret artikel: Anvendelsesområder for accept og formodet acceptklausul i systemudvikling[ja]
En generel forklaring på acceptprocessen er overladt til ovenstående artikel, men juridisk set, om brugerens accept er afsluttet eller ej, skal overvejes under hensyntagen til bestemmelserne om “formodet acceptklausul”.
Med dette i tankerne, er det første punkt, der skal overvejes, når brugeren nægter at betale, sandsynligvis følgende:
- Er arbejdet færdigt i første omgang, eller er det stadig ufærdigt?
- Kan ansvar for mangler (Japansk Civil Code § 635) anvendes eller ej?
Grunden til, at vi først skal bekræfte ovenstående to punkter, er, at hvis arbejdet ikke er færdigt, og ansvar for mangler (Japansk Civil Code § 635) ikke kan anvendes, kan vi ikke forvente at få betaling, selvom vi anlægger sag.
Så, hvad skal leverandørens repræsentant specifikt undersøge for at overveje ovenstående to punkter? Lad os se på, hvilke dokumenter der skal bekræftes nedenfor.
Dokumenter, der skal kontrolleres for at undersøge muligheden for at anmode om betaling
| Leveringsnota Hvis der ikke er en leveringsnota, vil det styrke antagelsen om, at leveringen ikke er fuldført, og at arbejdet ikke er færdigt. |
| Dokumenter, der meddeler resultatet af inspektionen Dette er det vigtigste dokument, når man skal afgøre, om arbejdet kan betragtes som færdigt. Desuden, hvis inspektionen er blevet udsat på grund af brugerens omstændigheder, vil det være godt at kontrollere, hvordan “deemed acceptance clause” er angivet i kontrakten. |
| Opgavehåndteringsliste Dette er et dokument, der bruges til at forstå, hvilke opgaver der er blevet fundet indtil nu, og hvilke foranstaltninger der er blevet truffet. Det er også et dokument, der bruges til at forstå situationen med fejl og mangler, der er opstået efter levering, og status for reparationer. |
| Kravspecifikationer, designspecifikationer og ændringsstyringsdokumenter, mødereferater osv. Ved at afklare, hvilken forståelse brugeren og leverandøren oprindeligt havde, bliver det klart, hvad der skal betegnes som fejl og mangler. |
For mere detaljerede forklaringer om, hvordan man håndterer ændringer i systemets specifikationer og hvordan man opretter ændringsstyringsdokumenter, se separate artikler.
Relaterede artikler: Juridisk synspunkt på, hvordan man håndterer ændringsstyring i systemudvikling[ja]
| Ophævelsesmeddelelse eller dokument, der angiver brugerens hensigt Dette er en metode til at forstå, hvad brugeren har til hensigt med hensyn til ikke at fortsætte med inspektionen (eller ikke at betale vederlaget). |
Næste, bekræft hvor meget du kan kræve i honorar
Det er principielt, at det beløb, der kan kræves, er angivet i kontrakten. Men det kan antages, at der ikke er en ordentlig kontrakt (eller et dokument, der svarer til det) tilbage, hvis der er foretaget ændringer i specifikationerne osv. efterfølgende. Vi forklarer detaljeret om, hvordan man genberegner estimater baseret på efterfølgende årsager som ændringer i specifikationer og tilføjelse af funktioner, i den følgende artikel.
Relateret artikel: Er det muligt at øge det estimerede beløb efter systemudvikling?[ja]
Metoden til genberegning af estimater er som beskrevet i denne artikel, men især fra perspektivet om at overveje, om det er muligt at øge det krævede beløb,
- Tilstedeværelsen og indholdet af estimatet for yderligere udvikling og funktionelle ændringer
- Brugerens reaktion på estimatet
- Tilstedeværelsen af en aftale om situationen, der forårsagede yderligere udvikling og funktionelle ændringer, der er angivet i problemstyringslisten, og det beløb
Det vil være nødvendigt at se på disse punkter. Det grundlæggende er at undersøge, om der var enighed med brugeren om at “bestille arbejdet til det beløb” (med andre ord, om kontrakten kan siges at være indgået).
Endelig, overvejelse af presserende spørgsmål i tilfælde af faktisk retssag
Vær opmærksom på muligheden for en modkrav
I systemudvikling er det ikke ualmindeligt, at når enten brugeren eller leverandøren anlægger sag mod den anden part, kan der blive rejst et modkrav. Det vil sige, at der kan være en eller anden form for indvending fra brugerens side i forhold til situationen, hvor betalingen ikke er blevet foretaget.
Systemudvikling indebærer i første omgang, at brugeren også har forskellige samarbejdsforpligtelser, men først og fremmest bør man ikke glemme, at leverandøren som ekspert i systemudvikling har en bred skønsbeføjelse og et stort ansvar. Vi har detaljeret forklaret leverandørens projektledelsesforpligtelser i forbindelse med systemudvikling i følgende artikel.
Relateret artikel: Hvad er projektledelsesforpligtelser i systemudvikling?[ja]
Det vil sige, det er nødvendigt at overveje på forhånd, om det er muligt at placere skylden på brugeren, der ensidigt nægter at betale. Hvis man ser på tidligere retssager, er der mange tilfælde, hvor leverandøren oprindeligt anlagde sag for at kræve betaling, men brugeren på sin side krævede genoprettelse til den oprindelige tilstand eller erstatning for skader.
Overvej også, om der virkelig er en forretningsmæssig fordel
Selv hvis leverandørens argumenter accepteres, og det er muligt at kræve betaling i en retssag, hvis situationen eskalerer til en retssag, kan det forventes, at det bliver vanskeligt at fortsætte med fremtidige transaktioner. Desuden, selvom dine argumenter anerkendes i en retssag, bør du være forberedt på, at det kan tage lang tid at modtage betalingen. Hvis du tager i betragtning, at omkostningerne og besværet ved at anlægge en retssag ikke er ubetydelige, kan det ofte være bedre at gøre en indsats for at finde et kompromis.
Opsummering
Hvis en bruger ikke overholder betalingsforpligtelser, kræver det en juridisk gennemgang af flere typer dokumenter for at løse problemet. Det er ikke nok blot at have en grundig dokumenthåndtering, man skal også overveje, hvilke organisatoriske risici og ulemper man kan stå overfor, hvis man ender med at gå til retssag.
Det er sandt, at grundig dokumenthåndtering normalt hører til på operationelt niveau. Men hvis man beslutter at gå til retssag baseret på de opbevarede dokumenter og materialer, kan det blive en alvorlig ledelsesbeslutning. I sådanne usædvanlige situationer bør man forstå hele processen, herunder vigtigheden af samhørighed og organisatorisk styrke mellem ledelsen og operationelt niveau.
Category: IT
Tag: ITSystem Development
