Egenutviklet programvare kan i mange tilfeller brukes som tingsinnskudd ved stiftelse eller kapitalforhøyelse i et aksjeselskap. Spørsmålet «programvare utviklet internt tingsinnskudd» dukker ofte opp når man ønsker å bruke verdiene man allerede har skapt i koden, i stedet for rene kontanter. Nøkkelen er at programvaren må ha dokumenterbar verdi, være overførbar til selskapet og faktisk komme selskapet til nytte fra dag én.
Hva menes med programvare som tingsinnskudd?
Med programvare mener vi normalt kildekode, kompilert kode, tilhørende teknisk dokumentasjon, designfiler, API-spesifikasjoner, databasedesign og eventuelle interne verktøy som samlet utgjør et fungerende produkt eller en tydelig komponent. Ofte følger det også med en prosjektstruktur (for eksempel et Git-repo), utbyggingsskript og konfigurasjoner som gjør det mulig for selskapet å ta over utviklingen og driften videre.
I tillegg til selve koden er «rettighetene» avgjørende: Opphavsrett og lisensielle rettigheter må kunne overføres til selskapet. Dersom løsningen baserer seg på tredjepartskomponenter, må lisensvilkårene tillate slik bruk og overføring.
Data, domener og varemerker er ikke programvare, men kan være egne eiendeler. Hvis de skal inngå i et tingsinnskudd sammen med koden, må de beskrives tydelig hver for seg, slik at det ikke er tvil om hva som overføres.
Når kan egenutviklet programvare brukes som innskudd?
Hovedregelen er at eiendelen må ha økonomisk verdi, være klart identifiserbar og faktisk kunne overtas av selskapet. Det gjelder også for immaterielle eiendeler som programvare. I praksis betyr det at løsningen må eksistere på stiftelses- eller emisjonstidspunktet, at rettighetene kan overdras, og at verdien lar seg begrunne. Dette er ofte gjenstand for uavhengig bekreftelse (typisk revisor eller annen fagkyndig) før registrering.
Formuleringen «programvare utviklet internt tingsinnskudd» rommer derfor et par terskler: Programvaren må være din å overføre, kunne leveres i en tilstand som selskapet faktisk kan bruke, og verdien må kunne underbygges med dokumentasjon. Usikkerhet rundt rettigheter eller nytteverdi gjør prosessen vesentlig vanskeligere.
Dokumentasjon av rettigheter og eierskap
Tilretteleggingen starter med en «chain of title» – altså bevisrekken for at du faktisk eier programvaren. Typiske elementer:
- Hvem har skrevet koden? Hvis flere utviklere har bidratt, må overdragelse fra hver enkelt være dokumentert.
- Har freelancere/leverandører hatt oppdrag? Sjekk at kontraktene inneholder eksplisitt overdragelse av opphavsrett til oppdragsgiver.
- Er koden skrevet i ansettelsesforhold? Klargjør arbeidsgivers rettigheter i kontrakter og personalhåndbok.
- Brukes tredjepartskomponenter eller åpen kildekode? Verifiser lisenskompatibilitet ved overdragelse og kommersiell bruk.
- Finnes det patenter, design eller varemerker knyttet til produktet? Da må disse rettighetene også identifiseres og eventuelt inngå i overføringen.
Lag en enkel mappestruktur som kan deles ved behov (for eksempel et «datarom») med sentrale avtaler, lisensoversikt, bidragslister og en kort, teknisk beskrivelse av systemet. Dette gjør vurderingen raskere og reduserer antall oppfølgingsspørsmål.
Verdsettelse i praksis
Målet er en forsvarlig og etterprøvbar verdi. Vanlige tilnærminger er:
- Kostmetode: Utgangspunkt i historiske, dokumenterte utviklingskostnader (timer, innkjøp, konsulenter). Justeres for hva som faktisk har varig verdi, modenhet og risiko.
- Inntektsmetode: Estimert kontantstrøm fra programvaren (for eksempel lisensinntekter), neddiskontert for risiko og tid.
- Markedsmetode: Sammenlikning med kjente transaksjoner/priser for lignende løsninger, justert for forskjeller i marked, IP-bredde og modenhet.
Ofte kombineres metodene. Dokumentasjon som styrker verdien kan være pilotavtaler, kundeinteresse, teknologiske fortrinn, patenter, eller demonstrerbar kostnadsbesparelse for målgruppen.
Eksempel: Har du brukt tydelig sporbart 2 000 utviklingstimer, og en kvalifisert part vurderer at 60–70 % representerer varig, overførbar verdi i dagens form, vil en kostmetode gi en grov verdiindikasjon. Denne vektes så med risiko og markedsmuligheter. Tallet i seg selv er mindre viktig enn at begrunnelsen er logisk og etterprøvbar.
Unngå oppblåste antakelser. En realistisk, godt forklart verdi gir smidigere prosess og mindre risiko for innsigelser i registreringen.
For overordnet veiledning om registrering og kapital, se informasjon fra Brønnøysund. Der finner du oppdaterte steg og skjemaer.
Steg-for-steg: Slik forbereder du tingsinnskudd med programvare
- Kartlegg innholdet: Hva består løsningen av, og hva skal inngå? Avklar avhengigheter, tredjepartskomponenter og driftsmiljø.
- Rydd rettighetene: Innhent overdragelser fra alle bidragsytere og verifiser lisensbetingelser.
- Dokumenter: Lag en kort teknisk beskrivelse, systemskisse, og en enkel drifts-/byggeguide. Ta med lisensmatrise.
- Verdsett: Få en uavhengig vurdering/erklæring. Vær behjelpelig med timelister, kontrakter og kundespor.
- Beskriv bidraget: I stiftelses-/emisjonsdokumentene må eiendelen beskrives tilstrekkelig presist, med verdi og hvem som yter innskuddet.
- Overfør: Signer overdragelse av IP-rettigheter, overlever repo-tilgang, nøkler, og eventuelt driftsoppsett (for eksempel infrastruktur-kontoer eller IaC-konfig).
- Registrer: Send inn nødvendige dokumenter for registrering. Følg opp eventuelle avklaringer raskt.
Tid og kostnad varierer med kompleksitet. Ryddige prosjekter kan gå raskt; sammensatte løsninger med mange bidragsytere og uklare lisenser tar lenger tid og koster mer å verifisere. Planlegg for både faglig vurdering og administrativ behandling.
Hva innebærer «levering» av programvaren?
Levering betyr at selskapet faktisk får kontroll, ikke bare en teoretisk rett. Praktisk innebærer det typisk:
- Tilgang til hoved-repo (overføring av eierskap eller speiling til selskapets kontroll)
- Krypteringsnøkler, API-nøkler og andre hemmeligheter – trygt og sporbart, ikke via uformelle kanaler
- Bygge- og deployinstrukser, gjerne automatisert (CI/CD)
- Lisensfiler og dokumentert avhengighetsmatrise
- Testmiljø eller demo slik at selskapet kan verifisere funksjon
Avklar også hva som ikke følger med (for eksempel personlige skytjenestekontoer). Der det er hensiktsmessig, flytt eierskap til separate, selskapskontrollerte kontoer.
Kostnader og tidsbruk – hva bør du forvente?
Kostnadsbildet omfatter typisk tre deler: teknisk/kommersielt forarbeid (opprydding og dokumentasjon), uavhengig vurdering/bekreftelse, og juridiske dokumenter/overdragelser. For prosjekter med god orden kan dette være overkommelig. Med flere bidragsytere, uavklarte lisenser og svak dokumentasjon øker både tidsbruk og honorarer.
Sett av tid til avklaringer. Et grep som ofte sparer både tid og penger, er å gjøre en egen «mini due diligence» i forkant: lisenssjekk, samtykker/overdragelser fra bidragsytere og oppdatert dokumentasjon.
Alternativer hvis du er usikker
- Kontantinnskudd nå, innkjøpsavtale senere: Selskapet kjøper eller lisensierer programvaren når rettigheter og verdi er styrket.
- Blandet løsning: Delvis kontant, delvis programvare (gjør dokumentasjonen håndterlig og verdien mer robust).
- Kapitalforhøyelse på et senere tidspunkt: Bygg mer verdi først, bidrar med programvaren når den er mer moden.
- Kjøp av ferdig stiftet selskap: Dersom tid er kritisk, kan hylleselskaper være et alternativ, og programvaren kan overføres inn i ettertid.
Velg det som best balanserer tempo, risiko og kost. Husk at fleksibilitet i rekkefølge (først stifte, så overføre) ofte er bedre enn å presse alt inn i stiftelsesøyeblikket dersom dokumentasjonen ikke er klar.
Vanlige fallgruver
- Uklare rettigheter fra freelancere og tidligere ansatte
- Avhengigheter som ikke kan overtas (for eksempel personlige skykontoer eller ikke-overdragbare lisenser)
- Åpen kildekode brukt i strid med lisensvilkår
- Overvurdering av verdi uten tilstrekkelig dokumentasjon
- For lite praktisk leveringsplan – selskapet får ikke startet utviklingen videre
- Ufullstendige beskrivelser av hva som inngår i tingsinnskuddet
Gå gjennom denne listen tidlig. Jo tidligere du lukker slike hull, desto enklere blir bekreftelse, registrering og investor-dialoger.
Eksempel: Slik kan et case se ut
Anta at to gründere har bygget en MVP for et B2B-verktøy. Koden ligger i et privat Git-repo, med tydelig modulstruktur og enkle deploy-skript. De har dokumentert 1 500 arbeidstimer, noe konsulentbistand, og en pilotkunde som har testet funksjonalitet.
Før stiftelse samler de: overdragelseserklæringer for opphavsrett (fra hver bidragsyter), en lisensmatrise for tredjepartskomponenter, en teknisk beskrivelse (arkitektur, datamodell, bygg), og et handover-oppsett for nøkler/hemmeligheter. En uavhengig part gjør en nøktern verdsettelse basert på kost og dokumenterte markedsindikasjoner. Tingsinnskuddet beskrives presist i dokumentene, og koden leveres til selskapets nye repo ved signering.
Resultat: De får registrert selskapet med programvaren som en del av aksjekapitalen, og kan umiddelbart fortsette utviklingen i selskapets regi. Dette gir også et bedre utgangspunkt for å invitere inn investorer, fordi eiendelen er ryddig plassert i selskapet.
I denne prosessen var spørsmålet om «programvare utviklet internt tingsinnskudd» håndtert ved at de både dokumenterte eierskapet og leverte en praktisk overførbar løsning med realistisk verdianslag.
Sjekkliste før du bestemmer deg
- Kan alle rettigheter dokumenteres og overdras til selskapet?
- Er det en tydelig, fungerende leveranse (kode, dokumentasjon, nøkler)?
- Har du valgt en realistisk metode for verdsettelse og samlet nødvendig underlag?
- Er beskrivelsen av innskuddet presis, og forstår utenforstående hva som faktisk inngår?
- Er det mer hensiktsmessig å bidra med kontanter nå og programvaren senere – eller å bruke hylleselskaper hvis tidsaspektet er kritisk?
Hvis du kan hake av på punktene over, står du langt sterkere når egenutviklet programvare skal vurderes som tingsinnskudd.