Verifactu en software a medida y ERP propio

Hay un grupo de empresas que lo tiene especialmente difícil con Verifactu: las que facturan con un programa hecho a medida. Un ERP desarrollado para ellas, una aplicación interna, un sistema que lleva diez años funcionando. Cuando todo el mundo habla de «actualiza tu software», ellas se preguntan: ¿y quién lo actualiza?

El problema de fondo

Con un programa comercial, el fabricante saca una actualización y listo. Con un desarrollo a medida, no hay fabricante que lo haga por ti. Puede que quien lo programó ya no esté, que el código esté sin documentar, o que esté escrito en una tecnología que ya casi nadie toca.

Y aun así, si ese programa emite facturas, tiene que cumplir. La obligación no depende de si el software es bonito o moderno.

Qué exige realmente a un sistema propio

No hay que rehacer todo. Hay que añadir una capa con unas funciones concretas:

Registro de facturación inmutable por cada factura emitida o anulada.
Huella encadenada entre registros.
Código QR en la factura.
Envío a la AEAT o, en su defecto, firma y registro de eventos (según la modalidad que elijas).
Control de errores y trazabilidad: qué se envió, cuándo y con qué resultado.

Lo demás de tu programa puede seguir como está. No hace falta migrar a otro sistema ni tocar la parte contable.

Dos formas de resolverlo

1. Integrar dentro del programa. Si el código es accesible y mantenible, se añade el módulo directamente en el momento de emitir la factura. Es la opción más limpia cuando se puede.

2. Integrar «por fuera». Si el código es inaccesible o frágil, se coloca una capa intermedia que lee las facturas emitidas (de una base de datos, una API o una carpeta) y se encarga de generar los registros y enviarlos. El programa original no se toca. Es menos elegante pero a veces es la única opción realista.

Cuál elegir se decide después de ver el sistema. No hay una respuesta universal.

Qué suelo revisar primero

Antes de proponer nada, miro estas cosas:

Dónde se genera exactamente la factura y si hay más de un punto de emisión.
Cómo se numera y si hay saltos o excepciones.
Qué ocurre cuando se corrige o anula una factura.
Qué tecnología usa y quién puede tocarla.
Si hay otros sistemas conectados que también facturan.

Sobre el último punto: es frecuente descubrir que hay «una segunda vía» de facturación (un Excel, un proceso manual) que nadie recordaba. Hay que localizarla porque también cuenta.

Laravel, PHP, .NET, Java…

La tecnología importa menos de lo que parece. He trabajado con sistemas de todo tipo, y lo habitual es que el reto no sea el lenguaje sino entender el flujo de facturación. Si tu sistema está en Laravel, por ejemplo, tienes un caso concreto explicado en Verifactu en Laravel.

¿Y si lo desarrollo yo mismo?

Si desarrollas tu propio software de facturación, tienes también responsabilidades como productor del sistema, incluida una declaración responsable sobre su cumplimiento. Es un punto que conviene confirmar con tu asesor, porque los matices dependen del caso.

Siguiente paso

Si tu sistema es a medida y quieres saber qué se necesita realmente, puedo revisarlo y decirte con claridad si es un trabajo pequeño o grande. Aquí tienes el enfoque general: Verifactu en software a medida. O escríbeme directamente y lo miramos.

Preguntas frecuentes

¿Tengo que reescribir mi programa? No. Se añade una capa de Verifactu, dentro o fuera del programa, y el resto sigue funcionando.

¿Y si quien lo programó ya no está? Se puede integrar por fuera, leyendo las facturas emitidas, sin tocar el código original.

¿Cuánto cuesta? Depende de lo que haya que adaptar. Tras revisar el sistema se puede dar una cifra realista, no antes.