VERI*FACTU en PrestaShop: ¿módulo en la tienda o API externa?

En septiembre de 2025, con VERI*FACTU cada vez más cerca, el grupo tuvo un debate largo y útil: ¿se puede cumplir con un módulo instalado dentro de PrestaShop o hace falta un sistema externo que facture? La postura de Gustavo fue tajante: un módulo de VERI*FACTU dentro de PrestaShop es un riesgo para quien lo desarrolla; un servicio externo al que la tienda envía los datos, mucho menos.

Qué se exige al software

Gustavo repasó los requisitos del reglamento de sistemas de facturación y de su orden de desarrollo. Entre otros:

• Un registro de facturación por cada factura o evento.
• Inalterabilidad: huella (hash) encadenada y sellado de tiempo.
• Trazabilidad: registro de altas, anulaciones, rectificaciones e incidencias.
• Exportación en los formatos normalizados.
• Que no sea software «de doble uso», capaz de ocultar o alterar facturas.
• El código QR y, en la modalidad VERI*FACTU, la leyenda y el envío de los registros a la AEAT.

Y el fabricante del software tiene que firmar una declaración responsable de que su sistema cumple. Otro compañero añadió un detalle que lo hace muy visible: cada registro identifica el sistema informático que lo genera, con el nombre y el NIF de quien lo ha hecho, el nombre del programa, su versión y el número de instalación.

El problema de PrestaShop

PrestaShop es abierto: con acceso al back-office o a la base de datos se puede cambiar una factura. Rekire lo matizó: siendo accesible la base de datos, cualquier sistema se puede modificar, también un ERP comercial. La diferencia, según Gustavo, es que el software no ofrezca él mismo la forma de hacerlo. En un CMS donde cualquier módulo puede tocar las tablas, garantizarlo es muy difícil, y quien firma la declaración responde. Un compañero recordó que las sanciones previstas para el desarrollador son altas.

Gustavo consultó además el caso de los conectores. La respuesta que compartió, que no es un criterio oficial de la AEAT y hay que tomar con cautela: si tu módulo solo recoge la factura que ya emite PrestaShop y la transmite, probablemente no eres el fabricante; si numera, calcula la huella o genera el PDF, sí lo eres.

Las salidas que se vieron en el grupo

1. PrestaShop envía el pedido y la factura se hace fuera. Por API o por fichero, el pedido llega a un sistema de facturación que sí cumple y que emite la factura. Un compañero iba por ahí: enviar los pedidos como presupuestos a su programa de facturación para convertirlos allí en factura, como le había confirmado un consultor. Gustavo lo resumió: «envías pedido y luego facturas».
2. Un módulo que habla con un servicio externo. La tienda manda los datos, el servicio genera el registro, devuelve el QR para la factura y lo envía a la AEAT. Es el planteamiento de Rekire: un módulo que trabaja contra su API, con su ERP detrás generando las facturas. En sus palabras: «solo con PrestaShop yo no veo la manera de hacerlo legal».
3. Un ERP conectado a la tienda, que además resuelve el TPV de la tienda física. Ojo con los TPV que trabajan dentro de PrestaShop: en el grupo salió el caso de uno que había dejado de vender licencias por no poder cumplir.

Lo que no puedes delegar

Gustavo fue duro con parte de los gestores: hay quien no sabe qué programa usan sus clientes ni si es compatible. Su consejo: el gestor, el informático y el dueño de la tienda tienen que hablarlo con tiempo, no el último mes. Y si te ofrecen facturar «desde PrestaShop sin más», pregunta quién firma la declaración responsable.

En Rekire lo resolvemos con CoreGest ERP con VERI*FACTU conectado a PrestaShop, que emite las facturas fuera de la tienda.

Esto salió en @PrestashopEsp, la mayor comunidad PrestaShop de España en Telegram. Ver la conversación