Timesheet per società di revisione: 4 errori silenziosi

Sono Denys, ingegnere full-stack e di IA. Tra maggio e ottobre 2026 una società di revisione è passata da uno strumento in cui tutti potevano aprire ogni cliente a un sistema di timesheet che ho costruito solo per lei, in 388 commit. La società qui non è nominata. Questo testo è per chi dirige uno studio e sceglie i suoi strumenti: di cosa ha bisogno una società di revisione dalla rilevazione delle ore, i quattro errori che ho trovato e come controllare un qualsiasi sistema.

Di cosa ha bisogno una società di revisione dalla rilevazione delle ore?

Una società di revisione vende ore, quindi la rilevazione delle ore è il registro su cui poggia tutta l’attività. Lo studio per cui ho costruito il sistema aveva bisogno di:

• Ore per cliente, progetto e attività. Ogni voce appartiene a un incarico, così le ore si leggono per cliente, per progetto e per persona.
• Timesheet settimanali con approvazione. Il personale invia la settimana, l’amministratore del progetto approva o respinge ogni voce, e contano solo le ore approvate.
• Promemoria. Chi ha ancora il timesheet vuoto prima della scadenza riceve un’email. Da settembre 2026 sollecita solo le ore mancanti e salta chi ha capacità zero.
• Pianificazione delle risorse. Chi lavora su quale incarico nelle settimane successive, rispetto alla capacità di ciascuno.
• Clienti riservati. Il titolare può limitare un cliente, con i suoi progetti, attività e ore, a membri scelti.
• Archiviare, mai eliminare. Un membro che se ne va viene disattivato e anonimizzato, e un progetto concluso viene archiviato, così lo storico dei timesheet resta intatto.

Non emette fatture. Il tipo di fatturazione e i budget di ore dei progetti stanno dietro un permesso a parte, e la fatturazione resta nel sistema contabile dello studio.

Chi deve vedere le ore di chi in una società di revisione?

Prima di questo progetto, tutti nello studio potevano aprire ogni cliente e le ore di tutti. Per una società di revisione è un problema di riservatezza prima che di software: non ogni membro deve vedere ogni cliente, e nessuno ha bisogno di vedere la settimana di un collega a meno che non la approvi.

Il modello di accesso confermato dallo studio è questo:

Ruolo	Vede	Può approvare
Membro del personale	Solo le proprie ore	Nulla
Amministratore del progetto	Le ore del team sui propri progetti	Le settimane del team su quei progetti
Titolare	Ogni cliente, progetto e persona	Tutto
Cliente riservato	Visibile solo ai membri scelti dal titolare	—

Il titolare modella ogni ruolo in una matrice di caselle, area per azione, e ogni regola vive nel database e non nelle schermate, quindi una pagina non può mostrare ciò che il database rifiuta. Ogni casella è stata testata su una copia di produzione prima del rilascio; come, e cosa ha trovato quel test, è in come testare la Supabase RLS.

Una domanda a cui la matrice non sapeva rispondere è arrivata dallo studio stesso. A giugno 2026 un membro con il ruolo più limitato ha visto altri membri e i loro progetti nella schermata di pianificazione, e si aspettava di vedere solo sé stesso e un collega. Un membro con restrizioni deve vedere le persone dei propri progetti? La regola su cui ci siamo accordati: sì, solo sui progetti condivisi, con la capacità e le assenze degli altri nascoste.

Come si arriva a un modello di accesso con cui uno studio è davvero d’accordo? Non ho chiesto al cliente di descriverlo a memoria. Ho inviato un questionario di 72 domande in 9 sezioni, con le griglie dei permessi già spuntate come il sistema in uso le aveva il 7 agosto 2026. Il cliente ha corretto ciò che era sbagliato, e ogni cella modificata è stata segnalata. Le persone correggono la realtà meglio di quanto la descrivano.

Errore 1: i totali dei report sarebbero usciti troppo bassi

La pagina dei timesheet ha le viste “Questo trimestre” e “Da inizio anno” per tutto lo studio. Caricavano ogni voce di tempo dell’intervallo in una sola richiesta. L’API del database dietro l’app restituisce al massimo 1000 righe per richiesta e, quando si ferma a 1000, non solleva alcun errore. Restituisce semplicemente le prime 1000.

Supabase documenta questo valore predefinito: i progetti restituiscono al massimo 1000 righe, finché il limite non viene cambiato nelle impostazioni dell’API.

Quindi, una volta superate le 1000 voci in un intervallo, membri e settimane sarebbero spariti dalla vista, e i totali sarebbero usciti troppo bassi senza nulla sullo schermo a segnalarlo. Con circa 70 voci a settimana, la vista da inizio anno era sulla strada per superare le 1000 voci intorno a metà novembre 2026. Un audit del codice il 24 settembre 2026 l’ha trovato prima che accadesse. La correzione legge ogni intervallo pagina per pagina, e ogni esportazione dei report ora pagina allo stesso modo.

Come controllare il suo strumento: scelga un intervallo lungo, esporti le voci grezze, le sommi da sé e confronti con il totale del report. Se i due valori differiscono, il report taglia delle righe.

Errore 2: “Salvato” quando non era stato salvato nulla

Quando il database rifiuta una modifica a causa di un permesso, o perché una regola richiede l’accesso a due fattori, può rispondere “0 righe modificate” senza alcun errore. Circa 30 punti dell’app che aggiornano o eliminano record leggevano quella risposta come un successo e mostravano “salvato”. La persona va avanti. La modifica non è mai avvenuta.

La correzione è fallire in modo chiuso: una scrittura che non tocca nessuna riga è un errore, mostrato come tale, e un test ora verifica che ogni percorso di scrittura lo tratti così.

Come controllare il suo strumento: acceda come membro senza il diritto di modificare qualcosa, provi a modificarlo, poi ricarichi la pagina. Se ha visto “salvato” e il vecchio valore è tornato, lo strumento mente sui salvataggi.

Errore 3: un cliente riservato trapelava dai report

Alcuni incarichi sono noti solo alle persone che ci lavorano. Dal 24 agosto 2026 il titolare può limitare un cliente a membri indicati. Tutti gli altri non ricevono nulla su quel cliente, sui suoi progetti, attività o ore. Il titolare ha sempre accesso, e quell’accesso viene calcolato da chi ha oggi il ruolo di titolare, non memorizzato, quindi si sposta quando si sposta il ruolo.

Nascondere il cliente dall’elenco dei clienti è stata la parte facile. Le fughe erano nelle porte laterali. Una revisione l’8 settembre 2026 ha trovato che:

• tre funzioni dei report ignoravano la restrizione, perché girano con diritti che saltano le normali regole di accesso, quindi le ore di un cliente riservato potevano comparire nei report;
• i conteggi d’uso dei tag nella panoramica di amministrazione contavano i progetti e le attività del cliente riservato, rivelando che l’incarico esisteva e più o meno quanto fosse grande;
• i messaggi di errore facevano la differenza: provare a modificare un record reale ma nascosto restituiva “vietato”, provare con uno inventato restituiva “non trovato”, quindi chiunque poteva sondare se un cliente riservato esistesse.

Ora tutte e tre applicano lo stesso controllo delle tabelle principali, e un record nascosto appare identico a uno mancante. Spostare un progetto o una voce fuori da un cliente riservato richiede inoltre il titolare o un permesso dedicato, e ogni spostamento viene registrato.

Come controllare il suo strumento: limiti un cliente a una sola persona. Poi, come qualcun altro, esegua ogni report, guardi ogni conteggio e filtro, cerchi il nome del cliente e apra un link diretto a uno dei suoi progetti. Non deve trovare alcuna traccia, nemmeno nel messaggio di errore.

Errore 4: un rifiuto poteva essere nascosto da un’approvazione successiva

Una settimana può avere voci su più progetti, quindi più persone la approvano. Se un amministratore di progetto respingeva una voce e un altro approvava poi la sua parte, l’approvazione successiva poteva chiudere l’intera settimana e mascherare il rifiuto. Spostare voci tra attività o riaprire una settimana poteva nasconderlo allo stesso modo.

Il 24 settembre 2026 la logica di approvazione è cambiata: una settimana resta respinta finché esiste una voce respinta ancora attiva, e un amministratore di progetto può archiviare una voce respinta solo se l’ha respinta lui stesso. Una sonda sul database ora esegue ciascuno di questi casi, e ognuno deve dare PASS.

Come controllare il suo strumento: usi due approvatori su una settimana. Respinga una voce come il primo, approvi tutto il resto come il secondo e veda in che stato finisce la settimana.

Comprare o costruire la rilevazione delle ore per una società di revisione?

Prima compri. Toggl, BigTime, ZenWorkflow e strumenti simili coprono già timer, approvazioni settimanali e fatturazione ai clienti, e si può cominciare con uno già questa settimana. Un sistema su misura ha senso quando lo studio ha regole che i prodotti non sanno esprimere, per esempio clienti riservati visibili solo a membri indicati, approvazione da parte di più amministratori di progetto per settimana, o ruoli che il titolare vuole modellare casella per casella.

In ogni caso, i quattro controlli qui sopra richiedono un pomeriggio e dicono più di un elenco di funzionalità. Ogni pagina di prodotto dice “permessi granulari”. Poche mostrano cosa succede quando si toglie la spunta a una casella.

Limiti di questo resoconto

• Un solo studio. Il modello di accesso, il volume di circa 70 voci a settimana e il questionario vengono da un’unica società.
• L’errore 1 è stato colto prima che scattasse. La data di metà novembre è una proiezione dal ritmo di voci dello studio, non un incidente misurato.
• Nessuna fatturazione. Il sistema contiene ore, tipo di fatturazione e budget di ore ma non fattura i clienti, quindi non posso parlare dei flussi dal tempo alla fattura.

Le regole di accesso qui sono row level security di Postgres. Due falle che una matrice dei ruoli non vede sono descritte a parte: un utente che appartiene a due org e un IF che si apre su NULL. La costruzione vera e propria è nel caso del time tracking per una società di revisione, e questo tipo di lavoro rientra negli strumenti interni e dashboard.