Kan softwareudvikling give fradrag for forsøg og forskning?

Softwareudvikling kan i særlige tilfælde være forsøgs- og forskningsvirksomhed efter ligningslovens § 8 B, og praksis er stram. Rutinepræget udvikling er efter Skattestyrelsens vejledning ikke omfattet, heller ikke når den er krævende, og I må ikke regne med, at softwareudvikling normalt giver fradrag. Afgørende er, om arbejdet har et nyhedselement i forhold til branchens vidensniveau og afhænger af et videnskabeligt eller teknologisk fremskridt. Det afgøres konkret. Tag spørgsmålet op med revisor tidligt, før udgifterne er afholdt, og før fradraget står i budgettet.

Hvad reglerne giver

Ligningslovens § 8 B, stk. 1, giver to valg for udgifter til forsøgs- og forskningsvirksomhed, der er knyttet til erhvervet: fuldt fradrag i afholdelsesåret eller afskrivning over fem år. For selskaber findes der en særregel om udgifter, før virksomheden er i gang.

To yderligere regler kan være relevante. Stk. 4 giver et forhøjet fradrag med et samlet loft på koncernniveau. Ligningslovens § 8 X giver en skattekredit, det vil sige udbetaling af skatteværdien af underskud fra straksafskrevne udgifter, med et maksimum pr. indkomstår, for selskaber og personer i virksomhedsordningen. Satser og lofter ændrer sig. Derfor står de ikke her, og I skal have dem fra revisor.

Skattestyrelsens tre kriterier

Vejledningen arbejder med tre kriterier:

1. Nyhedselement. Noget nyt i forhold til branchens vidensniveau. Målestokken er branchen, så det rækker ikke, at resultatet er nyt for jeres virksomhed.
2. Kreativitet. Arbejdet skal rumme et kreativt element.
3. Usikkerhed. Der skal være usikkerhed om omkostning, tid eller resultat.

For software tilføjer vejledningen et afgørende krav: Arbejdet skal være afhængigt af et teknologisk eller videnskabeligt fremskridt. At en funktion er ny for kunderne, er derfor utilstrækkeligt. Spørgsmålet er, om jeres arbejde løser et teknisk problem, som branchen ikke har en kendt løsning på.

Det, der falder uden for

Vejledningen nævner flere ting, som ikke er omfattet:

• Rutinepræget softwareudvikling og opdateringer.
• Brug af kendte metoder og værktøjer.
• Nye brugerfunktioner i eksisterende programmer.
• Websites bygget med eksisterende værktøjer.
• Tilpasning til en konkret anvendelse, medmindre det giver viden, der væsentligt forbedrer det grundlæggende program.

Også køb af FoU-projekter, markedsundersøgelser, kundeservice og sædvanlige driftsomkostninger ligger uden for ifølge vejledningen.

For et softwarehus er det væsentligt at læse listen ærligt. Meget af det, teamet laver på en almindelig dag, står på den, også når opgaven er krævende. At moderniseringen af et produkt i gammel teknologi er svær, gør den ikke i sig selv til forskning. Det samme kan gælde AI-funktioner i produktet, hvor en færdig sprogmodel kobles på med kendte metoder. Om et konkret projekt er anderledes, kan kun afgøres ud fra dets indhold.

Praksis er stram

To afgørelser viser retningen.

I SKM2023.448.ØLR, om en softwarebaseret handelsplatform, blev det fastslået, at forarbejderne ikke giver grundlag for en mildere fortolkning for software. I SKM2025.444.LSR af 10. marts 2025 havde selskabet bevisbyrden og fik afslag, og en sagkyndig fandt lignende teknologi på det tidspunkt.

Den anden afgørelse er nyttig at tænke over, for den viser, hvad der tæller. Virksomheden skal kunne vise, at arbejdet var nyt og usikkert, og vurderingen foretages af nogen, der ser på, hvad branchen allerede kunne. Hvad det betyder for jeres egen dokumentation, står i dokumentation af udviklingsprojekter.

Fem spørgsmål før mødet med revisor

Et godt møde med revisor kræver, at den tekniske og den økonomiske side er forberedt sammen. Bed den tekniske leder svare skriftligt på disse fem:

1. Hvilket konkret teknisk problem forsøger vi at løse?
2. Hvorfor kan det ikke løses med kendte metoder? Hvad har vi undersøgt?
3. Hvad var usikkert, da vi begyndte, og hvad kan gå galt?
4. Hvad er det nye, sammenlignet med det, andre i branchen kan?
5. Hvilke udgifter hører til netop dette arbejde, og hvordan kan de skilles fra den almindelige udvikling?

Kan spørgsmål 2 og 4 ikke besvares konkret, er svaret formentlig nej. Det er også en brugbar oplysning, for så kan budgettet lægges uden.

Sådan håndterer I spørgsmålet

Hold fradrag og tilskud adskilt. De følger hver sine regler, og en ansøgning om støtte er noget andet end en skattemæssig vurdering. Tilskud til vidensbaserede projekter er beskrevet i Innobooster til softwareprojekter.

Beslut, hvem der ejer sagen. Den tekniske leder kender indholdet, økonomiansvarlig kender tallene, og revisor kender reglerne. Vurderingen skal laves sammen. Lov heller ikke bestyrelsen eller banken et fradrag, før revisor har set på sagen. Et projekt skal kunne stå på egne ben, også hvis svaret bliver nej.

Det skal I lade være med

• At regne fradraget ind i planen, før det er vurderet · praksis er stram, og bevisbyrden er jeres.
• At kalde alt nyt for forskning · ordet betyder noget andet hos Skattestyrelsen end i teamet.
• At vente, til regnskabet er ved at blive lavet · så er oplysningerne sværere at finde.

Det skal I kræve af den eksterne

• ☐ Tekniske svar, som revisor kan bruge, skrevet i et sprog uden fagord.
• ☐ En ærlig vurdering af, hvad der er rutine.
• ☐ Ingen løfter om fradrag, for det spørgsmål hører hos revisor.

Kilder

• Den juridiske vejledning 2026-2, C.C.2.2.2.20: forsøgs- og forskningsudgifter, kriterier og gengivelse af SKM2023.448.ØLR.
• SKM2025.444.LSR: afgørelse af 10. marts 2025.

Senest gennemgået: november 2026.

Næste skridt

• Skat og tilskud til softwareudvikling
• Dokumentation af udviklingsprojekter

Læs også: Tilskud til et softwareprojekt · SMV:Digital og softwarevirksomheder

→ Kontakt · Tlf. 70 13 63 23 · Ekstern CTO hos Nielco IT