La adaptación a los sistemas informáticos de facturación no consiste en activar un botón el último día. Exige confirmar el alcance, actualizar o sustituir el software, revisar datos y series, generar registros con integridad y trazabilidad, probar rectificaciones, formar a las personas usuarias y preparar contingencias. Tras la ampliación aprobada en diciembre de 2025, los contribuyentes del Impuesto sobre Sociedades deben tener adaptados sus sistemas antes del 1 de enero de 2027; el resto de obligados incluidos en el reglamento, antes del 1 de julio de 2027.
Qué cambia en 2027 y qué no debe confundirse
El Real Decreto 1007/2023 aprobó el Reglamento que establece los requisitos de los sistemas y programas que soportan procesos de facturación. La Orden HAC/1177/2024 desarrolló las especificaciones técnicas y funcionales. El Real Decreto-ley 15/2025 amplió los plazos de adaptación hasta 2027.
En la conversación comercial se utiliza «Verifactu» para referirse a todo el cambio, pero conviene separar conceptos:
- El RRSIF regula requisitos que deben cumplir los sistemas informáticos de facturación dentro de su ámbito.
- VERI*FACTU es la modalidad que remite los registros de facturación a la sede de la Agencia Tributaria en los términos técnicos establecidos.
- Un sistema no VERI*FACTU también debe cumplir los requisitos que le correspondan y mantener registros y controles adicionales.
- La factura electrónica B2B responde a otro marco y a otros flujos. Compartirá datos e integraciones, pero no es sinónimo de VERI*FACTU.
Por tanto, la primera decisión no es «qué proveedor compro», sino qué entidades, actividades, establecimientos, series y aplicaciones quedan dentro del alcance y qué modalidad operativa se utilizará.
Calendario oficial y lectura práctica
La Agencia Tributaria recoge, tras la modificación de 2025:
| Grupo | Fecha límite de adaptación |
|---|---|
| Entidades que presentan el Impuesto sobre Sociedades | Antes del 1 de enero de 2027 |
| Resto de obligados incluidos | Antes del 1 de julio de 2027 |
El periodo anterior puede utilizarse para pruebas. No debería interpretarse como permiso para posponer el proyecto. Una organización con varios puntos de venta, integraciones o cierres complejos necesita reservar tiempo para corregir defectos sin poner en riesgo la facturación.
Las fechas y el alcance deben comprobarse de nuevo antes de publicar o ejecutar el plan, porque pueden existir cambios normativos, particularidades territoriales o situaciones excluidas. Las empresas acogidas al Suministro Inmediato de Información y quienes operan bajo regímenes forales, como TicketBAI, deben analizar específicamente su encaje. No es prudente extrapolar una respuesta general.
Paso 1. Inventariar cómo se factura de verdad
El inventario debe cubrir más que el programa principal. Muchas empresas facturan también desde ecommerce, TPV, hojas de cálculo, aplicaciones verticales, ERP secundarios o procesos manuales.
Para cada flujo se registra:
- entidad y NIF que factura;
- actividad, establecimiento y serie;
- aplicación y versión;
- proveedor y responsable interno;
- origen del pedido o servicio;
- reglas fiscales y descuentos;
- facturas ordinarias, simplificadas y rectificativas;
- copias, duplicados y abonos;
- integración contable y bancaria;
- volumen máximo y periodos críticos;
- modo de contingencia actual.
El inventario debe localizar «facturación en la sombra»: plantillas ofimáticas, tickets reescritos o documentos emitidos fuera del sistema. Si permanecen, el proyecto puede parecer terminado y seguir incumpliendo en un canal residual.
Paso 2. Confirmar alcance con asesoramiento fiscal
La empresa debe documentar quién está obligado, qué operaciones entran y qué excepciones aplica. Esta decisión no debe recaer exclusivamente en el proveedor de software.
Un expediente de alcance útil incluye:
- entidades y establecimientos analizados;
- normativa y criterio utilizados;
- aplicaciones afectadas;
- flujos excluidos y fundamento;
- modalidad elegida para cada sistema;
- validación fiscal y fecha de revisión.
También hay que definir la relación con SII, regímenes forales, facturación por destinatario o tercero, autofacturación y sistemas extranjeros. Si un grupo comparte plataforma, el alcance se decide por entidad y flujo, no por instalación.
Paso 3. Exigir evidencias al proveedor
No basta una afirmación comercial de «compatible con Verifactu». El proveedor debe identificar producto, versión y configuración; aportar la declaración responsable prevista en la normativa; explicar la modalidad; y documentar requisitos técnicos, actualización, soporte y conservación.
Preguntas esenciales:
- ¿Qué versión concreta cumple y desde qué fecha?
- ¿Cómo genera, encadena y conserva los registros?
- ¿Cómo trata rectificaciones y anulaciones?
- ¿Qué ocurre si falla la conexión o la AEAT?
- ¿Cómo se protegen claves y certificados?
- ¿Qué campos deben completar las personas usuarias?
- ¿Cómo se actualizan QR y textos de factura?
- ¿Qué exportación permite para auditoría o migración?
- ¿Qué evidencias quedan de eventos y cambios?
- ¿Qué SLA ofrece durante cierres y fechas límite?
No existe una «homologación individual» que permita sustituir la diligencia de la empresa por un logotipo comercial. Debe conservarse la declaración responsable y comprobar que la versión implantada coincide con la declarada.
Requisitos funcionales que deben probarse
El reglamento se orienta a garantizar integridad, conservación, accesibilidad, legibilidad, trazabilidad e inalterabilidad de los registros. Las especificaciones desarrollan estructura, encadenamiento, huellas, eventos, QR y remisión.
La prueba debe recorrer el ciclo completo:
Alta de factura
Se comprueba numeración, fecha, emisor, destinatario, descripción, bases, tipos, cuotas, totales y reglas de redondeo. El registro se genera en el momento que corresponda y queda vinculado a la factura.
Rectificación y anulación
Una factura emitida no se «edita» como un documento de texto. Los errores deben corregirse mediante los mecanismos previstos, conservando la trazabilidad. Hay que probar cambios de importe, destinatario, tipo impositivo, devolución y anulación improcedente.
Encadenamiento y huella
Se valida que la secuencia sea coherente y que una alteración se detecte. Las pruebas incluyen cambio de ejercicio, serie, restauración de copia y concurrencia entre terminales.
QR y representación de la factura
La factura debe incorporar los elementos exigidos según el caso. Se comprueba impresión, PDF, visualización móvil, facturas simplificadas, plantillas personalizadas y documentos generados por integraciones.
Remisión y respuesta
En modalidad VERI*FACTU se prueban envíos, respuestas, rechazos, reintentos y conciliación. Un envío técnico no equivale a aceptación; los estados deben resultar visibles y accionables.
Registro de eventos
Cuando resulte aplicable, debe existir evidencia de actuaciones relevantes del sistema. Los accesos y exportaciones se limitan y se protegen contra modificación no autorizada.
Migración sin perder trazabilidad
Actualizar puede implicar migrar datos o cambiar de proveedor. El objetivo no es copiarlo todo sin criterio, sino conservar la capacidad de consultar y acreditar lo necesario.
El plan separa:
- maestros activos: clientes, productos, impuestos y series;
- documentos pendientes: presupuestos, pedidos, albaranes y facturas;
- histórico legal y contable;
- registros técnicos y eventos;
- adjuntos y evidencias;
- usuarios, roles y autorizaciones.
Antes del corte se limpia la calidad de datos: NIF, domicilios, códigos fiscales, duplicados, series y reglas. Después se concilian recuentos e importes por entidad, ejercicio, serie e impuesto. Se toma una copia protegida del sistema anterior y se documenta cómo consultarla.
Nunca debe improvisarse una migración durante un cierre. El ensayo se realiza con una copia representativa, se cronometra y se define un criterio de abortar. El plan de reversión indica hasta qué momento puede volver a usarse el sistema anterior sin crear dos fuentes de verdad.
Integraciones: el punto donde más fallan los proyectos
ERP, ecommerce, TPV, CRM y aplicaciones sectoriales pueden compartir la creación de documentos. Debe existir un único responsable de numeración y estado final. Si dos sistemas generan números o rectifican de forma independiente, aparecerán huecos, duplicidades o incoherencias.
Cada integración debe definir:
| Elemento | Decisión necesaria |
|---|---|
| Sistema maestro | Quién crea y numera la factura |
| Momento de emisión | Evento exacto que dispara el registro |
| Identificador | Clave común e idempotente |
| Errores | Cola, reintento, alerta y responsable |
| Rectificación | Sistema que inicia y sincroniza |
| Conciliación | Comparación diaria de estados e importes |
Los reintentos deben ser idempotentes: repetir una petición tras un timeout no puede crear otra factura. También se ensayan caídas parciales, latencia y mensajes fuera de orden.
Seguridad, accesos y protección de datos
Los perfiles deben separar administración, emisión, rectificación, consulta y exportación. Las cuentas compartidas dificultan atribuir acciones. Se exige autenticación adecuada, baja inmediata de accesos, protección de copias, registro de actividad y gestión de vulnerabilidades.
Los certificados o credenciales utilizados para la remisión no deben estar incrustados en código ni accesibles a todas las personas usuarias. Deben almacenarse de forma segura, rotarse y monitorizarse.
Las facturas contienen datos personales. La adaptación debe integrarse con contratos de encargado, control de accesos, conservación, atención de derechos y análisis de transferencias cuando exista nube o soporte internacional. La obligación fiscal legitima determinadas conservaciones, pero no un uso comercial indiscriminado.
Plan de implantación por fases
Fase 1. Diagnóstico
- Inventario de entidades, sistemas y flujos.
- Decisión de alcance validada fiscalmente.
- Clasificación de criticidad e integraciones.
- Selección de modalidad y proveedor.
Fase 2. Preparación
- Actualización de maestros y reglas.
- Contrato, declaración responsable y plan de soporte.
- Entorno de pruebas y casos de aceptación.
- Diseño de migración, seguridad y contingencia.
Fase 3. Pruebas
- Facturas ordinarias, simplificadas y rectificativas.
- Encadenamiento, QR, remisión y errores.
- Integraciones, concurrencia y volumen máximo.
- Restauración, consulta histórica y reversión.
Fase 4. Piloto
- Una entidad, establecimiento o serie controlada.
- Conciliación diaria y mesa de incidencias.
- Formación basada en tareas reales.
- Corrección antes del despliegue general.
Fase 5. Puesta en producción
- Corte aprobado y comunicado.
- Monitorización reforzada.
- Soporte durante cierres.
- Acta de aceptación y archivo de evidencias.
Matriz de pruebas de aceptación
| Caso | Resultado esperado | Evidencia |
|---|---|---|
| Factura correcta | Registro y representación coherentes | PDF, registro y log |
| Dato fiscal inválido | Bloqueo o aviso controlado | Captura y ticket |
| Rectificación | Vínculo con original y trazabilidad | Registros relacionados |
| Caída de red | Cola y reintento sin duplicado | Log y conciliación |
| Restauración | Secuencia íntegra y consulta disponible | Acta de prueba |
| Cambio de ejercicio | Serie y encadenamiento correctos | Informe de secuencia |
| Integración duplicada | Idempotencia evita segunda factura | Log de petición |
Plan de contingencia
Debe responder a tres escenarios: aplicación indisponible, conexión con AEAT no disponible y error masivo tras una actualización. Para cada uno se fija quién declara la incidencia, cómo se sigue operando legalmente, qué datos se registran, cómo se recuperan y cómo se concilian después.
No conviene mantener una hoja paralela sin control como solución permanente. La contingencia debe estar aprobada, numerada, limitada en el tiempo y ensayada. Tras recuperar el servicio, una persona responsable concilia todas las operaciones y conserva evidencia.
Errores frecuentes
- Confundir el reglamento SIF con la modalidad VERI*FACTU.
- Esperar al plazo legal para solicitar la actualización.
- Inventariar solo el ERP y olvidar TPV, ecommerce o Excel.
- Aceptar «software homologado» sin comprobar versión y declaración.
- Probar solo una factura sencilla y no rectificaciones o caídas.
- Migrar históricos sin conciliación ni plan de reversión.
- Permitir cuentas compartidas y cambios sin trazas.
- No coordinar asesoría fiscal, negocio, IT y proveedor.
- Tratar factura electrónica B2B y VERI*FACTU como un único proyecto.
- No reservar soporte para cierres y picos de facturación.
Checklist para dirección
- Alcance documentado por entidad y flujo.
- Fechas aplicables confirmadas en fuente oficial.
- Software, versión y modalidad decididos.
- Declaración responsable y documentación conservadas.
- Maestros, series e impuestos depurados.
- Rectificaciones, QR, registros y remisión probados.
- Integraciones con idempotencia y conciliación.
- Seguridad, certificados y roles revisados.
- Migración y reversión ensayadas.
- Contingencia probada y responsables formados.
- Acta de aceptación y archivo de evidencias.
Preguntas frecuentes
¿VERI*FACTU es obligatorio para todas las empresas?
El reglamento exige que los sistemas incluidos cumplan sus requisitos. La modalidad de remisión VERI*FACTU debe distinguirse del sistema no VERI*FACTU. El encaje concreto debe validarse para cada obligado y flujo.
¿Cuáles son las fechas de 2027?
Antes del 1 de enero de 2027 para entidades que presentan el Impuesto sobre Sociedades y antes del 1 de julio de 2027 para el resto de obligados incluidos, según la ampliación aprobada en 2025.
¿Puedo seguir facturando con Excel?
Debe analizarse si la herramienta se utiliza como sistema informático de facturación dentro del ámbito. Una plantilla que genera y conserva facturas no debe darse por excluida sin análisis.
¿Existe software oficialmente homologado?
La norma se apoya en requisitos y en la declaración responsable del productor. La empresa debe comprobar producto, versión, configuración y evidencias, no basarse solo en una etiqueta comercial.
¿Es lo mismo que la factura electrónica B2B?
No. Son marcos diferentes, aunque comparten datos y pueden requerir una arquitectura coordinada.
¿Conviene esperar a 2027?
No. 2026 debe utilizarse para inventario, elección, pruebas, piloto y despliegue gradual. El margen permite corregir sin bloquear la facturación.
Fuentes oficiales consultadas
- Real Decreto 1007/2023 y texto consolidado.
- Orden HAC/1177/2024.
- Real Decreto 254/2025.
- Real Decreto-ley 15/2025.
- AEAT: ampliación de los plazos de adaptación.
Summum Sistemas puede acompañar el inventario, la selección, la migración, las integraciones y las pruebas. La responsabilidad fiscal debe validarse con asesoramiento competente; el objetivo técnico es que el cambio sea trazable, reversible y compatible con la operación real.