El riesgo no es solo incumplir: es llegar a la fecha sin poder facturar con normalidad
El calendario fiscal de los próximos años no puede gestionarse como una colección de avisos legales. Afecta a los datos maestros, la emisión y recepción de facturas, los flujos de aprobación, las rectificativas, los cobros y pagos, la conservación documental y la relación con plataformas de intercambio. Para una empresa con varias sociedades o sistemas heredados, la adaptación puede convertirse en un programa transversal de modernización financiera.
Hay dos obligaciones que se confunden con frecuencia. Los requisitos de los sistemas informáticos de facturación, conocidos en el debate empresarial como VeriFactu, se centran en la integridad y trazabilidad de los registros generados por el software emisor. La factura electrónica B2B regula el intercambio estructurado entre empresarios y profesionales y las comunicaciones de estados y pagos. No son la misma norma ni se resuelven necesariamente con el mismo componente técnico.
La diferencia importa porque una organización puede preparar correctamente su sistema de registros de facturación y seguir sin disponer de un circuito adecuado para recibir facturas de proveedores, intercambiar documentos con clientes o informar sobre pagos. También puede ocurrir lo contrario: tener intercambio electrónico y necesitar adaptar el software emisor a las exigencias que le correspondan.
Esta guía ofrece una lectura de los hitos vigentes a 25 de octubre de 2026 y distingue los plazos jurídicamente establecidos de los cambios anunciados pendientes de aprobación. Las empresas deben confirmar su situación con sus asesores fiscales y con las fuentes oficiales antes de tomar decisiones definitivas.
Cinco hitos que Finanzas e IT deben distinguir desde hoy
El calendario siguiente no mezcla automáticamente las fechas de factura electrónica con las de sistemas informáticos de facturación. Cada hito responde a un marco distinto y su aplicabilidad depende del contribuyente, de la operación y de las exclusiones previstas.
SIF · Impuesto sobre Sociedades
Fecha que figura actualmente en la AEAT para la adaptación de sistemas de facturación de los contribuyentes afectados. Existe una previsión ministerial de ampliación todavía no incorporada como nueva fecha aprobada.
SIF · Resto de obligados
Segundo plazo vigente mostrado por la AEAT para los colectivos incluidos en el reglamento, con las exclusiones y particularidades que correspondan.
Factura B2B · Más de 8 M€
Emisión y recepción electrónica obligatoria para el tramo que supera ocho millones de euros de volumen de operaciones a efectos del IVA, más comunicaciones de estados y pagos.
Factura B2B · Resto
Emisión y recepción para los demás empresarios y profesionales; estados y pagos también para personas jurídicas y entidades del tramo restante.
Estados y pagos · Ciertos colectivos
Comunicación de estados y pagos para personas físicas y entidades en atribución de rentas del tramo correspondiente.
Las fechas de factura electrónica B2B proceden del calendario de implantación publicado por la Agencia Tributaria tras la entrada en vigor de la Orden HAC/1028/2026 el 6 de octubre. La obligación de informar estados y pagos no empieza en 2029 para todas las empresas: los tramos de 2027 y 2028 también tienen exigencias en esta materia.
Consulta las fuentes oficiales: calendario de factura electrónica B2B de la AEAT y portal de sistemas informáticos de facturación y VeriFactu.
VeriFactu: qué está aprobado y qué sigue siendo una previsión
A fecha de elaboración de esta guía, la Agencia Tributaria mantiene en sus preguntas frecuentes el 1 de enero de 2027 para los contribuyentes del Impuesto sobre Sociedades y el 1 de julio de 2027 para el resto de obligados incluidos en el reglamento. Esas fechas responden a la ampliación aprobada anteriormente por el Real Decreto-ley 15/2025.
El 5 de octubre de 2026, el Ministerio de Hacienda comunicó una previsión de nueva ampliación del plazo de adaptación de los sistemas informáticos de facturación. La AEAT enlaza esa comunicación desde su portal oficial. Una comunicación ministerial sobre un cambio futuro no equivale a la entrada en vigor de una modificación normativa. Por ello, no debe sustituirse automáticamente el calendario vigente por una fecha anunciada.
Fecha vigente publicada
Las referencias actuales de la AEAT siguen siendo enero y julio de 2027 según el colectivo, sin perjuicio de exclusiones y supuestos particulares.
Cambio comunicado
Hacienda ha anunciado una intención de ampliar plazos. La fecha definitiva y su alcance deben comprobarse en la disposición normativa que eventualmente se publique.
Decisión prudente
Mantener diagnóstico, pruebas y planificación. Un aplazamiento puede permitir mejorar el proyecto, pero no justifica detenerlo.
Información a clientes
Comunicar siempre la fecha de actualización del análisis y separar visualmente obligación aprobada, previsión y recomendación operativa.
Además, es importante distinguir el reglamento de sistemas informáticos de facturación de la modalidad VERI*FACTU. No todas las empresas afectadas por el reglamento tienen necesariamente que elegir la modalidad de remisión de registros denominada VERI*FACTU; existen modalidades y requisitos específicos que deben revisarse. Tampoco todos los sujetos y operaciones entran en el mismo ámbito.
Para verificar la situación actual, consulta las preguntas frecuentes de ámbito y plazos de la AEAT.
Qué cambia realmente el 6 de octubre de 2027 y por qué afecta a tesorería
La Orden HAC/1028/2026, publicada en octubre de 2026, ha puesto en marcha el cómputo de plazos previsto para la factura electrónica obligatoria entre empresarios y profesionales. El primer tramo alcanza a quienes hayan superado ocho millones de euros de volumen de operaciones a efectos del IVA durante el año natural inmediato anterior, dentro del ámbito definido por la norma. La obligación de emitir y recibir factura electrónica comienza para ese colectivo el 6 de octubre de 2027.
El 6 de octubre de 2028 se incorpora el resto de empresarios y profesionales al intercambio obligatorio. La comunicación de estados y pagos tiene un calendario escalonado: coincide con el primer tramo en 2027, se aplica a otras personas jurídicas y entidades en 2028 y se extiende a determinados empresarios personas físicas y entidades en atribución de rentas en 2029. No es correcto explicar 2029 como la fecha única para informar de pagos.
La adaptación no consiste en convertir una factura a PDF. El nuevo modelo exige intercambio electrónico estructurado, interoperabilidad y procedimientos de comunicación conforme a las especificaciones aplicables. Durante el periodo transitorio previsto para el primer tramo, la AEAT indica la necesidad de acompañar determinadas facturas con un PDF que garantice legibilidad a otros destinatarios; ese documento complementario no sustituye el requisito principal.
Emisión y recepción
Identificar qué sistemas generan facturas y cuáles reciben documentos de proveedores, con sus formatos, canales y validaciones.
Estados comerciales
Definir dónde se registra la aceptación o rechazo y cómo se relaciona con el documento correcto.
Pagos y cobros
Distinguir fecha contable y fecha efectiva de pago, conciliando tesorería y los estados que deban comunicarse.
Interoperabilidad
Evaluar conexión con la solución pública o plataformas privadas y los requisitos de intercambio, autenticación y seguimiento.
El mayor impacto organizativo aparece cuando compras, contabilidad y tesorería operan en sistemas distintos. Una factura puede llegar por una plataforma, validarse en un flujo documental, registrarse en el ERP y pagarse desde un sistema bancario. El proyecto debe garantizar que el estado comunicado corresponda al hecho real y que los errores puedan detectarse y corregirse.
VeriFactu, factura electrónica, SII y TicketBAI no son equivalentes
La confusión entre marcos puede generar inversiones duplicadas. Un proveedor puede ofrecer una funcionalidad excelente para generar registros de facturación y no resolver la recepción de facturas electrónicas de proveedores. Otro puede automatizar el intercambio documental, pero no cubrir requisitos específicos del sistema emisor. En determinados territorios y colectivos también existen obligaciones de información o regímenes propios.
Sistemas informáticos de facturación
Requisitos del software que expide facturas: integridad, trazabilidad, conservación y modalidades de funcionamiento según el reglamento aplicable.
Factura electrónica B2B
Intercambio estructurado de facturas entre empresarios y profesionales, con comunicaciones de estados y pagos según colectivo y fecha.
Suministro Inmediato de Información
Sistema de llevanza electrónica de libros registro del IVA para sujetos incluidos en su ámbito; su interacción con otras obligaciones requiere análisis específico.
TicketBAI y regímenes forales
Obligaciones y calendarios propios en territorios forales, que no deben equipararse sin más al sistema estatal.
Una matriz fiscal por sociedad es más útil que una respuesta global para todo el grupo. Debe identificar territorio, obligaciones, condición tributaria, operaciones, plataforma de facturación y responsables. La misma compañía puede combinar sociedades sujetas a SII, operaciones en distintos territorios y varios ERP; no conviene imponer una única configuración sin estudiar esas diferencias.
Para Business Central, Ayesa dispone de soluciones específicas que deben evaluarse por su alcance real: adaptación a VeriFactu en Business Central y factura electrónica B2B y Business Central.
La factura debe tener un recorrido trazable desde el origen hasta el cobro
El cumplimiento se vuelve frágil cuando se resuelve mediante una aplicación aislada que obliga a duplicar documentos, revisar manualmente respuestas o introducir de nuevo datos que ya existen en el ERP. Un diseño sostenible conserva la responsabilidad de cada sistema y crea integraciones controladas para el intercambio, la evidencia y el seguimiento.
ERP y datos maestros
Cliente, proveedor, impuestos, series, sociedades y documentos coherentes.
Registros y documentos
Generación, validación, corrección y conservación según cada obligación.
Intercambio y respuesta
Canales de envío y recepción, estados, errores y confirmaciones.
Tesorería y control
Conciliación, pagos efectivos, indicadores y auditoría de excepciones.
El diagrama anterior describe capacidades que debe cubrir una arquitectura de cumplimiento, no funciones que estén garantizadas de serie en una versión concreta de Business Central o Dynamics 365 Finance. El alcance depende de localización, versión, licencias, extensiones, plataformas de intercambio y personalizaciones.
Es esencial establecer una fuente maestra para cada dato: el ERP puede conservar la factura contabilizada, la plataforma de intercambio puede gestionar mensajes y el sistema de tesorería puede conocer el pago efectivo. El proyecto debe definir qué evento desencadena una comunicación, cómo se confirma su recepción y quién actúa ante un rechazo.
Qué revisar en Business Central, Dynamics 365 Finance y sistemas heredados
No existe una respuesta única para todos los ERP. El análisis debe comenzar por versión, despliegue, localización española, extensiones, integraciones, volumen de facturas y dependencia de procesos a medida. Una actualización de producto no garantiza que todas las particularidades de una compañía queden cubiertas automáticamente.
Business Central Online
Evaluar las capacidades de localización, las extensiones instaladas, los flujos E-Documents cuando proceda, los conectores y las necesidades específicas de registros y factura B2B. Validar en entorno de pruebas.
Business Central on-premises
Revisar versión, soporte, compatibilidad de extensiones, conectividad y capacidad de actualización. No trasladar sin comprobar las funcionalidades anunciadas para la nube.
Dynamics NAV / Navision
Comparar adaptación del sistema existente, actualización y migración a Business Central. La decisión debe contemplar deuda técnica, personalizaciones y continuidad de facturación.
Dynamics 365 Finance
Analizar localización, Electronic Reporting, procesos de factura, integraciones y requisitos españoles concretos. Confirmar disponibilidad y cobertura en la versión y entorno de la empresa.
ERP propio o de terceros
Solicitar al fabricante evidencia de su hoja de ruta, interfaces, tratamiento de errores y mantenimiento normativo. Un desarrollo interno requiere propietario y capacidad de evolución.
Grupo multisociedad
Construir una matriz por entidad, obligación y sistema. Coordinar criterios comunes donde aporte valor sin ignorar diferencias fiscales o territoriales.
En el ecosistema de Ayesa, las aplicaciones disponibles en AppSource incluyen propuestas para facturación y cumplimiento en Business Central. La existencia de una aplicación no permite afirmar automáticamente que todas las obligaciones futuras están resueltas: es necesario confirmar el alcance actualizado y realizar pruebas con las operaciones reales.
Para una organización que está considerando modernizar NAV o sustituir un ERP heredado, el calendario puede servir como catalizador de una decisión más amplia. Sin embargo, la ley no obliga por sí misma a migrar a Business Central SaaS. Adaptar o migrar debe decidirse por coste total, riesgo, soporte, oportunidad y calendario viable.
Una empresa con cuatro sociedades y tres sistemas: por qué no basta una fecha única
Imaginemos un grupo con una sociedad comercial que supera el umbral de ocho millones de euros, otra sociedad de servicios de menor tamaño, una entidad que utiliza Business Central y una operación adquirida que sigue trabajando con un ERP heredado. Además, algunos documentos se generan desde una plataforma de comercio electrónico y determinados proveedores envían sus facturas por un portal.
En este escenario, la primera tarea no sería comprar cuatro licencias idénticas. Habría que comprobar qué entidad jurídica emite cada factura, qué obligación le corresponde, cuál es el sistema emisor real y dónde se registran aceptación, rechazo y pago. También habría que identificar qué operaciones ya están cubiertas por sistemas específicos y cuáles exigen integración adicional.
Sociedad A · Primer tramo B2B
La facturación electrónica debe planificarse para el 6 de octubre de 2027 si cumple el umbral y ámbito aplicables. El sistema debe poder emitir, recibir y gestionar las comunicaciones exigibles.
Sociedad B · Segundo tramo B2B
Puede disponer de más tiempo para emisión y recepción, pero necesita coordinar formatos, proveedores, datos maestros y preparación de tesorería.
Sociedad C · ERP actualizado
El riesgo principal puede estar en personalizaciones, flujos de aprobación y conectores. La prueba debe incluir incidencias y rectificativas, no solo facturas estándar.
Sociedad D · ERP heredado
Debe evaluarse si el fabricante ofrece adaptación mantenible o si resulta más razonable planificar actualización o migración.
El resultado de ese diagnóstico es una hoja de ruta con responsables, riesgos, hitos de prueba y decisiones de inversión. Un único proveedor de intercambio puede simplificar parte de la arquitectura, pero no resuelve por sí solo los datos inconsistentes ni las excepciones de negocio. La prioridad es garantizar continuidad y trazabilidad por sociedad.
El caso feliz de una demostración no representa el cierre financiero de una empresa
Las pruebas deben reproducir el volumen y la complejidad real. En una empresa mediana o grande hay abonos, rectificativas, facturas con distintas series, anticipos, pagos parciales, compensaciones, divisas, impuestos especiales, clientes extranjeros, documentos rechazados y periodos de cierre. Si la solución solo se ha validado con una factura sencilla, el riesgo de incidencia en producción sigue siendo alto.
Documentos y fiscalidad
Probar facturas ordinarias, rectificativas, abonos, series, impuestos, entidades y excepciones fiscales aplicables.
Mensajería y estados
Simular envío, recepción, rechazo, duplicado, error de autenticación, reintento y trazabilidad de respuesta.
Tesorería y conciliación
Verificar fecha efectiva de pago, pagos parciales cuando proceda, compensaciones, devoluciones y conciliación con ERP.
Seguridad y continuidad
Revisar certificados, permisos, segregación de funciones, archivo, recuperación y soporte en picos de operación.
Datos maestros
Comprobar identificadores, direcciones fiscales, NIF, datos de cliente y proveedor, y consistencia entre sociedades.
Usuarios y soporte
Definir quién corrige cada error, qué puede resolver Finanzas y cuándo debe intervenir IT o el partner.
El plan de contingencia merece atención especial. Una caída del servicio externo o un certificado caducado no debería convertirse en una crisis improvisada. Deben existir responsables, procedimientos, registros de errores y criterios de recuperación. Las pruebas deben verificar también que el personal de finanzas comprende los estados y puede actuar sin depender permanentemente de un técnico.
Es útil medir el porcentaje de documentos procesados sin intervención, el tiempo de resolución de incidencias, la tasa de rechazos, los registros pendientes y el número de correcciones manuales. Son indicadores operativos más relevantes que el simple hecho de haber instalado una extensión.
Seis fases para convertir un calendario fiscal en un proyecto controlado
La duración de cada fase depende del número de sociedades, el ERP, las integraciones y la madurez del dato. El orden, sin embargo, es útil para casi cualquier organización: primero comprender obligaciones y procesos; después diseñar; finalmente probar y desplegar. Saltar directamente a la compra de una aplicación suele desplazar los problemas al final.
Inventario fiscal
Entidades, territorios, umbrales, operaciones y obligaciones.
Mapa tecnológico
ERP, extensiones, plataformas, flujos y responsables.
Diseño objetivo
Datos, intercambios, controles, seguridad y soporte.
Piloto realista
Documentos complejos, rechazos y conciliación.
Despliegue gradual
Sociedades, formación y planes de contingencia.
Seguimiento
Incidencias, indicadores y cambios regulatorios.
El inventario debe registrar no solo el sistema principal, sino todas las fuentes que generan documentos con relevancia fiscal. Es frecuente descubrir facturación en aplicaciones satélite, portales, sistemas sectoriales o desarrollos a medida. El mapa de integraciones debe identificar qué datos salen, qué respuestas regresan y cómo se gestionan los errores.
La fase de diseño debe separar requisitos legales, necesidades operativas y preferencias tecnológicas. No todo requisito implica un desarrollo propio. Tampoco todas las soluciones estándar cubren las particularidades de una empresa. El objetivo es elegir el mínimo conjunto de componentes que permita operar de forma fiable y evolucionar cuando cambie la norma.
El piloto debe incluir usuarios reales de Finanzas y Tesorería, no solo pruebas técnicas. Después, un despliegue por sociedades o procesos reduce el riesgo de interrupción, siempre que la secuencia respete las fechas aplicables y las dependencias entre sistemas.
Qué debe presupuestar un CFO y qué debe exigir a su proveedor
El presupuesto de adaptación no debería reducirse al coste de licencia. Puede incluir análisis fiscal, revisión de datos maestros, actualización de ERP, conectores, certificados, entornos de prueba, integración con plataformas, pruebas de regresión, formación, soporte y mantenimiento de cambios normativos. En entornos heredados, la compatibilidad y las personalizaciones pueden pesar más que la herramienta de intercambio.
Conviene pedir propuestas desglosadas que separen capacidades estándar, configuración, desarrollos, integraciones y costes recurrentes. También es necesario conocer qué sucede cuando cambian las especificaciones o cuando una actualización del ERP afecta a la solución. El contrato de soporte debe contemplar incidencias de facturación críticas y procedimientos de escalado.
Coste de implantación
Diagnóstico, configuración, integraciones, pruebas, formación y gestión del cambio.
Coste recurrente
Licencias, plataforma de intercambio, mantenimiento, soporte, infraestructura y monitorización.
Riesgo operativo
Horas manuales, errores, facturas retenidas, retrasos de cobro y dependencia de personas clave.
Capacidad de evolución
Compatibilidad con futuras versiones, actualización normativa, documentación y propiedad de las integraciones.
La comparación de proveedores debe valorar la continuidad del proceso, la claridad de responsabilidades y la capacidad de evolucionar. Un precio inicial bajo puede ser caro si cada modificación normativa exige un proyecto nuevo o si el usuario necesita mantener controles paralelos fuera del ERP.
El retorno debe estimarse de forma prudente. La automatización puede reducir tareas y errores, pero no es correcto prometer un porcentaje de ahorro sin línea base. Primero deben medirse volumen, incidencias, tiempo de proceso y coste actual de operación.
Respuestas para dirección financiera, fiscalidad y sistemas
¿VeriFactu y factura electrónica B2B son lo mismo?
No. Responden a marcos distintos. Uno aborda requisitos del sistema informático emisor y sus registros; el otro, el intercambio estructurado de facturas y determinadas comunicaciones.
¿VeriFactu se ha aplazado ya a 2028?
A 25 de octubre de 2026 existe una previsión de ampliación comunicada por Hacienda, pero las fechas vigentes que sigue publicando la AEAT son enero y julio de 2027. Debe revisarse cualquier norma posterior.
¿Cuándo empieza la factura electrónica B2B?
El 6 de octubre de 2027 para el tramo que supera ocho millones de euros de volumen de operaciones a efectos del IVA, y el 6 de octubre de 2028 para el resto, según el ámbito legal.
¿Por qué se habla también de 2029?
Por el calendario específico de comunicación de estados y pagos de determinados empresarios personas físicas y entidades en atribución de rentas. Otros colectivos tienen esa obligación antes.
¿Basta con enviar un PDF?
No como solución general del nuevo intercambio estructurado B2B. La normativa contempla un PDF complementario durante un periodo transitorio para determinados casos.
¿Todas las sociedades deben implantar lo mismo?
No. Hay que revisar territorio, condición fiscal, volumen de operaciones, SII, regímenes propios, operaciones y sistema de facturación.
¿Debo migrar NAV a Business Central por ley?
La norma no impone esa migración tecnológica. Puede ser una oportunidad para modernizar, pero la decisión depende de compatibilidad, costes, riesgos y soporte.
¿Qué debería probar antes de producción?
Facturas, abonos, rectificativas, impuestos, series, rechazos, estados, pagos, permisos, certificados, integraciones y recuperación ante fallos.
Profundizar en cada obligación sin mezclar el calendario con la funcionalidad de producto
Esta página funciona como guía de decisión y calendario transversal. Para estudiar el detalle funcional y tecnológico, conviene acudir a los contenidos especializados. Así evitamos duplicar explicaciones y mantenemos una arquitectura editorial clara entre el calendario general, los procesos de facturación y las soluciones Microsoft.
VeriFactu en Business Central
Guía específica de adaptación de Business Central para revisar registros, incidencias, QR, trazabilidad y escenarios de implantación.
Factura electrónica B2B y Business Central
Análisis de los requisitos B2B de 2027 a 2029, con foco en emisión, recepción, estados, pagos y evolución del ERP.
Aplicaciones de Ayesa
Catálogo de soluciones Microsoft AppSource de Ayesa, con aplicaciones fiscales y documentales para Business Central.
Aceleradores financieros y fiscales
Webinar y recursos sobre extensiones financieras para evaluar un enfoque mantenible y evitar desarrollos innecesarios.
Como fuentes normativas de consulta permanente, utiliza el calendario oficial de factura electrónica y el portal oficial de VeriFactu y sistemas informáticos de facturación. La información regulatoria debe revisarse cuando se publiquen nuevas disposiciones.
También puedes consultar las designaciones, especializaciones y certificaciones Microsoft de Ayesa para conocer sus capacidades en el ecosistema empresarial.
Cumplimiento fiscal con una visión de arquitectura, integración y continuidad
La adaptación fiscal es una oportunidad para revisar la calidad del proceso de facturación, pero no debe utilizarse como excusa para implantar tecnología innecesaria. Una organización con Business Central actualizado puede necesitar una extensión y pruebas de integración. Otra con múltiples ERP y procesos fragmentados puede requerir un proyecto de arquitectura más amplio. La respuesta correcta depende de los sistemas y de las obligaciones concretas.
Ayesa puede abordar el diagnóstico desde el entorno Microsoft y sus soluciones para Business Central, conectando las necesidades de Finanzas, Fiscalidad e IT. El objetivo de una evaluación inicial es identificar obligaciones por sociedad, localizar los puntos críticos de facturación y construir una secuencia de adaptación con prioridades verificables.
La normativa cambia. Tu arquitectura debe poder evolucionar.
Conoce nuestras capacidades y plantea una adaptación que no dependa de procesos manuales ni soluciones desconectadas.
¿Tienes identificadas las obligaciones de cada sociedad y los cambios que necesita tu ERP?
Revisemos sistemas, facturación, integraciones y calendario para definir una hoja de ruta realista, con prioridades para Finanzas e IT y sin interrumpir la operativa.
Información normativa revisada el 25 de octubre de 2026. La aplicabilidad concreta depende de la situación fiscal de cada entidad y de las normas vigentes en cada momento.
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)