La Ley 11/2021, de 9 de julio, de medidas de prevención y lucha contra el fraude fiscal introdujo en el ordenamiento español un tipo infractor completamente nuevo. No sanciona el fraude consumado, sino la capacidad instalada de cometerlo. Su desarrollo reglamentario, el Real Decreto 1007/2023, de 5 de diciembre, establece los requisitos que debe cumplir todo Sistema Informático de Facturación (SIF) para ser considerado conforme.

Tipificación: el artículo 201 bis de la LGT

El artículo 201 bis de la Ley 58/2003 General Tributaria califica como infracción tributaria grave la producción, comercialización, adquisición y —este es el punto crítico— la mera tenencia de sistemas informáticos que:

  • Permitan llevar contabilidades distintas en los términos del artículo 200.1.d) de la LGT.
  • Permitan no reflejar, total o parcialmente, la anotación de transacciones realizadas.
  • Permitan registrar transacciones distintas a las anotaciones realizadas.
  • Permitan alterar transacciones ya registradas incumpliendo la normativa aplicable.
  • No cumplan con las especificaciones técnicas que garanticen la integridad, conservación, accesibilidad, legibilidad, trazabilidad e inalterabilidad de los registros.
  • No se certifiquen mediante la Declaración Responsable exigida reglamentariamente.

La consecuencia jurídica es determinante: la infracción se consuma con la simple disponibilidad del sistema. No es necesario que la Administración acredite que el comerciante ocultó un solo euro. Basta con demostrar que el software instalado permitía hacerlo.

PrestaShop nativo como software de doble uso

El concepto de software de doble uso designa aquel sistema que sirve simultáneamente para la gestión legítima del negocio y para la ocultación de operaciones. PrestaShop, en su instalación estándar, encaja en esta definición por una razón estructural que no comparten los SaaS cerrados: la propiedad del entorno de datos.

Al ser una solución open source autoalojada, el administrador de la tienda dispone de acceso directo y sin restricciones a la base de datos MySQL a través de herramientas como phpMyAdmin, Adminer o una simple conexión SSH. Esto habilita operaciones que la normativa considera incompatibles con un SIF:

  • Eliminación silenciosa de pedidos: una sentencia DELETE FROM ps_orders WHERE id_order = ... ejecutada desde phpMyAdmin borra el pedido y sus líneas asociadas sin generar ninguna entrada en un log de auditoría. El registro desaparece sin huella.
  • Modificación retroactiva de importes: un UPDATE sobre las tablas ps_orders u ps_order_detail permite alterar el importe total de una venta ya facturada y cobrada, sin dejar constancia del valor anterior.
  • Reasignación de la numeración: el contador de facturas (ps_order_invoice) es un campo editable. Es técnicamente trivial reutilizar números de factura o crear huecos en la serie.
  • Desactivación de módulos sin traza: un módulo de facturación puede deshabilitarse temporalmente para operar «en negro» durante un período y reactivarse después, sin que quede registro del intervalo.

Ninguna de estas capacidades constituye un fallo de PrestaShop: son consecuencias naturales y esperables de una arquitectura autoalojada. Pero desde la perspectiva del artículo 201 bis, esa flexibilidad es exactamente el elemento que convierte el sistema en infractor.

La brecha técnica nativa: cuatro incumplimientos estructurales

Con independencia del acceso a la base de datos, la facturación nativa de PrestaShop presenta cuatro carencias técnicas frente a la Orden HAC/1177/2024:

  • Sin encadenamiento hash SHA-256: PrestaShop genera cada factura como un documento independiente. No calcula la huella criptográfica de la factura anterior ni la incorpora al registro actual, por lo que no existe cadena de integridad verificable.
  • Sin código QR fiscal: las plantillas PDF nativas no incluyen el código QR de entre 30 y 40 mm con la URL de verificación en la sede electrónica de la AEAT, ni la leyenda obligatoria.
  • Sin huella de auditoría inalterable: no existe un Registro de Eventos que documente los sucesos relevantes del sistema (inicio, apagado, exportaciones, incidencias, cambios de configuración) de forma no modificable.
  • Sin Declaración Responsable: PrestaShop SA no emite ni puede emitir el certificado de conformidad para el núcleo del software, dado que el comportamiento final depende de la instalación, los módulos de terceros y el entorno del cliente.

Módulos homologados, requisitos y conexión con la AEAT

Existen dos rutas legalmente válidas para adaptar una tienda PrestaShop, y la elección tiene consecuencias operativas muy distintas.

Requisitos técnicos: PrestaShop nativo vs. módulo certificado

Cumplimiento del RD 1007/2023 — PrestaShop nativo vs. módulo homologado
Requisito (Orden HAC/1177/2024) PrestaShop nativo Módulo / ERP homologado
Hash SHA-256 encadenado entre registros consecutivos ✗ No calcula ✓ Obligatorio
Código QR fiscal (30–40 mm) con URL de verificación ✗ No genera ✓ Con leyenda VERI*FACTU
Registro de Eventos inalterable ✗ No implementa ✓ Sellado criptográficamente
Declaración Responsable firmada (art. 13) ✗ Inexistente ✓ Exigible al fabricante
Bloqueo de borrado y modificación de registros ✗ Acceso libre a MySQL ✓ Solo rectificativas
Generación de XML de registro de facturación ✗ No contemplado ✓ Formato AEAT
Gestión de facturas simplificadas (tickets B2C) Parcial (sin encadenar) ✓ Serie encadenada propia
Transmisión o conservación ante la AEAT ✗ Sin integración ✓ VeriFactu o No VeriFactu

Modalidad VeriFactu frente a No VeriFactu

El RD 1007/2023 configura dos modalidades de cumplimiento. Ambas son legales, pero su perfil de riesgo es radicalmente distinto para un e-commerce:

  • Modalidad VeriFactu (envío automático): por cada factura emitida, el módulo construye un XML de registro de facturación y lo transmite de forma inmediata al servicio web de la AEAT. La factura resultante incorpora el código QR con la leyenda VERI*FACTU, que permite al comprador verificar el documento en la sede electrónica. Ventaja decisiva: Hacienda custodia una copia inmutable desde el instante de la emisión, lo que traslada la carga probatoria y neutraliza cualquier sospecha de manipulación posterior.
  • Modalidad No VeriFactu (conservación local): el módulo genera el registro con hash encadenado y firma electrónica, pero lo conserva en el servidor del comercio, a disposición de la AEAT bajo requerimiento. En un entorno PrestaShop autoalojado esta opción es notablemente más arriesgada: el titular asume la responsabilidad íntegra de la custodia durante los cuatro años del período de prescripción, en un servidor al que él mismo tiene acceso administrativo. Ante una inspección, la ausencia de un tercero de confianza debilita la posición probatoria.

Dos rutas de adaptación para PrestaShop

  • Módulo VeriFactu certificado instalado en PrestaShop

    Se instala un módulo de un proveedor español que asuma el rol de SIF dentro del propio PrestaShop: calcula el hash encadenado, genera el QR, mantiene el Registro de Eventos y transmite el XML a la AEAT. Es la vía con menor fricción operativa, ya que la facturación permanece en el back-office habitual. Condición indispensable: exigir por escrito la Declaración Responsable del fabricante antes de la compra. Un módulo del marketplace sin ese documento no aporta cobertura legal alguna.

  • Desactivar la facturación nativa y delegar en un ERP externo por API

    Se deshabilita la generación de facturas en PrestaShop y se conecta la tienda mediante webhook o la API REST del ERP (Holded, Quipu u otro con Declaración Responsable). Al confirmarse el cobro, PrestaShop notifica la venta y el ERP emite la factura legal con hash, QR y envío a la AEAT. Arquitectura más robusta desde el punto de vista probatorio: el SIF reside fuera del entorno que el administrador controla. Recomendada para volúmenes altos y para tiendas con contabilidad ya centralizada en un ERP.

Plazos: 1 de julio de 2025 y 2027, dos hitos distintos

Existe una confusión extendida entre dos fechas que afectan a sujetos diferentes. Conviene precisarlas:

  • 1 de julio de 2025 — obligación para productores de software. Desde esa fecha, todo SIF ofrecido en el mercado español debe estar adaptado al RD 1007/2023 y contar con Declaración Responsable. Afecta a los desarrolladores de módulos para PrestaShop, no al comerciante. En la práctica significa que cualquier módulo de facturación comercializado hoy sin certificar ya está incumpliendo, y su distribuidor se expone a los 150.000 €.
  • 1 de enero de 2027 y 1 de julio de 2027 — obligación para usuarios. Según el RD-ley 15/2025, las sociedades mercantiles deben operar con un SIF conforme desde el 1 de enero de 2027, y los autónomos y personas físicas desde el 1 de julio de 2027.

La consecuencia operativa es que el mercado de módulos certificados ya debería estar maduro. Si un proveedor sigue sin poder entregar la Declaración Responsable, el problema no es de plazos: es un indicador de que ese módulo no va a estar conforme.

Anexo técnico-jurídico: cuatro precisiones que casi nadie explica

1. Ley Antifraude frente a Ley Crea y Crece: dos obligaciones que no son la misma

Se confunden sistemáticamente porque ambas afectan a la factura, pero regulan cosas distintas y su ámbito no coincide:

  • RD 1007/2023 (Ley Antifraude 11/2021) — Regula cómo debe comportarse el software. Impone inalterabilidad, trazabilidad, hash encadenado, código QR y, opcionalmente, reporte automático a la AEAT. Aplica a todas las operaciones, tanto B2C como B2B.
  • Ley 18/2022 Crea y Crece — Regula el formato de intercambio de la factura. Exige factura electrónica estructurada (FacturaE) en las relaciones exclusivamente entre empresas y profesionales (B2B), con obligación de informar del estado de pago.

La implicación práctica para PrestaShop es que un módulo que solo genere FacturaE no cumple VeriFactu, y un módulo que solo genere hash y QR no cumple Crea y Crece si la tienda vende a empresas. Un e-commerce mixto B2C/B2B necesita que su solución satisfaga ambos marcos de forma simultánea. Conviene verificarlo explícitamente en la ficha técnica del módulo antes de contratarlo.

2. Exención por SII: quién queda fuera del ámbito de VeriFactu

El RD 1007/2023 excluye de su ámbito de aplicación a los contribuyentes acogidos al Suministro Inmediato de Información (SII), por entender que ya remiten sus registros de facturación a la AEAT de forma telemática y prácticamente inmediata. Quedan exentos:

  • Empresas con volumen de operaciones superior a 6.010.121,04 € en el ejercicio anterior (gran empresa a efectos de IVA).
  • Inscritos en el REDEME (Registro de Devolución Mensual del IVA), con independencia de su facturación.
  • Grupos de entidades a efectos de IVA.
  • Quienes se hayan acogido al SII de forma voluntaria.

Para un e-commerce en crecimiento esto abre una decisión estratégica real: si la facturación se aproxima al umbral de los 6 millones, puede resultar más eficiente planificar la entrada en el SII que invertir en adaptar el stack de PrestaShop a VeriFactu. Son obligaciones alternativas, no acumulativas. La valoración debe hacerse con el asesor fiscal, ponderando la carga administrativa del SII frente al coste de adaptación.

3. Declaración Responsable (art. 13 RD 1007/2023): el documento que blinda o desprotege

El artículo 13 del RD 1007/2023 obliga a que todo SIF esté certificado mediante una Declaración Responsable emitida y firmada por el productor del software. Este documento no es un trámite comercial: es el instrumento que traslada la responsabilidad técnica del comerciante al fabricante.

Su contenido debe acreditar de forma expresa que el sistema cumple el reglamento y, muy específicamente, que no incorpora funcionalidades ocultas, puertas traseras (backdoors) ni mecanismos que permitan alterar o suprimir registros al margen de los procedimientos previstos.

En el ecosistema PrestaShop esta cautela es especialmente relevante por la naturaleza del mercado: existen centenares de módulos de facturación publicados por desarrolladores individuales y agencias pequeñas. Antes de comprar cualquier módulo, solicita la Declaración Responsable por escrito y verifica que identifique la versión exacta del módulo y del núcleo de PrestaShop sobre el que se certifica. Si el proveedor responde con evasivas, con un genérico «somos compatibles con VeriFactu» o con una simple mención en la ficha del producto, no hay cobertura legal. Ante una inspección, el titular de la tienda es quien responde de los 50.000 €.

4. Facturas simplificadas: el punto ciego del e-commerce B2C

La mayoría del volumen de una tienda online se factura a particulares que no solicitan factura completa. Estas operaciones se documentan mediante factura simplificada (el antiguo ticket), regulada por el Reglamento de Facturación con un límite general de 400 € y hasta 3.000 € en determinados sectores.

Existe una creencia errónea de que estos documentos quedan fuera de VeriFactu por su menor importe. Es falsa. Toda factura simplificada emitida mediante software debe generar su propio registro de facturación con hash encadenado, código QR y —en modalidad VeriFactu— transmisión a la AEAT en tiempo real. El importe es irrelevante: un pedido de 9,90 € genera exactamente las mismas obligaciones técnicas que uno de 900 €.

Implicación técnica para PrestaShop: el módulo debe gestionar una serie de numeración propia y encadenada para las simplificadas, independiente de la serie de facturas completas, y ser capaz de emitir la factura rectificativa correspondiente cuando el cliente devuelva el producto o solicite a posteriori la conversión del ticket en factura completa con sus datos fiscales. Este último escenario, muy frecuente en e-commerce, es donde fallan la mayoría de las integraciones improvisadas.

Checklist de cumplimiento para PrestaShop

Verifica cada punto antes de considerar tu instalación conforme al RD 1007/2023:

  • ☑ Declaración Responsable obtenida por escrito, con identificación de la versión del módulo y del núcleo de PrestaShop certificados.
  • ☑ Módulo o ERP que calcula hash SHA-256 encadenado en cada registro de facturación.
  • ☑ Facturas y tickets con código QR de 30–40 mm y URL de verificación en la sede AEAT.
  • ☑ Registro de Eventos activo e inalterable (arranques, exportaciones, incidencias, cambios de configuración).
  • ☑ Serie encadenada específica para facturas simplificadas (B2C), independiente de las completas.
  • ☑ Si se usa un ERP externo: facturación nativa de PrestaShop desactivada para evitar duplicidad de series.
  • ☑ Webhook disparado solo con el pago confirmado, nunca en la creación del pedido.
  • ☑ Devoluciones configuradas para emitir factura rectificativa automática, sin borrar el registro original.
  • ☑ Acceso a phpMyAdmin y MySQL restringido y auditado; credenciales de base de datos fuera del alcance del personal no autorizado.
  • ☑ Verificación de si la empresa está exenta por SII o REDEME antes de invertir en la adaptación.
  • ☑ Si se factura a empresas (B2B): comprobado que el módulo también cubre FacturaE (Ley Crea y Crece).
  • ☑ Procedimiento documentado de conservación de registros durante 4 años (prescripción tributaria).
  • ☑ Prueba de integración realizada con un pedido real y QR validado en la sede electrónica de la AEAT.