VERI*FACTU con varios programas, TPV o ERP

Varios programas no obligan a fabricar una sola cadena

Una empresa puede utilizar varios SIF, pero cada uno debe cumplir y encadenar sus registros de forma independiente. fuente oficial. La AEAT explica que un TPV que expide sus facturas con autonomía respecto de los demás es un SIF. Cada sistema mantiene su cadena para cada obligado tributario cuya facturación gestiona.

Esta regla evita una integración artificial. Dos tiendas desconectadas no necesitan consultar la huella del último registro generado en la otra antes de vender. Cada SIF encadena según su propio orden de generación. fuente oficial. La empresa puede tener tantas cadenas como puntos de expedición realmente independientes.

No deduzcas de ahí que cualquier módulo es un SIF. Un terminal que captura el pedido y lo envía al ERP, donde se expide la factura y se genera el registro, puede ser un componente del mismo sistema. Un TPV que asigna número, cierra la factura, genera QR y produce su registro funciona de otro modo. El análisis sigue responsabilidades y datos, no iconos del menú.

Primer paso: localizar la expedición

Recomendación editorial: dibuja todos los puntos de expedición, delimita cada SIF, asigna series y prueba la conciliación extremo a extremo. criterio derivado. Recorre ventas de mostrador, comercio electrónico, facturación recurrente, ERP, servicios técnicos, aplicaciones móviles y facturas creadas por la gestoría.

Para cada flujo responde:

1. ¿Dónde entra la información?
2. ¿Quién asigna serie y número?
3. ¿Qué acción convierte el borrador en factura expedida?
4. ¿Dónde se genera el registro de alta?
5. ¿Qué componente calcula la huella y el QR?
6. ¿Quién remite o conserva el registro?
7. ¿Dónde se corrige y anula?
8. ¿Qué declaración responsable cubre la versión y sus componentes?

El punto de expedición es más preciso que el punto de impresión. Una factura puede imprimirse en tienda y haberse expedido en un servicio central. También puede expedirse en un TPV y copiarse después al ERP. En el primer caso puede existir una cadena central; en el segundo, una cadena del TPV y una integración contable posterior.

La unidad técnica: SIF por obligado

La AEAT sitúa una cadena de registros por cada pareja distinta de SIF y obligado tributario. fuente oficial. Si tres TPV independientes facturan para una sociedad, hay tres cadenas. Si una aplicación de gestoría factura para veinte clientes, necesita una cadena separada por cada cliente dentro de ese SIF.

La Orden HAC/1177/2024 exige que un sistema multiobligado gestione por separado registros de facturación y, en su caso, de evento; genere cadenas independientes; permita VERI*FACTU de manera independiente y muestre claramente para qué obligado se opera. fuente oficial. Una simple columna de NIF en una cadena común no cumple esa separación.

El identificador de instalación forma parte del diseño. No lo improvises al desplegar. El proveedor debe explicar cómo identifica una instalación, qué sucede al clonar una máquina, restaurar una copia o sustituir un terminal. Dos equipos clonados con la misma identidad pueden confundir registros y soporte.

ERP y TPV: cuatro arquitecturas habituales

En una arquitectura central, los TPV capturan ventas y el ERP expide. El ERP o su componente principal genera registro, cadena, QR y remisión. Los terminales pueden seguir operando como interfaces, pero la contingencia debe decidir qué ocurre si pierden comunicación: no pueden afirmar que expidieron si el sistema central no completó el cierre.

En una arquitectura distribuida, cada TPV expide. Cada uno es SIF, mantiene cadena y resuelve remisión o conservación. El ERP recibe después la información para contabilidad y control. Esta opción tolera mejor la autonomía de centros, pero multiplica versiones, certificados, declaraciones, monitorización y reconciliaciones.

En un modelo híbrido, algunas líneas expiden en ERP y otras en TPV. Puede ser correcto si la separación responde a operaciones reales y las series son inequívocas. Es peligroso si el usuario puede elegir cualquiera para la misma venta. La interfaz debe impedir la doble expedición y hacer visible qué sistema cerró la factura.

En un modelo de servicio común, varias aplicaciones invocan un componente de facturación. La declaración responsable debe describir componentes y productor; si varios fabricantes intervienen, la Orden exige declaraciones de las ampliaciones y componentes en sus versiones. fuente oficial. El contrato debe decir quién dirige el cumplimiento del conjunto.

Series: una decisión de control, no de huella

Las cadenas independientes no sustituyen la numeración de facturas. Asigna series por establecimiento, canal o sistema cuando exista una razón y el Reglamento de facturación lo permita. La serie debe ayudar a saber qué SIF expidió el documento. Evita que dos sistemas puedan emitir la misma combinación de serie y número.

Una secuencia de facturas y una cadena de registros no son lo mismo. La cadena sigue el orden en que el SIF genera registros, que puede incluir altas y anulaciones según su diseño. La numeración sigue las reglas de la factura. No intentes hacer coincidir ambos conceptos mediante integraciones innecesarias.

Documenta el último número antes de migrar un centro, el primero después, la fecha de corte y los documentos pendientes. Si un TPV se sustituye, decide si el nuevo despliegue es la misma instalación actualizada o una nueva. La respuesta debe apoyarse en la declaración responsable y en el diseño del proveedor, no solo en mantener el nombre de la caja.

¿Todos VERI*FACTU o mezcla de modalidades?

La AEAT admite que dos SIF independientes de la misma empresa usen modalidades distintas. Un centro puede remitir como VERI*FACTU y otro conservar como sistema no verificable. La Agencia añade que no es la opción preferible: los listados disponibles en sede serían incompletos y podría necesitar requerimientos para completar la información. fuente oficial

No mezcles por comodidad del proveedor. Compara conectividad, firma, eventos, conservación, exportación y soporte en cada instalación. Si un centro aislado justifica NO VERI*FACTU, registra esa razón, los controles de reloj, custodia y requerimientos, y una fecha de revisión.

Una política uniforme simplifica formación, soporte y conciliación. Una excepción puede ser válida, pero debe ser visible. Los responsables de fiscalidad no deberían descubrirla porque faltan facturas en la consulta de registros remitidos.

Fallos de conexión y operación desconectada

En VERI*FACTU, la cola de envío forma parte del sistema. La Orden regula el control de flujo y las respuestas de aceptación o error. fuente oficial. Pregunta cuánto puede facturar un terminal sin red, cómo protege la cola, cuándo reintenta y qué ve el operador.

No permitas una “contingencia” que cree la misma factura de nuevo en otro sistema. Si el centro cambia a talonario manual o a un SIF alternativo, necesita serie, criterio de activación y reconciliación. Al recuperar conexión, no se deben registrar como nuevas las ventas ya expedidas por otra vía.

Para sistemas no verificables, la desconexión ordinaria no elimina la capacidad de remisión. Deben poder comunicarse con la AEAT y enviar registros en respuesta a requerimiento. Añade pruebas de exportación, certificado y precisión horaria.

Integración contable sin duplicar expedición

El ERP puede recibir las facturas de varios SIF para contabilizar. La FAQ señala que la trazabilidad reglamentaria se limita al ámbito del propio SIF y no exige rastrear el intercambio posterior de sus registros con otros sistemas. fuente oficial. Aun así, la empresa necesita una pista de auditoría para cuadrar ventas y cuentas.

Importa facturas como documentos ya expedidos. El ERP no debe generar un segundo registro de alta por el mismo documento si no es el SIF que expide. Conserva identificador de origen, serie, número, fecha, NIF, importe y estado de envío. Si la contabilidad transforma datos, registra reglas y diferencias.

Diseña una conciliación diaria o periódica por sistema: número de facturas, bases, cuotas, anulaciones, rectificativas, rechazos y cobros. No basta con que el total de caja coincida. Un duplicado y una omisión del mismo importe se neutralizan en el total.

Una matriz de responsabilidad por SIF

Completa una ficha por SIF y una por obligado en sistemas multiempresa. La matriz detecta huecos: un TPV sin productor identificado, un plugin que genera facturas fuera del ERP o una gestoría que usa la misma sesión para varios clientes.

Pruebas antes de aceptar la arquitectura

Centralizar conviene cuando existe un único punto real de expedición; separar encaja cuando los centros expiden de manera autónoma. criterio derivado. Valídalo con pruebas en tres capas.

Primero, prueba cada SIF aislado: alta, rectificación, anulación, caída, rechazo, cambio de certificado y cierre. Segundo, prueba el conjunto: dos centros facturan a la vez, el ERP importa y la conciliación detecta una factura omitida. Tercero, prueba el cambio: actualiza una versión, sustituye un terminal y recupera una copia.

Lee las declaraciones responsables de todas las versiones. Si hay componentes de fabricantes diferentes, reúne sus documentos. Confirma que la descripción coincide con la arquitectura desplegada. Una declaración de una edición monopuesto no cubre necesariamente una instalación distribuida modificada por terceros.

Errores de diseño frecuentes

El primero es ordenar una cadena global por miedo a que haya saltos. Crea dependencia entre tiendas sin que la AEAT la exija. El segundo es el contrario: llamar SIF a cada pantalla y multiplicar cadenas cuando todas dependen de un componente central de expedición.

El tercero consiste en usar la misma serie en sistemas alternativos. El cuarto, contabilizar una importación como si fuera una nueva expedición. El quinto, mezclar modalidades sin informar al equipo fiscal. El sexto, restaurar una imagen de terminal sin revisar identidad, registros pendientes y cadena.

Otro error aparece en grupos de sociedades: confundir establecimientos de una misma entidad con obligados distintos, o compartir una cadena entre NIF. La unidad de cadena por SIF y obligado resuelve ambos extremos.

El calendario no cambia la arquitectura

Los plazos vigentes son antes del 1 de enero de 2027 para el colectivo del artículo 3.1.a) y antes del 1 de julio de 2027 para los restantes obligados del artículo 3.1. fuente oficial. A 17 de julio de 2026 queda tiempo desigual, pero un inventario distribuido necesita pruebas más largas que una aplicación única.

No esperes a instalar para descubrir cuántos SIF existen. El inventario condiciona licencias, certificados, redes, series y formación. Un proveedor puede afirmar que su ERP está adaptado sin conocer los TPV que expiden fuera de él.

Esta guía aplica al marco estatal común y no analiza sistemas forales ni exclusiones como SII. Tampoco decide qué series son obligatorias en cada operación. Esas cuestiones deben revisarse junto con la arquitectura.

Gobierno de versiones en una red de terminales

Mantén un inventario automático o revisado de versión, instalación, declaración y certificado. Un despliegue parcial puede dejar tiendas con comportamientos distintos. Define una ventana, prueba de humo y reversión que no restaure registros antiguos sobre ventas nuevas.

Antes de actualizar, vacía o identifica colas pendientes. Después, expide una prueba controlada, comprueba QR, remisión y conciliación. Guarda la relación entre versión y periodos. Si un terminal se queda atrás, registra excepción y riesgo.

Los plugins de pago, comercio electrónico o fidelización pueden modificar datos antes del cierre. Inclúyelos en el mapa y en la revisión de componentes. Una actualización de terceros también puede exigir nueva declaración o prueba del conjunto.

Conciliación que detecta diferencias reales

Por cada SIF extrae recuento, series, bases, cuotas, totales, rectificativas, anulaciones y estados. Agrega después por obligado. Compara con ventas, cobros y asientos. Investiga diferencias por identidad de factura, no ajustando un total manual.

Una conciliación útil conserva el detalle de duplicados, ausentes, importe distinto y estado pendiente. Asigna responsable y fecha. Los rechazos de remisión no deben desaparecer del informe porque la venta está contabilizada.

En multiobligado, ejecuta la conciliación por NIF antes de consolidar grupo. Evita compensar un error de una sociedad con una operación de otra.

Plan de contingencia por centro

Clasifica incidentes: caída del terminal, red local, internet, servicio central, certificado o AEAT. Para cada uno define si se puede seguir facturando, con qué serie y quién autoriza. Prohíbe soluciones improvisadas como repetir la venta en el ERP.

Si existe un SIF de contingencia, trátalo como tal: declaración, modalidad, cadena, serie, pruebas y conciliación. Si se usan facturas manuales conforme a las reglas aplicables, documenta incorporación contable sin inventar registros retrospectivos fuera del procedimiento.

Prueba la recuperación en un día tranquilo. Una guía no ensayada no protege una tienda abierta. Mide cuánto tarda y qué información necesita soporte.

Migrar de arquitectura distribuida a central

El cambio requiere fecha de corte por centro. Cierra colas, conserva cadenas, anota último número y desactiva la capacidad de expedir en el sistema antiguo. El nuevo servicio comienza según su identidad y diseño; no intenta reconstruir una única cadena histórica.

Importa clientes y productos como datos maestros. Las facturas históricas entran en el ERP como documentos ya expedidos, no como altas nuevas. Mantén acceso al sistema anterior durante conservación y soporte.

Haz el recorrido inverso si una centralización no soporta centros desconectados. La arquitectura debe reflejar autonomía real, no una preferencia estética. Documenta la razón para que una integración futura no vuelva a crear dependencia accidental.

Quién debe aprobar el mapa

Operaciones confirma qué terminal cierra ventas. Tecnología identifica componentes y conexiones. Fiscalidad revisa obligado, series y casos. Contabilidad verifica importación. Seguridad revisa certificados y accesos. Cada área firma hechos concretos; ninguna puede aprobar sola el conjunto.

El responsable final conserva el inventario y convoca revisión al abrir un centro, adquirir una empresa o cambiar de ERP. Una franquicia o grupo necesita aclarar si los NIF y productores son distintos.

La documentación no tiene que ser extensa: diagrama, fichas, matriz de responsabilidad, pruebas y conciliación. Debe estar actualizada y localizarse durante una incidencia.

Añade un registro de decisiones. Si se considera que dos aplicaciones forman un solo SIF, explica el componente principal y el momento de expedición. Si se tratan como independientes, identifica cadenas y series. Registra también alternativas descartadas. Esta breve historia impide que un cambio de equipo revierta una decisión sin conocer su causa.

Revisa el mapa con una factura de devolución, una venta iniciada en web y terminada en tienda y una operación emitida por la gestoría. Los recorridos cruzados encuentran límites que no aparecen en la venta ordinaria. Cada excepción debe terminar en un único sistema de expedición y una sola identidad de factura.

Elige una venta de cada canal y síguela. Debes poder señalar el SIF que expidió, su cadena, la respuesta o conservación, la serie, el documento entregado y el asiento final. Después provoca una rectificación y comprueba que todos los sistemas muestran el mismo resultado sin crear otro alta original.

La independencia reglamentaria de las cadenas no elimina la obligación empresarial de controlar numeración, ventas y contabilidad conjunta. criterio derivado. La guía de VERI*FACTU para pymes resume el marco. Para convertir el mapa técnico en un plan fiscal y de transición, revisa el servicio fiscal-contable de TaxFactory. El objetivo no es reducir el número de cadenas, sino saber exactamente qué acredita cada una.

Preguntas frecuentes

¿Cada TPV necesita su propia cadena de registros?

Si cada TPV expide o gestiona sus facturas de forma independiente, la AEAT lo considera un SIF y debe mantener su propia cadena por obligado tributario.

¿El ERP y el TPV son siempre dos SIF?

No. Depende de quién expide y controla la generación del registro. Si el TPV solo captura datos y el ERP expide, puede existir un único SIF compuesto. Si ambos expiden independientemente, son dos SIF.

¿Todos los programas deben usar VERI*FACTU?

La AEAT admite que SIF independientes usen modalidades diferentes. No lo considera preferible porque los listados de sede quedarían incompletos y podrían requerir información adicional.

¿Una gestoría puede facturar para varios clientes en un sistema?

Sí, si separa la gestión y las cadenas por cada obligado, muestra claramente para quién se opera y permite elegir la modalidad de forma independiente para cada uno.

¿Cómo se evita duplicar facturas entre sistemas?

Deben asignarse series, funciones y responsables por SIF, bloquear rutas alternativas y conciliar periódicamente facturas, registros, cobros y contabilidad.