Timeregistrering mod commits og tickets: krydsvalidering

Forside · Gennemgået oktober 2026 · Af John Nielsen

Når en kunde mener, at en leverandør har faktureret timer, der ikke er brugt, kan timeregistreringen holdes op mod spor i udviklingsværktøjerne: commits, pull requests, tickets, byggekørsler og logins. Krydsvalideringen kan vise perioder med registrerede timer uden nogen synlig aktivitet, eller aktivitet uden registrerede timer. Den kan ikke vise, hvor meget tid en opgave reelt tog, fordi meget udviklingsarbejde ikke efterlader spor i værktøjerne.

Ledelsens side af sagen, med de første skridt for virksomheden, er beskrevet på bevissikring-digitalt.dk. Her går vi ind i metoden.

Datakilderne

Timeregistrering · Dato, person, timer, opgave eller ticket-nummer, beskrivelse
Git · Commits med author og committer, tidspunkter og ændret kode
Kodeplatform · Push-hændelser, pull requests, reviews og kommentarer med platformens tidsstempler
Ticket-system · Oprettelse, statusskift, kommentarer, tildeling og loggede timer
CI/CD · Byggekørsler udløst af bestemte brugere
Identitet og adgang · Logins til platforme, VPN og udviklingsmiljøer
Kommunikation · Møder i kalendere, aktivitet i chat

Ingen enkelt kilde er tilstrækkelig. Styrken ligger i at lægge dem side om side på en fælles tidslinje pr. person og pr. opgave.

Forberedelse

Før data sammenlignes, skal tre ting være på plads:

Identiteter. Hver udvikler kan optræde med forskellige navne og e-mails i Git, et brugernavn på kodeplatformen, en konto i ticket-systemet og et navn i timeregistreringen. Lav en tabel, der kobler identiteterne, og dokumentér grundlaget for hver kobling.
Tidszoner. Commits bærer udviklerens lokale tidszone, platforme gemmer typisk UTC, og timeregistreringen har ofte kun en dato. Normalisér til én tidszone, som beskrevet i sommertid og tidszoner i rapporten.
Opgavekobling. Find nøglen mellem kilderne: ticket-numre i commit-beskeder, grennavne eller pull requests, og ticket-nummeret i timeregistreringen.

Metoden

Analysen foregår typisk i to niveauer.

Pr. dag og person: For hver dag med registrerede timer undersøges, om der er spor af aktivitet i nogen af kilderne. Resultatet er en oversigt over dage med timer og ingen aktivitet, dage med aktivitet og ingen timer, og dage, hvor begge dele findes.

Pr. opgave: For hver ticket sammenlignes de fakturerede timer med omfanget af tilknyttede commits, pull requests og kommentarer, og med tidsrummet fra første til sidste aktivitet. En opgave med mange timer, men én lille commit og ingen kommentarer, kan være værd at se nærmere på. Det samme kan en opgave, hvor timerne er registreret efter, at ticketen blev lukket.

Kodemængde er et dårligt mål for tid, og analysen bør ikke omsætte linjer kode til timer. Den bruges til at finde uoverensstemmelser, der kræver forklaring.

Mønstre, der bør undersøges nærmere

Nogle uoverensstemmelser er mere sigende end andre:

registrerede timer på dage, hvor der ikke er nogen aktivitet i nogen kilde, heller ikke logins,
registrerede timer på helligdage, i ferier eller på dage, hvor personen ifølge andre kilder arbejdede på et andet projekt,
timer på opgaver, der var lukket eller endnu ikke oprettet i ticket-systemet,
store mængder timer på en opgave, hvis eneste kodeændring er lille og triviel,
flere personer med fuldt registrerede dage på samme opgave, men aktivitet fra kun én konto,
timer registreret i samlede blokke lang tid efter perioden, især lige før fakturering.

Hvert mønster har mulige uskyldige forklaringer, og listen er et udgangspunkt for spørgsmål, ikke en liste over konklusioner.

Statistik med forsigtighed

Det kan være fristende at beregne et forhold mellem timer og commits pr. person og sammenligne udviklere. Det giver sjældent mening, fordi arbejdsformer er forskellige, og fordi opgaverne ikke er ens. En senior, der bruger dagen på design og review, kan have færre commits end en junior, der retter småfejl. Sammenligning over tid for samme person og samme type opgave er mere robust end sammenligning mellem personer.

Fejlkilder

Arbejde uden spor. Analyse, design, møder, fejlsøgning, test og læsning af dokumentation efterlader ofte få eller ingen commits.
Samlede commits. Nogle udviklere committer sjældent og i store portioner, eller arbejdsgangen samler mange commits til én ved merge (squash). Så forsvinder fordelingen over dage.
Omskrevne tidspunkter. Rebase og amend ændrer committer date, mens author date kan være bevaret. Platformens push-tidspunkt er mere robust. Se kildekode og Git som bevis.
Lokalt arbejde. Kode, der er skrevet, men aldrig pushet, findes kun på udviklerens computer.
Delte konti. Hvis flere har arbejdet under samme konto, kan aktivitet ikke fordeles på personer.
Andre repositories. Arbejdet kan ligge i et repository, en gren eller et værktøj, der ikke er med i datagrundlaget.
Afrunding og samlet registrering. Timer kan være registreret i blokke, fx en hel uge på én dag, hvilket giver kunstige uoverensstemmelser på dagsniveau.

Hvem sad ved tastaturet

En commit med en bestemt e-mail viser, at den lokale Git-konfiguration havde den e-mail. Platformens push-log viser, hvilken konto der pushede. Ingen af delene viser alene, at en bestemt person udførte arbejdet. Hvis spørgsmålet er, om de fakturerede konsulenter faktisk var dem, der arbejdede, kræver det flere spor, fx loginlogs, enheder og IP-adresser. Principperne er beskrevet i attribution af brugerhandlinger.

Sikring af datagrundlaget

Repositories med fuld historik, hentet fra platformen og om muligt fra udviklernes computere.
Eksport af platformens hændelser: push, pull requests, reviews.
Eksport af ticket-systemets historik med felthistorik og loggede timer. Se ticket-systemer: ændringshistorik.
Timeregistreringen i rå form fra systemet, ikke kun de udskrevne fakturabilag.
Hashværdier og registrering af hver eksport.

Timeregistreringen bør hentes med ændringshistorik, hvis systemet har en. Registreringer, der er ændret eller oprettet længe efter den dag, de vedrører, er relevante for vurderingen.

Præsentation

Resultatet præsenteres bedst som en tidslinje eller en kalendervisning pr. person, hvor registrerede timer og aktivitet vises side om side, og hvor hver markering kan spores til kilden. Opbygningen er beskrevet i tidslinjeanalyse. Tabeller med summer pr. måned kan supplere, men de skjuler de enkelte dage, hvor uoverensstemmelserne findes.

Det er god praksis at vise hele perioden og ikke kun de dage, der skiller sig ud. En visning, hvor kun de afvigende dage er med, giver let indtryk af et større problem, end datagrundlaget bærer. Angiv også, hvor stor en andel af de registrerede timer der har sammenfaldende aktivitet, og hvor stor en andel der ikke har, så læseren kan se forholdet.

Hvad analysen kan og ikke kan bevise

Krydsvalideringen kan vise, at der på bestemte dage er registreret timer uden spor af aktivitet i de undersøgte systemer, og omvendt. Den kan påvise mønstre, fx timer registreret i ferier eller weekender uden aktivitet, eller timer på lukkede opgaver. Den kan ikke vise, at arbejdet ikke er udført, fordi fravær af spor ikke er det samme som fravær af arbejde.

Konklusioner bør derfor formuleres som observationer om sammenfald og uoverensstemmelser med en beskrivelse af, hvilke typer arbejde der ikke ville efterlade spor. Leverandøren bør have mulighed for at forklare de dage, der skiller sig ud, og forklaringerne kan ofte efterprøves i andre kilder.

Kilder og versioner

Senest gennemgået: oktober 2026.

Næste skridt

Massesletning efter en tvist er opstået: tekniske tegn

Læs også: CI/CD-logs og testdokumentation: virkede det eller ej? · GitHub, GitLab og Azure DevOps: auditlogs for kloning, forks og tokens

→ Uvildig IT-sagkyndig med forensic-baggrund · For sagkyndige · Tlf. 70 13 63 23 · Digital bevissikring hos Nielco IT

Skrevet af John Nielsen, IT‑sagkyndig og indehaver af Nielco IT. Selvstændig siden 2009 og mere end 30 års erfaring med IT‑sikkerhed. Har været IT‑sagkyndig i danske retskredse og ved Den Fælles Europæiske Patentdomstol (UPC). Om John Nielsen · LinkedIn · Redaktionel politik