1️⃣ El gran malentendido: “cada cliente debe firmar sus facturas y registros”

España está viviendo la mayor transformación legal y tecnológica en facturación desde el Reglamento de Facturación (RD 1619/2012). Dos piezas normativas se han cruzado:

• 🟢 Ley 18/2022 (Ley Crea y Crece) → obliga a la factura electrónica B2B estructurada.
• 🔵 RD 1007/2023 (Reglamento SIF / VERI*FACTU) → obliga a la transmisión segura y trazable de registros de facturación.

El resultado ha sido una avalancha de desarrollos SaaS, módulos y “conectores mágicos” hechos a toda prisa. Y con ellos ha llegado el error conceptual más grave:

“Como hay que garantizar autenticidad e integridad, cada empresa tendrá que firmar sus facturas o sus registros con su propio certificado, así que el SaaS debe pedir el .pfx o .p12 del cliente.”

❌ Esto es falso, tanto para la Ley Crea y Crece como para VERI*FACTU.

La realidad es justo la contraria: la ley no obliga a subir certificados al SaaS, ni a firmar cada factura con el certificado del emisor, ni a convertir cada tienda online en un HSM casero. Y por este triste malentendido, muchos estan vendiendo sistemas para cumplir veri*factu que son un verdadero peligro legal y de seguridad para sus clientes.

2️⃣ Qué exige realmente la Ley Crea y Crece (factura electrónica B2B)

La Ley Crea y Crece obliga a que las operaciones B2B entre empresas y autónomos usen factura electrónica en formato estructurado. Nada de PDFs sueltos como soporte único.

Lo que la ley sí exige:

• 📂 Que la factura sea un formato estructurado (XML, UBL, CII, Facturae, etc.).
• 🔄 Interoperabilidad entre plataformas y proveedores.
• 📬 Trazabilidad de envío, recepción, aceptación o rechazo.
• 🛡 Autenticidad del origen e integridad del contenido.

Y aquí está la frase clave (reformulación del marco legal):

Estos requisitos podrán garantizarse mediante firma electrónica avanzada o por otros medios admitidos en derecho.

Ese “podrán” y ese “o por otros medios” significan que:

• ✅ La firma electrónica del vendedor es una opción, no una obligación universal.
• ✅ La integridad puede garantizarse por el proveedor del sistema, no necesariamente por el emisor.
• ✅ No se exige que cada factura vaya firmada con un certificado FNMT del empresario.
• ✅ El sistema puede usar canales seguros, sellos, registros de auditoría, hashes, etc.

Conclusión: Crea y Crece no obliga a que cada empresa cliente del SaaS firme sus facturas con su propio certificado. Obliga a que el ecosistema garantice integridad y autenticidad por medios técnicamente robustos.

3️⃣ Qué exige realmente VERI*FACTU (RD 1007/2023)

El RD 1007/2023 introduce el sistema SIF/VERI*FACTU: envío de registros de facturación a la AEAT, con los principios ICATI:

• I – Integridad
• C – Conservación
• A – Accesibilidad
• T – Trazabilidad
• I – Inalterabilidad

Aquí sí hablamos de firma digital, encadenamiento, hash, sellado temporal, etc. Pero la pregunta clave no es “¿hay que firmar?”, sino:

¿Quién puede firmar los registros de facturación VERI*FACTU?

Y la respuesta —que casi nadie está explicando— es:

• ✅ Puede firmar el fabricante del software / SaaS, con su propio certificado.
• ✅ Puede firmar el presentador autorizado, como colaborador social.
• ✅ Puede firmar un HSM cualificado gestionado por un QTSP.
• ✅ Puede firmar un módulo que reside en la infraestructura del cliente.

En ningún sitio se exige que cada registro se firme con el certificado del emisor de la factura.

El certificado firma la evidencia técnica y el registro, mientras que el emisor queda identificado por el contenido del registro (NIF, razón social, etc.).

4️⃣ El verdadero problema: subir el certificado del cliente al SaaS

Lo que sí es un problema serio —legal, técnico y ético— es esta práctica tristemente extendida:

“Sube tu certificado .pfx / .p12 y la contraseña a nuestro SaaS, que nosotros firmamos todo por ti.”

Esto choca frontalmente con varias normas:

• ⚖ Ley 59/2003: el certificado debe estar bajo control exclusivo del titular.
• ⚖ Reglamento eIDAS: la clave privada no puede ser compartida ni copiada.
• ⚖ Ley 11/2021: exige un software de facturación seguro, trazable e íntegro.
• ⚖ RGPD / LOPDGDD: la clave privada es un “activo crítico” cuando firma documentos con valor legal.

Si el certificado es de persona física o de representante legal, el riesgo se multiplica: estamos hablando de suplantación digital si se utiliza sin control real del titular.

Conclusión directa: pedir al usuario subir su certificado al SaaS es una mala idea técnica y una pésima idea legal.

5️⃣ Cómo funciona esto en un SaaS con cientos de clientes

Un SaaS típico (por ejemplo, un conector para PrestaShop o un sistema en la nube multiempresa) no puede escalar si cada cliente debe aportar y gestionar su propio certificado en el servidor del proveedor.

Los modelos viables y legales son estos:

🅰 OPCIÓN A – Firma centralizada del SaaS

• • El SaaS utiliza su propio certificado cualificado.
  • Firma los registros de facturación o los mensajes enviados a AEAT.
  • El emisor de cada factura se identifica por el NIF y los datos contenidos en el registro.
  • El SaaS actúa como presentador técnico (como un colaborador social tecnológico).
  • La AEAT solo da certificados de Colaborador Social Autorizado a aquellas empresas que tengan un profesional colegiado en su plantilla.

Resultado: ✔ legal, ✔ escalable, ✔ sin certificados de cliente en el servidor.

🅱 OPCIÓN B – Firma en entorno del cliente (módulo local / plugin)

• • Se instala un módulo en el hosting del cliente.
  • Se instala un agente (un pequeño programa residente) en el servidor local que se comunique con el hosting.
  • El certificado del cliente nunca sale de su servidor local.
  • El agente firma los documentos (por ejemplo lanzando Autofirma) y los envía al SaaS o directamente a la AEAT.
  • Desarrollar un agente, que funcione en multiples plataformas, dependa de servicios externos, y de software de terceros, no es sencillo

Resultado: ✔ muy seguro, pero 🔸 requiere más despliegue y soporte.

🅾 OPCIÓN C – HSM remoto cualificado (QSCD cloud)

• • El certificado se almacena en un HSM cualificado gestionado por un QTSP.
  • El SaaS invoca las firmas vía API, sin ver la clave privada.
  • Se auditan todas las operaciones de firma.
  • La implementación propia puede costar miles de euros, y contratar un servicio externo tiene grandes costes debido a sus altisimas medidas de seguridad y responsabilidad

Resultado: ✔ modelo europeo estándar, ✔ robusto, 🔸 pero con coste y complejidad mayores.

6️⃣ Lo que NUNCA debería hacerse

En este contexto, hay varias prácticas que deberían considerarse red flags inmediatas:

• ❌ Guardar .pfx o .p12 de clientes en el servidor del SaaS.
• ❌ Almacenar la contraseña del certificado en texto plano o reversible.
• ❌ Firmar facturas de cientos de clientes con una clave privada que no es del SaaS.
• ❌ Usar certificados de persona física para procesos automatizados masivos.
• ❌ Firmar facturas con el certificado de colaborador social como si fuera el emisor.
• ❌ Mezclar certificados y empresas en buckets S3 o sistemas de almacenamiento poco controlados.

Regla de oro: si tu arquitectura depende de “sube tu certificado y yo ya me encargo”, vas por el camino equivocado.

7️⃣ Radiografía normativa: Crea y Crece vs VERI*FACTU

📘 Crea y Crece – Factura electrónica B2B

Obliga a:

• 📂 Usar formatos electrónicos estructurados.
• 🔄 Garantizar interoperabilidad entre plataformas.
• 📬 Mantener trazabilidad del ciclo de la factura (envío, recepción, rechazo).
• 🛡 Asegurar autenticidad e integridad por medios reconocidos.

No obliga a:

• ❌ Firmar cada factura con el certificado del emisor.
• ❌ Instalar certificados en todos los hostings.
• ❌ Transformar todo en Facturae firmado XAdES.

📙 VERI*FACTU – RD 1007/2023

Obliga a:

• 🧩 Enviar registros de facturación con ICATI.
• 🔗 Encadenar registros mediante hash.
• 🕒 Garantizar sellado temporal y trazabilidad.
• 🖊 Usar firma electrónica sobre los registros.

No obliga a:

• ❌ Que firme siempre el emisor de la factura.
• ❌ Que el certificado usado para la firma sea el del cliente.
• ❌ Que cada empresa tenga su propio HSM o QSCD.

Permite que:

• ✅ Firme el fabricante del SaaS como proveedor del sistema.
• ✅ Firme el presentador autorizado / colaborador social, en su rol de presentación.
• ✅ Firme un módulo/ agente local en el entorno del cliente.
• ✅ Firme un HSM remoto cualificado.

8️⃣ Ejemplos de sistemas mal implementados (y sus riesgos)

Estos ejemplos no son teóricos: están sucediendo hoy en el mercado.

• ⚠ Multiempresa con certificados en servidor compartido
  Un SaaS almacena los certificados de 200 empresas en el mismo servidor. Una mala configuración mezcla certificados, y una factura de la empresa A se firma con el certificado de la empresa B. → Falsedad documental, ruptura total de autenticidad.
• ⚠ Fuga de certificados desde un bucket S3
  Un .pfx queda expuesto durante 20 minutos por un error ACL. Suficiente para que alguien lo descargue y firme contratos, poderes o facturas. → Responsabilidad civil y penal para el proveedor.
• ⚠ Uso abusivo de un certificado de colaborador social
  El colaborador social firma registros o facturas “como si fuera” el cliente. → Confusión de roles: el colaborador puede presentar, pero no asumir la autoría de facturas.

9️⃣ Checklist técnico para un sistema legal y seguro

Si estás diseñando un SaaS, un conector para e-commerce o un sistema SIF, este checklist te sirve como brújula:

• ✅ El certificado del cliente nunca se sube al SaaS.
• ✅ El SaaS firma, en su caso, con su propio certificado cualificado.
• ✅ La autoría de la factura se determina por el contenido, no por el certificado.
• ✅ Los registros VERI*FACTU se encadenan con hash y se sellan correctamente.
• ✅ Todo acceso y operación de firma deja traza de auditoría.
• ✅ Si se usa HSM o QSCD, el SaaS nunca puede extraer la clave privada.
• ✅ La arquitectura está alineada con Ley 11/2021, RD 1007/2023, RD 1619/2012, Ley 59/2003 y eIDAS.

Si alguno de estos puntos chirría, es el momento de rediseñar antes de que lo haga la AEAT.

🔟 Conclusión: el futuro de la facturación en España no pasa por subir un .pfx

Ni la Ley Crea y Crece, ni VERI*FACTU exigen convertir cada empresa en experta en criptografía ni llenar los hostings compartidos de certificados privados.

Lo que piden, en realidad, es algo mucho más razonable: sistemas bien diseñados, con integridad, trazabilidad, seguridad y claridad de roles.

El camino no es “súbeme tu certificado y yo ya firmo por ti”, sino:

• 🧠 Diseñar arquitecturas híbridas y robustas.
• 🛡 Respetar el control exclusivo de las claves.
• 🧾 Separar claramente emisión, presentación y custodia.
• 🤝 Entender que el SaaS puede ser presentador y garante técnico, no suplantador.

En esta nueva etapa, sobrevivirán y crecerán los proveedores que comprendan tanto el lado legal como el lado criptográfico y sean capaces de explicarlo de forma transparente a sus clientes.