Hola a todos,
Llevo días dándole vueltas al tema de VeriFactu en Dolibarr y cómo lo están gestionando algunos proveedores. Me he encontrado con empresas que venden el módulo y entregan una declaración responsable, pero… sin revisar las instalaciones del cliente, sin controlar versiones y sin comprobar si el software ha cambiado al cabo de un año.
Y ahí me surgen varias dudas serias (supongo que a más de uno también):
Si la declaración tiene fecha de hace meses o incluso un año, ¿realmente sirve cuando llegue una inspección?
¿Cómo puede un proveedor asegurar que “su” declaración sigue siendo válida si la instalación del cliente ha cambiado, Dolibarr se ha actualizado o las plantillas PDF se han tocado?
¿Qué pasa si dentro de un año y medio te cae una revisión de Hacienda y el software no coincide con lo que decía esa declaración? ¿Se hacen cargo ellos, o el marrón es para la empresa?
He visto proveedores que actualizan la declaración cada vez que actualizan el módulo y realizan verificaciones reales. Por ejemplo, encontré esta opción que parece más seria respecto al tema de cumplimiento:
https://verifactudolibarr.es
¿Alguien más se ha encontrado con estas dudas?
¿Sabéis cómo lo gestiona vuestro proveedor?
Porque como esto no esté bien atado, las sanciones de la Ley Antifraude no son ninguna broma…
Módulo Verifactu para Dolibarr
-
Carlos_Valverde
- Novato
- Mensajes: 7
- Registrado: Lun, 17/11/2025, 19:30
Hola:
Nosotros en EasySoft somos los desarrolladores de un módulo VeriFactu para Dolibarr. Comento cómo gestionamos nosotros la Declaración Responsable y el cumplimiento, porque varias de las dudas que planteas son muy habituales.
1. La Declaración Responsable no es un PDF genérico.
En nuestro caso, la DR se genera siempre vinculada a la URL concreta de la instalación, a la versión exacta de Dolibarr y al hash del propio módulo.
Además, la compatibilidad entre versiones (Dolibarr ↔ módulo) queda indicada tanto en la configuración como en la propia hoja responsable.
2. Se emite por versión y en tiempo real.
Cada cliente puede generar su Declaración Responsable desde el propio módulo, en el mismo momento en el que la necesita, y queda firmada digitalmente, garantizando que corresponde a la instalación tal y como está en ese instante.
Esto implica que, si un cliente actualiza Dolibarr o actualiza el módulo, puede —y debe— generar una nueva DR acorde a la nueva situación.
3. Auditoría de la instalación antes de activar VeriFactu.
El módulo verifica, activa o pide inroducir todos los requisitos técnicos:
• Activación de inalterables
• Extrafields necesarios
• Configuración de series
• Funcionamiento del encadenado hash
• Certificado digital
• Correcta generación de QR
• Compatibilidad de versión
4. Sobre las plantillas personalizadas y el QR.
Normativamente, si un usuario modifica una plantilla y elimina el QR o lo hace no conforme, quien incumple es la empresa usuaria, igual que si modificase cualquier otro software certificado. Aun así, nuestro módulo valida en la medida de lo posible que las plantillas ODT/ODS usen las variables de QR correctas.
5. Mantenimiento y actualizaciones.
Incluimos las actualizaciones necesarias para:
• adaptaciones a cambios normativos
• compatibilidad con nuevas versiones de Dolibarr
• mejoras técnicas relacionadas con VeriFactu
6. Si actualizas tu dolibarr a una versión no compatible hay cambios normativos que obliguen a actualizar y no lo haces o modificas el código de nuestro módulo entonces SI pierdes la hoja responsable
Si necesitas cualquier aclaración concreta sobre cómo funciona nuestro módulo o cómo debe gestionarse la DR, puedes contactar con nosotros directamente (info@easysoft.es
). Estaremos encantados de ayudarte.
Nosotros en EasySoft somos los desarrolladores de un módulo VeriFactu para Dolibarr. Comento cómo gestionamos nosotros la Declaración Responsable y el cumplimiento, porque varias de las dudas que planteas son muy habituales.
1. La Declaración Responsable no es un PDF genérico.
En nuestro caso, la DR se genera siempre vinculada a la URL concreta de la instalación, a la versión exacta de Dolibarr y al hash del propio módulo.
Además, la compatibilidad entre versiones (Dolibarr ↔ módulo) queda indicada tanto en la configuración como en la propia hoja responsable.
2. Se emite por versión y en tiempo real.
Cada cliente puede generar su Declaración Responsable desde el propio módulo, en el mismo momento en el que la necesita, y queda firmada digitalmente, garantizando que corresponde a la instalación tal y como está en ese instante.
Esto implica que, si un cliente actualiza Dolibarr o actualiza el módulo, puede —y debe— generar una nueva DR acorde a la nueva situación.
3. Auditoría de la instalación antes de activar VeriFactu.
El módulo verifica, activa o pide inroducir todos los requisitos técnicos:
• Activación de inalterables
• Extrafields necesarios
• Configuración de series
• Funcionamiento del encadenado hash
• Certificado digital
• Correcta generación de QR
• Compatibilidad de versión
4. Sobre las plantillas personalizadas y el QR.
Normativamente, si un usuario modifica una plantilla y elimina el QR o lo hace no conforme, quien incumple es la empresa usuaria, igual que si modificase cualquier otro software certificado. Aun así, nuestro módulo valida en la medida de lo posible que las plantillas ODT/ODS usen las variables de QR correctas.
5. Mantenimiento y actualizaciones.
Incluimos las actualizaciones necesarias para:
• adaptaciones a cambios normativos
• compatibilidad con nuevas versiones de Dolibarr
• mejoras técnicas relacionadas con VeriFactu
6. Si actualizas tu dolibarr a una versión no compatible hay cambios normativos que obliguen a actualizar y no lo haces o modificas el código de nuestro módulo entonces SI pierdes la hoja responsable
Si necesitas cualquier aclaración concreta sobre cómo funciona nuestro módulo o cómo debe gestionarse la DR, puedes contactar con nosotros directamente (info@easysoft.es
). Estaremos encantados de ayudarte.
-
Carlos_Valverde
- Novato
- Mensajes: 7
- Registrado: Lun, 17/11/2025, 19:30
Gracias por la explicación. Queda más claro cómo lo gestionáis, pero me surgen varias dudas importantes respecto al cumplimiento real del RD 1007/2023 y de la validez futura de la Declaración Responsable:
La declaración la genera el propio cliente desde su instalación.
La norma exige que la declaración responsable la firme el fabricante o comercializador, no el usuario final.
Que el cliente pueda “autogenerar” una DR desde su instancia sin intervención del fabricante puede generar un problema jurídico:
¿Cómo se asegura EasySoft de que la declaración emitida desde una instalación local es realmente la que vosotros podéis respaldar legalmente?
No verificáis el entorno del cliente antes de firmar la DR.
Por lo que comentáis, el módulo hace comprobaciones automáticas (extrafields, QR, hashes…).
Pero el RD 1007/2023 exige que la declaración responsable certifique que el sistema completo (SIF) cumple:
plantillas, configuraciones, integridad del servidor, módulos externos, personalizaciones, etc.
El módulo puede comprobar partes técnicas, pero no audita el SIF completo.
¿Cómo podéis firmar una Declaración Responsable válida si no revisáis manualmente ni certificáis la instalación real?
Si el cliente cambia algo (plantillas, módulo, configuraciones), decís que pierde la hoja responsable.
Pero esto plantea otra duda clave:
¿Qué mecanismo tenéis para detectar que el cliente ha cambiado algo y que vuestra declaración deja de ser válida?
Porque si no existe ese control, un cliente podría tener una DR aparentemente válida pero técnicamente caducada.
Sobre la vigencia en inspección futura.
Si dentro de 1–2 años la AEAT solicita la DR, y el cliente ha actualizado, modificado o usado una versión previa:
¿EasySoft asume la responsabilidad legal de esa DR emitida desde la instalación del cliente?
¿O la responsabilidad recae totalmente sobre el usuario aunque la DR lleve vuestro nombre?
El RD 1007/2023 exige que la DR refleje el estado real del software comercializado.
Si el cliente genera la DR por su cuenta desde su instancia, puede emitirla en cualquier momento, incluso aunque esté desactualizado.
¿Cómo garantizáis que la DR generada corresponde a una versión que vosotros, como fabricantes, podéis certificar oficialmente en ese momento?
La declaración la genera el propio cliente desde su instalación.
La norma exige que la declaración responsable la firme el fabricante o comercializador, no el usuario final.
Que el cliente pueda “autogenerar” una DR desde su instancia sin intervención del fabricante puede generar un problema jurídico:
¿Cómo se asegura EasySoft de que la declaración emitida desde una instalación local es realmente la que vosotros podéis respaldar legalmente?
No verificáis el entorno del cliente antes de firmar la DR.
Por lo que comentáis, el módulo hace comprobaciones automáticas (extrafields, QR, hashes…).
Pero el RD 1007/2023 exige que la declaración responsable certifique que el sistema completo (SIF) cumple:
plantillas, configuraciones, integridad del servidor, módulos externos, personalizaciones, etc.
El módulo puede comprobar partes técnicas, pero no audita el SIF completo.
¿Cómo podéis firmar una Declaración Responsable válida si no revisáis manualmente ni certificáis la instalación real?
Si el cliente cambia algo (plantillas, módulo, configuraciones), decís que pierde la hoja responsable.
Pero esto plantea otra duda clave:
¿Qué mecanismo tenéis para detectar que el cliente ha cambiado algo y que vuestra declaración deja de ser válida?
Porque si no existe ese control, un cliente podría tener una DR aparentemente válida pero técnicamente caducada.
Sobre la vigencia en inspección futura.
Si dentro de 1–2 años la AEAT solicita la DR, y el cliente ha actualizado, modificado o usado una versión previa:
¿EasySoft asume la responsabilidad legal de esa DR emitida desde la instalación del cliente?
¿O la responsabilidad recae totalmente sobre el usuario aunque la DR lleve vuestro nombre?
El RD 1007/2023 exige que la DR refleje el estado real del software comercializado.
Si el cliente genera la DR por su cuenta desde su instancia, puede emitirla en cualquier momento, incluso aunque esté desactualizado.
¿Cómo garantizáis que la DR generada corresponde a una versión que vosotros, como fabricantes, podéis certificar oficialmente en ese momento?
Gracias por plantearlo con detalle. Intento responder punto por punto para que quede totalmente claro el alcance y los límites, que al final es lo que marca el propio RD 1007/2023.
1. Sobre quién emite realmente la Declaración Responsable
La DR generada desde el módulo no es una autodeclaración del cliente.
Va siempre:
- Firmada con nuestro certificado,
- Generada con nuestros datos de productor,
- Basada en los parámetros técnicos que exige el Reglamento,
- Y registrada internamente por EasySoft (versión, fecha, instalación, hash del módulo, etc.).
El botón solo ejecuta el proceso desde la instalación del cliente, pero la DR, jurídicamente, es nuestra, igual que cuando un proveedor permite descargar la DR desde un portal web.
Lo importante es que:
La DR sólo se emite si la instalación cumple las condiciones técnicas que nosotros exigimos para certificar la parte del SIF que producimos.
2. Sobre si “hay que auditar manualmente el SIF completo”
Aquí es donde hay más confusión general.
El RD define el SIF como algo que puede estar compuesto por distintos productos y fabricantes.
La propia AEAT, en sus FAQ, indica que en sistemas formados por varios componentes:
"Lo habitual es que haya varias declaraciones responsables, una por cada parte que afecta al cumplimiento."
Nosotros certificamos solo nuestra parte, que es lo que fabricamos:
- El módulo VeriFactu y el módulo antifraude.
- Los elementos de Dolibarr que son imprescindibles para que funcione el encadenado, la firma, el QR y la integridad del registro.
No certificamos:
- Plantillas creadas por terceros.
- Módulos externos ajenos a EasySoft.
- Personalizaciones hechas por el cliente.
- Código alterado.
Eso no lo exige la norma y, de hecho, ningún desarrollador podría asumir la responsabilidad de un SIF que no controla.
Nuestra auditoría previa garantiza que:
- La instalación cumple los requisitos obligatorios.
- El sistema está en condiciones de aplicar el RRSIF para las facturas emitidas con nuestro módulo.
- El alcance es claro y es el que marca el propio Reglamento.
3. “¿Qué pasa si el cliente cambia algo?”
(y cómo se detecta que una DR deja de ser válida)
Hay dos niveles aquí:
A) Nivel técnico
El módulo no permite generar una DR si:
- La versión de Dolibarr no está dentro del rango soportado,
- La versión del módulo no corresponde,
- Falta algún requisito técnico obligatorio (inalterables, extrafields, QR, firma, etc.).
Si no cumple → no hay DR.
B) Nivel jurídico
Las FAQ de la AEAT dicen expresamente que:
- Si el cliente no actualiza una versión adaptada por el fabricante, la responsabilidad pasa a él.
- Si el cliente rompe las medidas de seguridad, la responsabilidad pasa a él, aunque exista una DR previa.
Es decir:
Aunque se conserve un PDF antiguo, si el cliente modifica plantillas, módulos, código o versiones fuera del soporte, la DR queda invalidada automáticamente.
Esto no depende del proveedor, depende del uso que haga el cliente del software.
4. Vigencia de la DR en una inspección futura
Si la instalación:
- Mantiene versiones soportadas
- No ha sido manipulada
- Usa el módulo conforme al diseño
- Y se genera la DR correspondiente al estado real del sistema en ese momento
EasySoft respalda esa DR porque refleja exactamente el software que producimos.
Si la instalación:
- Ha sido tuneada,
- Está fuera de soporte,
- Se han roto medidas de seguridad,
- Se han borrado QR o alterado plantillas deliberadamente,
la responsabilidad pasa a ser del usuario, exactamente igual que indica la AEAT en sus guías.
No es un criterio nuestro: es lo que establece el propio Reglamento.
5. ¿Puede un cliente generar una DR “desactualizada”?
El módulo ya impide emitir DR si la instalación no cumple los requisitos técnicos mínimos o está fuera de versión.
Aun así, aunque alguien conservara un PDF antiguo:
La AEAT siempre contrasta la DR con el estado del sistema en el momento de la inspección.
Si el sistema está alterado o no coincide con los datos de la DR → la DR queda invalidada automáticamente.
Por eso nuestra DR incluye siempre:
- versión de Dolibarr,
- versión del módulo,
- hash,
- fecha,
- URL exacta.
No se puede “colar” como válida algo que ya no representa la instalación real.
6. En resumen
La DR es de EasySoft, no del usuario.
Solo se emite si la instalación cumple los requisitos.
Certificamos nuestra parte del SIF, como indica el RD para sistemas modulares.
Si el cliente altera el ERP, cambia versiones o rompe medidas de seguridad, la DR queda sin efecto (criterio AEAT).
Si el cliente mantiene el sistema conforme, EasySoft respalda la DR emitida.
Y si surgen dudas concretas de un caso real, las resolvemos directamente.
Si quieres ver algún caso práctico o revisar un escenario concreto, me lo dices sin problema, pero entiendo que igual es mejor por privado para no saturar el foro ni el post con una conversación entre dos.
Un saludo.
1. Sobre quién emite realmente la Declaración Responsable
La DR generada desde el módulo no es una autodeclaración del cliente.
Va siempre:
- Firmada con nuestro certificado,
- Generada con nuestros datos de productor,
- Basada en los parámetros técnicos que exige el Reglamento,
- Y registrada internamente por EasySoft (versión, fecha, instalación, hash del módulo, etc.).
El botón solo ejecuta el proceso desde la instalación del cliente, pero la DR, jurídicamente, es nuestra, igual que cuando un proveedor permite descargar la DR desde un portal web.
Lo importante es que:
La DR sólo se emite si la instalación cumple las condiciones técnicas que nosotros exigimos para certificar la parte del SIF que producimos.
2. Sobre si “hay que auditar manualmente el SIF completo”
Aquí es donde hay más confusión general.
El RD define el SIF como algo que puede estar compuesto por distintos productos y fabricantes.
La propia AEAT, en sus FAQ, indica que en sistemas formados por varios componentes:
"Lo habitual es que haya varias declaraciones responsables, una por cada parte que afecta al cumplimiento."
Nosotros certificamos solo nuestra parte, que es lo que fabricamos:
- El módulo VeriFactu y el módulo antifraude.
- Los elementos de Dolibarr que son imprescindibles para que funcione el encadenado, la firma, el QR y la integridad del registro.
No certificamos:
- Plantillas creadas por terceros.
- Módulos externos ajenos a EasySoft.
- Personalizaciones hechas por el cliente.
- Código alterado.
Eso no lo exige la norma y, de hecho, ningún desarrollador podría asumir la responsabilidad de un SIF que no controla.
Nuestra auditoría previa garantiza que:
- La instalación cumple los requisitos obligatorios.
- El sistema está en condiciones de aplicar el RRSIF para las facturas emitidas con nuestro módulo.
- El alcance es claro y es el que marca el propio Reglamento.
3. “¿Qué pasa si el cliente cambia algo?”
(y cómo se detecta que una DR deja de ser válida)
Hay dos niveles aquí:
A) Nivel técnico
El módulo no permite generar una DR si:
- La versión de Dolibarr no está dentro del rango soportado,
- La versión del módulo no corresponde,
- Falta algún requisito técnico obligatorio (inalterables, extrafields, QR, firma, etc.).
Si no cumple → no hay DR.
B) Nivel jurídico
Las FAQ de la AEAT dicen expresamente que:
- Si el cliente no actualiza una versión adaptada por el fabricante, la responsabilidad pasa a él.
- Si el cliente rompe las medidas de seguridad, la responsabilidad pasa a él, aunque exista una DR previa.
Es decir:
Aunque se conserve un PDF antiguo, si el cliente modifica plantillas, módulos, código o versiones fuera del soporte, la DR queda invalidada automáticamente.
Esto no depende del proveedor, depende del uso que haga el cliente del software.
4. Vigencia de la DR en una inspección futura
Si la instalación:
- Mantiene versiones soportadas
- No ha sido manipulada
- Usa el módulo conforme al diseño
- Y se genera la DR correspondiente al estado real del sistema en ese momento
EasySoft respalda esa DR porque refleja exactamente el software que producimos.
Si la instalación:
- Ha sido tuneada,
- Está fuera de soporte,
- Se han roto medidas de seguridad,
- Se han borrado QR o alterado plantillas deliberadamente,
la responsabilidad pasa a ser del usuario, exactamente igual que indica la AEAT en sus guías.
No es un criterio nuestro: es lo que establece el propio Reglamento.
5. ¿Puede un cliente generar una DR “desactualizada”?
El módulo ya impide emitir DR si la instalación no cumple los requisitos técnicos mínimos o está fuera de versión.
Aun así, aunque alguien conservara un PDF antiguo:
La AEAT siempre contrasta la DR con el estado del sistema en el momento de la inspección.
Si el sistema está alterado o no coincide con los datos de la DR → la DR queda invalidada automáticamente.
Por eso nuestra DR incluye siempre:
- versión de Dolibarr,
- versión del módulo,
- hash,
- fecha,
- URL exacta.
No se puede “colar” como válida algo que ya no representa la instalación real.
6. En resumen
La DR es de EasySoft, no del usuario.
Solo se emite si la instalación cumple los requisitos.
Certificamos nuestra parte del SIF, como indica el RD para sistemas modulares.
Si el cliente altera el ERP, cambia versiones o rompe medidas de seguridad, la DR queda sin efecto (criterio AEAT).
Si el cliente mantiene el sistema conforme, EasySoft respalda la DR emitida.
Y si surgen dudas concretas de un caso real, las resolvemos directamente.
Si quieres ver algún caso práctico o revisar un escenario concreto, me lo dices sin problema, pero entiendo que igual es mejor por privado para no saturar el foro ni el post con una conversación entre dos.
Un saludo.