Tidrapportering för revisionsbyråer: 4 tysta fel jag hittade

Jag heter Denys och är full-stack- och AI-ingenjör. Mellan maj och oktober 2026 gick en revisionsbyrå från ett verktyg där alla kunde öppna alla klienter till ett system som jag byggde enbart åt byrån, över 388 commits. Byrån nämns inte vid namn. Texten är till för dem som driver en byrå och väljer dess verktyg: vad en revisionsbyrå behöver av tidrapportering, de fyra felen jag hittade och hur du kontrollerar vilket system som helst för dem.

Vad behöver en revisionsbyrå av tidrapportering?

En revisionsbyrå säljer timmar, så tidrapporteringen är det underlag hela verksamheten vilar på. Byrån jag byggde för behövde:

• Timmar mot klient, projekt och uppgift. Varje rad hör till ett uppdrag, så timmarna kan läsas per klient, per projekt och per person.
• Veckovisa tidrapporter med godkännande. Medarbetarna skickar in veckan, projektadministratören godkänner eller avslår varje rad, och bara godkända timmar räknas.
• Påminnelser. Den vars tidrapport fortfarande är tom före deadline får ett mejl. Sedan september 2026 påminner det bara om saknade timmar och hoppar över personer med noll kapacitet.
• Resursplanering. Vem som arbetar med vilket uppdrag de kommande veckorna, mot varje persons kapacitet.
• Konfidentiella klienter. Ägaren kan begränsa en klient, med dess projekt, uppgifter och tid, till utvalda medlemmar.
• Arkivera, radera aldrig. En medlem som slutar inaktiveras och anonymiseras, och ett avslutat projekt arkiveras, så tidrapporternas historik finns kvar.

Systemet utfärdar inga fakturor. Projektens faktureringsform och timbudgetar ligger bakom en egen behörighet, och fakturering stannar i byråns bokföringssystem.

Vem ska se vems timmar på en revisionsbyrå?

Före det här projektet kunde alla på byrån öppna alla klienter och allas timmar. För en revisionsbyrå är det ett sekretessproblem innan det är ett mjukvaruproblem: alla medlemmar ska inte se alla klienter, och ingen behöver se en kollegas vecka om de inte godkänner den.

Åtkomstmodellen som byrån bekräftade ser ut så här:

Roll	Ser	Kan godkänna
Medarbetare	Bara egna timmar	Ingenting
Projektadministratör	Timmar för teamet på egna projekt	Teamets veckor på de projekten
Ägare	Alla klienter, projekt och personer	Allt
Konfidentiell klient	Syns bara för de medlemmar som ägaren valt	—

Ägaren formar varje roll i en matris med kryssrutor, område mot åtgärd, och varje regel ligger i databasen i stället för i skärmarna, så en sida kan inte visa något som databasen nekar. Varje ruta testades mot en kopia av produktionen före lanseringen; hur, och vad testet hittade, står i så testar du Supabase RLS.

En fråga kunde matrisen inte besvara, och den kom från byrån själv. I juni 2026 såg en medlem med den mest begränsade rollen andra medlemmar och deras projekt på resursskärmen, men förväntade sig bara se sig själv och en kollega. Ska en begränsad medlem se personerna på sina egna projekt? Regeln vi landade i: ja, bara på gemensamma projekt, och med andras kapacitet och ledighet dold.

Hur får man en åtkomstmodell som en byrå faktiskt är överens om? Jag bad inte klienten beskriva den ur minnet. Jag skickade ett frågeformulär med 72 frågor i 9 avsnitt, där behörighetsrutnäten redan var ifyllda så som det levande systemet fungerade den 7 augusti 2026. Klienten ändrade det som var fel, och varje ändrad cell markerades. Folk är bättre på att rätta verkligheten än på att beskriva den.

Fel 1: rapportsummorna skulle ha blivit för låga

Sidan Tidrapporter har vyerna “Det här kvartalet” och “Hittills i år” för hela byrån. De laddade alla tidrader i intervallet i en enda förfrågan. Databas-API:et bakom appen returnerar högst 1 000 rader per förfrågan, och när det stannar vid 1 000 ger det inget fel. Det returnerar bara de första 1 000.

Supabase dokumenterar standardvärdet: projekt returnerar högst 1 000 rader om gränsen inte ändras i API-inställningarna.

Så när byrån passerade 1 000 rader i ett intervall skulle medlemmar och veckor falla bort ur vyn, och summorna skulle bli för låga utan att något på skärmen sa det. Med cirka 70 rader i veckan var vyn “hittills i år” på väg att passera 1 000 rader runt mitten av november 2026. En kodgranskning den 24 september 2026 hittade det innan det hände. Åtgärden läser varje intervall sida för sida, och varje rapportexport hämtar nu data på samma sätt.

Så kontrollerar du ditt verktyg: välj ett långt intervall, exportera de råa raderna, summera dem själv och jämför med rapportens summa. Om de två skiljer sig skär rapporten bort rader.

Fel 2: “Sparat” när ingenting sparats

När databasen nekar en ändring på grund av en behörighet, eller för att en regel kräver tvåstegsinloggning, kan den svara “0 rader ändrade” utan något fel. Cirka 30 ställen i appen som uppdaterar eller raderar poster tolkade det svaret som lyckat och visade “sparat”. Personen går vidare. Ändringen skedde aldrig.

Åtgärden är att fela stängt: en skrivning som inte rör någon rad är ett fel och visas som ett fel, och ett test kontrollerar nu att varje skrivväg behandlar det så.

Så kontrollerar du ditt verktyg: logga in som en medlem utan rätt att redigera något, försök redigera det och ladda om sidan. Om du såg “sparat” och det gamla värdet är tillbaka ljuger verktyget om sparningar.

Fel 3: en konfidentiell klient läckte genom rapporter

Vissa uppdrag är bara kända av dem som arbetar med dem. Sedan 24 augusti 2026 kan ägaren begränsa en klient till namngivna medlemmar. Alla andra får ingenting tillbaka för den klienten, dess projekt, uppgifter eller tid. Ägaren har alltid åtkomst, och den åtkomsten räknas ut från vem som har ägarrollen i dag, den lagras inte, så den följer med rollen.

Att dölja klienten i klientlistan var den enkla delen. Läckorna fanns i sidodörrarna. En granskning den 8 september 2026 hittade att:

• tre rapportfunktioner ignorerade begränsningen, eftersom de körs med rättigheter som hoppar över de vanliga åtkomstreglerna, så en konfidentiell klients timmar kunde dyka upp i rapporter;
• taggräknare i administratörens taggöversikt räknade med den konfidentiella klientens projekt och uppgifter, vilket avslöjade att uppdraget fanns och ungefär hur stort det var;
• felmeddelandena avslöjade skillnaden: att försöka ändra en riktig men dold post gav “förbjudet”, medan en påhittad post gav “hittades inte”, så vem som helst kunde sondera om en konfidentiell klient fanns.

Alla tre tillämpar nu samma kontroll som huvudtabellerna, och en dold post ser exakt ut som en som saknas. Att flytta ett projekt eller en rad ut ur en konfidentiell klient kräver dessutom ägaren eller en särskild behörighet, och varje sådan flytt loggas.

Så kontrollerar du ditt verktyg: begränsa en klient till en enda person. Kör sedan som någon annan varje rapport, titta på varje räknare och filter, sök efter klientens namn och öppna en direktlänk till ett av dess projekt. Du ska inte hitta några spår av den, inte ens i felmeddelandet.

Fel 4: ett avslag kunde döljas av ett senare godkännande

En vecka kan ha rader på flera projekt, så flera personer godkänner den. Om en projektadministratör avslog en rad och en annan senare godkände sin del, kunde det senare godkännandet avgöra hela veckan och maskera avslaget. Att flytta rader mellan uppgifter eller öppna en vecka igen kunde dölja det på samma sätt.

Den 24 september 2026 ändrades godkännandelogiken så att en vecka förblir avslagen så länge någon avslagen rad fortfarande är aktiv, och en projektadministratör kan arkivera en avslagen rad bara om hen själv avslog den. En databassond kör nu vart och ett av fallen, och varje fall måste visa PASS.

Så kontrollerar du ditt verktyg: använd två godkännare på en vecka. Avslå en rad som den första, godkänn allt annat som den andra och se vilket tillstånd veckan hamnar i.

Köpa eller bygga tidrapportering för en revisionsbyrå?

Köp först. Toggl, BigTime, ZenWorkflow och liknande verktyg täcker redan timers, veckogodkännanden och klientfakturering, och du kan komma igång med ett av dem den här veckan. Ett skräddarsytt system är rimligt när byrån har regler som produkterna inte kan uttrycka, till exempel konfidentiella klienter som bara syns för namngivna medlemmar, godkännande av flera projektadministratörer per vecka eller roller som ägaren vill forma ruta för ruta.

Oavsett väg tar de fyra kontrollerna ovan en eftermiddag och säger dig mer än en funktionslista. Varje produktsida säger “detaljerade behörigheter”. Få visar vad som händer när du bockar ur en ruta.

Begränsningar i den här rapporten

• En byrå. Åtkomstmodellen, volymen på cirka 70 rader i veckan och frågeformuläret kommer från en enda byrå.
• Fel 1 fångades innan det slog till. Datumet i mitten av november är en prognos utifrån byråns radtakt, inte en uppmätt incident.
• Ingen fakturering. Systemet håller timmar, faktureringsform och timbudgetar men fakturerar inte klienter, så jag kan inte uttala mig om flöden från tid till faktura.

Åtkomstreglerna här är Postgres row-level security. Två hål som en rollmatris inte fångar är beskrivna för sig: en användare som tillhör två organisationer och ett IF som felar öppet vid NULL. Själva bygget står i caset om tidrapportering för en revisionsbyrå, och den här sortens arbete hör till interna verktyg och dashboards.