Verifactu no es un problema de facturas, es un problema de datos
Verifactu y la factura electrónica B2B exigen datos estructurados. El reto no es la factura: son las hojas de cálculo y los procesos que llegan hasta ella.
En muchas empresas, una factura es el último paso de una cadena bastante artesanal. El presupuesto se aprobó en un correo. El pedido vive en una hoja de cálculo. Los datos fiscales del cliente están en otra. Alguien junta todo a final de mes, lo pasa al programa de facturación y lo envía en PDF. Funciona porque una persona conoce el camino.
Las dos normas que llegan en 2027 no cambian el último paso. Cambian lo que ese último paso exige de todos los anteriores.
La normativa pide datos estructurados al final de la cadena. Quien los tiene desordenados al principio lo va a pagar ahí.
Qué llega y cuándo
Son dos obligaciones distintas que a menudo se confunden. Esto es un resumen para situarse, no asesoría fiscal: los detalles de tu caso, con tu asesor.
Verifactu. Los sistemas informáticos de facturación tienen que cumplir los requisitos del Real Decreto 1007/2023. Tras la ampliación del Real Decreto-ley 15/2025, según la Agencia Tributaria, los contribuyentes del Impuesto sobre Sociedades deben tenerlos adaptados antes del 1 de enero de 2027, y el resto de obligados antes del 1 de julio de 2027.
Factura electrónica entre empresas. El Real Decreto 238/2026, publicado en el BOE el 31 de marzo de 2026, obliga a empresarios y profesionales a emitir y recibir facturas electrónicas estructuradas en sus operaciones con otras empresas. La nota de la Agencia Tributaria explica dos puntos que importan aquí:
- Quien recibe la factura tendrá que comunicar su aceptación o rechazo comercial, y el pago completo con sus fechas.
- Se aplicará a los doce meses de la entrada en vigor de la orden ministerial que la desarrolla para quienes superen 8 millones de euros de volumen de operaciones, y a los veinticuatro meses para el resto.
Es decir: no basta con emitir bien. También habrá que saber, y comunicar, qué pasa con cada factura después.
La factura es el último eslabón
Un programa de facturación adaptado resuelve el formato, el registro y el envío. Lo que no resuelve es la calidad de lo que le llega. Y ahí es donde suele estar el problema real:
- Datos de cliente dispersos. El mismo cliente aparece con tres razones sociales y dos NIF en sitios distintos.
- Pedidos que no existen como datos. Lo que se vendió está en un hilo de correo, no en un registro.
- Precios que cambian sin rastro. La factura sale con el precio de hoy, no con el que se acordó.
- Estados que nadie registra. Si se aceptó, si se rechazó o cuándo se pagó lo sabe una persona, no un sistema.
Mientras todo acaba en un PDF, una persona puede tapar esos huecos a mano. Cuando la factura es un mensaje estructurado y sus estados también, los huecos se convierten en errores.
Qué he aprendido construyendo sistemas con datos que importan
No he construido un sistema de facturación, y no creo que la mayoría de las empresas deba hacerlo. Pero sí he tenido que resolver el mismo problema de fondo en otros contextos.
En Lantilla.com, una tienda de fotografía con variantes de presentación y tamaño, el pedido guarda una instantánea de título, variante y precio en el momento de la compra. Si mañana cambia el precio de una foto, el pedido de ayer sigue diciendo lo que se vendió. Los pedidos tienen estados explícitos, de pendiente a entregado o cancelado.
En Gustela CRM, las reglas de cumplimiento —quién no puede recibir más mensajes— viven en el servidor y se aplican antes de encolar. No dependen de que alguien se acuerde.
Y en Rocio.com la primera decisión fue normalizar antes de construir encima: con 320.093 filas de metadatos en texto, cualquier funcionalidad nueva habría heredado el problema.
Las tres ideas se aplican igual a la facturación: capturar el dato cuando nace, guardar lo que se acordó y no lo que hay hoy, y poner las reglas en el sistema y no en la memoria de alguien.
Estándar donde es estándar, a medida donde no
La facturación es un proceso estándar, y lo razonable es resolverla con un buen producto adaptado a la norma. Construirla a medida sería caro y no aportaría nada. Lo argumenté en el software debe adaptarse a la empresa, no la empresa al software: se construye solo donde está lo que te diferencia.
Lo que sí puede necesitar trabajo propio es lo que hay antes de la factura: el pedido, el presupuesto, la ficha del cliente, el proceso que hoy sostiene una hoja de cálculo. A veces basta con conectar lo que ya existe. Otras veces falta una pieza pequeña que capture esos datos bien desde el principio.
Una revisión antes de 2027
Antes de cambiar de programa, conviene responder a estas preguntas:
- ¿Dónde nace cada dato que acaba en una factura: cliente, concepto, cantidad, precio?
- ¿Cuántas veces se copia a mano entre su origen y la factura?
- ¿Existe una ficha única de cada cliente, o varias versiones?
- ¿Queda registrado el precio acordado, o se recalcula al facturar?
- ¿Quién sabe hoy si una factura se aceptó, se rechazó o se pagó, y dónde lo apunta?
Si las respuestas llevan a hojas de cálculo y a personas concretas, el cambio de normativa es una buena ocasión para ordenar el proceso, no solo para cambiar de programa.
La factura electrónica solo es tan buena como los datos que llegan hasta ella.
Si lo que sostiene tu proceso es una hoja de cálculo o un buzón de correo, en aplicaciones internas a medida explico cómo resuelvo ese cuello de botella concreto. Y si el problema es el trabajo manual de copiar entre sistemas, en automatización de procesos empresariales cuento cómo elijo entre reglas, integraciones e intervención humana.