Fichaje offline: qué es y por qué tu app debe funcionar sin cobertura

Si tu equipo trabaja en obras, almacenes, rutas de reparto o sótanos de centros comerciales, conoces bien el momento: el trabajador abre la app para fichar y el sistema responde con un icono de carga que no avanza. Sin cobertura. Sin wifi. Sin fichaje. Más tarde alguien anota la hora de memoria o, directamente, el fichaje queda sin registrar.

Eso no es un problema menor. Es un agujero en el registro de jornada que, ante una inspección de la Inspección de Trabajo y Seguridad Social (ITSS), puede ser exactamente tan grave como no registrar en absoluto. El fichaje offline no es un capricho técnico: es una condición necesaria para que el registro sea real, completo y verificable.

Qué es el fichaje offline

El fichaje offline es el registro de la entrada o la salida que se produce en el propio dispositivo, sin conexión a internet, y que se sincroniza con el servidor más tarde conservando la hora real en que ocurrió.

La definición tiene dos mitades y las dos importan:

Se registra sin red. El fichaje existe desde el momento en que el trabajador lo hace, no desde el momento en que hay cobertura.
Conserva su hora original. Cuando sube al servidor, lleva la marca temporal del instante real, no la de la sincronización.

Un sistema que cumple solo la primera mitad guarda el intento pero acaba sellando la hora equivocada. Uno que no cumple ninguna simplemente no registra: el trabajador se queda fuera del registro y la empresa, con un hueco que tendrá que explicar.

En el resto del artículo: por qué el offline importa más de lo que parece, qué significa exactamente una arquitectura «offline-first» (y qué no significa), cómo se conserva la integridad del fichaje hecho sin conexión y qué debes preguntar a cualquier proveedor antes de firmar.

El problema real: obras, rutas y sótanos donde no hay red al fichar

La conectividad en España está lejos de ser uniforme. Según los datos del Observatorio Nacional de Tecnología y Sociedad (ONTSI), hay zonas rurales, polígonos industriales y edificios con estructura metálica o subterránea donde la señal 4G es intermitente o directamente inexistente. Para las empresas con trabajadores en movilidad, esto no es una excepción: es el entorno habitual. Cómo se organiza el fichaje de esas plantillas está desarrollado en fichaje de trabajadores móviles sin oficina.

Los escenarios más frecuentes donde el fichaje sin conexión es imprescindible son:

Construcción y obra civil: un trabajador en una planta baja o en túneles de instalaciones puede no tener cobertura durante horas. La jornada empieza y acaba independientemente de si hay red.
Logística y reparto: los repartidores entran y salen de almacenes, garajes y zonas de carga donde el móvil no tiene señal. Un fichaje al inicio de turno puede hacerse en el exterior; la salida, en un punto ciego.
Mantenimiento industrial: técnicos que trabajan en salas de máquinas, subestaciones eléctricas o instalaciones subterráneas donde las señales de radio son atenuadas estructuralmente.
Hostelería y retail en centros comerciales: los vestuarios y zonas de personal de los centros comerciales grandes suelen estar en sótano, lejos de los puntos de acceso wifi y con cobertura degradada.
Agricultores y trabajadores de campo: en zonas rurales remotas, la cobertura puede fallar incluso en exterior.

En todos estos casos, si la aplicación no es capaz de registrar el fichaje localmente y sincronizarlo después, el trabajador queda fuera de registro. Eso puede tener consecuencias legales para la empresa —que tiene la obligación de garantizar el registro, no de intentarlo— y también para el propio trabajador, que puede ver sus horas no reconocidas.

Qué significa «offline-first» de verdad (y no «reintentar cuando vuelva la red»)

Aquí conviene ser precisos, porque hay dos aproximaciones técnicas muy distintas que el marketing de algunos proveedores presenta como equivalentes.

La aproximación reactiva: «reintentar cuando vuelva»

El enfoque más superficial consiste en que la aplicación detecta la pérdida de conexión, muestra un aviso («sin conexión, reintentando…») y espera a que la red se restablezca para enviar el fichaje al servidor. En algunos casos, almacena el intento localmente y lo reenvía automáticamente cuando hay señal.

Este enfoque tiene un problema fundamental: el registro no ocurre en el dispositivo, ocurre en el servidor. Mientras no hay conexión, no hay fichaje. Si el trabajador cierra la aplicación, el dispositivo se reinicia o transcurren varias horas antes de que haya conexión, el momento exacto del fichaje puede perderse o quedar registrado con la hora en que se sincronizó, no con la hora en que ocurrió.

La aproximación offline-first real

Una arquitectura offline-first invierte el orden de prioridades: el dispositivo es el origen del registro, no el servidor. Cuando el trabajador ficha, la aplicación genera un evento local —con marca de tiempo del dispositivo, identificador único, hash criptográfico y datos del contexto— y lo persiste localmente de forma inmediata. La sincronización con el servidor es posterior y automática, pero el fichaje ya existe con todos sus atributos antes de que haya red.

Esto cambia dos cosas fundamentales:

La hora registrada es la hora real del fichaje, no la hora de sincronización. Si la red tarda dos horas en recuperarse, el servidor recibirá el evento con la marca temporal de cuando se produjo, acompañada de la prueba criptográfica de que ese timestamp no ha sido manipulado.
El fichaje no puede perderse por problemas de red. Existe en el almacenamiento local del dispositivo hasta que el servidor lo confirma. Si el servidor no responde, el cliente no descarta el evento: lo reintenta con lógica de colas robusta.

La diferencia no es sutil. En una inspección de la ITSS, la pregunta relevante no es «¿intentó la aplicación registrar el fichaje?» sino «¿existe un registro completo e íntegro de las horas de inicio y fin de jornada de cada trabajador?». Solo el segundo enfoque puede responder «sí» de forma verificable.

Cómo se conserva la integridad del registro hecho sin conexión

El mayor recelo ante el fichaje offline es comprensible: si el registro ocurre en el dispositivo, sin supervisión del servidor, ¿quién garantiza que no ha sido manipulado? ¿Podría alguien cambiar la hora del dispositivo antes de fichar y registrar una entrada falsa?

Esta pregunta tiene respuesta técnica, y no requiere biometría ni grandes recursos de cómputo para resolverla.

Sellado de tiempo y contexto multifuente

Al generar el evento de fichaje, la aplicación recoge un conjunto de datos contextuales que van más allá del reloj del sistema: la hora del dispositivo, el identificador del chip NFC o código QR utilizado si el fichaje se hace por proximidad, los datos del sensor de movimiento en el momento del registro, la posición GPS si el trabajador la ha autorizado, y el estado de conexión de la red en ese instante. Estos datos se incluyen en el payload del evento y se firman juntos.

Si alguien manipula el reloj del dispositivo, los demás datos contextuales (acelerómetro, estado de red, token de turno) no coincidirán con el patrón esperado. No es una garantía absoluta ante un atacante sofisticado con acceso físico al dispositivo, pero sí frente a los vectores de fraude habituales en entornos laborales: cambiar manualmente la hora del móvil o anotar horas de memoria.

La cola offline como registro de auditoría

Los eventos generados offline se encolan en el almacenamiento local con su propio identificador secuencial y una referencia al evento anterior de la misma cola. Esto crea, en el propio dispositivo, una secuencia ordenada que el servidor puede verificar en la sincronización: si faltan eventos intermedios, si el orden es inconsistente o si los timestamps tienen saltos inexplicables, el sistema lo detecta.

La cadena de hash: qué es y por qué hace el registro verificable y no manipulable

Si el término «cadena de hash» te resulta críptico, la analogía más cercana es la del libro de actas con páginas numeradas y firmadas (el mecanismo, en detalle, está en la prueba criptográfica del registro de jornada). En ese libro, si alguien arranca una página o la sustituye, los números de página dejan de cuadrar y la firma de la página siguiente ya no corresponde al contenido de la anterior. Cualquiera puede detectar la manipulación.

Una hash-chain funciona de la misma manera, pero de forma criptográfica:

El primer fichaje del día genera un resumen matemático (hash) de su contenido: trabajador, tipo de evento, timestamp, datos contextuales.
El segundo fichaje incluye en su payload el hash del primero, y genera su propio hash incluyendo ese dato.
El tercer fichaje incluye el hash del segundo. Y así sucesivamente.

El resultado es una cadena en la que cada eslabón incluye una huella del eslabón anterior. Si alguien modifica cualquier registro —aunque sea cambiar un minuto en el timestamp del primer fichaje— el hash de ese registro cambia, lo que invalida el hash del siguiente, y del siguiente, y de todos los posteriores. La alteración es matemáticamente detectable.

Este mecanismo es el mismo que usan los sistemas de auditoría de bases de datos en entornos financieros y el que, presumiblemente, el borrador del Real Decreto de registro horario digital tiene en mente cuando exige «inalterabilidad técnicamente verificable» de los registros. El borrador del RD no está aún en vigor —a la fecha de este artículo no ha sido publicado en el BOE tras el dictamen contrario del Consejo de Estado de marzo de 2026—, pero la arquitectura de Tempika implementa este principio desde el diseño, no como adaptación posterior.

Lo que esto significa para una inspección

Cuando la ITSS solicita el historial de fichajes de un trabajador, el exportado de Tempika incluye no solo los eventos sino la prueba de integridad de la cadena: cualquier inspector o perito técnico puede verificar de forma independiente que los registros son idénticos a los que se generaron en el dispositivo, que ninguno ha sido modificado y que no falta ningún evento en la secuencia. Eso es lo que diferencia «trazable» de simplemente «almacenado». Lo que se pide en una visita, documento a documento, está en qué pide la Inspección de Trabajo sobre control horario.

Puedes leer más sobre los requisitos legales actuales y el estado del borrador del RD en nuestra guía completa de la ley de registro horario digital.

Diferencia entre «inalterable» técnico y promesas de marketing

El término «inalterable» se ha convertido en uno de los más usados —y más mal usados— en el marketing de herramientas de control horario. Vale la pena ser precisos sobre lo que significa y lo que no.

Qué significa «inalterable» técnicamente: Un registro es inalterable cuando existe un mecanismo matemático o criptográfico que hace detectable cualquier modificación posterior a su creación. No significa que nadie pueda intentar cambiarlo; significa que cualquier intento deja una huella verificable. La hash-chain es uno de esos mecanismos. El sello electrónico de entidad del propio proveedor —que actúa como tercero independiente del empresario— es otro, y es la dirección en la que avanza Tempika (en desarrollo); no se recurre a un prestador cualificado externo (QTSP), porque ni lo exige la ley ni hace falta cuando el proveedor ya es independiente del empresario.

Qué no significa «inalterable» en muchos productos del mercado: En muchos sistemas, «inalterable» significa simplemente que la interfaz de usuario no ofrece un botón de «editar» accesible al usuario estándar. Pero si el proveedor accede directamente a la base de datos, o si un administrador con acceso a la consola backend modifica el registro, no existe ningún mecanismo que lo detecte. El registro es técnicamente mutable; solo está protegido por las políticas de acceso.

Esta distinción es relevante porque una tabla de base de datos sin auditoría técnica —aunque tenga una contraseña robusta y una política de acceso estricta— no puede demostrar ante un perito judicial que sus datos no han sido modificados. Una hash-chain sí puede.

Qué debes preguntar: Cuando evalúes cualquier herramienta, estas preguntas separan el marketing de la técnica:

¿Dónde se genera el hash o sello de tiempo del fichaje: en el dispositivo del trabajador antes de la sincronización o en el servidor tras recibirlo?
¿Qué ocurre si un administrador modifica un fichaje desde el backend? ¿Queda registro del valor anterior, del usuario que lo modificó y de la fecha del cambio?
¿Puede el proveedor demostrar que sus propios ingenieros no pueden modificar un registro histórico sin que esa modificación quede registrada?
¿Se puede exportar la prueba de integridad junto con los registros, de forma que un tercero pueda verificarla de forma independiente?

Si el proveedor no tiene respuesta clara para estas preguntas, es probable que su «inalterabilidad» sea una promesa de interfaz, no una garantía técnica.

Qué preguntar al proveedor sobre pérdida de fichajes y duplicados

Hay dos escenarios de fallo que cualquier solución offline-first debe gestionar explícitamente, y que raramente aparecen en las demos comerciales.

Pérdida de fichajes

¿Qué ocurre si el trabajador ficha offline, y antes de que el dispositivo sincronice, el teléfono se pierde, se rompe o se formatea? Si el único almacenamiento del evento es el dispositivo local, el fichaje se pierde.

Una arquitectura robusta combina el almacenamiento local con sincronización periódica en segundo plano —incluso cuando la red es precaria— y con la posibilidad de recuperar los eventos pendientes si el trabajador inicia sesión desde otro dispositivo. Ninguna solución puede garantizar cero pérdida en escenarios de fallo físico del hardware, pero debe ser capaz de responder con precisión cuáles son sus garantías y en qué condiciones puede haber pérdida.

Duplicados

El escenario inverso también ocurre: el dispositivo envía el fichaje al servidor, no recibe confirmación por un problema de red puntual, y lo reenvía al recuperar la conexión. Si el servidor no tiene lógica de deduplicación por identificador único de evento, puede registrar el mismo fichaje dos veces.

Un duplicado de fichaje es tan problemático como una laguna: puede hacer que el sistema contabilice horas incorrectas, generar inconsistencias en los cuadrantes y, en una inspección, levantar sospechas sobre la fiabilidad del registro.

Preguntas directas que hacer al proveedor:

¿Cómo identifica el sistema de forma unívoca cada evento de fichaje para evitar duplicados en la sincronización?
¿Qué pasa si el trabajador ficha dos veces seguidas por error (doble toque)? ¿El sistema lo detecta y lo descarta o registra dos entradas?
¿Qué pasa si el dispositivo envía el mismo evento diez veces por problemas de red? ¿El servidor es idempotente?

La respuesta a estas preguntas revela el nivel de madurez técnica del producto detrás del nombre comercial.

Cómo evaluar una solución: más allá del «funciona sin internet»

La mayoría de las aplicaciones de fichaje del mercado dicen «funcionar sin internet». Pocas especifican en qué condiciones, con qué garantías y qué ocurre exactamente cuando la red falla. Las diferencias que importan para sectores como construcción, logística o hostelería están en esos detalles.

Un checklist práctico para evaluar cualquier solución:

Momento de generación del registro: ¿ocurre en el dispositivo (offline-first) o en el servidor (online-required)?
Integridad técnica del evento offline: ¿hash, firma o sello de tiempo generado antes de la sincronización?
Timestamp verificable: ¿la hora del fichaje es la del dispositivo en el momento del evento, no la de la sincronización?
Deduplicación: ¿el sistema es idempotente ante reenvíos por problemas de red?
Auditabilidad de correcciones: si RRHH corrige un fichaje, ¿queda el valor original, el nuevo, el usuario y la fecha del cambio?
Exportación de prueba de integridad: ¿se puede exportar junto con los registros la evidencia que permite verificarlos de forma independiente?

Si estás evaluando alternativas al mercado actual, en nuestra comparativa alternativa a Sesame HR analizamos cómo se posicionan las principales herramientas en estos aspectos.

Conclusión: el offline no es una funcionalidad secundaria

Para muchas empresas, la app de fichaje tiene que funcionar exactamente en los lugares donde el móvil no tiene cobertura. Un sistema que solo registra cuando hay red no es una solución de fichaje completa: es una solución de fichaje con excepciones, y las excepciones en el registro de jornada tienen nombre legal: incumplimiento del artículo 34.9 del Estatuto de los Trabajadores.

El fichaje offline-first resuelve el problema de raíz: el registro ocurre en el dispositivo, con integridad criptográfica, y se sincroniza cuando hay red. La cadena de hash garantiza que lo que llegó al servidor es exactamente lo que se generó en el momento del fichaje. No hay margen para perder eventos por problemas de conectividad ni para manipular registros sin dejar huella.

Si tu empresa trabaja en entornos con cobertura intermitente o directamente inexistente, este no es un detalle técnico menor: es el criterio que debería encabezar la evaluación de cualquier herramienta.

Puedes ver cómo Tempika implementa este enfoque en la página de producto de Tempika o consultar los planes y precios disponibles de Tempika. Si tienes dudas sobre el cumplimiento legal en tu sector, el área de cumplimiento normativo resuelve las preguntas más frecuentes.

Artículo elaborado por el Equipo Tempika. El contenido es de carácter divulgativo y no constituye asesoramiento jurídico. Para situaciones concretas, consulta con un asesor laboral especializado.