--- title: "Timeregistrering for revisjonsselskap: 4 stille feil" description: "Timeregistrering for et revisjonsselskap: fire feil ingen skjerm viste. For lave summer, falske lagringer, en lekkende klient og skjulte avvisninger." url: "https://madsalt.tech/no/blog/time-tracking-for-audit-firms/" author: "Denys Zaichenko" language: "no" published: 2026-10-19 --- # Timeregistrering for revisjonsselskap: 4 stille feil TL;DR Timeregistrering i et revisjonsselskap handler ikke om timeren. Den handler om to ting: hvem som kan se hvilken klients timer, og om summene i rapportene stemmer. Da jeg bygde et system for ett revisjonsselskap, fant jeg fire feil som ingen skjerm viste: rapportsummer som i det stille ville blitt for lave, rundt 30 handlinger som sa "lagret" uten at noe var lagret, en konfidensiell klient hvis eksistens lekket gjennom rapporter og tagtellere, og en avvist linje som en senere godkjenning kunne skjule. Hver av dem kan testes på noen minutter i hvilket som helst verktøy, kjøpt eller bygget. Jeg er Denys, fullstack- og AI-ingeniør. Mellom mai og oktober 2026 gikk et revisjonsselskap fra et verktøy der alle kunne åpne alle klienter, til et system jeg bygde kun for selskapet, over 388 commits. Selskapet nevnes ikke ved navn. Teksten er for dem som driver et selskap og velger verktøyene dets: hva et revisjonsselskap trenger av timeføring, de fire feilene jeg fant, og hvordan du sjekker et hvilket som helst system for dem. ## Hva trenger et revisjonsselskap av timeregistrering? Et revisjonsselskap selger timer, så timeregistreringen er grunnlaget hele virksomheten hviler på. Selskapet jeg bygde for, trengte: - **Timer mot klient, prosjekt og oppgave.** Hver linje hører til ett oppdrag, så timene kan leses per klient, per prosjekt og per person. - **Ukentlige timelister med godkjenning.** Medarbeiderne sender inn uken, prosjektadministratoren godkjenner eller avviser hver linje, og bare godkjente timer teller. - **Påminnelser.** Den hvis timeliste fortsatt er tom før fristen, får en e-post. Siden september 2026 minner den bare om manglende timer og hopper over folk med null kapasitet. - **Ressursplanlegging.** Hvem som jobber med hvilket oppdrag de kommende ukene, mot hver persons kapasitet. - **Konfidensielle klienter.** Eieren kan begrense en klient, med prosjekter, oppgaver og tid, til utvalgte medlemmer. - **Arkiver, aldri slett.** Et medlem som slutter, deaktiveres og anonymiseres, og et avsluttet prosjekt arkiveres, slik at historikken i timelistene blir stående. Systemet utsteder ikke fakturaer. Prosjektenes faktureringsform og timebudsjetter ligger bak en egen tilgang, og fakturering blir i selskapets regnskapssystem. ![En ukes timer, fra linje til rapport. Timer når rapportene først når prosjektadministratoren har godkjent dem. Godkjent uke: Medarbeider → Innsendt uke → Prosjektadmin. → Uke godkjent → Rapporter; Avvist linje: Medarbeider → Innsendt uke → Prosjektadmin. → Tilbake med begrunnelse.](https://madsalt.tech/charts/no/time-tracking-for-audit-firms-week.svg) *Figur 1. Den ukentlige timelisten i revisjonsselskapets system. En avvist linje går tilbake til den som registrerte den.* ## Hvem skal se hvem sine timer i et revisjonsselskap? Før dette prosjektet kunne alle i selskapet åpne alle klienter og alles timer. For et revisjonsselskap er det et taushetsproblem før det er et programvareproblem: ikke alle medlemmer skal se alle klienter, og ingen trenger å se en kollegas uke med mindre de godkjenner den. Tilgangsmodellen selskapet bekreftet, ser slik ut: | Rolle | Ser | Kan godkjenne | | --------------------- | ------------------------------------------- | ------------------------------ | | Medarbeider | Bare egne timer | Ingenting | | Prosjektadministrator | Timer for teamet på egne prosjekter | Teamets uker på de prosjektene | | Eier | Alle klienter, prosjekter og personer | Alt | | Konfidensiell klient | Synlig bare for medlemmene eieren har valgt | — | ![Hvem ser hvem sine timer. Tilgangsmodellen selskapet bekreftet. Databasen håndhever den, ikke skjermen. Medarbeider: Medarbeider → Bare egne timer; Prosjektadmin.: Prosjektadmin. → Team på egne prosjekter → Godkjenner ukene deres; Eier: Eier → Alle klienter og personer; Konfidensiell klient: Begrenset klient → Bare valgte medlemmer.](https://madsalt.tech/charts/no/time-tracking-for-audit-firms-roles.svg) *Figur 2. Standardroller i revisjonsselskapets system. Eieren kan endre hver rolle i en tilgangsmatrise.* Eieren former hver rolle i en matrise av avkrysningsbokser, område mot handling, og hver regel ligger i databasen i stedet for i skjermene, så en side kan ikke vise noe databasen avviser. Hver boks ble testet mot en kopi av produksjon før lansering; hvordan, og hva testen fant, står i [slik tester du Supabase RLS](https://madsalt.tech/no/blog/how-to-test-supabase-rls/). Ett spørsmål kunne ikke matrisen besvare, og det kom fra selskapet selv. I juni 2026 så et medlem med den mest begrensede rollen andre medlemmer og prosjektene deres på ressursskjermen, men forventet bare å se seg selv og én kollega. Skal et begrenset medlem se personene på sine egne prosjekter? Regelen vi landet på: ja, bare på felles prosjekter, og med andres kapasitet og fravær skjult. Hvordan får man en tilgangsmodell et selskap faktisk er enig i? Jeg ba ikke klienten beskrive den fra hukommelsen. Jeg sendte et spørreskjema med 72 spørsmål i 9 seksjoner, med tilgangsrutenettene allerede fylt ut slik det levende systemet fungerte 7. august 2026. Klienten rettet det som var feil, og hver endrede celle ble markert. Folk er bedre til å rette virkeligheten enn til å beskrive den. ## Feil 1: rapportsummene ville blitt for lave Siden Timelister har visningene "Dette kvartalet" og "Hittil i år" for hele selskapet. De lastet alle tidslinjer i perioden i én forespørsel. Database-API-et bak appen returnerer maksimalt 1 000 rader per forespørsel, og når det stopper på 1 000, gir det ingen feil. Det returnerer bare de første 1 000. Supabase dokumenterer standarden: [prosjekter returnerer høyst 1 000 rader](https://supabase.com/docs/reference/javascript/select) med mindre grensen endres i API-innstillingene. Så når selskapet passerte 1 000 linjer i en periode, ville medlemmer og uker falle ut av visningen, og summene ville blitt for lave uten at noe på skjermen sa det. Med rundt 70 linjer i uken var "hittil i år"-visningen på vei til å passere 1 000 linjer rundt midten av november 2026. En kodegjennomgang 24. september 2026 fant det før det skjedde. Løsningen leser hver periode side for side, og hver rapporteksport henter nå data på samme måte. **Slik sjekker du verktøyet ditt:** velg en lang periode, eksporter de rå linjene, summer dem selv og sammenlign med rapportens sum. Hvis de to er ulike, kutter rapporten rader. ## Feil 2: "Lagret" når ingenting ble lagret Når databasen avviser en endring på grunn av en tilgang, eller fordi en regel krever tofaktorpålogging, kan den svare "0 rader endret" uten noen feil. Rundt 30 steder i appen som oppdaterer eller sletter poster, leste det svaret som vellykket og viste "lagret". Personen går videre. Endringen skjedde aldri. Løsningen er å feile lukket: en skriving som ikke berører noen rad, er en feil og vises som en feil, og en test sjekker nå at hver skrivevei behandler det slik. **Slik sjekker du verktøyet ditt:** logg inn som et medlem uten rett til å redigere noe, prøv å redigere det og last siden på nytt. Hvis du så "lagret" og den gamle verdien er tilbake, lyver verktøyet om lagring. ## Feil 3: en konfidensiell klient lekket gjennom rapporter Noen oppdrag er bare kjent for dem som jobber med dem. Siden 24. august 2026 kan eieren begrense en klient til navngitte medlemmer. Alle andre får ingenting tilbake for den klienten, prosjektene, oppgavene eller tiden. Eieren har alltid tilgang, og den tilgangen regnes ut fra hvem som har eierrollen i dag, den lagres ikke, så den følger rollen. Å skjule klienten i klientlisten var den enkle delen. Lekkasjene satt i sidedørene. En gjennomgang 8. september 2026 fant at: - **tre rapportfunksjoner ignorerte begrensningen**, fordi de kjører med rettigheter som hopper over de vanlige tilgangsreglene, så en konfidensiell klients timer kunne dukke opp i rapporter; - **tagtellere** i administratorens tagoversikt telte den konfidensielle klientens prosjekter og oppgaver med, noe som avslørte at oppdraget fantes og omtrent hvor stort det var; - **feilmeldingene avslørte forskjellen**: å prøve å endre en ekte, men skjult post ga "forbudt", mens en oppdiktet post ga "ikke funnet", så hvem som helst kunne undersøke om en konfidensiell klient fantes. Alle tre bruker nå samme sjekk som hovedtabellene, og en skjult post ser nøyaktig ut som en som mangler. Å flytte et prosjekt eller en linje ut av en konfidensiell klient krever dessuten eieren eller en egen tilgang, og hver slik flytting logges. **Slik sjekker du verktøyet ditt:** begrens én klient til én enkelt person. Kjør deretter som en annen alle rapporter, se på hver teller og hvert filter, søk etter klientens navn og åpne en direkte lenke til ett av prosjektene. Du skal ikke finne noe spor av den, heller ikke i feilmeldingen. ## Feil 4: en avvisning kunne skjules av en senere godkjenning En uke kan ha linjer på flere prosjekter, så flere personer godkjenner den. Hvis én prosjektadministrator avviste en linje og en annen senere godkjente sin del, kunne den senere godkjenningen avgjøre hele uken og maskere avvisningen. Å flytte linjer mellom oppgaver eller gjenåpne en uke kunne skjule den på samme måte. 24. september 2026 ble godkjenningslogikken endret slik at en uke forblir avvist så lenge en avvist linje fortsatt er aktiv, og en prosjektadministrator kan arkivere en avvist linje bare hvis vedkommende selv avviste den. En databaseprobe kjører nå hvert av tilfellene, og hvert må vise PASS. **Slik sjekker du verktøyet ditt:** bruk to godkjennere på én uke. Avvis én linje som den første, godkjenn alt annet som den andre, og se hvilken tilstand uken ender i. ## Kjøpe eller bygge timeregistrering for et revisjonsselskap? Kjøp først. Toggl, BigTime, ZenWorkflow og lignende verktøy dekker allerede timere, ukentlige godkjenninger og klientfakturering, og du kan komme i gang med ett av dem denne uken. Et skreddersydd system gir mening når selskapet har regler produktene ikke kan uttrykke, for eksempel konfidensielle klienter som bare er synlige for navngitte medlemmer, godkjenning fra flere prosjektadministratorer per uke eller roller eieren vil forme boks for boks. Uansett vei tar de fire sjekkene over en ettermiddag og forteller deg mer enn en funksjonsliste. Hver produktside sier "detaljerte tilganger". Få viser hva som skjer når du fjerner en hake. ## Begrensninger i denne rapporten - **Ett selskap.** Tilgangsmodellen, volumet på rundt 70 linjer i uken og spørreskjemaet kommer fra ett enkelt selskap. - **Feil 1 ble fanget før den utløste.** Datoen midt i november er en framskriving ut fra selskapets linjetakt, ikke en målt hendelse. - **Ingen fakturering.** Systemet holder timer, faktureringsform og timebudsjetter, men fakturerer ikke klienter, så jeg kan ikke uttale meg om flyter fra tid til faktura. Tilgangsreglene her er Postgres row-level security. To hull en rollematrise ikke fanger, er beskrevet for seg: [en bruker som tilhører to organisasjoner](https://madsalt.tech/no/notes/supabase-rls-user-in-two-organizations/) og [en IF som svikter åpent ved NULL](https://madsalt.tech/no/notes/plpgsql-if-not-null-fails-open/). Selve bygget står i [caset om timeregistrering for et revisjonsselskap](https://madsalt.tech/no/work/audit-firm-time-tracking/), og denne typen arbeid hører under [interne verktøy og dashboards](https://madsalt.tech/no/services/internal-tools-dashboards/). Velger eller bygger du timeregistrering for selskapet ditt? Utveksler gjerne erfaringer om tilgangsregler og godkjenninger. Ingen salgspitch. [Ta kontakt](https://madsalt.tech/no/#contact)