Respuesta corta: sí, con separación real por obligado

Sí, un mismo SIF puede facturar para varios obligados, pero debe comportarse como un SIF independiente para cada uno y separar sus registros, requisitos, cadenas y modalidad VERI*FACTU. Esa es la respuesta de la FAQ de la AEAT sobre uso múltiple de un SIF.

El artículo 7.a) del Reglamento aprobado por el Real Decreto 1007/2023 permite un mismo sistema para varios obligados cuando los registros de cada uno están diferenciados y el reglamento se cumple por separado. Fuente legal: artículo 7.a) del RD 1007/2023. La Orden HAC/1177/2024 exige ese comportamiento independiente. Fuente legal: artículo 2 de la Orden HAC/1177/2024.

Compartir producto, servidor o interfaz puede ser compatible; compartir sin separación el expediente de facturación no lo es. La norma no exige necesariamente una aplicación, ordenador o licencia aislados por empresa: exige probar el resultado en cada operación.

Qué significa «varios obligados»

Aquí «empresa» es una abreviatura práctica. La norma habla de obligado tributario y la AEAT de obligado a expedir factura (OEF). Cada sociedad o persona que expide sus facturas conserva su identidad fiscal aunque una gestoría o proveedor opere la misma aplicación.

El artículo 1 del RD 1007/2023 define el SIF como el conjunto de hardware y software que admite información, procesa la facturación, genera registros y permite expedir la factura. Fuente legal: objeto y definición del sistema en el artículo 1 del RD 1007/2023. El nombre comercial de un ERP o SaaS no decide por sí solo qué componente forma parte del SIF.

Para analizar el perímetro, identifica quién emite la factura, qué NIF entra en el registro, qué componente genera el registro, quién lo remite o conserva y si la cuenta gestiona una o varias facturaciones. Un módulo que recibe datos para contabilidad no es automáticamente el SIF que expidió la factura. La FAQ técnica de desarrolladores de la AEAT distingue introducción, generación, expedición con QR y remisión.

La separación alcanza a todo el recorrido

La separación por obligado es una exigencia de comportamiento. El artículo 2.a) de la Orden HAC/1177/2024 exige gestionar por separado sus registros de facturación y, cuando proceda, sus registros de evento, garantizando para cada uno las características del artículo 8 del reglamento. Fuente legal: artículo 2.a) de la Orden HAC/1177/2024.

Eso incluye seleccionar la empresa antes de crear la factura, aplicar sus datos fiscales, asignar su serie y numeración, generar el alta o la anulación, calcular su huella y gestionar su modalidad y remisión. También alcanza accesos, exportaciones y comprobaciones. El RD 1007/2023 exige integridad, conservación, accesibilidad, legibilidad, trazabilidad e inalterabilidad de los registros. Fuente legal: artículo 8.1 del RD 1007/2023.

La separación no impone una tecnología concreta. Puede haber una base compartida, varias bases, un servicio central o una arquitectura mixta. Las fuentes oficiales no permiten concluir que «multi-tenant», «cloud» o «ERP» equivale a cumplimiento. La prueba es que ningún registro, serie, NIF o configuración de una empresa se confunda con otra. La AEAT lo resume así: el SIF debe comportarse como un SIF propio e independiente para cada OEF. Fuente oficial: FAQ AEAT de uso múltiple.

Cómo identificar al obligado activo

La Orden exige visualizar claramente y en todo momento la información identificativa del obligado al que corresponde la operación. También exige un mensaje rápido, fácil e intuitivo cuando el sistema soporta más de un obligado, estén sus facturaciones de alta, de baja o en otro estado. Fuente legal: artículo 2.d) de la Orden HAC/1177/2024.

La FAQ de desarrolladores aclara que basta un dato que distinga inequívocamente al obligado: razón social, NIF, código inteligible o combinación. Fuente oficial: FAQ de desarrolladores, apartado de visualización de usuarios. «Cliente 2» no sirve si el usuario no puede saber qué NIF representa.

Antes de expedir, revisa como control operativo la razón social y NIF activos, sus series, la modalidad y, cuando proceda, el estado de remisión y número de instalación. Es una lista de comprobación, no una nueva lista normativa cerrada. Un código interno solo es útil si está documentada su correspondencia con el NIF. El mensaje que informa de varias facturaciones debe estar en el sistema, no únicamente en un manual. FAQ AEAT de uso múltiple.

Una cadena para cada pareja SIF y obligado

La AEAT exige una cadena independiente por cada pareja de valores SIF y obligado tributario cuando un SIF gestiona varias facturaciones. Fuente oficial: FAQ AEAT sobre trazabilidad. Si un producto gestiona cuatro sociedades, no se usa una cadena global para las cuatro.

Cada registro apunta al inmediatamente anterior mediante datos del registro previo; la trazabilidad no se consigue ordenando después un listado comercial. Fuente oficial: mecanismo de encadenamiento en la FAQ AEAT. Para un obligado, sus registros de alta y anulación forman parte de la cadena que corresponda. Fuente legal: artículos 7 y 11 de la Orden HAC/1177/2024. Una serie distinta no crea por sí sola otro SIF. Una anulación no borra el alta: queda vinculada al registro correspondiente. FAQ AEAT sobre anulación de registros.

Hash, fechas y datos que no deben cruzarse

Para el registro de alta, el artículo 13 de la Orden incluye en la huella, entre otros, NIF del emisor, número y serie, fecha de expedición, tipo, cuota, total y fecha, hora y huso horario de generación. Fuente legal: artículo 13 de la Orden HAC/1177/2024. El NIF emisor queda unido a la factura y a su cadena.

La Orden exige comprobar la huella y saltar al registro anterior o posterior cuando esté disponible, indicando si encadenamiento y orden temporal son correctos. Fuente legal: especificaciones de trazabilidad de la Orden HAC/1177/2024. Una exportación que mezcla filas de empresas sin conservar esa relación no prueba el cumplimiento. La fecha y hora deben ser exactas, con margen máximo de un minuto, e incluir el huso horario. Fuente legal: artículos 7 y 9 de la Orden HAC/1177/2024.

Registros de evento: dependen de la modalidad

La FAQ de la AEAT indica que el registro de eventos es obligatorio para los sistemas de emisión no verificables y no es necesario cuando el SIF funciona como VERI*FACTU. Fuente oficial: FAQ AEAT sobre registro de eventos. La Orden contempla esos registros dentro de las especificaciones aplicables cuando correspondan.

Si una facturación multiempresa opera en NO VERIFACTU, sus eventos y controles deben quedar vinculados a ese obligado y a la instalación que lo soporta; un diario genérico de toda la cuenta no basta. Si otra facturación funciona como VERIFACTU, la remisión no elimina la necesidad de identificarla ni de mantener su cadena.

La FAQ técnica describe IndicadorMultiplesOT en los registros de facturación y, cuando proceda, de evento. Fuente oficial: FAQ de desarrolladores de la AEAT, apartado IndicadorMultiplesOT. En un SIF SaaS se calcula por usuario, no globalmente: «S» si ese usuario tiene más de una facturación, sean del mismo o distinto obligado y estén activas o de baja; «N» si solo tiene una. La implementación debe seguir las especificaciones técnicas vigentes; esta página no inventa valores para una instalación concreta.

Identificación técnica del SIF y número de instalación

La documentación técnica de la AEAT identifica un SIF mediante la concatenación de Id.OEF, Id.SIF y número de instalación. El Id.OEF es el NIF; el Id.SIF es el código que asigna el fabricante al producto; el número de instalación completa la identificación unívoca de cada SIF de un mismo OEF. Fuente oficial: FAQ de desarrolladores de la AEAT, apartado de identificación del SIF.

Un cambio de versión no crea por sí solo otro identificador. El número de instalación no puede repetirse entre instalaciones del mismo obligado, ni siquiera tras formatear y reinstalar. Fuente oficial: identificación, versiones y número de instalación en la FAQ de desarrolladores. Cada facturación que gestiona el producto debe tener su propio número; la AEAT puede tratarlas como SIF independientes o «virtuales» dentro del producto completo.

Esto describe identificadores, no una receta de base de datos. Pide al proveedor el inventario de identificadores y su regla de no reutilización.

VERI*FACTU debe poder elegirse por separado

El artículo 2.c) de la Orden exige que un SIF que gestiona varios obligados permita funcionar como VERI*FACTU de forma independiente para cada uno. Fuente legal: artículo 2.c) de la Orden HAC/1177/2024. La elección no tiene por qué ser un interruptor global para toda la cuenta.

Una sociedad puede remitir como VERI*FACTU y otra usar la modalidad no verificable, siempre que el sistema cumpla los requisitos de cada modalidad y mantenga claro el perímetro. La FAQ AEAT sobre sistemas VERI*FACTU no autoriza a mezclar registros.

En VERIFACTU el sistema debe poder remitir registros y gestionar mensajes, respuestas e incidencias conforme al artículo 16 de la Orden. Fuente legal: artículo 16 de la Orden HAC/1177/2024. En NO VERIFACTU, la firma electrónica de registros de facturación y evento es una exigencia adicional, según la FAQ AEAT sobre firma. En un producto dual, la configuración de cada obligado determina los controles que se activan.

Qué debe decir la declaración responsable

La declaración responsable debe identificar nombre, código y versión del sistema, componentes de hardware y software, si solo funciona como VERIFACTU, si permite uso por varios obligados, firma cuando no opere como VERIFACTU, productor, identificación, contacto, manifestación de cumplimiento y fecha y lugar de firma. Fuente legal: artículo 15 de la Orden HAC/1177/2024.

El artículo 15.1.f) exige indicar si permite usarlo para varios obligados o que un usuario dé soporte a varias facturaciones. Fuente legal: artículo 15.1.f) de la Orden HAC/1177/2024. Marcar «sí» declara una capacidad, pero no demuestra que una instalación esté bien configurada.

Debe estar disponible de forma legible e individualizada dentro del sistema, con acceso rápido, fácil e intuitivo, y entregarse al comercializador y cliente al adquirirlo y después. Fuente legal: artículo 15.3 de la Orden HAC/1177/2024. Cuando intervienen terceros, cada ampliación o componente necesita su declaración para sus versiones. Fuente legal: artículo 15.4 de la Orden HAC/1177/2024. Los ejemplos de declaraciones responsables de la AEAT son ayuda, no una plantilla para copiar otro producto.

Arquitecturas permitidas y límites

Las arquitecturas mixtas, con varios programas, componentes o fabricantes, no son contrarias a la normativa por ese mero hecho. La FAQ técnica de la AEAT describe terminales conectados en tiempo real con un backoffice central que genera el registro y lo devuelve para imprimir el QR. Fuente oficial: FAQ de desarrolladores de la AEAT, apartado de arquitecturas.

Eso no prueba el cumplimiento de una arquitectura concreta sin conocer sus funciones, versiones, flujos y declaraciones. Esta página no prescribe una base de datos por NIF, microservicio por sociedad ni instalación física por empresa. Lo exigible es separar registros, cadenas, identificación y modalidad por obligado y demostrar ese resultado.

Compartir aplicación tampoco separa responsabilidades. Los obligados que realizan las operaciones documentadas siguen siendo responsables del reglamento y de facturación. Fuente legal: responsabilidad del obligado en el RD 1007/2023. Si hay datos personales, deben cumplirse también RGPD, Ley Orgánica 3/2018 y demás normativa aplicable. Fuente legal: artículo 7.a) del RD 1007/2023.

Una cadena independiente no autoriza a mezclar numeraciones, datos o responsabilidades: la protección de datos y las obligaciones fiscales de cada empresa siguen siendo cuestiones separadas. Fuente legal: artículo 7.a) del RD 1007/2023. La separación técnica exigida por VERI*FACTU no sustituye la revisión de permisos ni el control fiscal de cada obligado.

Lista de comprobación antes de activar varias empresas

El control práctico empieza por identificar cada obligado, asignar su facturación y probar que la cadena, la modalidad y el registro quedan vinculados al NIF correcto. Fuente oficial: FAQ AEAT de uso múltiple. Es una comprobación operativa basada en las exigencias de separación e identificación, no una certificación automática del producto.

1. Identifica el perímetro

Incluye un inventario de cada obligado, NIF, series, usuarios y equipos. Incluye facturaciones de baja: el sistema debe indicar que soporta más de un obligado con independencia de su estado. Fuente oficial: FAQ AEAT de uso múltiple.

2. Sigue una factura de prueba conceptual

Sin datos reales, recorre una factura de cada empresa y anota selección del obligado, serie, número, NIF del registro, huella, modalidad, remisión o conservación y componente responsable. No uses numeración real de producción para pruebas.

3. Comprueba el encadenamiento

Verifica anterior y siguiente de un registro de A y repite con B; prueba una anulación controlada en cada cadena. La regla es una cadena por cada par SIF y obligado, no una cadena global. Fuente oficial: FAQ AEAT sobre trazabilidad.

4. Revisa identificadores y modalidad

Solicita Id.OEF, Id.SIF y número de instalación de cada facturación. Confirma que no se reutiliza tras reinstalar y prueba una respuesta, incidencia y reintento sin cruzar NIF ni colas. Fuente oficial: FAQ de desarrolladores sobre número de instalación.

5. Archiva la declaración y revisa accesos

Conserva las declaraciones del producto, versión y componentes; comprueba el campo multiobligado. Prueba que A no pueda expedir con el NIF de B por una selección residual o permiso excesivo y documenta quién cambia series, modalidad, certificados y usuarios. Fuente legal: artículo 7 del RD 1007/2023.

Cuándo conviene separar productos

Compartir SIF es razonable solo cuando el producto puede aislar la operación de cada obligado y mantener controles de acceso; si no puede probarlo, hay que revisar el diseño antes de ponerlo en producción. Fuente legal: artículo 2 de la Orden HAC/1177/2024. La decisión debe basarse en evidencia de la configuración real.

La norma permite compartir un SIF, pero no obliga a hacerlo. Compartir puede simplificar soporte y actualizaciones, pero concentra el riesgo de que un cambio afecte a varias empresas. Separar productos puede reducir el alcance de un error, aunque multiplica versiones, declaraciones, certificados e incidencias.

El criterio es la capacidad demostrable: aislamiento, obligado activo, cadena correcta, modalidad y declaración coherente con la versión. Si el proveedor no enseña esa evidencia, no se arregla llamando a la cuenta «multiempresa».

En un ERP centralizado, si todos los módulos pertenecen a un SIF, puede exigirse una cadena por obligado con independencia de las series; si módulos inconexos generan facturación descentralizada, pueden ser SIF distintos. Depende de funciones e interrelación real, no de la palabra ERP. Fuente oficial: FAQ AEAT sobre trazabilidad y arquitecturas.

La trazabilidad exigida se limita al ámbito del propio SIF y obligado que gestiona; no regula lo que otro programa haga después al recibir registros para contabilidad o stock. Fuente oficial: alcance de la trazabilidad en la FAQ AEAT. La conciliación de facturas, cobros, libros y declaraciones de cada sociedad sigue siendo necesaria.

Preguntas frecuentes sobre un SIF multiempresa

¿Puede un mismo SIF facturar para varias empresas?

Sí. El artículo 7.a) del RRSIF lo permite si los registros de cada obligado están diferenciados y el sistema cumple los requisitos por separado. La Orden HAC/1177/2024 exige que se comporte como un sistema independiente para cada obligado. Fuente legal: artículo 7.a) del RD 1007/2023 y artículo 2 de la Orden HAC/1177/2024.

¿Debe haber una cadena por cada NIF?

Debe existir una cadena independiente por cada combinación de SIF y obligado tributario. Si el mismo SIF gestiona tres sociedades, no se usa una cadena común para las tres. Fuente oficial: FAQ AEAT sobre trazabilidad.

¿Cómo debe identificarse la empresa activa?

El sistema debe mostrar de forma clara y permanente un dato que identifique unívocamente al obligado, como su razón social, NIF, código inteligible o una combinación de ellos. Fuente legal: artículo 2.d) de la Orden HAC/1177/2024. La interfaz debe indicar además que gestiona más de un obligado cuando esa sea la situación.

¿La declaración responsable debe decir que el SIF es multiempresa?

Sí. El artículo 15 de la Orden exige indicar si permite el uso por varios obligados o por un mismo usuario para varias facturaciones, además de identificar versión, componentes, productor y modalidad. Fuente legal: artículo 15.1.f) de la Orden HAC/1177/2024. Revisa siempre la versión instalada, porque la declaración se refiere al sistema concreto que describe.

¿Compartir una base de datos ya cumple VERI*FACTU?

No se puede concluir eso solo por tener una base común. La norma exige separación efectiva de registros, cadenas, configuración y operativa por obligado; la arquitectura concreta debe demostrar ese comportamiento. Fuente oficial: FAQ AEAT de uso múltiple. La protección de datos y los permisos de acceso añaden controles que deben analizarse por separado.

Próximo paso: pide una prueba por obligado

Si valoras un mismo producto para varias sociedades, pide una demostración con dos obligados distintos y la versión exacta que instalarás. Debe mostrar obligado activo, factura y NIF del registro, cadena, número de instalación, modalidad, una incidencia y declaración responsable. No necesitas imponer una arquitectura para hacer estas preguntas.

El hub fiscal-contable reúne el resto de guías. Para comparar alternativas, revisa el caso de sociedades con software de facturación y el proceso para migrar un programa de facturación a VERI*FACTU.

TaxFactory puede ayudarte a revisar el perímetro y la documentación antes de contratar un servicio fiscal-contable para empresas. Consulta también la guía general sobre sistemas VERI*FACTU para pymes. Esta página ofrece información general para España con fuentes consultadas el 31 de agosto de 2026; no sustituye revisar la configuración, contrato, versión ni obligaciones concretas de cada obligado.