El artículo 8 del RD 1007/2023 exige al SIF integridad, conservación, accesibilidad, legibilidad, trazabilidad e inalterabilidad, con exportación a un almacenamiento externo en formato electrónico legible. Artículo 8 del RRSIF. La norma formula requisitos tecnológicos neutrales y no declara conforme, homologa ni recomienda por sí sola una arquitectura local o en la nube.
Por tanto, «está en la nube» no responde a la pregunta decisiva. Hay que saber qué versión del sistema genera el registro, dónde quedan sus copias, quién puede recuperarlas, qué ocurre al terminar el contrato y cómo se entrega una copia ante un requerimiento. Un proveedor conocido, una pantalla con un QR o una frase comercial sobre cumplimiento no prueban por sí solos esos extremos.
Esta guía se limita a la conservación y al acceso de registros de facturación en un SIF alojado en la nube. No compara marcas ni sustituye el análisis del ámbito subjetivo del RRSIF, de la obligación de facturar, del SII, de la normativa foral o de la situación concreta de la empresa.
La respuesta corta: la nube es un medio, no una garantía
Concluir que una solución alojada en la nube puede cumplir es una inferencia editorial condicionada: hay que verificar que el SIF, su versión, sus componentes y su instalación concreta satisfacen todos esos requisitos. El artículo 8 no homologa la arquitectura en la nube. Base normativa de la inferencia.
La norma formula requisitos funcionales. Un servicio remoto puede satisfacerlos, igual que una instalación local puede incumplirlos. La evaluación debe recaer en el sistema, su versión, sus componentes y su instalación real. La AEAT explica que la declaración responsable identifica precisamente esos elementos y los datos del productor; no es una homologación general de todo servicio que use el mismo nombre comercial criterio oficial sobre la declaración responsable.
Conviene separar cuatro capas. La primera es el SIF que genera los registros. La segunda es la infraestructura donde se ejecuta y almacena. La tercera son conectores, copias y herramientas de exportación. La cuarta es la organización del usuario: permisos, procedimientos, conciliación y respuesta a incidencias. El cumplimiento puede fallar en cualquiera de ellas, aunque las demás estén bien diseñadas.
La etiqueta VERI*FACTU describe la modalidad que remite los registros a la sede de la AEAT. No convierte a la Agencia en administradora del ERP, custodio de toda la documentación contable ni garante de que la empresa pueda reconstruir su operativa. La empresa sigue necesitando facturas, datos maestros, conciliaciones y un plan de continuidad.
Qué exige realmente el artículo 8
El sistema debe proteger seis propiedades relacionadas: integridad, conservación, accesibilidad, legibilidad, trazabilidad e inalterabilidad. No son sinónimos. Una copia puede conservarse y, sin embargo, resultar ilegible; un fichero puede abrirse y no permitir seguir la secuencia; un PDF puede parecer correcto y no ser el registro estructurado que generó el SIF.
El artículo 8 exige que los registros queden encadenados y correctamente fechados, de manera que pueda seguirse su secuencia desde el primero hasta el último. Prohíbe funcionalidades que alteren u oculten ese rastro artículo 8.2.b. En la nube, esto obliga a comprobar algo más que la retención de archivos: hay que preservar cadenas, fechas, huellas y relaciones entre altas y anulaciones.
La conservación tampoco equivale a mantener activa una cuenta. El sistema ha de contar con descarga, volcado y archivo seguro, y los registros deben poder exportarse a almacenamiento externo en formato electrónico legible. Esa salida reduce la dependencia del proveedor, pero solo sirve si se prueba y si incluye los elementos necesarios para interpretar y verificar los registros.
Una exportación de facturas en PDF es útil para consulta humana, aunque puede no contener la estructura, el encadenamiento y los metadatos del registro de facturación. Pide al proveedor que identifique formatos, esquemas, alcance y documentación. Ejecuta una exportación real con un periodo representativo, no una demostración preparada con tres documentos.
VERIFACTU y NO VERIFACTU no conservan igual
En modalidad VERI*FACTU, el SIF remite los registros de forma continuada a la AEAT. La Administración explica que esta remisión evita su alteración posterior y asegura su conservación en sede modalidades de cumplimiento. Esto reduce parte de la carga técnica asociada a custodiar registros, pero no elimina la necesidad empresarial de acceder a la facturación ni convierte el envío en una copia completa de todos los datos del negocio.
En modalidad NO VERI*FACTU, el sistema no remite de manera ordinaria todos los registros. Como contrapartida, soporta requisitos adicionales, entre ellos la firma de registros y el registro de eventos. Si una empresa valora un SaaS que permite ambas modalidades, debe confirmar qué cambia al elegir una: almacenamiento, firma, eventos, exportación, incidencias y evidencias disponibles.
No conviene diseñar el control contractual con una frase común para las dos. En VERIFACTU importan especialmente la cola de envío, las respuestas y la continuidad durante cortes de conexión. En NO VERIFACTU pesa más la custodia íntegra a largo plazo y el acceso al registro de eventos. En ambos casos, el SIF debe generar el registro de alta simultáneamente o inmediatamente antes de expedir cada factura artículo 9.
Quién responde cuando interviene un proveedor en la nube
El artículo 8 exige que una alteración de los registros sea detectada y avisada por el SIF. Fuente oficial. Por separado, la AEAT indica que delegar materialmente el cumplimiento en un tercero no exime al obligado tributario de la responsabilidad sobre ese cumplimiento. Criterio oficial sobre delegación.
La frase requiere un matiz. La AEAT también indica que quien usa un sistema respaldado por la correspondiente declaración responsable no responde del incorrecto funcionamiento imputable al sistema; esa responsabilidad puede corresponder al fabricante conforme al artículo 201 bis de la LGT información oficial sobre certificación. Esto no autoriza al usuario a desentenderse de sus propias decisiones: emitir bien, asignar permisos, no manipular, atender requerimientos y conservar documentación siguen siendo tareas suyas.
Por eso el contrato debe repartir hechos concretos, no prometer genéricamente “cumplimiento total”. Diferencia defecto del software, indisponibilidad de infraestructura, error de configuración, dato erróneo introducido por el usuario y actuación de un tercero integrado. Define quién detecta, comunica, contiene, recupera y documenta cada supuesto.
Un acuerdo de nivel de servicio puede fijar disponibilidad y tiempos de respuesta. No demuestra por sí solo que los registros estén íntegros. De igual modo, una copia diaria no prueba que pueda restaurarse ni cuánto trabajo se perdería. Pide objetivos de recuperación, frecuencia, retención, redundancia y procedimiento de salida, y compruébalos con pruebas.
El acceso de Hacienda no es acceso indiscriminado a la nube
La Administración tributaria puede requerir una copia electrónica de los registros conservados, que se suministrará mediante soporte físico o envío seguro conforme a la LGT y al reglamento de aplicación de los tributos artículo 14 del RRSIF. El SIF también debe disociar el acceso a la información con trascendencia tributaria de la información confidencial no patrimonial.
Esto no significa que haya que entregar credenciales maestras del proveedor o abrir toda la infraestructura sin límites. Significa que la organización necesita una ruta fiable para consultar y obtener los registros afectados por una actuación, con su estructura y evidencias, y entregarlos por el canal procedente. El alcance concreto dependerá del requerimiento y de las facultades ejercidas.
Prepara un procedimiento con responsables suplentes. Debe explicar cómo localizar un obligado, periodo, serie y registro; cómo comprobar la integridad de la exportación; qué documentación acompaña al fichero; y quién autoriza la entrega. Si el proceso depende de una sola persona o de un ticket sin plazo comprometido, existe un riesgo operativo evitable.
Un mismo sistema puede servir a varios obligados solo si sus registros están diferenciados y los requisitos se cumplen por separado para cada uno artículo 7.a. En un SaaS multiempresa, prueba que un administrador no puede mezclar exportaciones, secuencias o credenciales. La separación visual entre pestañas no basta: revisa filtros, permisos y salida de datos.
Un proceso de evaluación que se pueda repetir
Revisa contrato, ubicación y roles, prueba exportación y restauración, verifica copias y documenta el acceso de inspección. Fuente oficial.
Empieza por dibujar el circuito real. Identifica qué aplicación crea la factura, cuándo genera el registro, qué conectores intervienen, dónde queda la cola y dónde se almacenan las copias. Si un ERP envía datos a otro módulo, averigua cuál es el SIF y qué ocurre cuando el enlace falla.
Después solicita la declaración responsable de la versión contratada. Debe identificar sistema, versión, composición, funcionalidades e instalación AEAT. Contrasta esos datos con tu despliegue: módulos, personalizaciones, conectores y modalidad. Una declaración de otra versión no cierra la revisión.
Construye un lote de prueba con factura ordinaria, simplificada si procede, rectificación, anulación, fallo de red y usuario sin permisos. Comprueba factura, QR, registro, encadenamiento, respuesta de envío y recuperación. Usa datos ficticios y documenta versión y fecha.
Exporta un periodo completo. Abre el resultado fuera del SaaS, verifica que es legible y que puede relacionarse con las facturas. Guarda la documentación técnica necesaria para interpretar el formato. Luego simula una restauración o, si el proveedor no permite restaurar en autoservicio, exige evidencia del procedimiento y sus tiempos.
Finalmente, ensaya una salida. Pregunta qué recibirá la empresa si cancela mañana, cuánto tiempo estará disponible, qué coste tiene, cómo se autentica la entrega y cuándo se borran las copias residuales. No esperes a una baja conflictiva para descubrir que la exportación completa necesita un desarrollo adicional.
Comparar arquitecturas sin caer en falsos atajos
Compara nube, copia local y alojamiento propio por recuperación, trazabilidad y control, no por la marca del proveedor SaaS. Fuente oficial.
La nube gestionada suele facilitar actualizaciones, redundancia y acceso distribuido. A cambio, aumenta la dependencia de identidad, conectividad, contrato y portabilidad. Una copia local controlada por la empresa añade una vía de salida, pero debe protegerse, actualizarse y comprobarse. El alojamiento propio ofrece más control directo y también transfiere a la empresa tareas de seguridad, disponibilidad y mantenimiento.
No hay una opción universal. Una microempresa sin personal técnico puede estar más protegida con un proveedor sólido y una exportación periódica que con un servidor olvidado. Una organización con gran volumen o integraciones críticas puede necesitar redundancia adicional, pruebas de recuperación y condiciones de salida más exigentes.
Puntúa cada alternativa con evidencias: tiempo para recuperar, pérdida máxima tolerable, exportación completa, legibilidad independiente, separación entre obligados, historial de cambios, soporte en incidentes y continuidad tras la baja. Añade coste total, incluida la verificación, no solo la cuota mensual.
Controles contractuales que sí ayudan
El contrato debería identificar servicio, versión o política de versiones, roles, ubicación o regiones aplicables, subencargados relevantes, copias, retención, exportación, asistencia ante requerimientos, incidentes y salida. Evita aceptar una cláusula que permita cambios materiales sin aviso si pueden alterar el SIF o su declaración responsable.
Define plazos medibles para entregar datos y colaborar en una incidencia. Reserva el derecho a obtener exportaciones durante el contrato y al terminarlo. Especifica formato y documentación, no solo “los datos del cliente”. Incluye continuidad cuando exista una disputa de facturación para que el bloqueo comercial no impida cumplir una obligación tributaria.
Pide notificación de cambios que afecten a versión, componentes o localización. Esto no exige congelar el SaaS: permite revisar los cambios relevantes. Conserva declaraciones responsables anteriores si se usaron para emitir facturas, junto con las fechas de despliegue.
El contrato no reemplaza la prueba técnica. Tampoco debe prometer acceso de la AEAT al conjunto de la plataforma: debe permitir al cliente atender solicitudes legítimas sobre sus registros. Coordina estas cláusulas con privacidad y seguridad, materias que tienen obligaciones propias.
Continuidad: qué hacer si el proveedor falla
Define primero qué significa “fallar”: indisponibilidad breve, pérdida de conexión, rechazo de registros, corrupción, cierre del proveedor o secuestro de cuenta. Cada escenario requiere una respuesta distinta. Un plan que solo dice “usar copias” no explica cómo seguir facturando ni cómo evitar duplicidades.
Mantén contactos de escalado y un inventario de administradores. Protege el acceso con autenticación robusta y cuentas nominales. Revisa periódicamente quién puede exportar, cambiar series o desactivar integraciones. Conserva fuera del SaaS la declaración responsable, el contrato, las actas de prueba y las instrucciones de recuperación.
Ante una caída, registra inicio, alcance, documentos afectados y actuaciones. No reemitas indiscriminadamente las facturas cuando vuelve el servicio. Concilia números, registros y respuestas; determina con soporte qué operaciones llegaron a generarse. Una recuperación apresurada puede crear duplicados o huecos.
Si el proveedor cesa, la salida preparada marca la diferencia. Debes poder recibir registros y documentación en tiempo útil, validar el conjunto y migrar sin alterar el historial. La nueva aplicación no debería reconstruir registros antiguos como si los hubiera generado originalmente.
Errores habituales al seleccionar un SaaS
El primero es confundir declaración responsable con certificación previa de la AEAT. La declaración la emite el productor bajo su responsabilidad. El segundo es revisar solo la factura visible e ignorar el registro estructurado. El tercero es aceptar una exportación que no se ha abierto fuera de la plataforma.
También es frecuente dejar la cuenta a nombre de un proveedor externo, no documentar administradores o usar un único acceso compartido. Otro error es asumir que la remisión VERI*FACTU sustituye toda conservación fiscal y contable. Finalmente, algunas empresas no prueban la baja: descubren demasiado tarde límites, costes o formatos propietarios.
La señal más útil de madurez no es un eslogan, sino la capacidad del proveedor para mostrar declaración responsable, arquitectura funcional, procedimiento de exportación, tratamiento de incidencias y condiciones de salida de forma coherente.
Límites que no debe ocultar una decisión tecnológica
Delegar materialmente el cumplimiento en un tercero no exime al obligado tributario de la responsabilidad sobre ese cumplimiento. Fuente oficial.
Esta guía no determina si una operación debe facturarse, si el obligado está excluido por SII, qué plazo de prescripción corresponde a un expediente concreto ni qué datos pueden transferirse internacionalmente. Tampoco garantiza que un proveedor cumpla por figurar en un listado comercial. Esas conclusiones exigen revisar hechos, contrato, versión y normativa aplicable.
Para delimitar antes el proyecto, consulta la guía madre de VERI*FACTU para pymes y el centro de recursos fiscal y contable. Si el punto de partida es todavía manual, revisa facturación sin programa. Las sociedades tienen además un análisis propio sobre software de facturación para sociedades, que no debe mezclarse con esta comparación de alojamiento.
Preguntas frecuentes
¿Se pueden guardar registros VERI*FACTU en la nube?
Sí. El RRSIF no prohíbe el alojamiento remoto. El SIF concreto debe garantizar las propiedades del artículo 8 y permitir descarga, volcado, archivo seguro y exportación legible. Comprueba versión, contrato y salida real; «en la nube» no es una prueba de cumplimiento.
¿Quién responde si falla el proveedor en la nube?
Depende de la causa. El productor puede responder por el funcionamiento incorrecto del sistema respaldado por su declaración responsable, mientras que el obligado conserva sus deberes propios de facturación, uso y colaboración. El contrato debe separar defecto de software, infraestructura, configuración y datos introducidos.
¿Qué acceso debe tener Hacienda a los registros?
La AEAT puede requerir una copia electrónica y ejercer las funciones previstas legalmente sobre la información tributaria. El SIF debe separar esta información de datos confidenciales no patrimoniales. No equivale a un acceso ilimitado a toda la cuenta en la nube; hay que atender el requerimiento concreto por el canal aplicable.
¿Qué controles contractuales debe exigir una pyme a su proveedor en la nube?
Como mínimo, conviene concretar versiones, roles, copias, recuperación, exportación, formatos, asistencia ante incidencias y requerimientos, cambios materiales y salida. Después hay que probarlo: una cláusula de portabilidad no sirve si nadie ha abierto ni conciliado la exportación.
Cerrar la decisión con una prueba, no con una promesa
Antes de contratar, ejecuta un ciclo completo y conserva la evidencia: declaración responsable, lote, exportación, restauración, incidencia y salida. Asigna un responsable y un suplente para el acceso. Programa revisiones al cambiar de versión, integración, modalidad o proveedor.
Si necesitas contrastar el circuito y sus controles con tu operativa, el servicio fiscal-contable puede ayudarte a Auditar un SIF alojado en la nube.
Contenido informativo general para España, revisado a 31 de agosto de 2026. No constituye asesoramiento fiscal, legal, contable, de protección de datos ni tecnológico individualizado.