Factura electrónica B2B: ¿quién registra el pago?
En muchas empresas, casi nadie registra el pago en el sistema que emitió la factura. La factura nace en un programa, el cobro llega al banco y la aceptación se decide en un correo. El Real Decreto 238/2026 exige comunicar aceptación, rechazo y pago en cuatro días, y cumplirlo cuesta si los tres sitios no se hablan.
¿Qué cambia con el Real Decreto 238/2026?
Cambia que la factura entre empresas deja de ser un PDF. El Real Decreto 238/2026 desarrolla la facturación electrónica obligatoria entre empresarios y profesionales. Se publicó en el BOE el 31 de marzo de 2026 y entró en vigor el 20 de abril. Su aplicación efectiva, sin embargo, dependía de una orden ministerial que regulara la solución pública de la Agencia Tributaria. Esa orden se publicó en el BOE el 5 de octubre de 2026 y entró en vigor el día 6.
Desde esa orden corren los plazos. Según la nota informativa de la Agencia Tributaria, son 12 meses para las empresas con facturación superior a 8 millones de euros (obligación desde el 6 de octubre de 2027) y 24 meses para las demás (desde el 6 de octubre de 2028). Para las personas físicas y las entidades en atribución de rentas, la comunicación de estados y pagos llega a los 36 meses, el 6 de octubre de 2029. Quedan fuera las ventas a consumidores.
El proyecto de esa orden se sometió a información pública en abril de 2026, según el texto publicado por Hacienda. La versión definitiva es la Orden HAC/1028/2026, de 2 de octubre, y con ella el calendario dejó de depender de una fecha incierta.
¿Qué tienes que comunicar y en cuánto tiempo?
Dos estados, y los dos vuelven al emisor. Según el artículo 10 del real decreto, el destinatario debe comunicar la aceptación o el rechazo comercial de la factura y la fecha en que se produce, y el pago efectivo completo con su fecha efectiva. El plazo máximo, en el apartado 3, es de cuatro días naturales, excluidos sábados, domingos y festivos nacionales. El artículo 12 añade la comunicación del pago a la solución pública.
Hay un detalle fácil de pasar por alto: tu empresa ocupa los dos lados. Cuando emites, esperas los estados de tus clientes. Cuando recibes facturas de proveedores, los estados los debes tú. La orden prevé que esas comunicaciones se hagan por servicios web o por un formulario, y el formulario funciona factura por factura.
La factura se emite en formato estructurado conforme al modelo semántico europeo EN16931, con una de las sintaxis admitidas, entre ellas UBL y Facturae. Esa parte es técnica y tiene solución conocida. Lo que no viene resuelto de fábrica es lo anterior: que alguien, en algún sistema, sepa en cada momento si la factura se aceptó y si se pagó.
¿Dónde vive hoy el dato que te piden?
En sitios distintos, y casi siempre escrito por personas distintas. La aceptación la decide quien recibió el servicio, y suele constar en un correo o en una conversación. El pago consta en el banco. La factura consta en el ERP, que solo se entera del pago cuando alguien concilia el extracto y lo teclea.
Las herramientas, en general, existen. En la encuesta del INE sobre uso de TIC en las empresas (año 2024 y primer trimestre de 2025), el 63,6% de las empresas con diez o más empleados usa un ERP y el 34,5% usa un CRM. La encuesta no mide si esos programas se hablan entre sí ni en cuál se registra el cobro, de modo que de ella no se puede deducir que el dato esté donde hace falta.
Un plazo de cuatro días mide una cosa muy concreta: cuánto tarda un hecho en quedar escrito en un sistema que pueda comunicarlo. Si el hecho vive en el banco y el sistema que comunica es otro, el retraso es el de la persona que los une.
Un ejemplo, y es una hipótesis
Empresa de mantenimiento industrial, cuarenta y cinco personas, tres millones de euros de facturación, unos sesenta proveedores. Por tamaño, el calendario general le da hasta el 6 de octubre de 2028. Compró un ERP hace años. Administración paga a proveedores en lotes de transferencias los jueves y concilia el extracto del banco cada quince días, en una hoja de cálculo que luego se vuelca al ERP.
Mira lo que ocurre con una factura de proveedor. Llega por correo el lunes. El responsable de obra, que es quien recibió el servicio, la acepta de palabra el miércoles. Se paga en el lote del jueves. El ERP la marca como pagada el día de la conciliación, que puede caer hasta catorce días después del pago. La fecha de pago existe desde el jueves. El sistema que debería comunicarla la conoce con dos semanas de retraso.
Las cifras de este escenario son una hipótesis de trabajo, no una medición de ningún cliente. Sirven para enseñar dónde mirar. No hace falta cambiar el ERP para ver el problema: basta con preguntar, factura por factura, en qué momento y en qué sistema se escribió cada estado.
¿Qué decisión de arquitectura evita el problema?
Lo que suele fallar no es el programa de facturación sino la arquitectura: el estado de la factura se escribe en un sitio distinto del que lo necesita. La decisión que lo resuelve se toma antes de elegir plataforma, y tiene cuatro piezas.
La primera es un único registro por factura, con estados explícitos (recibida, aceptada, rechazada, pagada), cada uno con su fecha y con quién lo cambió. La segunda es escribir cada estado donde ocurre el hecho, no donde se acuerda uno de él después. El pago entra desde el movimiento bancario; la aceptación la registra con un clic quien recibió el servicio, no un tercero que lo deduce de un correo.
La tercera es un dueño por cada cambio de estado. Quién puede rechazar una factura y qué ocurre cuando esa persona está de vacaciones son preguntas de operación, y el texto del real decreto habla de pago efectivo completo, de modo que conviene revisar con tu asesoría cómo se trata cada caso intermedio. Ninguna herramienta decide por ti quién acepta y quién responde: esa decisión es humana y va antes de cualquier automatización. La cuarta es un registro de eventos de cada cambio y un aviso cuando una factura se acerca al límite de los cuatro días.
Después viene la conexión: plataforma privada o solución pública, formulario o servicio web. Es el orden que ya señala el análisis de las fallas que comprometen las integraciones internas: conectar antes de mapear es la primera de ellas. Un ejemplo de plataforma que reúne en un solo sistema la gestión de pólizas, agentes y comisiones es el caso de UniTrust, un IMO de seguros de Estados Unidos.
Preguntas frecuentes
Mi equipo lleva los cobros en una hoja de cálculo y está cómodo así. ¿Hay que dejarla?
No necesariamente el primer día. Lo que importa es si la hoja es el lugar donde se escribe el pago, si la fecha es la real y si otro sistema puede leerla sin que alguien la copie. Una hoja con un solo responsable puede servir de origen durante un tiempo. Deja de servir cuando la editan varias personas o cuando el plazo de cuatro días depende de que alguien se acuerde.
¿La integración con el ERP que ya usamos va a ser complicada?
Depende menos del ERP que del orden. Primero se decide qué sistema escribe cada estado, y eso es trabajo de operación. La conexión con la plataforma o con la solución pública viene después, y la orden prevé servicios web para ello. Si tu ERP puede exponer sus datos, la integración puede ser bastante más acotada. Si no puede, esa es la información que necesitas antes de comprar nada.
No tenemos equipo técnico para esto. ¿Qué hacemos?
El primer paso no requiere programar: es levantar, para una muestra de facturas, dónde y cuándo se escribió cada estado. Con ese mapa se decide qué se resuelve con un producto de un tercero y qué conviene construir a medida, con alguien que responda por ello. Y hay margen para hacerlo con método: con 8 millones de euros de facturación o menos, la obligación llega el 6 de octubre de 2028, y por encima de esa cifra, el 6 de octubre de 2027.
El siguiente paso
Si no tienes claro en qué sistema se escribiría hoy el pago de una factura recibida, el Diagnóstico de Arquitectura Operacional es una conversación de 30 minutos para mapearlo antes de cualquier propuesta técnica: agenda la conversación.
Cases relacionados
¿Reconociste tu operación en este artículo?
Agenda el Diagnóstico de Arquitectura Operacional: 30 minutos para mapear dónde está el cuello de botella de tu operación. Sin propuesta en la primera conversación.
Agendar diagnóstico