🛑 El dilema fundacional: libertad del código abierto vs. criptografía tributaria

Si tu operación se basa en PrestaShop, WooCommerce (WordPress), Magento u otra plataforma autohospedada, disfrutas de soberanía técnica: control total sobre código, servidor y, sobre todo, acceso directo a la base de datos (DB). Esa libertad disparó el e-commerce en España… y a la vez fricciona con el marco VERI*FACTU.

VERI*FACTU (RRSIF) te exige ICALTI: Integridad, Conservación, Accesibilidad, Legibilidad, Trazabilidad e Inalterabilidad. Cada registro de facturación debe ser una verdad inmutable encadenada criptográficamente a las anteriores. Por lo tanto, aparentemente esa libertad que le permite al propietario de la tienda acceso total al código fuente y a la base de datos, le permite modificar la información relacionada con la facturación, y en consecuencia es incompatible con VERI*FACTU. Por muchos plugins que instales, por muchas restricciones que les pongas, si el propietario quiere defraudar siempre tendrá la posibilidad de modificar el código fuente o modificar las tablas del MySQL:

• Si el propietario modifica los datos DESPUÉS DE ENVIARLOS A LA AEAT, simplemente está provocando la rotura de la integridad de los datos, y el código QR y los registros de facturación ya enviados, podría facilitar la detección por parte de la AEAT.

“Un registro de facturación, una vez generado (y firmado / remitido a la AEAT según la modalidad empleada) no debe ser modificado nunca por nadie (si se hiciera, se podría detectar: gracias a la huella, firma, encadenamiento...).” Agencia Tributaria

• Pero... ¿qué pasa si el propietario modifica los datos ANTES DE QUE EL PEDIDO SE CONVIERTA EN FACTURA Y SE ENVÍE A LA AEAT? 

“El SIF deberá garantizar la integridad e inalterabilidad, la trazabilidad, y conservación de los registros de facturación …” Agencia Tributaria+1
Y añade: “Cualquier necesidad de corrección o anulación de los datos obligatorios registrados deberá ser realizada mediante los procedimientos regulados en el reglamento y su orden ministerial, generando al menos un registro de facturación adicional posterior, de forma que se conserven inalterables los datos originalmente registrados y los corregidos.” Agencia Tributaria

Ni ningún plugin (ya sea un plugin autohospedado, o uno que envía datos a una API, o uno que envía datos a un ERP) puede dar ninguna garantía absoluta (es técnicamente imposible) de que esto no suceda, en este aspecto, todos los fabricantes de plugins estan en la misma situación:

no es posible "blindar" UN SOFTWARE OPENSOURCE AUTOHOSPEDADO.

La AEAT conoce perfectamente este problema, y deja claro de quien es la responsabilidad final:

La empresa que efectúe la programación del código o integre partes de otro software, ya sea o no de código abierto, debe realizar la declaración responsable, incorporar los datos obligatorios e indicar qué componentes utiliza. En el caso de que utilice código abierto, se hará responsable del funcionamiento del mismo, incluyendo los sistemas de seguridad exigidos para preservar la integridad, conservación, accesibilidad, legibilidad, trazabilidad e inalterabilidad de los registros.

La fórmula que ha elegido la AEAT para no dejar fuera de la ley a las decenas de miles de tiendas online que existen en España, son las DECLARACIONES RESPONSABLES, y que cada parte del código (cada módulo), aclare su función en la DR y tenga un responsable, y finalmente, el propietario de la web sea el responsable del buen uso del conjunto más allá del cumplimiento de los requisitos técnicos. Por eso el cumplimiento real es:  técnico + legal + organizativo

1) Factura ≠ Registro (y por qué importa)

A) La Factura (documento mercantil) — Se rectifica

Se rige por el Reglamento de facturación. Si la factura emitida contiene errores, no se edita retroactivamente: se emite Factura Rectificativa (o de abono, o de anulación o de sustitución), pero nunca se altera la factura inicial. Convivirán original y rectificativa para que la trazabilidad del documento sea completa. Y aquí hay un matiz muy importante: 
¿el error es uno que ha provocado que la AEAT rechace la factura (por ejemplo un NIF incorrecto)?
En caso afirmativo, tienes la oportunidad de SUBSANAR el error, es decir CORREGIR aquello que ha provocado que la AEAT no te acepte esa factura.
Una vez SUBSANADO ese error inicial, nunca más podra MODIFICARSE LA FACTURA BAJO NINGÚN CONCEPTO.

“En caso de rechazo, los obligados tributarios deberán realizar las subsanaciones necesarias y proceder a una nueva remisión en la que incluirán los registros que en su momento fueron rechazados.” Agencia Tributaria+2

B) El Registro de facturación (asiento técnico VERI*FACTU) — Se encadena

Se rige por el RRSIF y su Orden. El sistema genera registros de alta (simultáneo a la expedición) y, cuando proceda, de anulación/rectificación; a todos se les calcula huella/hash y se encadenan. Nunca se sobrescribe un registro antiguo: si hay que SUBSANAR, se genera uno nuevo y se mantiene la cadena, lo mismo si se abona la factura, o cualquier acción posible, NUNCA SE MODIFICA NADA, se añade un nuevo registro de facturación a la cadena por cada paso.

“Cuando sea necesario cambiar algún dato de un registro de facturación de alta ya producido, deberá generarse otro registro que complete, modifique o anule el contenido del anterior, pero no podrá alterarse o manipularse el primer registro de facturación para evitar que la secuencia de facturas se altere.” Agencia Tributaria

2) VERI*FACTU no es un sello: es una forma de operar y una responsabilidad compartida

El RRSIF define qué es un SIF, los tipos de registros, cuándo se generan, cómo se calcula la huella y cómo se encadenan. La Orden baja al detalle: estructura de los registros, eventos (aceptación/rechazo, reintentos, contingencias), y el QR con mención “VERI*FACTU” en la factura que habilita el cotejo por terceros y refuerza la presunción de integridad. Son aspectos técnicos que pueden ser cumplidos por el Módulo de terceros... pero ¿que pasa con el resto del cumplimiento legal y operativo? ¿con todo aquello que NO PUEDE SER CONTROLADO POR UN MÓDULO?

3) Como ha explicado la AEAT: Que es SIF, CPF, CF y “quién firma qué”

En open source, el comerciante que combina CPF + CF para su propio uso se convierte en autoproductor del SIF: responsable del cumplimiento global: La responsabilidad de los plugins se limita a la parte técnica de VERI*FACTU, al envío y conservación de todos los registros de facturación, etc, y así queda constancia en la declaración responsable del productor. El propietario de la tienda debe publicar su propia declaración responsable, comprometiéndose formalmente a no utilizar el resto del sistema (Prestashop) para defraudar. Dos declaraciones responsables publicadas (no es obligatorio pero si recomenable) en la página web.

4) Casos prácticos que solo el propietario puede controlar (amplios y con aterrizaje legal)

4.1. Pedido de 430 € con NIF mal

¿Es obligatorio el NIF? No siempre. Sí en supuestos concretos o cuando el destinatario lo exige para sus derechos. Si era obligatorio y está mal: mientras la AEAT rechace la factura por que contiene errores, puedes subsanar y reenviar y nuevos registros encadenados son generados y enviados. 

“La obligación de expedir factura podrá ser cumplida mediante la expedición de factura simplificada … a) Cuando su importe no exceda de 400 euros, IVA incluido.” Ley Factura Electrónica+3Agencia Tributaria+3

4.2. Dirección de envío errónea (dato no fiscal esencial)

Si no afecta a identificación fiscal/Base/IVA, resuélvelo operativamente, es decir, no está permitido modificar nada de la factura pero esos datos al no ser fiscalmente relevantes, no tienen por que formar parte de la factura y un cliente no puede obligarte a que la cambies por ese motivo. En teoria deberias emitir una nota de entrega, o una nota de transporte o algo parecido, pero si el cliente insiste, deberás anularla y generar una totalmente distinta con los datos cambiados.

“Cualquier cambio que se desee hacer constar sobre el mismo [registro de facturación], deberá realizarse a través de la generación de uno o más … registros de facturación nuevos, del tipo que corresponda a cada caso …” Agencia Tributaria+3VeriFactu+3

4.3. Cambio de precio tras emitir

Nada de “editar”. Procede abono (parcial/total) y nueva factura con sus registros. 

“Cualquier cambio que se desee hacer constar sobre el mismo [registro de facturación], deberá realizarse a través de la generación de uno o más … registros de facturación nuevos, del tipo que corresponda a cada caso …” Agencia Tributaria+3VeriFactu+3

4.4. Restauré un backup antiguo

Si rebobina por detrás del último registro remitido, rompes tu línea de tiempo local. Declara contingencia, documenta y aporta respuestas de la AEAT como prueba. Prevención: backups compatibles . Si tus registros de facturación estan en un servidor externo, se podrá reconstruir la informacion que la AEAT considera más importante:

“Si la pérdida solo afecta a registros de facturación, en un sistema VERI*FACTU esta situación sería menos problemática pues los registros los tendría la AEAT y el obligado podría recuperarlos en su integridad.” Agencia Tributaria

4.5. Apago el módulo un día o lanzo un UPDATE manual

Si con ello suprimes trazabilidad, casaría con el espíritu de “software de doble uso”. Mitigación: staging con datos de test, feature flags y bloqueos en producción.

“Este reglamento y el real decreto que lo aprueba (…) imponen una serie de requisitos a los sistemas informáticos de facturación (SIF) … con el objetivo de evitar o dificultar y detectar que se pueda llevar a cabo prácticas fraudulentas en ese proceso, tales como la omisión de facturas o la alteración de las facturas de venta una vez expedidas.” Agencia Tributaria+1“El artículo 201 bis de la Ley 58/2003, de 17 de diciembre, General Tributaria (LGT), prevé … cuando los sistemas informáticos no cumplan con lo establecido … se sancionará con… 50.000 euros por cada ejercicio.” Agencia Tributaria+1

4.6. Factura simplificada (TPV) conectada a la web

Cuidado con cambios de cliente a posteriori: requieren rectificativa + completa nueva, simplemente por que todos estos datos ya estaban enviados a la AEAT, y, atención, el cliente puede solicitar que le cambies la factura para que incorpore sus datos durante 4 años. Ojo con realizar cambios sospechosos, por ejemplo, anular una factura que has hecho a nombre de un particular y hacerla de nuevo a nombre de una empresa de la que ese particular es el administrador.

 “Cuando el destinatario de la operación lo solicite dentro del plazo de ejercicio del derecho a la deducción de la cuota soportada, el expedidor expedirá factura completa, debiendo consignar el número y la fecha de las factura/s simplificadas que aquella sustituye.” BOE+2

4.7. Multitienda y multi-SIF (PrestaShop)

Un SIF por tienda (ID propio) si estan desconectadas entre ellas o SIF común con separación inequívoca (cada una con su serie o numeración) si estan interconectadas. Claves: IDs SIF unívocos, colas separadas, métricas por SIF, DR que describa arquitectura.

Si todos los sistemas informáticos mencionados (tanto el central como el de la sede "desconectada") expiden independientemente facturas, cada una con su QR incluido, serán ambos sistemas considerados sistemas informáticos de facturación (SIF) independientes, según el artículo 1.2 del reglamento aprobado por el RD 1007/2023, de 5 de diciembre (RRSIF) y, por lo tanto, cada uno de ellos debe cumplir separadamente dicho RRSIF.

4.8. Marketplace (comisiones y facturación a vendedores)

Define si el SIF eres tú o cada vendedor. Si facturas comisión al vendedor, tu SIF cubre tus facturas; si el vendedor factura al cliente final, cada vendedor resuelve su propio SIF/DR.

4.9. Ventas intracomunitarias/B2B (IVA y verificación NIF-IVA)

Intracomunitarios, ventanilla única, exportaciones, etc.... hay muchas combinaciones, la mayoria requieren de módulos de terceros. Asegúrate de que estan guardando correctamente las bases imponibles, los porcentajes y los totales de los impuestos en las tablas de prestashop para no tener problemas a la hora de enviar esa información a la AEAT.

6) Checklist ampliado (propietario + equipo técnico)

7) Conclusión y borrador de declaración responsable para propietarios

El código abierto no es el enemigo: lo es la ausencia de gobierno.

• La Declaración Responsable del módulo +api te la damos nosotros y acredita que tu herramienta cumple;
• la Declaración Responsable del SIF del propietario de la tienda y el Control de Entorno demuestran que tu uso cumple.

 Eso es lo que busca el marco:

Tecnología conforme + Explotación responsable, VERI*FACTU no castiga el software libre: lo profesionaliza.