Skal et softwareprojekt vurderes af Skattestyrelsen eller en fond, skal virksomheden kunne vise, hvad der var nyt, hvad der var usikkert, og hvad der faktisk blev gjort. Bevisbyrden ligger hos jer. Skattestyrelsens vejledning indeholder ingen formel liste over dokumenter. Vores anbefaling er derfor en let projektlog, som føres undervejs: hypoteser, forsøg, resultater og fravalg. Loggen er ingen garanti for fradrag eller tilskud, og selve vurderingen hører hos revisor. En historie, der først skrives et år senere, er dog meget svagere end noter fra den dag, tingene skete.
Hvorfor dokumentationen afgør sagen
Skattestyrelsen ser efter noget nyt, kreativitet og usikkerhed om, hvad arbejdet koster, tager eller fører til, se artiklen om fradraget. I SKM2025.444.LSR fik et selskab afslag. Bevisbyrden lå hos selskabet, og den sagkyndige pegede på, at lignende teknologi allerede fandtes.
Det fortæller to ting. For det første skal I kunne vise, hvad der var ukendt, da I begyndte, og det er svært at rekonstruere. Bagefter virker det hele logisk. For det andet skal I kunne vise, hvad I undersøgte om, hvad andre kunne. Den, der vurderer sagen, ser på det med friske øjne, ofte år senere.
Projektloggen
Hold den enkel. En kort tekstfil eller et dokument pr. projekt rækker, og et par linjer om ugen er nok i de perioder, hvor der sker noget afgørende. Vigtigst er datoerne og det, der gik galt.
Følgende indhold er nyttigt:
- Projektbeskrivelse ved start. Hvad forsøger vi at opnå, og hvilket teknisk problem står i vejen?
- Undersøgelse af det kendte. Hvad kan andre i branchen, hvilke metoder, produkter eller artikler har vi set på, og hvorfor rækker de ikke? Dato og henvisninger.
- Hypoteser. Hvad tror vi virker, og hvorfor? Skrevet, før forsøget begynder.
- Forsøg og resultater. Hvad gjorde vi, og hvad viste det? Også målinger fra forsøget.
- Fravalg og fejl. Hvad virkede ikke, og hvad blev opgivet? De sider tæller, for de viser usikkerheden.
- Personer og tid. Hvem arbejdede på det, og hvor meget tid gik til netop dette arbejde?
Et tænkt eksempel på en post: “12. marts. Hypotese: Vi kan samle sensordata i realtid med den valgte database ved den forventede belastning. Forsøg med testdata viser, at forsinkelsen stiger kraftigt ved høj belastning. Skift af indeks hjælper ikke. Næste forsøg: ny opdeling af data.”
Koblet til det, I allerede laver
En log, der er et ekstra system, dør hurtigt. Læg den, hvor arbejdet alligevel foregår. Beslutningsnotaterne fra skriv de tekniske beslutninger ned dækker meget af det: baggrund, beslutning og fravalg er næsten det samme som hypoteser og fravalg. Kodearkivets historik viser datoer. Opgaver i projektværktøjet kan mærkes, så de hører til projektet, og tidsregistrering kan sættes op, så projektets timer kan skilles fra den øvrige udvikling.
Udpeg én person, der hver måned tjekker, at loggen er ført, og som samler det, der mangler. Det falder naturligt hos den tekniske leder. Økonomiansvarlig skal vide, at projektet findes, så udgifter kan følges fra starten.
Det, der er anderledes ved tilskud
Ved tilskud er rækkefølgen vigtig. Innobooster fra Innovationsfonden støtter ikke udgifter før projektstart, og projektet må ikke være startet, når der søges. Beskrivelsen skal altså ligge klar, før noget begynder: projektets idé, plan, milepæle og risici. Det er uddybet i Innobooster til softwareprojekter. Se altid aktuelle runder og fondens retningslinjer, før arbejdet går i gang.
Loggen kan bruges begge steder, og de to spørgsmål er forskellige. En fond spørger, om projektet er innovativt og vidensbaseret. Skattestyrelsen spørger, om det opfylder kriterierne for forsøg og forskning. Et tilsagn fra en fond afgør derfor ikke skattespørgsmålet.
Sådan kommer I i gang
Har I et projekt i gang nu, så start i dag, og skriv datoen på. Skriv på en side, hvad I ved om forløbet indtil nu, og marker det tydeligt som bagudrettet. Rekonstruktion må aldrig se ud som noter fra dengang.
Tag derefter et kort møde med revisor, før I bruger tid på mere. Vis, hvad I har, og spørg, om det er relevant at fortsætte med at dokumentere til dette formål. Svaret kan være nej, og så har loggen stadig en værdi for teamet, for I undgår at prøve det samme to gange.
Det skal I lade være med
- At skrive hele historien bagefter · den kan ikke længere vise, hvad I ikke vidste.
- At skjule fejlene · fravalg og opgivne spor er noget af det, der viser, at noget var usikkert.
- At bruge kundenavne og persondata i loggen uden grund · hold den til det tekniske.
- At se loggen som et bevis for fradrag · den er et grundlag for revisors vurdering.
Det skal I kræve af den eksterne
- ☐ En enkel skabelon til projektlog, som teamet selv kan føre.
- ☐ Kobling til de beslutningsnotater og værktøjer, I allerede bruger.
- ☐ Tekniske beskrivelser, som revisor og fonde kan læse.
- ☐ Klar besked om, at vurderingen af fradrag og tilskud ligger hos andre.
Kilder
- Den juridiske vejledning 2026-2, C.C.2.2.2.20: kriterier for forsøg og forskning. Vejledningen har ingen formel dokumentationsliste, og projektloggen er vores anbefaling.
- SKM2025.444.LSR: bevisbyrden ligger hos selskabet.
- Innovationsfonden: Innobooster: aktuelle vilkår og retningslinjer.
Senest gennemgået: november 2026.
Næste skridt
Læs også: Skriv de tekniske beslutninger ned · Tilskud til et softwareprojekt
→ Kontakt · Tlf. 70 13 63 23 · Ekstern CTO hos Nielco IT
