El hecho: un desarrollo específico para factura electrónica B2B.
El BOE publicó el 31 de marzo de 2026 el Real Decreto 238/2026, de 25 de marzo, por el que se desarrolla el sistema de facturación electrónica obligatoria entre empresarios y profesionales. La norma también modifica el Reglamento de obligaciones de facturación.
Se trata de un marco que debe leerse junto con sus disposiciones de aplicación y desarrollo. Este artículo explica cómo organizar la evaluación del software; no asigna una fecha de obligación B2B a una empresa concreta ni da por verificados todos los hitos posteriores que pueden condicionar su aplicación.
BOE: texto consolidado del Real Decreto 238/2026 ↗
Por qué no basta con preguntar si un programa tiene VERI*FACTU.
La pregunta sobre VERI*FACTU se refiere a una modalidad del sistema de facturación y a la remisión de registros a la AEAT. La entrega de una factura a otro empresario introduce cuestiones sobre el documento, su formato y el canal de intercambio. Una misma operación exige comprender ambas partes.
Si el proceso se resume en una única etiqueta, es fácil dar por cubierto un requisito que nadie ha comprobado. La respuesta comercial debe especificar qué resuelve el producto y bajo qué condiciones, especialmente cuando participan plataformas o aplicaciones diferentes.
La consecuencia práctica: dos grupos de requisitos.
Organiza una lista para el sistema que prepara y emite, y otra para el intercambio con el destinatario. En la primera, identifica producto, versión, documentación y recorrido de los registros. En la segunda, anota clientes, formatos, canales y necesidades de seguimiento que deban evaluarse.
Después relaciona ambos grupos. No necesitas contratar dos programas por el hecho de que existan dos marcos distintos, pero sí comprobar que la solución elegida responde a cada necesidad. La cobertura puede variar según la versión, el servicio y las integraciones incluidas.
Qué pedir a un proveedor sin mezclar promesas y funciones.
Solicita que distinga lo disponible de lo previsto. Una fecha comercial de desarrollo no equivale a una funcionalidad que ya puedes utilizar. Si una necesidad depende de una integración, pide identificar la aplicación, el responsable del mantenimiento y el alcance contratado.
Pregunta también cómo se reflejan las incidencias. El usuario debe poder saber si está revisando una operación, una emisión, una entrega o una remisión de registro. Usar un único estado genérico para todo dificulta entender qué tarea sigue pendiente.
Cómo revisar calendarios sin crear una fecha ficticia.
Identifica el texto que establece cada obligación y los acontecimientos de los que depende. Si encuentras una noticia que indica un plazo, comprueba si habla de aprobación, publicación, entrada en vigor o aplicación efectiva. Son referencias que no siempre coinciden.
Cuando un desarrollo posterior sea relevante, consulta su publicación oficial antes de convertir un plazo relativo en un día concreto. Lleva a la asesoría la fuente y la pregunta sobre tu actividad. Una fecha anotada sin su fundamento se vuelve difícil de actualizar cuando cambia el contexto.
Qué hacer con esta información al preparar una compra.
Añade a la solicitud de demo una operación habitual y los destinatarios con los que trabajas. Pide ver cómo sale la factura del sistema y cómo identificas su resultado. Completa la revisión con documentación y condiciones, no solo con una captura de pantalla.
En la propuesta final, separa funciones incluidas, conexiones adicionales y puntos pendientes de confirmación. Este orden te permite valorar un software que cumple con VERI*FACTU sin atribuirle automáticamente otras capacidades que no se hayan acreditado. La publicación de la norma es un motivo para revisar el proceso con más precisión, no para simplificarlo en una promesa genérica.