El plazo de aplicación efectiva no se cuenta desde marzo de 2026. Empieza cuando entre en vigor la orden ministerial que desarrollará la solución pública de facturación electrónica.
La segunda fase llegará doce meses después de la primera. A 4 de octubre de 2026 la AEAT sigue indicando que la orden ministerial está en tramitación.
No hay una fecha final cerrada todavía. Sí hay ya suficiente información para preparar el sistema con criterio.
Esperar a que se publique la orden para empezar a pensar el proyecto es confundir fecha legal con fecha de trabajo. El Real Decreto ya define el modelo general, los canales de intercambio, los estados que habrá que comunicar, la obligación de interoperabilidad y los formatos admitidos. La orden completará la parte técnica de la solución pública y pondrá en marcha el reloj. Para una empresa con ERP, plataformas de facturación, clientes, proveedores, integraciones y procesos de cobro, doce meses pueden parecer muchos hasta que hay que coordinar todo a la vez.
Enviar un PDF por correo ya no será suficiente para hablar de factura electrónica B2B obligatoria.
El nuevo modelo parte de una idea sencilla: una factura electrónica obligatoria entre empresas debe poder viajar entre sistemas y ser interpretada automáticamente. Por eso el Real Decreto exige mensajes estructurados ajustados al modelo semántico EN16931 y admite distintas sintaxis, entre ellas CII, UBL, EDIFACT y Facturae.
Esto cambia el problema. Ya no basta con generar un documento visual que una persona pueda leer. El emisor, la plataforma, el destinatario y la solución pública deben poder trabajar con información estructurada, identificar la factura de forma inequívoca y mantener un circuito interoperable. La factura deja de ser un adjunto para convertirse en un objeto digital que participa en un proceso.
Para Finanzas, esto significa revisar cómo nace la factura en el ERP, qué formato se genera, cómo se envía, dónde se almacena, cómo se reciben estados, quién informa el pago y cómo se relaciona todo ello con el ciclo real de cobro y cierre. Para IT, significa revisar conectores, identidad, certificados, plataformas, trazabilidad y mantenimiento.
Aceptación, rechazo y pago pasan a formar parte del circuito digital y de las obligaciones de información.
Plataforma privada, solución pública o combinación de ambas: la empresa tendrá que decidir cómo quiere operar.
El modelo previsto no obliga a todas las empresas a utilizar exactamente la misma plataforma. El Real Decreto permite emitir y recibir a través de la solución pública, plataformas privadas o una combinación de ambas. Esa flexibilidad es útil, pero traslada una decisión de arquitectura a cada organización.
Solución pública
La Agencia Tributaria desarrollará y gestionará una solución pública gratuita. Cuando una empresa no haya acordado expresamente con sus proveedores recibir facturas a través de plataformas privadas, se entenderá que opta por la solución pública.
Su funcionamiento técnico definitivo dependerá de la orden ministerial actualmente en tramitación.
Plataforma privada
Las empresas podrán trabajar con operadores privados siempre que cumplan los requisitos del sistema español. Las plataformas tendrán que interoperar, transformar formatos admitidos y cumplir requisitos técnicos y de seguridad.
Elegir plataforma no debería hacerse solo por precio; hay que revisar integración con ERP, estados, soporte, volumen, SLA y capacidad de evolución.
Si emites fuera de la solución pública, habrá que remitir una copia fiel en UBL
El Real Decreto establece que las plataformas, soluciones o sistemas que no utilicen la solución pública para emitir deberán remitir simultáneamente una copia electrónica fiel de cada factura en sintaxis UBL a la solución pública. Esto convierte la interoperabilidad en una obligación de arquitectura, no en una recomendación técnica.
CII, UBL, EDIFACT y Facturae: el reto no es elegir siglas, sino asegurar que la factura pueda viajar y seguir siendo la misma.
La factura electrónica obligatoria deberá ajustarse al modelo semántico EN16931 y podrá utilizar varias sintaxis. Las plataformas privadas tendrán que ser capaces de transformar mensajes entre formatos admitidos manteniendo autenticidad e integridad. Además, las facturas deberán incorporar un código único que incluya, como mínimo, NIF del emisor, número y serie y fecha de expedición.
CII
Formato intersectorial creado por UN/CEFACT. Puede formar parte de intercambios B2B estructurados donde distintas plataformas necesitan entender un mismo modelo de información.
UBL
Universal Business Language será especialmente relevante porque la solución pública utilizará esta sintaxis y las copias fieles remitidas desde sistemas privados deberán enviarse en UBL.
EDIFACT
Sigue formando parte de los formatos admitidos. Esto importa en sectores donde EDI lleva años siendo parte de la relación entre proveedor, distribuidor y cliente.
Facturae
Formato ya habitual en España y soportado por Business Central para escenarios de facturación electrónica. Seguirá formando parte del catálogo de sintaxis admitidas por el nuevo sistema.
La decisión práctica: no conviene diseñar el futuro proceso alrededor de un único formato si la empresa trabaja con clientes, proveedores o plataformas diferentes. El objetivo debería ser que Business Central produzca y reciba información de forma gobernada y que la capa de intercambio resuelva transformaciones sin introducir tareas manuales.
No se trata solo de emitir bien. También habrá que comunicar qué ha pasado después.
Aceptada, rechazada, pagada: el nuevo modelo obliga a mirar más allá de la emisión.
Los destinatarios deberán informar al emisor, al menos, de la aceptación o rechazo comercial de la factura y del pago efectivo completo, incluyendo sus fechas. El sistema también permite comunicar voluntariamente estados como aceptación parcial, pago parcial o cesión de la factura a un tercero.
El plazo previsto para comunicar los estados es de un máximo de cuatro días naturales desde que se produce el estado, excluyendo sábados, domingos y festivos nacionales. Además, el pago completo deberá comunicarse a la solución pública, con independencia de que la factura se haya intercambiado mediante esa solución o a través de una plataforma privada.
Esto conecta facturación y cobro de una forma mucho más directa. Para una empresa, el reto no es generar otro mensaje electrónico. Es definir de dónde sale el estado, quién lo valida, cómo se automatiza, qué ocurre con pagos agrupados, compensaciones, rechazos y rectificativas, y cómo mantener trazabilidad sin multiplicar tareas administrativas.
Microsoft ya tiene un marco de documentos electrónicos. La obligación española exigirá conectarlo con el modelo definitivo que establezca la orden.
Business Central dispone de E-Documents, un marco estándar para gestionar documentos electrónicos y conectores con servicios externos. En España, Microsoft documenta actualmente el soporte del formato FacturaE dentro de la localización. Esa base es relevante, pero no conviene confundir “Business Central admite factura electrónica” con “mi entorno ya está preparado automáticamente para todo el régimen B2B de 2026”.
Un marco para enviar y recibir documentos electrónicos
Microsoft proporciona una estructura común para configurar servicios, flujos y formatos. Esto reduce la necesidad de construir una arquitectura totalmente distinta en cada país o proveedor.
FacturaE ya forma parte del soporte actual
Microsoft Learn documenta FacturaE 3.2.2 para la facturación electrónica en España. Es un punto de partida importante para empresas que ya operan con Business Central.
Lo que todavía no conviene dar por supuesto
La orden ministerial definirá especificaciones técnicas de la solución pública, autenticación, comunicación de pagos, uso de UBL, codificación única e interconexión con plataformas privadas. Por tanto, cualquier empresa que afirme hoy que “ya cumple todo” debería poder explicar exactamente cómo cubrirá esos elementos cuando se publique el desarrollo técnico definitivo.
La ventaja de empezar desde una solución ya integrada en Business Central es no tener que construir el proceso desde cero.
IB eFactura 365 es la solución de Ayesa para integrar la emisión, firma y trazabilidad de facturas electrónicas en Microsoft Dynamics 365 Business Central. Actualmente permite trabajar con Facturae y PDF firmado digitalmente, almacenar documentos, enviarlos, mantener trazabilidad y operar desde el propio entorno del ERP.
Ese punto de partida reduce una parte importante del trabajo: el proceso ya vive junto a la factura, el cliente, la serie, el documento registrado y el histórico. Cuando llegue el desarrollo técnico definitivo del nuevo B2B, la conversación no parte de “¿cómo digitalizamos la factura?”, sino de “¿qué cambios necesita nuestra arquitectura actual para adaptarse al nuevo intercambio, estados y comunicación de pagos?”.
Esto no significa afirmar hoy que una solución actual cubre automáticamente todos los requisitos futuros. Significa algo más serio: disponer de una base integrada sobre la que revisar formato, conectores, plataforma, estados, comunicaciones y roadmap con mucha menos dispersión que si la facturación electrónica vive en utilidades externas.
El cumplimiento es mucho más mantenible cuando el usuario trabaja desde el mismo proceso que ya conoce.
Factura electrónica B2B y VeriFactu se relacionan, pero resuelven obligaciones distintas.
Muchas empresas están oyendo hablar de VeriFactu, factura electrónica, Ley Crea y Crece, sistemas de facturación y nuevos plazos al mismo tiempo. Mezclarlo todo conduce a proyectos confusos. Lo correcto es separar obligaciones y luego decidir cómo deben convivir en el mismo ERP.
Intercambio estructurado entre empresas y seguimiento de estados
Regula cómo se emite, transmite y recibe la factura entre empresarios y profesionales, cómo interoperan plataformas, qué formatos se admiten y cómo se comunican determinados estados y pagos.
Requisitos del sistema de facturación y registros asociados
Se centra en los requisitos de los sistemas informáticos de facturación, integridad, trazabilidad y, cuando procede, remisión de registros a la Agencia Tributaria. Su calendario actual se sitúa en 2027.
La decisión inteligente: evitar dos proyectos aislados. Si Business Central es el núcleo financiero, conviene diseñar cómo convivirán VeriFactu, factura electrónica B2B, documentos, plataformas de intercambio, pagos, certificados y automatizaciones. La empresa puede tener dos obligaciones distintas, pero no necesita dos arquitecturas caóticas.
No necesitas implantar mañana. Sí necesitas saber qué tendrás que cambiar cuando empiece el contador.
El mejor uso del periodo actual es diagnóstico. Una empresa puede avanzar muchísimo sin comprometer todavía una arquitectura definitiva: inventariar procesos, entender cómo factura y recibe, identificar plataformas actuales, revisar versiones de ERP, mapear estados y pagos, localizar excepciones y definir responsables.
Inventario de emisión
Qué sociedades emiten, desde qué sistemas, con qué series, qué tipos de factura, qué monedas, qué clientes y qué excepciones. Si hay varios ERPs, portales o herramientas, hay que saberlo antes de diseñar.
Inventario de recepción
Cómo llegan hoy las facturas de proveedores, qué formatos se aceptan, cómo se validan, quién las aprueba, qué herramientas de OCR o captura existen y cómo terminan registradas en Business Central.
Estados y pagos
Dónde se produce la aceptación o rechazo, cómo se conoce el pago efectivo, qué ocurre con pagos parciales, compensaciones o remesas y qué sistema tiene la información necesaria para comunicar cada estado.
Plataformas y conectores
Qué proveedor se utiliza hoy, qué SLA ofrece, qué formatos maneja, cómo se integra con Business Central, si soportará el futuro sistema español y cómo gestionará la interconexión con la solución pública.
Versión y extensiones de Business Central
SaaS, on-premise, NAV heredado, extensiones de facturación, documentos personalizados, desarrollos fiscales e integraciones pueden cambiar de forma radical el camino de adaptación.
Responsabilidades
Quién será propietario del proceso, quién interpreta la obligación fiscal, quién mantiene la integración, quién responde ante un rechazo y quién monitoriza estados y pagos. El gobierno debe existir antes del go-live.
La adaptación no será igual para una empresa de 20 millones que para un grupo con 40 sociedades o una compañía que aún trabaja sobre NAV.
Empresa > 8 M€ con Business Central Online
Será de las primeras en entrar cuando se publique la orden. Conviene priorizar diagnóstico, proveedor de intercambio, estados, pagos y roadmap del conector. Doce meses pasan rápido cuando el proceso afecta a clientes y proveedores.
Empresa ≤ 8 M€ con procesos simples
Tendrá más margen temporal, pero también menos recursos internos. La prioridad debería ser evitar un proyecto sobredimensionado y elegir una solución mantenible que no requiera una operación técnica compleja.
Grupo multiempresa
Varias sociedades, distintos ERPs, monedas, proveedores de plataforma o modelos de cobro exigen una matriz por entidad. El error sería imponer una solución idéntica sin entender diferencias operativas y de calendario.
NAV o ERP legacy
La nueva obligación puede convertirse en otro desarrollo sobre una arquitectura heredada o en un detonante para modernizar. Conviene comparar coste de adaptar dos veces frente a coordinar factura electrónica y migración a Business Central.
Añadir otra obligación al ERP heredado puede funcionar. La pregunta es si compensa seguir ampliando una arquitectura que ya querías cambiar.
Muchas empresas conservan Dynamics NAV porque sigue resolviendo el núcleo financiero y conocen perfectamente sus personalizaciones. Ante cada cambio legal, se añade una extensión, un desarrollo o una herramienta externa. Cada pieza es razonable por separado. El problema aparece cuando se acumulan diez decisiones razonables y el sistema termina siendo difícil de actualizar, integrar y gobernar.
La factura electrónica B2B incorpora intercambio estructurado, plataformas, estados, pagos y nuevas integraciones. Si la compañía ya contempla migrar a Business Central en los próximos años, tiene sentido analizar si conviene resolver el nuevo modelo directamente sobre la plataforma objetivo.
No siempre habrá que migrar antes de la obligación. Pero sí conviene evitar desarrollar dos veces la misma necesidad: una solución temporal sobre NAV y otra nueva inmediatamente después sobre Business Central. El diagnóstico conjunto permite decidir con números, no con intuición.
¿Cuánto tiempo seguiremos con NAV?
El horizonte temporal cambia totalmente la lógica de inversión.
¿Qué parte puede reutilizarse?
Conectores, conocimiento funcional y procesos pueden aprovecharse aunque cambie la plataforma.
¿Qué deuda añadimos si esperamos?
Cada nueva obligación puede aumentar coste de soporte y complejidad futura.
Si la factura electrónica obliga a revisar el circuito, aprovecha para eliminar pasos manuales que ya eran un problema antes de la ley.
Una regulación no debería convertirse en la excusa para digitalizar el mismo proceso roto. Si hoy existen facturas que se descargan, renombran, adjuntan, reenvían, registran dos veces o se siguen en Excel, el nuevo modelo puede ser una oportunidad para redefinir el circuito con menos intervención.
Avisos, excepciones y aprobaciones
Puede ayudar a coordinar incidencias, rechazos, documentación pendiente o tareas humanas sin introducir más lógica dentro del core financiero.
Visibilidad de emisión, aceptación y cobro
Una vez que el proceso genera estados estructurados, la empresa puede explotar esa información para seguimiento de cobro, incidencias y tiempos.
Colaboración alrededor del proceso
Documentación, coordinación con negocio, evidencias y comunicación pueden mantenerse conectadas sin convertir el correo en el sistema de registro.
Integración, identidad y escalabilidad
En escenarios complejos, Azure puede aportar servicios de integración, seguridad y operación cuando el circuito supera una única aplicación.
Diez preguntas para saber si tu empresa está realmente preparada para empezar el proyecto.
Especialmente si algunas superan 8 millones y otras no.
ERP, portales, filiales, aplicaciones sectoriales y procesos externos.
Correo, EDI, portales, Facturae, plataformas privadas o captura manual.
ERP, tesorería, compras, plataforma o una hoja de cálculo paralela.
La futura obligación de comunicar pagos exige una fuente fiable.
Facturae, UBL, EDI, PDF o combinaciones distintas por cliente.
Interoperabilidad, copia UBL, estados, pagos y conexión con la solución pública.
SaaS, on-premise o NAV cambian las opciones y el esfuerzo.
No todo necesita automatización, pero lo repetitivo no debería seguir siendo manual.
Finanzas, Fiscal, IT, Compras y partner deben compartir un modelo de gobierno claro.
El primer trabajo no debería ser buscar proveedor. Debería ser comparar el desarrollo definitivo con el mapa que ya has preparado.
La futura orden ministerial completará los elementos técnicos de la solución pública: mecanismos de autenticación, especificaciones del servicio de comunicación de pagos, uso de UBL, codificación única, comunicación con plataformas privadas y otros requisitos necesarios para operar. Cuando se publique, muchas empresas empezarán desde cero. Las que hayan preparado previamente su mapa de procesos podrán hacer algo mucho más útil: una revisión de diferencias.
Esa comparación debería responder preguntas muy concretas. ¿Nuestro proveedor actual soporta la nueva interconexión? ¿La versión de Business Central necesita una extensión nueva? ¿Qué información adicional debe guardarse? ¿Podemos obtener de forma fiable los estados y la fecha efectiva de pago? ¿Qué excepciones quedan fuera del flujo automático? ¿Qué cambia para clientes, proveedores y usuarios internos?
El resultado debería ser un backlog priorizado y no una reacción de pánico. Las capacidades que ya existen se mantienen. Las que requieran adaptación se planifican. Las decisiones que dependen de terceros se lanzan con tiempo. Y aquello que afecte a usuarios se prueba antes de producción. La ventaja de llegar con el diagnóstico hecho es convertir doce meses legales en doce meses de ejecución, no en seis meses de descubrimiento y seis de urgencia.
Controlar impacto sobre facturación y cobro
Necesita saber si el nuevo circuito puede retrasar emisión, recepción, aceptación o pago; qué información estará disponible sobre estados y si el cambio puede mejorar visibilidad sobre morosidad y ciclo de cobro.
Diseñar una integración que pueda mantenerse
Debe revisar identidad, conectores, plataformas, API, certificados, monitorización, seguridad, volúmenes y soporte. El objetivo no es conectar una vez, sino operar el sistema con fiabilidad después del go-live.
Evitar duplicar tareas
Los usuarios necesitan saber qué cambia en su día a día: cómo se emite, cómo se consulta una incidencia, qué ocurre si una factura es rechazada, cómo se reenvía y qué parte queda automatizada.
Preparar también la recepción
La obligación no se limita a emitir. La empresa también recibirá facturas electrónicas estructuradas y necesitará validar, registrar, aceptar o rechazar y conectar ese proceso con compras, recepción y pago.
La prueba decisiva: ejecutar un ciclo completo de extremo a extremo
Antes de considerar el proyecto listo, conviene probar emisión, transmisión, recepción, aceptación, rechazo, rectificación, pago, comunicación del estado, archivo, consulta y recuperación. También deben probarse caídas de servicio, errores de formato, certificados caducados, clientes con plataformas diferentes y pagos que no siguen el caso perfecto. La factura electrónica es un proceso distribuido: si solo se prueba el botón de “enviar”, se está probando una fracción del riesgo real.
La factura electrónica no es una isla. Toca ERP, integración, seguridad, procesos, automatización y gobierno del dato.
Ayesa Digital combina capacidades en Business Central, Dynamics 365, Power Platform, Azure, Microsoft 365, datos e IA. Esa cobertura es relevante cuando un cambio regulatorio afecta al core financiero y, al mismo tiempo, exige interoperabilidad con plataformas, estados, pagos y nuevos servicios.
El objetivo no debería ser implantar una app y cerrar el proyecto. Debería ser construir un circuito que cumpla, reduzca tareas manuales, pueda evolucionar con el desarrollo técnico definitivo y no obligue a rehacer la arquitectura cuando cambie el volumen, el ERP o el proveedor de intercambio.
Lo que conviene tener claro sobre factura electrónica B2B y Business Central.
¿La factura electrónica B2B ya es obligatoria en octubre de 2026?
El Real Decreto 238/2026 ya está en vigor, pero su aplicación efectiva depende de la entrada en vigor de la orden ministerial de la solución pública. La AEAT sigue indicando que esa orden está en tramitación.
¿Cuándo empezarán los plazos?
Cuando entre en vigor la orden ministerial. Desde ese momento habrá 12 meses para empresas y profesionales con volumen de operaciones superior a 8 millones de euros y 24 meses para el resto.
¿Servirá enviar un PDF por email?
No como factura electrónica obligatoria B2B del nuevo sistema. La factura deberá emitirse, transmitirse y recibirse en formato electrónico estructurado conforme a los requisitos técnicos del Real Decreto y su desarrollo.
¿Qué formatos se admitirán?
El Real Decreto admite CII, UBL, EDIFACT y Facturae, todos ellos dentro del marco semántico definido. La solución pública utilizará UBL en los términos que determine la orden ministerial.
¿Business Central ya soporta factura electrónica en España?
Sí. Microsoft documenta el marco E-Documents y soporte de FacturaE para España. Pero el nuevo sistema B2B incorpora obligaciones adicionales que deberán alinearse con la orden técnica definitiva.
¿Qué estados habrá que comunicar?
Como mínimo, aceptación o rechazo comercial y pago efectivo completo, con sus fechas. También podrán comunicarse estados adicionales como aceptación parcial, pago parcial o cesión.
¿Cuánto tiempo habrá para comunicar estados?
El Real Decreto establece un máximo de cuatro días naturales desde que se produce el estado, excluyendo sábados, domingos y festivos nacionales.
¿Qué ocurre si utilizamos una plataforma privada?
Podrá seguir utilizándose si cumple los requisitos del sistema. Cuando no se utilice la solución pública para emitir, deberá remitirse una copia fiel en UBL a la solución pública.
¿IB eFactura 365 cubre ya todo el futuro régimen B2B?
IB eFactura 365 ya integra emisión, firma y trazabilidad en Business Central y constituye una base sólida. El encaje definitivo con el nuevo sistema deberá revisarse cuando se publique la orden técnica y se concreten todos los requisitos de interoperabilidad.
¿Factura electrónica B2B y VeriFactu son lo mismo?
No. Son obligaciones distintas que pueden afectar al mismo proceso de facturación. Conviene diseñarlas de forma coordinada para evitar duplicar sistemas, integraciones y trabajo administrativo.
Real Decreto 238/2026
Texto oficial del sistema español de factura electrónica obligatoria entre empresarios y profesionales.
Agencia Tributaria
La AEAT resume el calendario y confirma que la orden ministerial de la solución pública sigue en tramitación.
Microsoft Learn
Documentación de E-Documents y facturación electrónica para la localización española de Business Central.
IB eFactura 365
Solución Ayesa para integrar emisión, firma, envío y trazabilidad de facturas electrónicas dentro de Business Central.
No necesitas esperar a que empiece el plazo para saber si tu arquitectura está preparada.
Podemos revisar tu versión de Business Central, sociedades, plataformas de intercambio, formatos, procesos de emisión y recepción, estados de factura y circuito de pagos para definir qué preparar ahora y qué dejar para cuando se publique la orden técnica definitiva.
Business Development Manager | PSELLER Microsoft en Ayesa | Miembro Unidad Transición Energética, Climática y Urbana en Tecnalia | Secretaria de la Junta Directiva del Cluster de la Construcción (Build INN)