La nueva norma convierte un pendiente en una decisión de inversión
El 6 de octubre de 2026 dejó de ser una fecha abstracta. La entrada en vigor de la Orden HAC/1028/2026 activó el cómputo de la factura electrónica obligatoria entre empresarios y profesionales. Para muchas compañías con sistemas Microsoft, esto significa que el proyecto ha dejado de ser una conversación de futuro y empieza a competir por recursos con el cierre contable, las inversiones, las actualizaciones del ERP y el resto de prioridades de TI.
Si trabajas con NAV o Business Central on-premises, la pregunta no es simplemente si puedes generar una factura en formato electrónico. Seguramente ya lo haces en algún escenario. La cuestión es mucho más amplia: ¿cómo vas a emitir, recibir, intercambiar, registrar estados y comunicar pagos de manera consistente, segura y verificable?
Ayesa parte de una base de producto real con IB eFactura 365, pero distinguir una funcionalidad existente de una adaptación normativa pendiente es imprescindible para planificar bien. El objetivo de este artículo es ayudarte a tomar una decisión de arquitectura y negocio sin asumir que todas las versiones de NAV, todos los entornos de Business Central o todas las extensiones actuales responderán igual.
Fechas exactas: octubre de 2027, octubre de 2028 y el matiz de 2029
La Orden HAC/1028/2026, de 2 de octubre, publicada en el BOE el 5 de octubre y vigente desde el 6, regula la solución pública de facturación electrónica. Se integra en el régimen desarrollado por el Real Decreto 238/2026, de 25 de marzo, dentro del marco de la Ley 18/2022, conocida como Ley Crea y Crece. El impacto no se limita a facturar a la Administración pública: se refiere a operaciones entre empresarios y profesionales comprendidas en el ámbito de aplicación.
El umbral de ocho millones no debe confundirse con una cifra informal de ventas ni con el número de empleados. La norma remite al volumen de operaciones calculado conforme a la normativa del IVA, considerando el año natural inmediato anterior en los términos correspondientes. Por eso, Finanzas y el área fiscal deben validar qué entidades del grupo quedan en cada fase.
En la primera fase, los obligados con volumen superior a ocho millones deben también informar sobre estados de factura y pagos. En la segunda fase, esa información pasa a exigirse asimismo a personas jurídicas con volumen inferior o igual al umbral. El calendario de estados para determinadas personas físicas y entidades en atribución de rentas se prolonga hasta octubre de 2029. Este detalle es importante para compañías que gestionan relaciones con proveedores profesionales de naturaleza jurídica diversa.
La planificación debería partir de un mapa por sociedad: qué entidades están afectadas primero, qué plataformas utilizan, cómo se emite actualmente, dónde entra la factura del proveedor y qué responsabilidades existirán para comunicar aceptación, rechazo o pago. Una matriz de entidades suele aportar más valor que una presentación genérica de la ley.
La factura deja de ser un documento y se convierte en un circuito
Cuando una organización explica que “ya hace factura electrónica” conviene preguntarle a qué se refiere. ¿Envía un PDF firmado? ¿Produce Facturae para clientes públicos? ¿Intercambia ficheros con plataformas privadas? ¿Recibe facturas estructuradas de proveedores? ¿Puede devolver estados y registrar pagos sin intervención manual? Son respuestas muy distintas.
El nuevo modelo requiere una factura interpretable por sistemas, interoperabilidad entre plataformas, trazabilidad y determinados flujos de información sobre el estado y pago. Por tanto, el cumplimiento no es una impresión de pantalla ni una exportación adicional: es un proceso empresarial conectado.
El flujo explica por qué un sistema antiguo puede ser capaz de emitir una factura en Facturae y seguir necesitando trabajo: quizá no tenga una interfaz estable para recuperar acuses, no pueda interpretar eventos o dependa de una tabla histórica sin relación automática con cobros. Si el dato de pago reside en otro programa, habrá que resolver esa integración. Si la entidad tiene varios ERPs, habrá que consolidar responsabilidades.
En ese escenario, parchear la salida documental puede resolver la primera pantalla del problema, pero deja intactos los riesgos de funcionamiento. Una adaptación bien diseñada debe acompañar al usuario hasta el cierre del proceso y dejar claro qué hacer ante un rechazo, un corte de conexión o un error de intercambio.
Por qué NAV y Business Central on-premises necesitan una revisión específica
NAV ha demostrado ser un sistema extraordinariamente duradero en organizaciones con procesos de gestión intensivos. Precisamente por eso abundan las instalaciones que no se parecen al estándar: facturación adaptada, series especiales, aprobaciones propias, módulos verticales, objetos C/AL, integraciones antiguas, SQL, desarrollos fiscales y procesos heredados que sobreviven gracias a personas que saben cómo funcionan.
Ese patrimonio puede ser valioso. También puede complicar cualquier normativa que exija nuevos formatos, respuestas automatizadas y modificaciones sostenibles. No todos los entornos NAV disponen de los mismos mecanismos de integración y no todas las versiones de Business Central on-premises son equivalentes en extensibilidad, soporte o compatibilidad. La decisión no debería basarse en el nombre del ERP, sino en la instalación concreta.
Hay una tentación comprensible: seguir utilizando el mismo sistema mientras lo permita el negocio. Puede ser una decisión razonable cuando existen personalizaciones esenciales, limitaciones temporales o una operación que no admite cambios bruscos. Pero debe ser una decisión explícita y presupuestada, no una espera indefinida en la que el proyecto fiscal llega siempre el último.
Si tu ERP necesita modificaciones de objetos, nuevas comunicaciones y almacenamiento de eventos, conviene estimar el mantenimiento de esa inversión durante los próximos años. Un desarrollo puntual puede parecer asequible hasta que obliga a tocarlo después por un cambio de versión, una migración, un nuevo proveedor de intercambio o una segunda normativa.
Qué ofrece hoy Microsoft: una base real, no una garantía universal
Microsoft dispone del marco E-Documents para trabajar con documentos electrónicos. En la localización española documenta el soporte de Facturae, y la documentación de producto describe mecanismos extensibles para intercambio de documentos, servicios y conectores. Esto es un punto de partida tecnológico real, especialmente para organizaciones que ya trabajan en Business Central moderno.
Pero el nuevo sistema español combina varios elementos: modelo semántico EN16931, formatos estructurados admitidos, solución pública con UBL, posible uso de plataformas privadas, remisión de copia fiel, servicios de comunicación de estados, autenticación y tratamiento de errores. Por eso no basta con decir “Microsoft tiene E-Documents” para dar por cubierto todo el nuevo régimen B2B.
Esto introduce una variable de proyecto especialmente relevante: no conviene diseñar el calendario de adaptación alrededor de una fecha de disponibilidad de Microsoft que no esté comprometida públicamente. Si la entidad tiene obligación en octubre de 2027, debe poder estimar su esfuerzo incluso si el roadmap del estándar cambia. Y si el estándar evoluciona, habrá que medir qué desarrollos quedan sustituidos, cuáles siguen siendo necesarios y qué sucede con los conectores.
El enfoque más sólido consiste en comprobar las capacidades que ya existen, listar las diferencias contra el circuito regulatorio y separar tres capas: datos y eventos del ERP, transformación/intercambio de documentos y proceso operativo de Finanzas. Así se evita rehacer la lógica de negocio cada vez que cambie el operador externo.
Para contrastar estos puntos, la referencia documental pública debe ser E-Documents de Microsoft Learn y la localización española de Business Central. Esa documentación describe las capacidades existentes; el alcance final de adaptación a la normativa debe verificarse para cada caso.
IB eFactura 365: avanzar desde un producto existente
Ayesa ya dispone de un activo propio: IB eFactura 365. Su documentación actual describe una extensión integrada en Business Central que permite emitir facturas en Facturae XML y PDF firmado, trabajar con certificados, mantener trazabilidad, almacenar el documento vinculado a la factura, enviar documentos y gestionar emisión individual o por lotes. La ficha también indica uso en Business Central online y on-premises.
Este punto de partida importa. No se trata de construir desde cero toda la lógica de generación y trazabilidad. Pero la solución existente no debe confundirse con la adaptación completa ya certificada del nuevo marco B2B. La evolución anunciada por Ayesa tendrá que comprobar, entre otros aspectos, el encaje de formatos, plataformas, estados de aceptación o rechazo, comunicación de pagos, copias fieles y tratamiento de errores.
Que Ayesa tenga una solución publicada representa una ventaja para organizar la evolución. La conversación puede comenzar sobre un producto ya existente y una base instalada con procesos conocidos. La ventaja comercial no debería formularse como “todo está resuelto”, sino como “sabemos de qué sistema partimos, qué piezas están maduras y cómo abordar las diferencias concretas”.
Esto también abre dos relaciones comerciales legítimas: la adaptación técnica del entorno existente y la evaluación de su hoja de ruta. No tienen por qué ser proyectos incompatibles. Una empresa puede necesitar una primera intervención de cumplimiento y, después, decidir una migración. O puede optar por coordinar ambos trabajos y evitar inversión duplicada, siempre que los plazos y el riesgo operativo lo permitan.
Tres caminos: adaptar, actualizar o migrar a SaaS
No existe una respuesta única para todos los clientes de NAV y Business Central. La decisión adecuada puede depender más de la versión y del calendario de inversión que del tamaño de la empresa. El primer paso es comparar tres rutas viables con una misma metodología de alcance, riesgos y coste total.
Ruta 1 no es un fracaso tecnológico. Una empresa con NAV muy adaptado a fabricación o distribución puede preferir proteger el negocio, diseñar una integración compatible y planificar una migración posteriormente. La clave es que el desarrollo regulatorio quede documentado, mantenible y desacoplado en lo posible del código heredado.
Ruta 2 no equivale automáticamente a modernización definitiva. Actualizar a una versión intermedia puede resolver compatibilidad, pero si el ERP queda sujeto a otra actualización relevante poco después, la inversión podría repetirse. Conviene construir una hoja de ruta plurianual antes de decidir.
Ruta 3 no debería venderse por miedo a la multa. Migrar a Business Central SaaS tiene sentido cuando el retorno incluye menos complejidad técnica, más capacidad de integración, actualización y eficiencia financiera. Si se hace sin diagnosticar datos, extensiones y usuarios, el proyecto puede llegar tarde al plazo legal.
Cómo elegir sin sobredimensionar ni crear deuda técnica
Para un director financiero, la conversación suele comenzar con una fecha y un presupuesto. Para un CIO, comienza con versiones, dependencias y sistemas externos. Para Operaciones, comienza con continuidad: ¿se van a seguir emitiendo facturas, cobrando y cerrando correctamente cuando entre en vigor el nuevo circuito? Una decisión correcta necesita integrar las tres perspectivas.
La decisión también puede variar dentro de un mismo grupo. Una sociedad puede trabajar ya en SaaS mientras otra utiliza una versión antigua de NAV; algunas facturan desde la matriz y otras usan sistemas satélite. El proyecto tiene que respetar las responsabilidades legales de cada entidad y, al mismo tiempo, evitar que el grupo acumule diez conectores y diez procedimientos distintos.
En entornos con alto volumen de facturas, el coste recurrente de resolver excepciones manualmente puede superar el de construir una integración sólida. En entornos con pocos documentos, una arquitectura sobredimensionada puede ser igualmente mala. Por eso conviene conocer volúmenes, excepciones, personas implicadas y costes de operación antes de seleccionar proveedor.
Ocho preguntas de control que debe resolver el proyecto B2B
Los proyectos de adecuación normativa fallan cuando se tratan como cambios exclusivamente tecnológicos. El usuario fiscal define la interpretación, Finanzas controla emisión y cobros, Sistemas mantiene los conectores y el equipo operativo es quien sufre las incidencias. Si una factura llega rechazada, ¿quién la revisa? Si se comunica un pago erróneo, ¿cómo se corrige? Si hay una factura rectificativa, ¿qué relación guarda con la original?
La revisión funcional debe recorrer, como mínimo, ocho ámbitos. No son ocho productos que comprar, sino ocho decisiones del proceso que deben quedar identificadas antes de pasar a producción.
Las empresas con ventas recurrentes, facturación intercompañía, múltiples almacenes, proyectos o servicios deben revisar también cómo se propagan las referencias entre sistemas. La factura electrónica no corregirá por sí sola datos maestros incompletos ni reconciliaciones lentas. Puede, eso sí, dejar al descubierto procesos que llevan años funcionando gracias a correos y hojas de cálculo.
Un buen proyecto documenta los casos excepcionales antes del piloto. La factura estándar suele ser fácil; los problemas aparecen en abonos, rectificaciones, pagos con descuentos, discrepancias de recepción, cesiones, registros duplicados, reintentos o operaciones emitidas desde una sociedad distinta. Es ahí donde una demo bonita deja de servir y comienza una implantación seria.
Tres escenarios reales de decisión, sin cifras comerciales inventadas
Imaginemos un fabricante con 24 millones de euros de volumen de operaciones, tres sociedades y un NAV heredado con varias personalizaciones de facturación. Atiende a mayoristas, distribuidores y clientes industriales. El entorno sigue funcionando, pero la emisión electrónica se apoya en un módulo antiguo y la confirmación de cobro se reconcilia diariamente desde el banco.
Su primera obligación comienza en octubre de 2027 si se encuentra comprendido en el umbral y ámbito aplicables. El proyecto no debe limitarse a generar facturas con otra sintaxis. Debe identificar emisores, canales, estados, facturas rectificativas y circuitos de información de pagos. Si parte de las ventas se registra fuera de NAV, habrá que revisar cómo se unifica el dato a reportar.
En este ejemplo, migrar todo el ERP antes del plazo podría ser viable o no según el alcance. La respuesta responsable sería comparar un proyecto de adaptación delimitado frente a una migración coordinada. Si existe un programa de modernización aprobado, la nueva obligación puede ayudar a acelerar decisiones. Si no lo hay, forzar una reimplantación solo por la fecha puede crear más riesgo que valor.
Un segundo ejemplo: una empresa de servicios con cinco millones de volumen y pocos cientos de facturas al mes. Dispondrá de más margen para la fase de emisión y recepción, pero eso no implica que deba esperar hasta el último momento. Puede aprovechar 2027 para limpiar datos, definir el operador, evaluar costes recurrentes, formar a Administración y preparar un piloto de recepción antes de la fecha de aplicación.
Un tercer ejemplo: un grupo de empresas que factura desde Business Central y desde aplicaciones comerciales satélite. Aunque Business Central esté actualizado, el cumplimiento no se resolverá solo en su extensión de facturación. Será necesario revisar el origen, la unicidad y la transmisión de cada documento, así como la propiedad de los estados. En estos grupos, la arquitectura de integración puede ser la parte más estratégica del proyecto.
Cuánto puede costar cumplir: el presupuesto depende del ERP, no solo de la norma
El coste no depende de una supuesta tarifa única de “factura electrónica”. Depende de cuántos circuitos existen, qué productos ya se utilizan, cuántas excepciones hay, cómo se conectan plataformas y qué entornos deben mantenerse. En algunas cuentas habrá un proyecto pequeño de integración y validación. En otras, el mayor gasto estará en actualizar objetos, modernizar servidores, coordinar sociedades o cambiar el ERP.
Para estimarlo con transparencia, Finanzas debería exigir una comparación de coste total y no solamente una cifra de implantación. Una misma adaptación puede tener diferente retorno si se realiza sobre un ERP que va a mantenerse cinco años o sobre una instalación cuya migración ya está aprobada para el siguiente ejercicio.
No recomendaría calcular un retorno con porcentajes de ahorro genéricos sin disponer del volumen real de facturas, tiempo de proceso y tasa de incidencias de cada organización. Sí prepararía un modelo sencillo: coste de mantener el proceso actual + coste de adaptar el entorno + coste de operarlo durante tres años, comparado con el proyecto alternativo de actualización o migración y sus beneficios funcionales adicionales.
En esa comparación, los beneficios que no están ligados exclusivamente al cumplimiento también cuentan: mejor reporting financiero, menos mantenimiento del entorno, automatización, accesibilidad, integración con Microsoft 365 y preparación para nuevas capacidades. Pero deben expresarse como hipótesis económicas verificables, no como ahorros prometidos por la normativa.
Cómo empezar sin comprometer todavía una arquitectura equivocada
La mejor forma de acortar incertidumbre es empezar con un diagnóstico que cierre decisiones antes de tocar código. No requiere prometer un gran proyecto desde el primer día. Sí exige obtener una fotografía precisa de la instalación y convertir las obligaciones normativas en una matriz de brechas funcionales y técnicas.
Conviene designar una persona responsable de negocio. Si el proyecto se deposita exclusivamente en TI, las cuestiones de estado de pago, aceptación comercial, vencimiento o conciliación pueden quedar sin dueño. Si recae exclusivamente en Finanzas, puede subestimarse el impacto en APIs, versiones y seguridad. Los mejores resultados aparecen cuando el proceso se gobierna transversalmente.
Otro elemento práctico: no esperar al último mes para probar con un proveedor y un cliente reales, o con un entorno de pruebas que reproduzca sus plataformas. La interoperabilidad exige ensayar escenarios más allá de la factura de muestra. Los mensajes de error, la recuperación, la continuidad y la reconciliación deben tener un procedimiento definido.
No confundas factura electrónica B2B con VeriFactu
Factura electrónica B2B y VeriFactu aparecen con frecuencia en las mismas reuniones, pero corresponden a marcos de obligaciones distintos. La primera se ocupa del intercambio electrónico entre empresas y profesionales y de la información asociada a factura y pagos. VeriFactu se relaciona con los requisitos de los sistemas informáticos de facturación y sus registros, bajo su normativa específica.
Que ambos afecten al mismo ERP no significa que puedan resolverse con una sola extensión sin verificación. Tampoco significa que deban gestionarse en proyectos completamente aislados. En una empresa con NAV o Business Central conviene identificar los puntos compartidos —documentos, series, datos fiscales, certificados, gestión de usuarios y operación— y después separar las obligaciones, los flujos y las evidencias de cada régimen.
Especialmente en instalaciones antiguas, una adaptación mal coordinada puede introducir modificaciones repetidas en la misma lógica de facturación. Un plan global de cumplimiento evita conflictos entre personalizaciones y facilita las pruebas. La coordinación debe contemplar también otras obligaciones fiscales o sectoriales que correspondan a cada cliente, sin afirmar que todas tienen el mismo calendario.
Ayesa dispone de una oferta diferenciada en IB eFactura 365 y IB VeriFactu 365. La presencia de ambos productos permite abordar la conversación de forma integrada desde el punto de vista del ERP, manteniendo el análisis legal y técnico específico de cada obligación.
El papel de Ayesa: cumplimiento, continuidad y modernización
Cuando un cliente busca un proveedor para adaptar su NAV no necesita que le reciten artículos del BOE: necesita que conozcan el ERP, entiendan por qué su instalación es singular y puedan sostener el funcionamiento después. Esa es la base de una conversación comercial de valor para Ayesa: conectar conocimiento de la base instalada Microsoft, solución de facturación existente y capacidad de evolucionar el sistema cuando sea necesario.
IB eFactura 365 ofrece una base integrada que permite empezar desde funcionalidades tangibles. El equipo de servicios puede evaluar la instalación actual, determinar qué módulos son reutilizables, estudiar los cambios que exige el nuevo circuito B2B y proponer una hoja de ruta compatible con las prioridades del negocio. Cuando la migración tiene sentido, Ayesa también puede acompañar la transición a Business Central SaaS, sin convertirla en una condición artificial para comenzar el diagnóstico.
Si la empresa decide permanecer en NAV durante un periodo adicional, sigue necesitando soporte y evolutivos responsables. Si decide migrar, necesita gobernar datos, extensiones, funcionalidades y continuidad. La regulación crea urgencia, pero la diferenciación de un partner se mide por su capacidad de diseñar un camino viable, no por aprovechar la urgencia para imponer una única solución.
Preguntas habituales de empresas con NAV y Business Central
Antes de aprobar presupuesto, es normal que dirección financiera y tecnología formulen preguntas muy concretas. Estas son las respuestas que debería tener disponibles cualquier organización afectada por la nueva norma.
Recursos para preparar el ERP con criterio
Si quieres profundizar en las distintas dimensiones de la decisión, estos contenidos y soluciones de Ayesa desarrollan la normativa general, las capacidades de IB eFactura 365 y las rutas de modernización del ERP. Cada uno responde a una pregunta diferente y complementa este diagnóstico sobre entornos on-premises.
Contexto normativo, formatos, solución pública y procesos de intercambio.
Solución Ayesa de emisión, firma y trazabilidad integrada en Business Central.
Criterios para planificar modernización, datos, extensiones y evolución del ERP.
Continuidad y evolutivos cuando la empresa necesita mantener el entorno actual.
Plataforma Microsoft para gestionar finanzas, operaciones e integración.
Otra obligación fiscal que conviene coordinar sin confundir con B2B.
Para verificar los requisitos legales, consulta las fuentes oficiales: Orden HAC/1028/2026, Real Decreto 238/2026 y calendario de la AEAT. Los detalles técnicos del producto deben contrastarse con Microsoft Learn.
Tu siguiente paso no es elegir un conector. Es saber qué necesita realmente tu ERP.
Ayesa puede revisar la versión de NAV o Business Central, los procesos de emisión y recepción, las sociedades afectadas, los conectores y el encaje de IB eFactura 365. A partir de ahí, definimos una ruta de adaptación o modernización que proteja el negocio y prepare los nuevos requisitos B2B.
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)