VeriFactu & Systema
La arquitectura más robusta en facturación electrónica, diseñada para el cumplimiento estricto de la normativa vigente. Datos independientes por cliente, acceso blindado y cada factura sellada, firmada y vinculada a la anterior de forma irreversible.
01 · Qué es VeriFactu?
La Ley de Medidas de Prevención y Lucha contra el Fraude Fiscal (Ley 11/2021) exige que cualquier software de facturación garantice mínimo tres propiedades sobre cada registro emitido. Systema los cumple y va más allá: base de datos aislada por cliente, tokens criptográficos de 256 bits y autenticación de correo certificada, en definitiva más capas de seguridad que la ley no exige pero que protegen al cliente.
Las 4 caracteristicas son:
Inalterabilidad
Una factura registrada no puede modificarse sin dejar rastro. Cualquier cambio posterior genera un registro de anulación, nunca una sobreescritura silenciosa.
Trazabilidad
Cada factura encadena criptográficamente con la anterior. Cualquier alteración retroactiva rompe la integridad del conjunto y es detectable de forma inmediata.
Envío en tiempo real
Remisión automática de registros de facturación a la AEAT en el momento de emisión. Generación de XML firmado conforme al esquema oficial.
Fase B · Agosto 2026QR de verificación
Cada factura incluye un código QR que permite al receptor verificar su autenticidad. Generado en base64 e incrustado directamente en el PDF.
01a · Seguridad 256 bits
El siguiente diagrama muestra la arquitetura diseñada y el registro a registro, cómo cada factura queda encadenada a la anterior mediante su huella de seguridad encriptada SHA-256. Si alguien modificara un dato, importe, fecha, NIF la cadena entera se rompe y el fraude es detectable de forma inmediata.
01b · Factura VeriFactu en producción
El siguiente documento es una factura real emitida con Systema. Cada elemento —número de serie, QR de verificación, datos fiscales— forma parte de la cadena de integridad VeriFactu Fase A.
Anatomía del enlace seguro
El enlace que recibe el cliente en su correo electrónico no expone ningún identificador secuencial. El acceso al documento está protegido por un token criptográfico único generado en el momento de emisión:
Documento real emitido con Systema
Factura SR2026-0001 emitida por Sondejos Riudoms S.L. — instalación de prueba en producción. El QR superior permite verificar la autenticidad del documento. El pie de página confirma que el documento ha sido generado electrónicamente.
02 · Declaración Responsable del Desarrollador
De conformidad con lo dispuesto en el Reglamento de Facturación vigente, el desarrollador del software emite la siguiente declaración responsable:
El sistema no permite la modificación ni eliminación de facturas registradas sin dejar rastro auditable. La integridad de la cadena de registros se verifica mediante SHA-256. Ninguna instalación puede emitir facturas fuera de la secuencia numerada ni con datos fiscales alterados retroactivamente.
03 · Arquitectura Zero-Trust
La seguridad de Systema no se implementa como una capa adicional. Es la arquitectura base. Cada decisión de diseño elimina una clase entera de vulnerabilidades por construcción.
Aislamiento total — Una base de datos por cliente
La mayoría de plataformas SaaS almacenan los datos de todos sus clientes en una única base de datos, separados únicamente por un campo tenant_id. Un error en una consulta puede exponer datos de múltiples clientes simultáneamente.
Systema opera con un modelo diferente. Cada instalación dispone de su propia base de datos independiente. Los datos de una instalación nunca están en el mismo contenedor que los de otra. La propagación entre instalaciones es imposible por diseño.
Autenticación en tres capas independientes
El sistema implementa tres capas de autenticación completamente desacopladas. El compromiso de una capa no afecta a las restantes.
| Capa | Protege | Mecanismo | Estado |
|---|---|---|---|
| Capa 1 | Acceso al ERP | bcrypt + contraseña maestra como hash. Nunca almacenada en texto plano. | Activo |
| Capa 2 | Motor de actualizaciones | Sesión independiente. La credencial del ERP no da acceso al panel de actualizaciones. | Activo |
| Capa 3 | Panel de mantenimiento | Contraseña independiente. Acceso restringido al administrador técnico. | Activo |
04 · Tokens Criptográficos de Documento
Ningún documento en Systema es accesible a través de un identificador secuencial predecible. Cada factura y presupuesto dispone de un token único de 64 caracteres hexadecimales generado con random_bytes(32).
Problema que resuelve
Un sistema que utilice URLs del tipo /factura?id=42 permite que cualquier receptor modifique el identificador y acceda a documentos de terceros. Con un conjunto de 1.000 facturas, un atacante puede recorrer todos los registros en menos de un minuto mediante un script automatizado.
Implementación en Systema
El servidor valida que el token corresponde exactamente al documento solicitado. Si se modifica el token o se añade un parámetro ?id= distinto, la respuesta es 403 Forbidden.
05 · Especificaciones VeriFactu en Systema
Encadenamiento SHA-256
Cada factura genera un hash SHA-256 que incorpora el hash de la factura inmediatamente anterior. Cualquier modificación retroactiva invalida la integridad de todos los registros posteriores en la cadena.
Numeración secuencial garantizada
La tabla series_numeracion utiliza transacciones PDO con bloqueo exclusivo para garantizar que dos facturas creadas de forma concurrente nunca reciban el mismo número de serie.
Registro de eventos — Audit Trail
| Evento | Datos registrados | Tabla |
|---|---|---|
| Emisión de factura | Número, fecha, NIF emisor, NIF receptor, total, hash SHA-256 | facturas |
| Envío por email | Timestamp de envío, destinatario, tracking ID | facturas.email_enviado_at |
| Apertura por receptor | Timestamp de primera lectura, pixel 1×1 | email_tracking |
| Cambio de estado | Estado anterior, estado nuevo, whitelist de transiciones válidas | update_estado.php |
| Acceso portal contable | Token de acceso, timestamp, datos servidos | resultados_anuales |
06 · Infraestructura y Capas de Red
Seguridad en el transporte — TLS/SSL
Toda comunicación entre el cliente y Systema se realiza sobre HTTPS con TLS. Los datos en tránsito —facturas, información fiscal, credenciales— no viajan en texto plano bajo ninguna circunstancia.
Autenticación de correo electrónico
Los correos emitidos por Systema (facturas, presupuestos, alertas) están autenticados mediante tres registros DNS complementarios que garantizan la identidad del remitente y la integridad del mensaje.
SPF — Sender Policy Framework
Declara qué servidores están autorizados a enviar en nombre del dominio. Previene la suplantación de identidad del remitente.
DKIM — DomainKeys Identified Mail
Cada email incluye una firma digital verificable. Si el mensaje es modificado en tránsito, la firma no coincide y el servidor receptor lo rechaza.
DMARC — Política de autenticación
Define la acción a aplicar sobre mensajes que no superan SPF o DKIM. Validado en producción con servidores corporativos reales.
Pixel de seguimiento
Cada email incluye un pixel 1×1 que registra la fecha y hora de primera apertura. Permite al emisor confirmar que el destinatario ha recibido y leído la factura.
OperativoValidación de licencias — HMAC-SHA256
Cada instalación valida su licencia activa contra un servidor central mediante un token HMAC-SHA256. La validación queda en caché durante 7 días para garantizar disponibilidad ante interrupciones del servidor de licencias. Sin licencia válida, el sistema no inicia sesión.
07 · Roadmap Normativo
VeriFactu Fase A Activo desde v1.0
Inalterabilidad de registros, encadenamiento SHA-256, QR en documentos, numeración secuencial sin gaps, audit trail completo de eventos.
Parche RGPD en tokens v1.2
Token público validado contra el identificador concreto del documento. Imposible el acceso cruzado entre documentos de la misma instalación.
VeriFactu Fase B Agosto 2026
Envío automático de registros de facturación a la AEAT en tiempo real. XML firmado conforme al esquema oficial. En desarrollo, disponible antes del plazo legal.
Facturación electrónica B2B 2027
La obligatoriedad de facturación electrónica entre empresas está prevista para 2027. La arquitectura de Systema está preparada para incorporar esta capa sin rediseño estructural.
08 · Tabla Comparativa de Seguridad
Systema frente al estándar habitual de mercado en cada dimensión relevante de seguridad y cumplimiento normativo.
| Dimensión | Estándar de mercado | Systema | Estado |
|---|---|---|---|
| Aislamiento de datos | BD compartida con tenant_id | BD independiente por instalación | Superior |
| Acceso a documentos | Identificador secuencial en URL | Token SHA-256 de 64 caracteres | Superior |
| Almacenamiento de contraseñas | Hash MD5 o SHA1 | bcrypt con salt automático | Superior |
| Autenticación de email | Sin DKIM o configuración básica | SPF + DKIM + DMARC | Superior |
| Trazabilidad fiscal | Sin log o log básico | Audit trail completo + SHA-256 por registro | Superior |
| Numeración de facturas | Auto-increment sin bloqueo de concurrencia | Transacción PDO con SELECT FOR UPDATE | Superior |
| Inyección SQL | Depende de la implementación | 100% prepared statements · PDO emulate=false | Protegido |
| VeriFactu Fase A | Pendiente en muchos ERPs | Activo desde v1.0 | Completo |
| VeriFactu Fase B | Obligatorio agosto 2026 | En desarrollo, disponible antes del plazo | En progreso |
| Sistema de actualizaciones | Manual o por FTP | Automático con backup previo + rollback + SHA256 | Superior |
09 · Preguntas Frecuentes
Respuestas a las dudas más habituales de clientes, gestores y auditores técnicos durante el proceso de validación.
¿Systema cumple la normativa VeriFactu vigente en España?
Sí. Systema cumple íntegramente la Fase A de VeriFactu (activa desde v1.0), que incluye inalterabilidad de registros mediante encadenamiento SHA-256, trazabilidad completa del ciclo de vida de cada factura y código QR de verificación incrustado en el documento. La Fase B — envío automático de registros a la AEAT en tiempo real — está en desarrollo y estará disponible antes del plazo legal de agosto de 2026.
¿Es posible modificar o eliminar una factura emitida?
No. Una factura registrada no puede modificarse sin romper la cadena de integridad SHA-256. Cualquier alteración retroactiva —importe, fecha, NIF— invalida el hash del registro afectado y todos los posteriores, haciendo el fraude detectable de forma inmediata. Si existe un error, el flujo correcto es emitir una factura rectificativa, que queda registrada como nuevo eslabón en la cadena. Nunca se sobreescribe un registro existente.
¿Pueden los datos de un cliente mezclarse con los de otro?
No es posible por arquitectura. Cada instalación de Systema opera con su propia base de datos MySQL independiente. No existe ninguna tabla compartida entre instalaciones, ni un campo tenant_id que pudiera fallar. Un error en la consulta de una instalación no tiene ninguna capacidad de afectar a otra. Esta separación física de datos garantiza el cumplimiento del RGPD por diseño, sin depender de configuración ni de lógica de aplicación.
¿Cómo sé que el enlace de una factura que me llega por email es auténtico?
Cada enlace incluye un token criptográfico de 64 caracteres hexadecimales generado con random_bytes(32) en el momento de emisión. Este token equivale a 256 bits de entropía — adivinar uno por fuerza bruta a razón de un billón de intentos por segundo requeriría más tiempo que la edad del universo. Adicionalmente, el correo está autenticado mediante SPF, DKIM y DMARC, lo que garantiza que el mensaje proviene del dominio declarado y no ha sido alterado en tránsito.
¿Dónde se almacenan las contraseñas de acceso? ¿Están protegidas?
Ninguna contraseña se almacena en texto plano en ningún punto del sistema. Las credenciales se guardan como hash bcrypt con salt automático, el estándar más robusto para almacenamiento de contraseñas. La contraseña maestra de administración existe únicamente como hash hardcodeado — nunca se escribe en disco ni en base de datos. El acceso al ERP, al motor de actualizaciones y al panel de mantenimiento está protegido mediante tres sesiones completamente independientes: el compromiso de una no afecta a las otras dos.