La asesoría de Valencia que descubrió a tres meses del plazo que su software no cumplía Veri*factu
Resumen:
- Veri*factu no es una obligación de enviar facturas: es una obligación sobre cómo las genera y las guarda tu software.
- Los tres requisitos que más sistemas antiguos incumplen son el encadenamiento de registros, la imposibilidad de borrar y el registro de eventos.
- La responsabilidad legal es de la empresa que factura, no del fabricante del programa.
- Lo que más retrasa una adaptación no es el desarrollo: son los datos maestros sucios.
Una asesoría de Valencia con veintidós empleados nos escribió en primavera. Facturaban con un programa que un desarrollador local les había hecho once años antes y que, según ellos, «funcionaba perfectamente». Su gestor les había mencionado de pasada que había una normativa nueva y querían una segunda opinión antes de gastar dinero.
El programa funcionaba, es cierto. Emitía facturas, las numeraba, las imprimía y las guardaba. El problema es que la ley había dejado de conformarse con eso.
Qué exige realmente Veri*factu a tu software
La confusión más extendida es pensar que se trata de mandar las facturas a Hacienda. No es eso. El reglamento regula los requisitos que debe cumplir cualquier sistema informático de facturación, y la remisión a la AEAT es solo una de las dos modalidades posibles.
Lo que la norma exige, en la práctica, se puede resumir en cuatro propiedades que el sistema debe garantizar sobre cada factura emitida:
| Propiedad | Qué significa en el código |
|---|---|
| Integridad | Cada registro de facturación lleva una huella criptográfica que incluye la huella del registro anterior. Modificar una factura de hace tres meses rompe la cadena de todas las posteriores y eso es detectable. |
| Inalterabilidad | No existe ninguna operación en el sistema que permita editar o borrar un registro emitido. Las correcciones se hacen con registros de anulación o rectificación, que también quedan encadenados. |
| Trazabilidad | Se puede reconstruir el orden exacto en que ocurrieron las cosas: qué se emitió, cuándo, quién lo hizo y qué se anuló después. |
| Conservación | Los registros permanecen accesibles y legibles durante el plazo legal, en un formato que se pueda entregar a la Administración si lo pide. |
Dicho de otro modo: la norma asume que el software puede ser manipulado y obliga a que cualquier manipulación deje huella.
El diagnóstico: qué encontramos al abrir el programa
Pedimos acceso al código y a una copia de la base de datos. La revisión llevó tres días. Estos fueron los hallazgos, ordenados de más grave a menos.
La factura se podía editar
Había una pantalla de «corregir factura» que actualizaba directamente la fila existente en la tabla de facturas. Se usaba a diario y con buena fe: alguien detectaba un error en el nombre del cliente, entraba y lo arreglaba. Después de la modificación no quedaba ningún rastro de cuál era el valor anterior ni de quién lo había cambiado.
Esto, por sí solo, invalidaba el sistema completo. No es un defecto técnico: es exactamente la conducta que la normativa pretende impedir.
No existía registro de facturación separado
El programa guardaba las facturas y punto. La norma exige un registro de facturación: una estructura aparte, en la que cada alta genera una entrada nueva y encadenada, independientemente de lo que pase después con el documento comercial. La distinción parece burocrática y no lo es. Es lo que permite demostrar qué se emitió realmente, aunque la factura se anule más tarde.
La numeración tenía huecos
Encontramos saltos en la serie. Al investigarlos resultó que, cuando una factura se creaba y el usuario cancelaba antes de guardar, el número ya se había consumido. Nadie lo había notado en once años. Con la norma nueva, un hueco sin justificar es un hallazgo de inspección.
Lo que sí se pudo salvar
No todo era malo. El programa concentraba la emisión de facturas en una sola función, algo que suena obvio pero que en sistemas antiguos casi nunca ocurre. Eso significaba que se podía interceptar ese único punto para generar el registro encadenado, en lugar de perseguir veinte pantallas distintas. También tenían el histórico completo desde el primer día, sin borrados.
Esos dos hechos decidieron el proyecto: adaptar en lugar de reescribir.
La conversación incómoda sobre quién es responsable
El gerente hizo la pregunta que hace todo el mundo: ¿esto no debería arreglarlo el que nos hizo el programa?
Moralmente, quizá. Legalmente, no. La obligación de emitir facturas conforme a la normativa recae sobre el obligado tributario, es decir, sobre la asesoría. Si el software no cumple, el problema es de quien factura, no de quien programó. El fabricante tiene sus propias obligaciones —debe declarar responsablemente que su producto cumple— pero eso no traslada la responsabilidad del usuario.
En este caso el desarrollador original llevaba cuatro años ilocalizable. Es un escenario más común de lo que parece y es la razón por la que insistimos siempre en dos cláusulas: quién garantiza la adaptación normativa y en qué plazo, y derecho a una exportación completa de los datos en formato abierto.
Qué revisamos en cualquier sistema de facturación
De aquella auditoría salió una lista que ahora aplicamos en todos los diagnósticos. Sirve como autoevaluación: si respondes «no» a alguna, tienes trabajo pendiente.
- ¿Existe alguna pantalla, script o acceso directo a base de datos que permita modificar una factura emitida?
- ¿Cada registro incorpora la huella del anterior, de forma que la cadena sea verificable?
- ¿Las anulaciones generan un registro nuevo en lugar de borrar el original?
- ¿Queda constancia de qué usuario realizó cada operación y cuándo?
- ¿La numeración es correlativa sin huecos, o los huecos están justificados con un registro?
- ¿Se puede exportar el conjunto completo de registros en un formato legible por la Administración?
- ¿El sistema impide emitir dos veces la misma factura ante un fallo de red o un doble clic?
- ¿Existe copia de seguridad con retención suficiente y se ha probado la restauración?
Preguntas frecuentes
¿Veri*factu obliga a enviar todas las facturas a la AEAT?
No necesariamente. Hay dos modalidades: la remisión voluntaria en tiempo real a la AEAT, que es la que da nombre al sistema, y la modalidad de sistema no verificable, en la que los registros se conservan en el propio equipo con las mismas garantías de integridad y se ponen a disposición cuando la Administración los solicite. La primera reduce obligaciones de conservación; la segunda exige más control interno.
¿Qué pasa si mi proveedor de software desaparece?
La responsabilidad de emitir facturas conforme a la norma es del obligado tributario, no del fabricante. Si el proveedor cierra o no actualiza, la empresa sigue siendo responsable. Por eso conviene revisar en el contrato quién garantiza la adaptación normativa y en qué plazo, y disponer de una exportación completa de los datos.
¿Se puede adaptar un software antiguo o hay que empezar de cero?
Depende de si la base de datos permite añadir una tabla de registros inmutable y de si el código concentra la emisión de facturas en un punto o la reparte por toda la aplicación. Cuando la emisión está centralizada, la adaptación es viable. Cuando cada pantalla escribe facturas por su cuenta, suele salir más barato reescribir el módulo.
¿Una hoja de cálculo puede cumplir Veri*factu?
No. Un sistema informático de facturación debe garantizar que un registro, una vez emitido, no se puede alterar ni borrar sin dejar rastro. Una hoja de cálculo es modificable por diseño, así que no puede cumplir el requisito de inalterabilidad por mucho que se protejan las celdas.
¿Cuánto tiempo lleva adaptar un sistema existente?
En los casos que hemos visto, entre seis y catorce semanas de trabajo efectivo cuando la emisión de facturas está bien delimitada en el código. El factor que más alarga el proyecto casi nunca es el desarrollo: es la limpieza de datos maestros de clientes que llevaban años acumulando duplicados y campos incompletos.
Cómo terminó
La asesoría eligió adaptar. Se construyó una tabla de registros encadenada, se eliminó la pantalla de edición y se sustituyó por un flujo de rectificativas, y se añadió un registro de eventos con usuario y marca de tiempo. La parte más lenta fue, como casi siempre, normalizar la base de clientes: tres mil quinientas fichas con duplicados, NIF mal formados y direcciones incompletas que nadie había revisado desde 2014.
La lección que se llevaron no fue técnica. Fue que llevaban once años con una dependencia crítica sin contrato de mantenimiento, sin acceso al código y sin plan de salida. La normativa solo hizo visible un riesgo que ya existía.
Si estás en una situación parecida, el primer paso no es contratar desarrollo: es responder las ocho preguntas de la lista de arriba sobre tu sistema actual. Con esas respuestas se sabe si toca adaptar, reescribir el módulo o cambiar de herramienta.