Control de horas en auditoría: 4 errores silenciosos

Soy Denys, ingeniero full-stack y de IA. Entre mayo y octubre de 2026, una firma de auditoría pasó de una herramienta en la que todos podían abrir cualquier cliente a un sistema que construí solo para ella, en 388 commits. La firma no se nombra aquí. Este texto es para quienes dirigen una firma y eligen sus herramientas: qué necesita una firma de auditoría del registro de horas, los cuatro errores que encontré y cómo comprobar cualquier herramienta.

¿Qué necesita una firma de auditoría del control de horas?

Una firma de auditoría vende horas, así que el control de horas es el registro sobre el que descansa todo el negocio. La firma para la que construí necesitaba:

• Horas por cliente, proyecto y tarea. Cada entrada pertenece a un solo encargo, de modo que las horas se leen por cliente, por proyecto y por persona.
• Partes de horas semanales con aprobación. El personal envía la semana, el administrador del proyecto aprueba o rechaza cada entrada, y solo cuentan las horas aprobadas.
• Recordatorios. Quien tenga el parte de horas todavía vacío antes del plazo recibe un correo. Desde septiembre de 2026 solo avisa de las horas que faltan y omite a las personas con capacidad cero.
• Asignación de recursos. Quién trabaja en qué encargo en las próximas semanas, frente a la capacidad de cada persona.
• Clientes confidenciales. El propietario puede restringir un cliente, con sus proyectos, tareas y tiempo, a miembros elegidos.
• Archivar, nunca eliminar. Un miembro que se va se desactiva y se anonimiza, y un proyecto terminado se archiva, de modo que el historial de partes de horas queda intacto.

No emite facturas. El tipo de facturación y los presupuestos de horas de los proyectos están tras un permiso propio, y la facturación sigue en el sistema contable de la firma.

¿Quién debe ver las horas de quién en una firma de auditoría?

Antes de este proyecto, todos en la firma podían abrir cualquier cliente y las horas de cualquiera. Para una firma de auditoría eso es primero un problema de confidencialidad y luego uno de software: no todos los miembros deben ver todos los clientes, y nadie necesita ver la semana de un compañero salvo que la apruebe.

El modelo de acceso que la firma confirmó es este:

Rol	Ve	Puede aprobar
Colaborador	Solo sus propias horas	Nada
Admin de proyecto	Las horas del equipo en sus propios proyectos	Las semanas de su equipo en esos proyectos
Propietario	Todos los clientes, proyectos y personas	Todo
Cliente confidencial	Visible solo para los miembros que elige el propietario	—

El propietario da forma a cada rol en una matriz de casillas, área frente a acción, y cada regla vive en la base de datos y no en las pantallas, así que una página no puede mostrar lo que la base de datos rechaza. Cada casilla se probó contra una copia de producción antes del lanzamiento; cómo, y qué encontró esa prueba, está en cómo probar Supabase RLS.

Una pregunta que la matriz no podía responder vino de la propia firma. En junio de 2026, un miembro con el rol más limitado veía en la pantalla de asignación a otros miembros y sus proyectos, y esperaba ver solo a sí mismo y a un compañero. ¿Debe un miembro restringido ver a las personas de sus propios proyectos? La regla a la que llegamos: sí, solo en proyectos compartidos, con la capacidad y las ausencias de los demás ocultas.

¿Cómo se consigue un modelo de acceso con el que una firma esté de verdad de acuerdo? No pedí al cliente que lo describiera de memoria. Envié un cuestionario de 72 preguntas en 9 secciones, con las cuadrículas de permisos ya marcadas como funcionaba el sistema en vivo el 7 de agosto de 2026. El cliente corrigió lo que estaba mal y cada celda cambiada quedó señalada. La gente corrige la realidad mejor de lo que la describe.

Error 1: los totales de los informes saldrían demasiado bajos

La página Partes de horas tiene las vistas “Este trimestre” y “Año hasta la fecha” para toda la firma. Cargaban todas las entradas de tiempo del rango en una sola petición. La API de la base de datos detrás de la aplicación devuelve como máximo 1.000 filas por petición, y cuando se detiene en 1.000 no lanza ningún error. Solo devuelve las primeras 1.000.

Supabase documenta este valor por defecto: los proyectos devuelven como máximo 1.000 filas mientras no se cambie el límite en los ajustes de la API.

Así que, una vez que la firma superara las 1.000 entradas en un rango, miembros y semanas desaparecerían de la vista, y los totales saldrían demasiado bajos sin que nada en pantalla lo dijera. Con unas 70 entradas por semana, la vista del año hasta la fecha iba camino de superar las 1.000 entradas hacia mediados de noviembre de 2026. Una auditoría del código el 24 de septiembre de 2026 lo encontró antes de que ocurriera. La corrección lee cada rango página a página, y cada exportación de informes pagina ahora de la misma manera.

Cómo comprobar su herramienta: elija un rango largo, exporte las entradas en bruto, súmelas usted mismo y compare con el total del informe. Si no coinciden, el informe está recortando filas.

Error 2: “Guardado” cuando no se había guardado nada

Cuando la base de datos rechaza un cambio por un permiso, o porque una regla exige inicio de sesión con dos factores, puede responder “0 filas cambiadas” sin ningún error. Unos 30 lugares de la aplicación que actualizan o eliminan registros leían esa respuesta como éxito y mostraban “guardado”. La persona sigue con lo suyo. El cambio nunca ocurrió.

La corrección es fallar cerrado: una escritura que no toca ninguna fila es un error, se muestra como tal, y ahora una prueba comprueba que cada camino de escritura lo trata así.

Cómo comprobar su herramienta: inicie sesión como un miembro sin derecho a editar algo, intente editarlo y luego recargue la página. Si vio “guardado” y vuelve el valor anterior, la herramienta miente al guardar.

Error 3: un cliente confidencial se filtraba por los informes

Algunos encargos solo los conocen las personas que trabajan en ellos. Desde el 24 de agosto de 2026 el propietario puede restringir un cliente a miembros concretos. Todos los demás no reciben nada de ese cliente, sus proyectos, tareas o tiempo. El propietario siempre tiene acceso, y ese acceso se calcula según quién tiene hoy el rol de propietario, no se almacena, así que se mueve cuando se mueve el rol.

Ocultar el cliente de la lista de clientes fue la parte fácil. Las filtraciones estaban en las puertas laterales. Una revisión el 8 de septiembre de 2026 encontró que:

• tres funciones de informes ignoraban la restricción, porque se ejecutan con derechos que se saltan las reglas de acceso normales, de modo que las horas de un cliente confidencial podían aparecer en los informes;
• los contadores de uso de etiquetas en la vista de administración de etiquetas contaban los proyectos y tareas del cliente confidencial, lo que delataba que el encargo existía y más o menos su tamaño;
• los mensajes de error marcaban la diferencia: intentar cambiar un registro real pero oculto devolvía “forbidden”, y uno inventado devolvía “not found”, así que cualquiera podía sondear si existía un cliente confidencial.

Las tres aplican ahora la misma comprobación que las tablas principales, y un registro oculto se ve exactamente igual que uno inexistente. Mover un proyecto o una entrada fuera de un cliente confidencial también exige al propietario o un permiso específico, y cada movimiento así queda registrado.

Cómo comprobar su herramienta: restrinja un cliente a una sola persona. Luego, como otra persona, ejecute todos los informes, mire cada contador y cada filtro, busque el nombre del cliente y abra un enlace directo a uno de sus proyectos. No debería encontrar rastro alguno, tampoco en el mensaje de error.

Error 4: un rechazo podía quedar oculto por una aprobación posterior

Una semana puede tener entradas en varios proyectos, así que la aprueban varias personas. Si un administrador de proyecto rechazaba una entrada y otro aprobaba después su parte, la aprobación posterior podía cerrar toda la semana y enmascarar el rechazo. Mover entradas entre tareas o reabrir una semana podía ocultarlo del mismo modo.

El 24 de septiembre de 2026 se cambió la lógica de aprobación para que una semana siga rechazada mientras quede una entrada rechazada activa, y para que un administrador de proyecto solo pueda archivar una entrada rechazada si la rechazó él mismo. Una sonda de base de datos ejecuta ahora cada uno de estos casos, y todos deben decir PASS.

Cómo comprobar su herramienta: use dos aprobadores en una misma semana. Rechace una entrada como el primero, apruebe todo lo demás como el segundo y mire en qué estado termina la semana.

¿Comprar o construir el control de horas de una firma de auditoría?

Compre primero. Toggl, BigTime, ZenWorkflow y herramientas similares ya cubren cronómetros, aprobaciones semanales y facturación a clientes, y puede empezar con una esta misma semana. Un sistema a medida tiene sentido cuando la firma tiene reglas que los productos no saben expresar, por ejemplo clientes confidenciales visibles solo para miembros concretos, aprobación por varios administradores de proyecto en una misma semana, o roles que el propietario quiere moldear casilla a casilla.

Se decida como se decida, las cuatro comprobaciones de arriba llevan una tarde y dicen más que una lista de funciones. Toda página de producto habla de “permisos granulares”. Pocas muestran qué pasa cuando se desmarca una casilla.

Límites de este informe

• Una sola firma. El modelo de acceso, el volumen de unas 70 entradas por semana y el cuestionario son de una única firma.
• El error 1 se detectó antes de producirse. La fecha de mediados de noviembre es una proyección a partir del ritmo de entradas de la firma, no un incidente medido.
• Sin facturación. El sistema guarda horas, tipo de facturación y presupuestos de horas pero no factura a los clientes, así que no puedo opinar sobre los flujos del tiempo a la factura.

Las reglas de acceso aquí son row level security de Postgres. Dos huecos que una matriz de roles no detecta están escritos aparte: un usuario que pertenece a dos organizaciones y un IF que falla abierto con NULL. La construcción en sí está en el caso del seguimiento de horas para una firma de auditoría, y este tipo de trabajo entra en herramientas internas y paneles.