Dos centros sin conexión entre sí pueden expedir facturas si cada sistema es realmente autónomo: cada centro actúa como un SIF independiente, cumple el RRSIF por separado y mantiene su propia cadena de registros. La FAQ de la AEAT sobre centros desconectados resuelve expresamente este supuesto.

La desconexión no autoriza a aplazar las funciones que corresponden al momento de expedir. Cada sede debe poder cerrar la factura, generar su registro, mantener la trazabilidad y aplicar la modalidad elegida sin esperar a que vuelva la comunicación con la central. Después puede transferir información a contabilidad o a un repositorio corporativo, pero ese intercambio no rehace lo que ocurrió al expedir.

El punto decisivo es la autonomía funcional, no la distancia física. Dos ordenadores en edificios distintos pueden ser terminales del mismo sistema central. En cambio, dos equipos en el mismo local pueden ser SIF diferentes si cada uno expide con independencia. Antes de elegir una arquitectura, hay que observar qué sistema asigna la factura, genera el registro y resuelve una incidencia.

Esta guía se limita a centros del mismo obligado que expiden mediante sistemas físicamente desconectados. No sustituye la revisión de la versión instalada, la declaración responsable, el territorio, el calendario aplicable ni las circunstancias de una empresa concreta.

La primera decisión: uno o dos SIF

Llamar «centro» a una tienda, almacén u oficina no determina cuántos SIF existen. Para saberlo, recorre una venta desde que entra el pedido hasta que la factura queda expedida. Anota dónde se decide la serie y el número, qué acción cierra el documento, dónde nace el registro de alta y qué componente conserva o remite ese registro.

Un centro es autónomo cuando puede completar ese recorrido sin pedir al otro sistema un dato imprescindible para cerrar la factura. No basta con que imprima localmente. Si el equipo consulta a un servicio central para obtener el número, generar el registro o autorizar la expedición, puede ser un componente remoto de un sistema compuesto. La caída de la red revelará esa dependencia: el terminal podrá quizá capturar un pedido, pero no necesariamente expedir.

Mantener SIF separados encaja cuando cada centro puede expedir y recuperar su operativa sin depender del otro; si una sede necesita al sistema central para cerrar la factura, la arquitectura no es autónoma y debe analizarse como un sistema compuesto. Es un criterio operativo apoyado en el supuesto que aborda la FAQ de la AEAT sobre centros desconectados y debe contrastarse con las funciones de la versión real. La definición reglamentaria de SIF permite ordenar el análisis sin fiarse del nombre comercial.

Señales de autonomía real

Un centro independiente debería poder responder con evidencia a estas preguntas:

  1. ¿Puede expedir una factura ordinaria sin comunicarse con la otra sede?
  2. ¿Genera el registro de alta en ese mismo flujo?
  3. ¿Mantiene su propia secuencia de registros y detecta una ruptura?
  4. ¿Puede emitir una rectificativa y relacionarla con la operación correspondiente?
  5. ¿Resuelve la anulación o incidencia sin crear una segunda factura incoherente?
  6. ¿Aplica el QR y los demás requisitos de la versión instalada?
  7. ¿Conserva o remite los registros conforme a su modalidad?
  8. ¿Puede recuperar su estado sin reconstruir la cadena desde un listado de la central?

Si varias respuestas dependen de una conexión permanente, hay que describir el diseño como centralizado o compuesto. No es un defecto por sí mismo, pero cambia la contingencia: una sede no puede afirmar que ha expedido localmente si el componente que completa la expedición estaba inaccesible.

Cada centro genera y encadena lo suyo

La AEAT indica que los SIF de los dos centros generan el registro de alta al expedir cada factura. La respuesta oficial vincula la expedición con la generación del registro en cada sistema. No plantea que la sede desconectada guarde un borrador para que la central cree el registro horas después.

Cada SIF encadena sus registros de forma independiente y respeta su propio orden de generación. La cadena de la sede A avanza con los registros producidos en A; la de B, con los producidos en B. Un SIF no necesita conocer las facturas que expide el otro para generar y encadenar sus propios registros. La FAQ sobre centros desconectados lo explica de forma expresa.

Esto elimina una dependencia poco razonable: la tienda B no tiene que esperar la huella del último registro de A antes de atender a un cliente. También impide otra conclusión frecuente. La independencia técnica de los SIF no obliga a fabricar una única cadena para toda la sociedad. La empresa tendrá dos secuencias técnicas y necesitará una visión empresarial que las reúna sin alterarlas.

La trazabilidad permite comprobar si están todos los registros generados por un SIF de un obligado y si conservan el orden en que fueron producidos. La AEAT explica la finalidad del encadenamiento. No demuestra por sí sola que el consolidado de la empresa contenga todas las ventas de los dos centros. Ese segundo control pertenece a la conciliación conjunta.

Cadena, numeración y serie no son lo mismo

La cadena ordena registros por SIF. La serie identifica facturas conforme al diseño de facturación de la empresa. Confundir ambas cosas lleva a soluciones frágiles, como obligar a dos sedes desconectadas a reservar números alternos o a esperar una confirmación central para no coincidir.

Como recomendación operativa, asigna series inequívocas por centro y conserva un inventario que relacione sede, SIF, versión, instalación, modalidad y responsable. La recomendación no se presenta como una frase literal de la AEAT. Su objetivo es que una factura revele dónde se expidió y que el equipo pueda conciliarla con el registro correcto. La FAQ oficial sobre independencia de los sistemas aporta el contexto técnico.

Evita reutilizar una serie en dos centros si el diseño permite colisiones. Tampoco cambies la serie en una exportación para que el consolidado «quede bonito». El dato que llega a contabilidad debe relacionarse con la factura expedida y con el registro que realmente generó el SIF.

Modalidades distintas en los dos centros

La AEAT admite que un centro use VERI*FACTU y el otro una modalidad no verificable, porque cada SIF puede cumplir en una modalidad distinta. Consulta la respuesta sobre modalidades en centros desconectados. La posibilidad técnica no equivale a una recomendación de mezclar.

La propia AEAT advierte de que mezclar modalidades no es la opción preferible: los registros disponibles en su Sede ofrecerían listados incompletos de facturas emitidas y podrían tener que completarse mediante requerimientos. La advertencia aparece en la misma FAQ. La central debe saber que el listado visible en Sede no representará por sí solo toda la facturación.

Un centro VERIFACTU remite sus registros conforme a esa modalidad. El centro no verificable conserva los suyos con los controles que le correspondan. Cuando tesorería o contabilidad compare la Sede con las ventas, debe incorporar ambas fuentes y dejar constancia de qué parte no está en el listado de VERIFACTU.

Antes de mezclar, valora cuatro costes concretos:

  • dos procedimientos de soporte y recuperación;
  • dos formas de comprobar el estado de los registros;
  • un listado de Sede que no cubre toda la facturación;
  • más explicaciones cuando otra persona revisa el cierre.

Elegir la misma modalidad en ambos centros simplifica la operación, aunque no corrige por sí sola una mala delimitación. Dos terminales que dependen de un servidor central siguen dependiendo de él aunque compartan modalidad. Dos SIF autónomos siguen necesitando dos cadenas aunque remitan de la misma manera.

El volcado nocturno no arregla la expedición

Un volcado al final del día no permite tratar como remisión diferida a VERI*FACTU los registros de facturas que los clientes ya se llevaron impresas. La AEAT rechaza expresamente ese planteamiento. El problema no es la hora del archivo, sino que la factura ya fue expedida y entregada sin que la remisión se integrara en ese flujo.

Hay que distinguir tres operaciones:

  1. El SIF expide y genera el registro en el centro.
  2. El SIF cumple su modalidad: remite o conserva con los requisitos aplicables.
  3. La empresa exporta después datos a contabilidad, existencias o análisis.

Los registros ya generados por un SIF pueden enviarse después a otros sistemas para contabilidad o gestión de existencias sin convertir a esos destinos en el SIF emisor. La FAQ de trazabilidad delimita esa transferencia posterior. Esa exportación sirve para consolidar; no retrocede en el tiempo para transformar una factura ya expedida.

No llames «contingencia» a una rutina diaria prevista porque el centro carece de la conectividad necesaria para la modalidad escogida. Una incidencia es un hecho que debe detectarse, tratarse y dejar evidencia. Si la operación habitual consiste en imprimir durante el día y enviar por la noche, el diseño debe revisarse antes de usarlo.

Conectividad y capacidad del sistema

Todos los SIF deben tener capacidad de comunicarse con la AEAT, tanto para atender un requerimiento como para adoptar la modalidad VERI*FACTU con remisión inmediata en línea. La AEAT vincula esta capacidad con el artículo 8.1 del RRSIF. Por tanto, un centro desconectado del otro no puede equipararse sin más a un sistema incapaz de comunicarse con la Agencia Tributaria.

La arquitectura puede separar la red corporativa de la conectividad necesaria para remitir. Por ejemplo, la sede B puede no comunicarse con el ERP de A y, sin embargo, disponer de su propia salida segura para VERI*FACTU. También puede operar en modalidad no verificable y conservar registros localmente, siempre que el sistema cumpla sus requisitos y mantenga la capacidad exigida.

El artículo 8 del RRSIF exige que los sistemas garanticen integridad, conservación, accesibilidad, legibilidad, trazabilidad e inalterabilidad de los registros de facturación. Consulta el texto consolidado del Real Decreto 1007/2023. Un plan de continuidad debe preservar esas cualidades; no basta con recuperar un PDF o volver a crear un asiento.

Qué documentar ante una caída

Para cada centro, define antes de abrir al público:

  • cómo se detecta que la remisión o el servicio ha fallado;
  • qué estado ve la persona que factura;
  • si puede continuar y bajo qué procedimiento de la versión instalada;
  • qué datos se conservan durante la incidencia;
  • cómo se reintenta sin duplicar la factura ni el registro;
  • qué evidencia queda del error y de la recuperación;
  • quién comprueba después la cadena y la conciliación.

No inventes un procedimiento genérico que contradiga al productor. Pide la documentación de la versión, la declaración responsable y las instrucciones de recuperación. Después pruébalas en un entorno controlado, sin datos reales de clientes.

Consolidar sin modificar las cadenas

La centralización posterior tiene un objetivo distinto del encadenamiento. Debe permitir ver toda la facturación de la empresa, cuadrarla con cobros, IVA y contabilidad, y localizar el registro de origen. No debe recalcular huellas, reordenar registros ni sustituir los identificadores producidos en cada sede.

Diseña una tabla de conciliación con, al menos, centro, serie, número, fecha de expedición, importe, identificador del SIF, modalidad, estado del registro y asiento contable. Añade la referencia a una rectificativa o anulación cuando corresponda. La tabla es un control empresarial; la cadena sigue viviendo en el sistema que generó los registros.

Haz cierres por centro antes del consolidado. Si el centro B informa de cien facturas y la central recibe noventa y nueve, no arregles la diferencia importando de nuevo todo el lote sin investigar. Identifica la factura ausente, comprueba su registro y revisa el transporte. Un duplicado contable y una ausencia de registro son problemas distintos.

La conciliación también debe detectar rutas alternativas. Un usuario podría expedir desde el centro A una venta que ya se cerró en B, o utilizar una aplicación antigua durante una caída. Asigna permisos y responsabilidades para que cada operación tenga una sola ruta de expedición. Si existe una ruta excepcional, documéntala y pruébala.

Prueba la arquitectura antes de depender de ella

La prueba operativa debe recorrer en cada centro una factura ordinaria, una rectificativa y una anulación: expedición, registro, cadena, QR, remisión o conservación, exportación y conciliación central. Es una recomendación editorial basada en las funciones que el RRSIF exige proteger, no un guion oficial único.

Haz la prueba en cuatro estados:

  1. ambos centros funcionan con normalidad;
  2. se pierde la comunicación entre sedes;
  3. falla la salida a la AEAT o el servicio de remisión del centro afectado;
  4. se restaura el equipo o se recupera una copia autorizada.

En cada estado anota qué ve la persona usuaria, si puede expedir, qué registro se genera, qué respuesta recibe y cómo queda la operación al recuperar. No des por válida una prueba porque el PDF aparezca en pantalla. Comprueba registro, cadena, modalidad y consolidación.

Usa facturas de prueba y evita datos personales reales. Conserva capturas de configuración, versión del sistema, resultados y fecha de la validación. Repite la prueba cuando cambie la versión, la red, el certificado, la integración o el procedimiento de soporte.

Criterios de aceptación por sede

Un centro no debería entrar en producción hasta que el equipo pueda demostrar:

  • que una venta solo puede expedirse una vez;
  • que el registro corresponde a la factura entregada;
  • que la cadena continúa después de reiniciar;
  • que una incidencia no crea huecos ocultos ni duplicados;
  • que la modalidad real coincide con la configurada;
  • que la exportación conserva referencias suficientes para conciliar;
  • que soporte y responsables saben recuperar la operación.

Si una prueba falla, no tapes el resultado con un procedimiento manual improvisado. Decide si el defecto está en la configuración, la integración, la conectividad o el producto. Corrige y repite desde el principio con la versión que se vaya a utilizar.

Cuándo conviene centralizar

La independencia es útil si responde a una necesidad real: centros con conectividad corporativa inestable, operación autónoma, horarios distintos o continuidad local. A cambio, la empresa mantiene más instalaciones, más cadenas, más evidencias y una conciliación posterior.

Centralizar puede ser preferible cuando ambos centros dependen ya de datos comunes en tiempo real, la red es suficientemente robusta y un único componente expide de verdad. Reduce puntos de configuración, pero concentra la contingencia: si el servicio central cae, ningún terminal dependiente debería aparentar que ha completado la expedición.

No elijas por el número de pantallas. Compara autonomía, recuperación, soporte, capacidad de conciliación y coste de mantener versiones. La arquitectura duradera es la que coincide con el flujo real y puede probarse. Si una solución necesita fingir que un borrador es una factura expedida durante la desconexión, el fundamento es incorrecto.

Para el caso más amplio de TPV, ERP y aplicaciones conectadas, consulta la guía sobre VERI*FACTU con varios programas de facturación. Esta página mantiene una frontera más estrecha: dos centros que deben seguir facturando sin comunicarse entre sí.

Preguntas frecuentes

¿Pueden dos centros facturar sin estar conectados?

Sí, cuando cada centro expide mediante un SIF autónomo. Cada sistema genera el registro de alta con la factura, mantiene su cadena y cumple por separado. Si una sede necesita al sistema central para cerrar la factura, hay que analizar el conjunto como un sistema compuesto, no dar por supuesta la independencia. La AEAT responde al supuesto de dos centros desconectados.

¿Puede un centro ser VERI*FACTU y otro no?

La AEAT admite modalidades distintas para SIF independientes, pero advierte de que no es la opción preferible. La Sede electrónica mostraría un listado incompleto de facturas emitidas y la información podría tener que completarse mediante requerimientos. Cada centro debe cumplir todas las reglas de su modalidad. Consulta la FAQ oficial.

¿Cómo encadenar facturas en sedes independientes?

Cada SIF encadena los registros que él mismo genera, en su propio orden. No consulta la huella del otro centro ni crea una cadena única para toda la sociedad. La empresa sí debe poder conciliar después series, facturas, registros y contabilidad sin modificar las cadenas originales. La AEAT explica el encadenamiento por SIF.

¿Qué pruebas deben superar las sedes antes de facturar desconectadas?

Prueba por separado una factura ordinaria, una rectificativa y una anulación. Comprueba expedición, registro, cadena, QR, remisión o conservación, recuperación tras una incidencia, exportación y conciliación central. Usa datos de prueba y conserva la evidencia de la versión validada.

Siguiente paso: dibujar y probar cada centro

Empieza por una venta realista de cada sede y dibuja dos recorridos separados. Marca el punto exacto de expedición, el registro que nace, la cadena, la modalidad y el destino contable. Después corta la comunicación entre centros y repite la prueba. El resultado debe coincidir con el diagrama.

Para situar esta decisión en el marco general, consulta la guía madre sobre VERI*FACTU y sistemas de facturación para pymes y el hub de recursos fiscal-contables. Si uno de los centros pretende operar sin ningún programa, la guía sobre facturación manual y VERI*FACTU delimita ese caso distinto.

Si necesitas revisar la arquitectura, el servicio fiscal-contable de TaxFactory puede ayudar a inventariar sedes, SIF, modalidades y pruebas. La decisión final debe quedar documentada por versión: qué expide cada centro, qué ocurre cuando pierde conexión y cómo se concilia todo sin alterar los registros originales.