Tuntiseuranta tilintarkastusyhteisölle: 4 hiljaista virhettä

Olen Denys, full-stack- ja tekoäly-insinööri. Toukokuun ja lokakuun 2026 välillä tilintarkastusyhteisö siirtyi työkalusta, jossa jokainen näki jokaisen asiakkaan, seurantasovellukseen, jonka rakensin sille yksin, 388 commitin aikana. Yhteisön nimeä en kerro. Tämä kirjoitus on yritystä johtaville ja sen työkaluja valitseville: mitä tilintarkastusyhteisö tarvitsee tuntiseurannalta, mitkä neljä virhettä löysin ja miten minkä tahansa seurantatyökalun voi tarkistaa niiden varalta.

Mitä tilintarkastusyhteisö tarvitsee tuntiseurannalta?

Tilintarkastusyhteisö myy tunteja, joten tuntiseuranta on tietue, jonka varassa koko liiketoiminta on. Yhteisö, jolle rakensin, tarvitsi:

• Tunnit asiakkaalle, projektille ja tehtävälle. Jokainen kirjaus kuuluu yhteen toimeksiantoon, joten tunnit voi lukea asiakkaan, projektin ja henkilön mukaan.
• Viikoittaiset tuntilistat hyväksynnällä. Työntekijät lähettävät viikon, projektin ylläpitäjä hyväksyy tai hylkää kunkin kirjauksen, ja vain hyväksytyt tunnit lasketaan.
• Muistutukset. Kenelle tahansa, jonka tuntilista on määräaikaan mennessä tyhjä, lähtee sähköposti. Syyskuusta 2026 alkaen se muistuttaa vain puuttuvista tunneista eikä huomioi ihmisiä, joiden kapasiteetti on nolla.
• Resurssien allokointi. Kuka työskentelee missäkin toimeksiannossa tulevien viikkojen aikana, suhteessa kunkin kapasiteettiin.
• Luottamukselliset asiakkaat. Omistaja voi rajata asiakkaan projekteineen, tehtävineen ja aikakirjauksineen valituille jäsenille.
• Arkistoi, älä poista. Lähtevä jäsen deaktivoidaan ja anonymisoidaan, ja valmis projekti arkistoidaan, joten tuntilistojen historia säilyy eheänä.

Se ei laskuta. Projektien laskutustapa ja tuntibudjetit ovat oman oikeutensa takana, ja laskutus pysyy yhteisön kirjanpitojärjestelmässä.

Kenen pitäisi nähdä kenen tunnit tilintarkastusyhteisössä?

Ennen tätä projektia jokainen yhteisössä pystyi avaamaan jokaisen asiakkaan ja kaikkien tunnit. Tilintarkastusyhteisölle se on ensin luottamuksellisuusongelma ja vasta sitten ohjelmisto-ongelma: kaikkien jäsenten ei kuulu nähdä kaikkia asiakkaita, eikä kenenkään tarvitse nähdä kollegansa viikkoa, ellei hän hyväksy sitä.

Yhteisön vahvistama käyttöoikeusmalli näyttää tältä:

Rooli	Näkee	Voi hyväksyä
Työntekijä	Vain omat tunnit	Ei mitään
Projektin admin	Tiimin tunnit omissa projekteissaan	Tiimin viikot näissä projekteissa
Omistaja	Kaikki asiakkaat, projektit ja henkilöt	Kaiken
Luottamuksellinen asiakas	Näkyy vain omistajan valitsemille jäsenille	—

Omistaja muokkaa kutakin roolia valintaruutujen matriisissa, alueet toimintoja vastaan, ja jokainen sääntö asuu tietokannassa eikä näytöissä, joten sivu ei voi näyttää sitä, minkä tietokanta torjuu. Jokainen ruutu testattiin tuotannon kopiota vasten ennen julkaisua; miten, ja mitä testi löysi, kerrotaan kirjoituksessa Supabase RLS:n testaus.

Yhteen kysymykseen matriisi ei pystynyt vastaamaan, ja se tuli yhteisöltä itseltään. Kesäkuussa 2026 rajatuimman roolin jäsen näki allokointinäytöllä muita jäseniä ja heidän projektejaan, vaikka odotti näkevänsä vain itsensä ja yhden tiimikaverin. Pitäisikö rajatun jäsenen nähdä oman projektinsa ihmiset? Sääntö, johon päädyimme: kyllä, mutta vain yhteisissä projekteissa, ja muiden kapasiteetti ja vapaat piilotetaan.

Miten saa käyttöoikeusmallin, josta yhteisö on oikeasti samaa mieltä? En pyytänyt asiakasta kuvaamaan sitä muistista. Lähetin 72 kysymyksen kyselyn 9 osiossa, ja oikeusruudukot oli jo rastitettu sen mukaan, miten oikea järjestelmä toimi 7. elokuuta 2026. Asiakas muutti sen, mikä oli väärin, ja jokainen muutettu ruutu merkittiin. Ihmiset korjaavat todellisuutta paremmin kuin kuvaavat sitä.

Virhe 1: raporttien summat olisivat jääneet liian pieniksi

Timesheets-sivulla on koko yhteisön “Tämä neljännes” ja “Vuoden alusta” -näkymät. Ne latasivat kaikki aikarajan kirjaukset yhdellä pyynnöllä. Sovelluksen takana oleva tietokanta-API palauttaa enintään 1 000 riviä pyyntöä kohti, eikä se nosta virhettä, kun se pysähtyy tuhanteen. Se palauttaa vain ensimmäiset 1 000.

Supabase dokumentoi oletuksen: projektit palauttavat enintään 1 000 riviä, ellei rajaa muuteta API-asetuksista.

Kun yhteisö ylittäisi 1 000 kirjausta aikavälillä, jäseniä ja viikkoja putoaisi näkymästä, ja summat jäisivät liian pieniksi ilman että mikään ruudulla kertoisi siitä. Noin 70 kirjauksen viikkovauhdilla vuoden alusta -näkymä oli ylittämässä 1 000 kirjausta marraskuun 2026 puolivälissä. Koodin tarkastus 24. syyskuuta 2026 löysi sen ennen kuin niin kävi. Korjaus lukee jokaisen aikavälin sivu kerrallaan, ja jokainen raporttivienti sivuttaa nyt samoin.

Näin tarkistat työkalusi: valitse pitkä aikaväli, vie raakakirjaukset, laske ne itse yhteen ja vertaa raportin loppusummaan. Jos ne eroavat, raportti leikkaa rivejä.

Virhe 2: “Tallennettu”, vaikka mitään ei tallennettu

Kun tietokanta torjuu muutoksen oikeuden puutteen vuoksi tai koska sääntö vaatii kaksivaiheisen kirjautumisen, se voi vastata “0 riviä muutettu” ilman virhettä. Noin 30 kohtaa sovelluksessa, jotka päivittävät tai poistavat tietueita, luki tuon vastauksen onnistumiseksi ja näytti “tallennettu”. Ihminen jatkaa eteenpäin. Muutosta ei tapahtunut.

Korjaus on epäonnistua suljetusti: kirjoitus, joka ei kosketa yhtään riviä, on virhe ja näytetään virheenä, ja testi tarkistaa nyt, että jokainen kirjoitusreitti käsittelee sen niin.

Näin tarkistat työkalusi: kirjaudu jäsenenä, jolla ei ole oikeutta muokata jotakin, yritä muokata sitä ja lataa sivu uudelleen. Jos näit “tallennettu” ja vanha arvo on takaisin, työkalu valehtelee tallennuksista.

Virhe 3: luottamuksellinen asiakas vuosi raporttien kautta

Jotkin toimeksiannot tunnetaan vain niissä työskentelevät. Omistaja voi 24. elokuuta 2026 alkaen rajata asiakkaan nimetyille jäsenille. Kaikki muut saavat tyhjää takaisin asiakkaasta, sen projekteista, tehtävistä ja ajasta. Omistajalla on aina pääsy, ja se pääsy lasketaan siitä, kenellä omistajan rooli on nyt, ei tallenneta, joten se siirtyy roolin mukana.

Asiakkaan piilottaminen asiakasluettelosta oli helppo osa. Vuodot olivat sivuovissa. Katselmointi 8. syyskuuta 2026 löysi, että:

• kolme raporttifunktiota ohitti rajauksen, koska ne ajetaan oikeuksilla, jotka ohittavat tavalliset pääsysäännöt, joten luottamuksellisen asiakkaan tunnit saattoivat näkyä raporteissa;
• tunnisteiden käyttömäärät ylläpidon tunnisteyhteenvedossa laskivat luottamuksellisen asiakkaan projektit ja tehtävät, mikä paljasti toimeksiannon olemassaolon ja suunnilleen sen koon;
• virheilmoitukset erottivat tapaukset: olemassa olevan mutta piilotetun tietueen muuttaminen palautti “forbidden”, keksityn tietueen muuttaminen palautti “not found”, joten kuka tahansa pystyi koettelemaan, onko luottamuksellista asiakasta olemassa.

Kaikki kolme käyttävät nyt samaa tarkistusta kuin päätaulut, ja piilotettu tietue näyttää täsmälleen puuttuvalta. Projektin tai kirjauksen siirto pois luottamuksellisesta asiakkaasta vaatii myös omistajan tai erillisen oikeuden, ja jokainen tällainen siirto kirjataan lokiin.

Näin tarkistat työkalusi: rajaa yksi asiakas yhdelle henkilölle. Sitten, jonakin toisena, aja jokainen raportti, katso jokainen lukumäärä ja suodatin, hae asiakkaan nimeä ja avaa suora linkki yhteen sen projekteista. Jälkeäkään ei pitäisi löytyä, ei virheilmoituksessakaan.

Virhe 4: myöhempi hyväksyntä saattoi piilottaa hylkäyksen

Viikolla voi olla kirjauksia useissa projekteissa, joten sen hyväksyy useampi ihminen. Jos yksi projektin ylläpitäjä hylkäsi kirjauksen ja toinen hyväksyi myöhemmin oman osansa, myöhempi hyväksyntä saattoi päättää koko viikon ja peittää hylkäyksen. Kirjausten siirtäminen tehtävien välillä tai viikon avaaminen uudelleen saattoi piilottaa sen samalla tavalla.

24. syyskuuta 2026 hyväksyntälogiikka muutettiin niin, että viikko pysyy hylättynä niin kauan kuin yksikin hylätty kirjaus on voimassa, ja projektin ylläpitäjä voi arkistoida hylätyn kirjauksen vain, jos hylkäsi sen itse. Tietokantakoetin ajaa nyt jokaisen näistä tapauksista, ja jokaisen on luettava PASS.

Näin tarkistat työkalusi: käytä kahta hyväksyjää yhdellä viikolla. Hylkää yksi kirjaus ensimmäisenä, hyväksy kaikki muu toisena ja katso, missä tilassa viikko päätyy.

Osta vai rakenna tuntiseuranta tilintarkastusyhteisölle?

Osta ensin. Toggl, BigTime, ZenWorkflow ja vastaavat työkalut kattavat jo ajastimet, viikoittaiset hyväksynnät ja asiakaslaskutuksen, ja niillä pääsee alkuun jo tällä viikolla. Räätälöity seurantatyökalu on järkevä, kun yhteisöllä on sääntöjä, joita tuotteet eivät osaa ilmaista, esimerkiksi luottamukselliset asiakkaat, jotka näkyvät vain nimetyille jäsenille, viikon hyväksyntä usean projektin ylläpitäjän toimesta tai roolit, jotka omistaja haluaa muotoilla ruutu kerrallaan.

Kumman tien valitsetkin, neljä yllä olevaa tarkistusta vievät iltapäivän ja kertovat enemmän kuin ominaisuuslista. Jokaisella tuotesivulla lukee “hienojakoiset oikeudet”. Harva näyttää, mitä tapahtuu, kun poistat rastin.

Tämän kirjoituksen rajat

• Yksi yhteisö. Käyttöoikeusmalli, noin 70 kirjauksen viikkomäärä ja kysely ovat yhdestä yhteisöstä.
• Virhe 1 pyydystettiin ennen kuin se laukesi. Marraskuun puolivälin päivämäärä on ennuste yhteisön kirjausvauhdista, ei mitattu tapaus.
• Ei laskutusta. Seurantatyökalu pitää sisällään tunnit, laskutustavan ja tuntibudjetit mutta ei laskuta asiakkaita, joten en voi sanoa mitään ajasta laskuun -kuluista.

Tässä käytetyt käyttöoikeussäännöt ovat Postgresin rivitason tietoturvaa. Kaksi aukkoa, joita roolimatriisi ei havaitse, on kirjoitettu erikseen: käyttäjä, joka kuuluu kahteen organisaatioon ja IF, joka ohittaa tarkistuksen NULLilla. Itse rakennus on tilintarkastusyhtiön ajanseurannan tapauksessa, ja tällainen työ kuuluu sisäisiin työkaluihin ja koontinäyttöihin.