Adjunto información de un nuevo módulo para cumplir con Verifactu en España.
Es de pago único, es decir sin cuotas mensuales ni anuales.
https://www.youtube.com/watch?v=z5A_smwNmkg
Nuevo Modulo Verifactu
-
Carlos_Valverde
- Novato
- Mensajes: 7
- Registrado: Lun, 17/11/2025, 19:30
¿Qué procedimiento técnico y documental seguís para poder emitir una declaración responsable válida según el RD 1007/2023 si no revisáis ni certificáis la instalación, el entorno, las plantillas PDF ni el funcionamiento real del sistema de facturación donde se integra vuestro módulo?
-
Carlos_Valverde
- Novato
- Mensajes: 7
- Registrado: Lun, 17/11/2025, 19:30
Como empresa me preocupa que dentro de un año y medio tenga una inspección de Hacienda. Aunque hoy me entreguéis una declaración responsable, el software puede haber cambiado en ese tiempo. Si eso ocurre, ¿vosotros vais a responder ante la AEAT dentro de un año y medio si surge un problema? ¿Asumís la responsabilidad técnica y legal de una declaración emitida hoy cuando el software ya no es el mismo?
-
Carlos_Valverde
- Novato
- Mensajes: 7
- Registrado: Lun, 17/11/2025, 19:30
Adjunto información de un módulo certificado para cumplir con Verifactu Dolibarr en España.
En la que declara hacerse responsable ante una inspección año a año, para la seguridad empresarial.
https://verifactudolibarr.es
En la que declara hacerse responsable ante una inspección año a año, para la seguridad empresarial.
https://verifactudolibarr.es
Respecto a las dudas planteadas:
1. La Declaración Responsable no certifica una instalación concreta durante años.
El RD 1007/2023 establece que la Declaración Responsable acredita que el software entregado cumple con los requisitos.
No obliga —ni permite— a un desarrollador asumir responsabilidad sobre modificaciones posteriores realizadas por el usuario, terceros o actualizaciones externas del ERP.
La responsabilidad de mantener el entorno conforme es de la empresa usuaria, igual que ocurre con cualquier solución certificada que permita personalizaciones o integraciones.
2. En EasySoft solo emitimos DR cuando el sistema está en condiciones de cumplir.
Nuestro módulo genera la DR firmada digitalmente, y va vinculada a:
• URL de la instalación
• versión exacta de Dolibarr
• versión del módulo
• hash del propio módulo
Si el cliente actualiza Dolibarr, cambia elementos críticos o modifica nuestro módulo, la instalación puede dejar de cumplir. Por eso la DR puede —y debe— regenerarse desde el propio módulo en cualquier momento.
Por otro lado si el usuario añade plantillas que no emiten el QR es responsabilidad del propio usuario y sería el quien incumple la normativa.
3. No existe en la normativa el concepto de “responsabilidad año a año del proveedor sobre instalaciones que no controla”.
Ningún desarrollador puede asumir legalmente la responsabilidad de un software que él no administra, no actualiza y no mantiene en el servidor del cliente.
Técnicamente es imposible y jurídicamente no lo exige la AEAT.
El RD exige:
• que el software entregado cumpla
• que el usuario mantenga su instalación conforme
• que existan mecanismos para trazar, verificar y regenerar DR conforme a la instalación actual
Nuestro módulo cumple esto de forma estricta.
4. Auditamos antes de activar VeriFactu.
Revisamos versión, inalterables, extrafields, QR, certificado digital y configuración.
Solo después se activa el modo VeriFactu.
Esto garantiza que la DR se emite sobre una instalación válida.
5. Sobre “responder dentro de un año y medio”.
Si dentro de un año la instalación ha sido actualizada a una versión no compatible con su módulo , modificado nuestro módulo, se han cambiado plantillas o se ha manipulado el software, la Declaración Responsable original deja de ser válida, como ocurre en cualquier entorno empresarial.
Por eso nuestro sistema permite regenerarla en segundos desde el propio módulo, siempre basándose en el estado técnico exacto del momento.
6. Cada uno es libre de elegir el proveedor que considere más adecuado.
Solo aclarar que, en cualquier caso, nadie puede garantizar el cumplimiento de un sistema que no controla, que ha cambiado o ha sido modificado por terceros.
Eso no lo exige la ley ni lo permite la propia arquitectura de Dolibarr.
Si tienes cualquier otra duda concreta, puedes plasmarla en este mismo post o hacérnosla llegar al mail info@easysoft.es.
Un saludo.
1. La Declaración Responsable no certifica una instalación concreta durante años.
El RD 1007/2023 establece que la Declaración Responsable acredita que el software entregado cumple con los requisitos.
No obliga —ni permite— a un desarrollador asumir responsabilidad sobre modificaciones posteriores realizadas por el usuario, terceros o actualizaciones externas del ERP.
La responsabilidad de mantener el entorno conforme es de la empresa usuaria, igual que ocurre con cualquier solución certificada que permita personalizaciones o integraciones.
2. En EasySoft solo emitimos DR cuando el sistema está en condiciones de cumplir.
Nuestro módulo genera la DR firmada digitalmente, y va vinculada a:
• URL de la instalación
• versión exacta de Dolibarr
• versión del módulo
• hash del propio módulo
Si el cliente actualiza Dolibarr, cambia elementos críticos o modifica nuestro módulo, la instalación puede dejar de cumplir. Por eso la DR puede —y debe— regenerarse desde el propio módulo en cualquier momento.
Por otro lado si el usuario añade plantillas que no emiten el QR es responsabilidad del propio usuario y sería el quien incumple la normativa.
3. No existe en la normativa el concepto de “responsabilidad año a año del proveedor sobre instalaciones que no controla”.
Ningún desarrollador puede asumir legalmente la responsabilidad de un software que él no administra, no actualiza y no mantiene en el servidor del cliente.
Técnicamente es imposible y jurídicamente no lo exige la AEAT.
El RD exige:
• que el software entregado cumpla
• que el usuario mantenga su instalación conforme
• que existan mecanismos para trazar, verificar y regenerar DR conforme a la instalación actual
Nuestro módulo cumple esto de forma estricta.
4. Auditamos antes de activar VeriFactu.
Revisamos versión, inalterables, extrafields, QR, certificado digital y configuración.
Solo después se activa el modo VeriFactu.
Esto garantiza que la DR se emite sobre una instalación válida.
5. Sobre “responder dentro de un año y medio”.
Si dentro de un año la instalación ha sido actualizada a una versión no compatible con su módulo , modificado nuestro módulo, se han cambiado plantillas o se ha manipulado el software, la Declaración Responsable original deja de ser válida, como ocurre en cualquier entorno empresarial.
Por eso nuestro sistema permite regenerarla en segundos desde el propio módulo, siempre basándose en el estado técnico exacto del momento.
6. Cada uno es libre de elegir el proveedor que considere más adecuado.
Solo aclarar que, en cualquier caso, nadie puede garantizar el cumplimiento de un sistema que no controla, que ha cambiado o ha sido modificado por terceros.
Eso no lo exige la ley ni lo permite la propia arquitectura de Dolibarr.
Si tienes cualquier otra duda concreta, puedes plasmarla en este mismo post o hacérnosla llegar al mail info@easysoft.es.
Un saludo.
-
Carlos_Valverde
- Novato
- Mensajes: 7
- Registrado: Lun, 17/11/2025, 19:30
Gracias por la explicación detallada, se agradece que alguien entre al fondo del tema y no se limite a “mi módulo cumple y ya está”.
Dicho esto, hay varios puntos que me siguen generando dudas serias, más de concepto que de tecnología:
Quién emite realmente la Declaración Responsable
Decís que el módulo genera la DR firmada digitalmente desde la propia instalación del cliente, vinculada a URL, versión, hash, etc.
La cuestión es:
La DR, jurídicamente, ¿la está emitiendo EasySoft como fabricante/comercializador o la está “autogenerando” el propio usuario desde su servidor?
¿Lleváis un registro interno de todas esas DR emitidas (UUID, fecha, versión, cliente, etc.) para poder acreditarlo ante la AEAT en caso de inspección?
Porque si el usuario puede regenerar DR “en segundos” sin vuestra intervención directa, me cuesta ver cómo se garantiza que cada PDF que exista por ahí está realmente respaldado por vosotros en esa fecha concreta.
Alcance real de la auditoría
Comentáis que auditáis versión, inalterables, extrafields, QR, certificado y configuración antes de activar VeriFactu.
Eso está muy bien como punto de partida, pero el RD no habla solo de “módulo VeriFactu”, habla del SIF completo (sistema de facturación: ERP + módulos + personalizaciones + plantillas + integraciones).
Aquí la duda es clara:
¿Hasta dónde llega realmente vuestra auditoría?
¿Podéis afirmar que, con solo esas comprobaciones automáticas, está certificado el SIF completo del cliente, con todas sus personalizaciones, módulos adicionales y plantillas?
Regenerar DR vs. responsabilidad futura
Decís que no existe en la normativa el concepto de “responsabilidad año a año del proveedor sobre instalaciones que no controla”, y estoy de acuerdo en algo: nadie puede responder por lo que el cliente rompe después.
Pero al mismo tiempo comentáis que:
La DR puede regenerarse en cualquier momento desde el módulo,
Siempre “basándose en el estado técnico exacto del momento”.
Ahí es donde veo la posible contradicción práctica:
Si un cliente, dentro de 2 años, sin mantenimiento, con su Dolibarr tuneado hasta la médula, genera una nueva DR desde el módulo porque la opción sigue ahí, ¿de verdad esa DR la respalda EasySoft ante Hacienda?
¿Tenéis algún mecanismo para impedir que se genere DR en instalaciones que ya no deberían estar cubiertas (versiones obsoletas, sin parches, sin soporte, etc.)?
Límite entre responsabilidad del proveedor y del usuario
Que el usuario sea responsable si borra el QR o manipula el código, perfecto, eso es de sentido común.
Pero otra cosa es:
¿Se le está dejando claro al cliente, por contrato y por documentación, cuándo deja de ser válida vuestra DR?
¿O se le da la sensación de que “mientras pueda darle al botón de generar DR, está cubierto”?
En resumen, no discuto que vuestro módulo haga muchas comprobaciones técnicas ni que el usuario tenga parte importante de responsabilidad. Lo que intento aclarar es esto:
¿Hasta qué punto EasySoft respalda, con nombre y CIF, cada Declaración Responsable que un cliente pueda generar desde su instalación dentro de 1 o 2 años, si esa instalación ya no está bajo vuestro control ni mantenimiento?
Dicho esto, hay varios puntos que me siguen generando dudas serias, más de concepto que de tecnología:
Quién emite realmente la Declaración Responsable
Decís que el módulo genera la DR firmada digitalmente desde la propia instalación del cliente, vinculada a URL, versión, hash, etc.
La cuestión es:
La DR, jurídicamente, ¿la está emitiendo EasySoft como fabricante/comercializador o la está “autogenerando” el propio usuario desde su servidor?
¿Lleváis un registro interno de todas esas DR emitidas (UUID, fecha, versión, cliente, etc.) para poder acreditarlo ante la AEAT en caso de inspección?
Porque si el usuario puede regenerar DR “en segundos” sin vuestra intervención directa, me cuesta ver cómo se garantiza que cada PDF que exista por ahí está realmente respaldado por vosotros en esa fecha concreta.
Alcance real de la auditoría
Comentáis que auditáis versión, inalterables, extrafields, QR, certificado y configuración antes de activar VeriFactu.
Eso está muy bien como punto de partida, pero el RD no habla solo de “módulo VeriFactu”, habla del SIF completo (sistema de facturación: ERP + módulos + personalizaciones + plantillas + integraciones).
Aquí la duda es clara:
¿Hasta dónde llega realmente vuestra auditoría?
¿Podéis afirmar que, con solo esas comprobaciones automáticas, está certificado el SIF completo del cliente, con todas sus personalizaciones, módulos adicionales y plantillas?
Regenerar DR vs. responsabilidad futura
Decís que no existe en la normativa el concepto de “responsabilidad año a año del proveedor sobre instalaciones que no controla”, y estoy de acuerdo en algo: nadie puede responder por lo que el cliente rompe después.
Pero al mismo tiempo comentáis que:
La DR puede regenerarse en cualquier momento desde el módulo,
Siempre “basándose en el estado técnico exacto del momento”.
Ahí es donde veo la posible contradicción práctica:
Si un cliente, dentro de 2 años, sin mantenimiento, con su Dolibarr tuneado hasta la médula, genera una nueva DR desde el módulo porque la opción sigue ahí, ¿de verdad esa DR la respalda EasySoft ante Hacienda?
¿Tenéis algún mecanismo para impedir que se genere DR en instalaciones que ya no deberían estar cubiertas (versiones obsoletas, sin parches, sin soporte, etc.)?
Límite entre responsabilidad del proveedor y del usuario
Que el usuario sea responsable si borra el QR o manipula el código, perfecto, eso es de sentido común.
Pero otra cosa es:
¿Se le está dejando claro al cliente, por contrato y por documentación, cuándo deja de ser válida vuestra DR?
¿O se le da la sensación de que “mientras pueda darle al botón de generar DR, está cubierto”?
En resumen, no discuto que vuestro módulo haga muchas comprobaciones técnicas ni que el usuario tenga parte importante de responsabilidad. Lo que intento aclarar es esto:
¿Hasta qué punto EasySoft respalda, con nombre y CIF, cada Declaración Responsable que un cliente pueda generar desde su instalación dentro de 1 o 2 años, si esa instalación ya no está bajo vuestro control ni mantenimiento?
Carlos, gracias de nuevo por el nivel de detalle de las preguntas. Intento responder sin alargarme demasiado.
1. Quién emite realmente la Declaración Responsable
Jurídicamente, la DR la emite EasySoft como productor del componente del SIF que hemos desarrollado, tal y como establece el artículo 13 del RRSIF. Aunque el PDF se genere desde la propia instalación del cliente, va:
- Firmado con nuestro certificado.
- Identificando claramente el SIF/componentes a los que aplica.
Y nosotros conservamos internamente un registro de las DR emitidas (versión, fecha, instalación, etc.), como exige la AEAT.
Es decir: no es una “autodeclaración” del usuario, es una DR nuestra, emitida desde su instalación pero respaldada por EasySoft.
2. Alcance real: qué certificamos y qué no
El Reglamento habla del SIF completo, pero la propia AEAT, en sus FAQ, indica que en sistemas formados por varios componentes de distintos fabricantes lo normal es que haya varias declaraciones responsables, una por cada pieza que afecta al cumplimiento, y todas disponibles para el usuario.
Nuestro alcance es muy concreto:
- Módulo antifraude
- Módulo VeriFactu + configuración mínima de Dolibarr que exigimos (inalterables, extrafields, QR, firma, etc.).
No certificamos código de terceros que no producimos, ni módulos ajenos, ni desarrollos internos del cliente. Si un módulo de terceros incumple la normativa es responsabilidad del productor de ese módulo o adaptación y del cliente final.
Eso no es “escaquearse”, es exactamente lo que prevé la norma cuando un SIF se compone de varias piezas.
3. Regenerar DR y versiones obsoletas
Que el módulo permita “regenerar” la DR no significa que se pueda hacer en cualquier situación.
El propio módulo comprueba antes de emitirla:
- Versión de Dolibarr dentro del rango soportado.
- Versión del módulo.
- Parámetros necesarios para cumplir el RRSIF (inalterables, hash encadenado, firma, QR, etc.).
Si la instalación no cumple esas condiciones, no se emite DR. Y, además, las FAQ de AEAT son claras: si el fabricante ofrece versión adaptada y el cliente decide no actualizar o romper las medidas de seguridad, la responsabilidad pasa al usuario, no al fabricante.
4. Límite entre responsabilidad del proveedor y del usuario
Aquí, en la práctica, hay dos escenarios muy distintos:
A - Usuario que quiere cumplir
- Mantiene versiones soportadas.
- No manipula la base de datos ni el código para “saltarse” controles.
- Si hay inspección, el SIF tendrá los registros encadenados, firmados y, si se usa VeriFactu, remitidos a AEAT.
En este escenario, EasySoft responde por el software que ha producido y por la DR emitida para esa versión.
B - Usuario que quiere defraudar
- Desactiva el QR en plantillas, altera la base de datos por fuera, modifica el código para ocultar operaciones, etc.
En cuanto rompe las medidas de seguridad o deja de usar versiones adaptadas, se sale del marco de la DR. La propia AEAT indica que, en estos casos, la responsabilidad es del usuario que ha vulnerado el sistema.
En nuestra documentación y DR se indica siempre el alcance: versión, fecha, componente certificado y condiciones. No transmitimos la idea de “mientras puedas darle al botón estás cubierto pase lo que pase”, porque no sería cierto.
5. Sobre otros proveedores y el modelo de servicio
No entro a valorar el módulo que mencionas. Cada uno elige su modelo: cuotas recurrentes, auditorías periódicas, acompañamiento anual en inspecciones, etc.
Nuestro enfoque es otro:
- Pago único por el módulo.
- Declaración Responsable emitida por EasySoft dentro del marco legal que hay.
- Posibilidad de contratar mantenimiento si el cliente quiere que le acompañemos en el tiempo.
Y, como en cualquier SIF, mientras se mantengan las condiciones de versión y configuración, el cliente está cubierto; si decide manipular o no adaptar el sistema, la responsabilidad cambia de sitio.
Si tienes dudas muy concretas sobre un caso real (no tanto teóricas), encantado de que nos escribas a info@easysoft.es
y lo vemos con más detalle, porque a partir de cierto punto ya entra más el terreno jurídico que el técnico y creo que, para e foro, quedó claro tus preocupaciones y creo que quedaron claro nuestro planteamiento.
Un saludo.
1. Quién emite realmente la Declaración Responsable
Jurídicamente, la DR la emite EasySoft como productor del componente del SIF que hemos desarrollado, tal y como establece el artículo 13 del RRSIF. Aunque el PDF se genere desde la propia instalación del cliente, va:
- Firmado con nuestro certificado.
- Identificando claramente el SIF/componentes a los que aplica.
Y nosotros conservamos internamente un registro de las DR emitidas (versión, fecha, instalación, etc.), como exige la AEAT.
Es decir: no es una “autodeclaración” del usuario, es una DR nuestra, emitida desde su instalación pero respaldada por EasySoft.
2. Alcance real: qué certificamos y qué no
El Reglamento habla del SIF completo, pero la propia AEAT, en sus FAQ, indica que en sistemas formados por varios componentes de distintos fabricantes lo normal es que haya varias declaraciones responsables, una por cada pieza que afecta al cumplimiento, y todas disponibles para el usuario.
Nuestro alcance es muy concreto:
- Módulo antifraude
- Módulo VeriFactu + configuración mínima de Dolibarr que exigimos (inalterables, extrafields, QR, firma, etc.).
No certificamos código de terceros que no producimos, ni módulos ajenos, ni desarrollos internos del cliente. Si un módulo de terceros incumple la normativa es responsabilidad del productor de ese módulo o adaptación y del cliente final.
Eso no es “escaquearse”, es exactamente lo que prevé la norma cuando un SIF se compone de varias piezas.
3. Regenerar DR y versiones obsoletas
Que el módulo permita “regenerar” la DR no significa que se pueda hacer en cualquier situación.
El propio módulo comprueba antes de emitirla:
- Versión de Dolibarr dentro del rango soportado.
- Versión del módulo.
- Parámetros necesarios para cumplir el RRSIF (inalterables, hash encadenado, firma, QR, etc.).
Si la instalación no cumple esas condiciones, no se emite DR. Y, además, las FAQ de AEAT son claras: si el fabricante ofrece versión adaptada y el cliente decide no actualizar o romper las medidas de seguridad, la responsabilidad pasa al usuario, no al fabricante.
4. Límite entre responsabilidad del proveedor y del usuario
Aquí, en la práctica, hay dos escenarios muy distintos:
A - Usuario que quiere cumplir
- Mantiene versiones soportadas.
- No manipula la base de datos ni el código para “saltarse” controles.
- Si hay inspección, el SIF tendrá los registros encadenados, firmados y, si se usa VeriFactu, remitidos a AEAT.
En este escenario, EasySoft responde por el software que ha producido y por la DR emitida para esa versión.
B - Usuario que quiere defraudar
- Desactiva el QR en plantillas, altera la base de datos por fuera, modifica el código para ocultar operaciones, etc.
En cuanto rompe las medidas de seguridad o deja de usar versiones adaptadas, se sale del marco de la DR. La propia AEAT indica que, en estos casos, la responsabilidad es del usuario que ha vulnerado el sistema.
En nuestra documentación y DR se indica siempre el alcance: versión, fecha, componente certificado y condiciones. No transmitimos la idea de “mientras puedas darle al botón estás cubierto pase lo que pase”, porque no sería cierto.
5. Sobre otros proveedores y el modelo de servicio
No entro a valorar el módulo que mencionas. Cada uno elige su modelo: cuotas recurrentes, auditorías periódicas, acompañamiento anual en inspecciones, etc.
Nuestro enfoque es otro:
- Pago único por el módulo.
- Declaración Responsable emitida por EasySoft dentro del marco legal que hay.
- Posibilidad de contratar mantenimiento si el cliente quiere que le acompañemos en el tiempo.
Y, como en cualquier SIF, mientras se mantengan las condiciones de versión y configuración, el cliente está cubierto; si decide manipular o no adaptar el sistema, la responsabilidad cambia de sitio.
Si tienes dudas muy concretas sobre un caso real (no tanto teóricas), encantado de que nos escribas a info@easysoft.es
y lo vemos con más detalle, porque a partir de cierto punto ya entra más el terreno jurídico que el técnico y creo que, para e foro, quedó claro tus preocupaciones y creo que quedaron claro nuestro planteamiento.
Un saludo.
Buenos días;
Disculpa la demora pero no nos llegan avisos de las respuestas en el post.
El precio de los módulos necesarios (Verifactu + Antifraude) actualmente es de 450 € un solo pago (sin cuotas anuales obligatorias)
Un saludo.
Disculpa la demora pero no nos llegan avisos de las respuestas en el post.
El precio de los módulos necesarios (Verifactu + Antifraude) actualmente es de 450 € un solo pago (sin cuotas anuales obligatorias)
Un saludo.
-
Carlos_Valverde
- Novato
- Mensajes: 7
- Registrado: Lun, 17/11/2025, 19:30
No me queda del todo claro. Aquí dicen que es un único pago, lo cual me parece perfecto, pero en tu respuesta anterior comentas lo siguiente:
"- Posibilidad de contratar mantenimiento si el cliente quiere que le acompañemos en el tiempo."
Entonces, ¿si quien compra vuestro módulo no contrata el mantenimiento después del primer año, ya no le dais soporte ni le acompañáis en adelante? ¿Y cómo queda entonces la declaración responsable?