El artículo 3.1.a del RRSIF incluye a los contribuyentes del Impuesto sobre Sociedades, pero deja fuera a las entidades totalmente exentas del artículo 9.1 LIS. Las entidades parcialmente exentas de los apartados 2, 3 y 4 del artículo 9 LIS solo quedan sometidas por las operaciones que generan rentas sujetas y no exentas. Fuente oficial.
Para las entidades incluidas, la adaptación debe estar lista antes del 1 de enero de 2027. Fuente oficial. No es la fecha inicial que todavía aparece en algunas guías antiguas.
La obligación afecta al sistema que soporta la expedición de facturas, no a la mera tenencia de un programa contable. Tampoco impone que todas las sociedades remitan cada registro a la AEAT: el reglamento admite la modalidad VERI*FACTU y la modalidad de sistema no verificable. La primera envía los registros de facturación; la segunda los conserva bajo requisitos adicionales. Conviene separar esas dos decisiones desde el principio: primero se determina si la sociedad y sus operaciones están dentro del RRSIF; después se escoge la modalidad y se implanta.
El filtro de ámbito antes de hablar con el proveedor
El punto de partida es el artículo 3 del reglamento. Incluye a los contribuyentes del Impuesto sobre Sociedades, pero excluye a quienes llevan los libros de IVA mediante el Suministro Inmediato de Información en relación con sus propias facturas. También hay que revisar la sujeción a normativa foral y las eventuales resoluciones de no aplicación. La AEAT resume el análisis con cuatro comprobaciones: uso de un SIF, no estar en SII, no quedar bajo normativa foral por imposición directa y no tener una resolución vigente de exclusión. Fuente oficial.
Estar constituido como sociedad no basta para decidir el circuito: los obligados sometidos al SII quedan fuera del RRSIF respecto de sus propias facturas. Fuente oficial. La exclusión no significa que cualquier aplicación que use la empresa quede exenta. El software debe seguir cubriendo las exigencias del SII y del Reglamento de facturación.
Una sociedad patrimonial merece una comprobación expresa. La AEAT indica que el artículo 3 incluye a la totalidad de contribuyentes del Impuesto sobre Sociedades sin distinguir el tipo de actividad. Si la entidad expide facturas con un sistema y no está excluida, llamarla “patrimonial” no resuelve el análisis. En grupos con varias entidades tampoco sirve una respuesta única: cada NIF, adscripción al SII, domicilio fiscal y circuito emisor puede arrojar un resultado distinto.
El RRSIF comprende tanto las facturas completas como las simplificadas y define el sistema informático por las funciones de entrada, conservación y procesamiento de información de facturación. Fuente oficial. Por eso el inventario no debe limitarse al programa que imprime el PDF.
En una empresa mediana puede haber pedidos en un CRM, precios en un ERP, cobros en una pasarela, facturas en una plataforma externa y asientos en otra aplicación. La pregunta útil es qué componente expide la factura y qué otros componentes intervienen en las tres funciones legales. Si un módulo recibe datos, conserva información o los procesa para producir resultados de facturación, debe quedar documentado en la arquitectura y en la declaración responsable que corresponda.
Es útil dibujar un recorrido por canal. Venta presencial, suscripción, proyecto, devolución, anticipo y autofacturación suelen seguir rutas distintas. Anota dónde nace el número de factura, quién decide la serie, qué sistema calcula impuestos, dónde se genera el registro de alta y qué aplicación conserva la respuesta de la AEAT. Un diagrama sencillo descubre integraciones que el proveedor principal quizá no controla.
No todo fichero es otro SIF. Una exportación contable posterior puede ser solo un destino de datos. A la inversa, una hoja que calcula y emite numeración, o un complemento que permite rectificar facturas, puede formar parte del sistema aunque internamente se considere una herramienta menor. La calificación exige observar funciones, no nombres comerciales.
VERI*FACTU y sistema no verificable no son sinónimos
VERI*FACTU remite a la AEAT los registros de facturación de forma continuada, automática y consecutiva. Fuente oficial. La respuesta informa de la aceptación o rechazo del registro. Fuente oficial. Una respuesta afirmativa no implica que el registro sea completamente válido ni impide validaciones posteriores. Fuente oficial.
En VERI*FACTU el sistema remite los registros de alta y anulación a la AEAT de forma continuada. La conexión, las respuestas y los reintentos necesitan un procedimiento operativo. El artículo 16.3 de la Orden HAC/1177/2024 precisa que una respuesta afirmativa no implica validez completa del registro ni impide validaciones posteriores.
En la modalidad no verificable los registros no se envían ordinariamente. La sociedad asume la conservación y los controles adicionales previstos para proteger integridad, trazabilidad, accesibilidad e inalterabilidad. Fuente oficial. La aparente ventaja de no remitir información debe compararse con la carga de evidenciar que el sistema y la operación mantienen esos requisitos durante el periodo correspondiente.
Para decidir, usa datos reales: conectividad de sedes, recursos de soporte, volumen de facturas, sensibilidad de integraciones, capacidad de conservar evidencias y política interna de cumplimiento. No elijas por una etiqueta comercial. Pide al proveedor que explique qué ocurre cuando falla Internet, qué respuesta queda registrada, cómo se recupera un rechazo y si cambiar de modalidad requiere una migración.
La declaración responsable debe identificar el sistema, su versión y componentes, el productor y la forma en que se cumplen las especificaciones. Fuente oficial. Debe estar disponible dentro del sistema y entregarse al comercializador y al cliente. Una frase genérica en una propuesta comercial no sustituye ese documento.
Vale la pena solicitar la declaración de la versión exacta que se instalará. Si la solución incorpora módulos de terceros, conectores o ampliaciones producidos por otras empresas, pregunta por sus declaraciones respectivas. Conserva las versiones utilizadas y la fecha de entrada en producción. Una declaración de la versión 5.2 no prueba por sí sola la situación de una instalación que sigue en 4.8 o que usa un complemento modificado.
Pide también una matriz funcional. Debe cubrir altas, anulaciones, rectificativas, facturas simplificadas, duplicados, series, destinatarios, impuestos especiales del negocio y caídas de servicio. Añade quién mantiene cada interfaz y qué tiempos de respuesta ofrece el soporte. El contrato debería aclarar cómo se aplican actualizaciones obligatorias y cómo se recuperan datos si termina la relación.
El modelo oficial de certificación se apoya en la declaración responsable del productor para el sistema y la versión, no en una homologación individual general emitida por la AEAT. Fuente oficial. Un proveedor puede aportar ensayos adicionales, pero debe distinguirlos del documento previsto en la Orden.
La prueba debe parecerse a un cierre real
La adaptación debe verificarse sobre la versión que se usará en producción, su declaración responsable y un circuito de pruebas que reproduzca las operaciones reales de la sociedad. Un alta de factura con un cliente nacional y tipo general de IVA solo demuestra el camino más fácil.
Prepara casos con anticipos, abonos parciales, errores descubiertos después de expedir, cambios de destinatario, ventas exentas, operaciones internacionales, suplidos si existen y facturas emitidas por terceros. Añade el cierre de caja y la convivencia entre varias series. Cada caso debe tener una entrada conocida y una salida esperada: factura visible, registro generado, encadenamiento, QR, respuesta o evidencia de conservación.
No pruebes únicamente la interfaz. Revisa el registro técnico y su correspondencia con la factura. Comprueba que una rectificación no borra el original y que una anulación no se utiliza como atajo contable para corregir cualquier error. El personal que factura debe entender qué acción corresponde, porque un software conforme no corrige una instrucción operativa equivocada.
Puede ser práctico incluir fallos deliberados en un entorno seguro. Desconecta la comunicación, fuerza un dato inválido, recupera un envío y examina qué ve el usuario. Si el sistema oculta la cola de pendientes, define un control diario. Si muestra alertas, asigna dueño y plazo. Una incidencia sin responsable acaba convertida en registros atrasados que nadie sabe conciliar.
Muchas sociedades delegan la expedición material en una asesoría, una plataforma o el destinatario. Esa delegación no borra la responsabilidad del obligado. Hay que identificar quién opera el SIF, con qué certificado se realizan los envíos y cómo recibe la sociedad los registros, respuestas y evidencias necesarias.
Separa series cuando el Reglamento de facturación lo exija o cuando la organización lo necesite para distinguir establecimientos y circuitos. La separación no debe romper la trazabilidad. Documenta qué serie usa cada canal, qué sistema asigna el número y cómo se evita que dos aplicaciones emitan sobre la misma secuencia.
Si una plataforma externa expide en nombre de varias sociedades del grupo, no mezcles NIF ni configuraciones. Cada emisor necesita sus datos, series y controles. La centralización puede reducir mantenimiento, pero concentra el riesgo: una configuración defectuosa alcanza a varias entidades. Por eso las pruebas de aceptación deben ejecutarse por emisor, no solo sobre el entorno compartido.
Los usuarios también importan. Limita permisos para anular, rectificar o cambiar series. Conserva un procedimiento de altas y bajas. El registro de facturación no reemplaza el control de acceso; ambos responden a riesgos diferentes.
Calendario de implantación sin esperar a diciembre
La fecha jurídica es anterior al 1 de enero de 2027 para los contribuyentes del Impuesto sobre Sociedades. Eso significa que el primer día de 2027 el sistema ya debe estar adaptado, no que el proyecto empiece entonces. El Real Decreto-ley 15/2025 desplazó el calendario que había fijado previamente el Real Decreto 254/2025. Cualquier plan que aún trabaje con 2026 debe corregirse.
Un calendario razonable parte hacia atrás. Reserva tiempo para inventario y decisión de modalidad, contratación, parametrización, pruebas integradas, formación y estabilización. Añade un margen para corregir interfaces. La duración concreta depende del mapa de la empresa; prometer que cualquier implantación se resuelve en unas semanas sería poco serio.
Resulta sensato evitar un cambio general el mismo día del cierre anual. Si el proveedor permite activar antes la solución, estudia una puesta en producción controlada. Una vez obligatoria la adaptación, el comienzo efectivo de envíos VERI*FACTU obliga a mantener esa modalidad al menos hasta terminar el año natural. Fuente oficial.
En contratos plurianuales, no des por hecho que la antigüedad permite conservar una versión no adaptada. La disposición final cuarta mantiene la obligación de adaptar los sistemas incluidos en mantenimiento antes de las fechas de los usuarios. Revisa hitos, responsabilidades y costes del contrato, y documenta cualquier excepción que el proveedor alegue.
El registro de facturación y el asiento contable no son la misma cosa. Diseña una conciliación entre facturas expedidas, registros generados, registros enviados o conservados y contabilidad. La periodicidad puede depender del volumen, pero debe detectar huecos, duplicados, rechazos y desfases.
Conserva evidencias útiles: declaración responsable, manuales de la versión, actas de pruebas, incidencias, decisiones de configuración y cambios. No acumules capturas sin contexto. Cada evidencia debe contestar qué se probó, cuándo, con qué versión y cuál fue el resultado.
Cuando el sistema se actualice, aplica una evaluación de impacto. Una corrección visual no requiere repetir todo; un cambio en impuestos, series, encadenamiento o envío sí. Define un conjunto corto de pruebas de regresión que pueda ejecutarse con rapidez y un conjunto completo para cambios mayores.
La dirección debería recibir indicadores comprensibles: registros pendientes, rechazos sin resolver, diferencias con contabilidad y versiones fuera de soporte. Una métrica de “facturas emitidas” no detecta por sí sola incumplimientos. Tampoco resulta útil inundar el comité con cada código técnico.
Errores de decisión que encarecen el proyecto
El primero es comprar una solución antes de cerrar el ámbito. Una sociedad en SII puede acabar pagando un módulo que no necesita para sus propias facturas; otra entidad del grupo, fuera del SII, puede quedar olvidada. El segundo es asumir que el ERP cubre los portales o cajas conectadas sin haberlo probado.
Las facturas expedidas por los SIF incluidos deben incorporar el código QR tributario. Fuente oficial. El QR no sustituye los requisitos de registros, integridad, trazabilidad ni la declaración responsable del sistema. Fuente oficial.
También falla la implantación que deja al proveedor toda la decisión fiscal. El productor conoce el programa; la sociedad conoce sus operaciones y su ámbito tributario. Hace falta una revisión conjunta. El asesor debe delimitar obligaciones y casos; tecnología debe demostrar el funcionamiento; finanzas debe reconciliar resultados.
Por último, no uses la prórroga a 2027 para congelar el proyecto. El cambio legal dio más tiempo, pero no redujo la complejidad del inventario ni de las integraciones. Una entidad con varios canales necesita ese margen.
La sociedad debería cerrar el proyecto con una carpeta breve y ordenada. Incluye el mapa de entidades, la conclusión de ámbito, la modalidad elegida, la declaración responsable, las versiones instaladas, el contrato de soporte y el acta de pruebas. Añade una captura o exportación de la configuración solo cuando ayude a reproducirla. Un volcado enorme de pantallas sin explicación no demuestra qué se verificó.
El acta debe identificar entorno, fecha, usuario, datos de prueba y resultado esperado. Registra fallos y su corrección. Si un caso se acepta con una limitación, explica quién la aprobó y qué control temporal compensa. No marques como superada una prueba que el proveedor promete arreglar después.
A menudo ayuda asignar vigencia. La evidencia de una versión deja de describir la realidad cuando se actualiza un componente relevante. Mantén un índice con fecha de revisión y próximo disparador: nueva entidad, nueva serie, cambio de SII, actualización mayor o apertura de canal.
La documentación también facilita continuidad. Si cambia el responsable de finanzas o tecnología, otra persona puede entender por qué se eligió modalidad y cómo se atiende un rechazo. Ese conocimiento no debería quedar solo en correos del consultor.
Preguntas para la reunión de salida
Antes de aceptar, pide una respuesta demostrable a estas cuestiones: qué versión está instalada, dónde aparece su declaración, qué componente genera el registro, cómo se detecta un rechazo, quién reintenta, cómo se exporta el histórico y cómo se restaura. Una corrección de datos registrados debe producir un registro posterior y conservar inalterados los originales. Fuente oficial.
Confirma que las licencias cubren todas las entidades y usuarios. Revisa límites de volumen, almacenamiento y API. Un entorno que funciona en pruebas con cien facturas puede comportarse distinto al importar miles; solicita una prueba proporcional al cierre real.
Por último, valida el soporte fuera del horario habitual si la empresa factura entonces. Documenta teléfono, prioridad y escalado. La conformidad normativa del producto no garantiza que una incidencia operativa se resuelva a tiempo.
El artículo 3.1.a del RRSIF incluye a los contribuyentes del Impuesto sobre Sociedades, pero deja fuera a las entidades totalmente exentas del artículo 9.1 LIS. Fuente oficial.
Las entidades parcialmente exentas de los apartados 2, 3 y 4 del artículo 9 LIS solo quedan sometidas al RRSIF por operaciones que generen rentas sujetas y no exentas del Impuesto sobre Sociedades. Fuente oficial.
Los contribuyentes del Impuesto sobre Sociedades incluidos deben adaptar sus sistemas antes del 1 de enero de 2027. Fuente oficial.
El sistema debe generar el registro de alta de forma simultánea o inmediatamente anterior a la expedición de cada factura. Fuente oficial.
El artículo 7 permite cumplir mediante un sistema ajustado al reglamento o mediante la aplicación que desarrolle la Administración tributaria. Fuente oficial.
El resto de la guía baja esas reglas al proyecto de una sociedad. Son criterios de implantación, no obligaciones añadidas al texto legal.
El próximo paso de la sociedad
Una opción razonable es preparar un inventario por NIF y canal. Marca Impuesto sobre Sociedades, SII, territorio fiscal, resolución de exclusión, software emisor, versión, modalidad prevista y proveedor. Después selecciona diez operaciones reales que representen la facturación del negocio y exige una demostración documentada.
Solicita la declaración responsable y compárala con la instalación. Cierra un calendario que termine antes del 1 de enero de 2027, con responsables de fiscalidad, finanzas y tecnología. Deja por escrito qué se hará ante rechazos, caídas y rectificaciones. Esa documentación será más útil que una presentación comercial que solo diga “listo para VERI*FACTU”.
Para situar el proyecto dentro del cambio normativo, consulta la guía sobre sistemas de facturación para pymes. Si necesitas revisar el ámbito, las operaciones y el plan de pruebas de tu sociedad, el servicio fiscal-contable de TaxFactory puede ayudarte a ordenar el trabajo. Este contenido es información general para España, revisada el 17 de julio de 2026; no sustituye el análisis de la entidad, sus impuestos, su software ni las normas vigentes en la fecha de implantación.