Programa contable sin facturación: ¿entra en VERI*FACTU?

La contabilidad suele estar al final de una cadena: recibe una venta ya documentada, crea el asiento y la relaciona con el cobro. VERI*FACTU obliga a mirar hacia atrás y localizar un instante anterior: aquel en el que los datos dejan de ser un pedido o un borrador y pasan a ser una factura expedida con su registro. Esa frontera, no el nombre del producto, decide qué aplicación debe analizarse como Sistema Informático de Facturación (SIF).

La pregunta se resuelve mirando la función real: un programa contable que no expide facturas no se convierte en un Sistema Informático de Facturación (SIF) solo porque se llame “programa de gestión” o porque reciba una exportación. La AEAT limita el RRSIF a los sistemas usados para expedir facturas. El Reglamento de los requisitos de los sistemas informáticos de facturación (RRSIF) mira el proceso real: qué aplicación admite los datos de facturación, dónde los conserva, cómo los procesa y, sobre todo, qué sistema se utiliza para expedir la factura. Consulta las preguntas frecuentes generales de la AEAT.

El mapa usa cuatro estados: pedido, factura preparada, factura expedida y registro generado. Sitúa cada interfaz entre dos estados para distinguir un destino contable de un componente que decide la expedición.

La conclusión concreta depende de la versión instalada, las funciones habilitadas y el recorrido efectivo de cada canal en territorio común español.

El punto de corte: antes o después de expedir

El artículo 1.2 del Real Decreto 1007/2023 define el SIF como un conjunto de hardware y software utilizado para expedir facturas mediante tres acciones: admitir información de facturación, conservarla y procesarla para producir resultados derivados. Consulta el artículo 1.2 en el texto consolidado del BOE. El procesamiento puede estar en el propio sistema o en otro sistema al que se remita la información. No se exige que todo esté instalado en el mismo ordenador ni que el producto se venda con la palabra “facturación” en la caja.

El mismo artículo incluye la factura completa y la factura simplificada. Por eso la pregunta no se resuelve diciendo que el programa solo hace tickets, recibos o documentos de caja. Si el documento es realmente una factura simplificada y el sistema la expide, entra en el análisis. Si solo es un justificante de entrega, un pedido, un albarán o un comprobante de cobro que no tiene la condición de factura, ese documento no activa el RRSIF por sí mismo. La FAQ de conceptos de la AEAT distingue las facturas de los demás documentos justificativos.

Hay una precisión que suele perderse en los diagramas: “procesar” no significa que cualquier suma o consulta transforme un software contable en SIF. La AEAT explica que el procesamiento relevante es el de la información capturada y conservada de las facturas para obtener productos derivados, como libros registro de IVA o IRPF, contabilidad u otros resultados utilizados para cumplir obligaciones tributarias. La AEAT detalla esta definición de procesamiento. Hay que analizar esa función en relación con el momento en el que se expide la factura, no como una etiqueta aislada en el menú.

Flujo A: contabilidad recibe el resultado cerrado

Imagina este recorrido: el comercio electrónico crea el pedido, el SIF emisor valida los datos, asigna serie y número, expide la factura, genera el registro de alta y lo remite o lo conserva según la modalidad elegida. Al final del proceso, una exportación estructurada llega al programa contable para crear el asiento de venta. Ese destino puede conciliar ventas y bancos, consultar el PDF y preparar informes sin convertirse por ello en el SIF que expidió.

La AEAT trata expresamente esta situación en su FAQ sobre trazabilidad: los registros generados por un SIF pueden enviarse después a otros sistemas para fines como contabilidad o gestión de existencias, y a esos sistemas destinatarios no se les exigen los requisitos propios del SIF por el hecho de recibirlos. La condición es importante: deben ser registros ya generados por el SIF emisor, no datos que el programa contable utiliza para cerrar la factura que todavía no existe.

La contabilidad debe comprobar que la factura corresponde a la operación, que el asiento no duplica la venta y que una rectificación llega con su referencia. Son controles del cierre; no convierten automáticamente al receptor en SIF.

Flujo B: contabilidad decide cómo se cierra la factura

El mismo producto puede tener un módulo contable que queda fuera y otro módulo que forma parte del SIF. Por ejemplo, el libro mayor posterior puede ser un destino, mientras que una pantalla de “factura de venta” con numeración, PDF, QR y botón de expedición controla la emisión. En ese caso el nombre del producto no sirve para separar responsabilidades. Hay que identificar la función que cumple cada módulo y el vínculo entre ellos.

La Orden HAC/1177/2024 llama componente de facturación al conjunto de hardware y software que implementa, dirige, gestiona o controla requisitos del Reglamento. Consulta la definición de componente en la Orden HAC/1177/2024. Define como componente principal el que implementa las funcionalidades necesarias para poder expedir facturas o dirige su implementación. Esta terminología permite documentar una arquitectura con ERP, TPV, servicio de facturación, conector y contabilidad sin fingir que cada icono es un SIF independiente.

Un módulo contable debe entrar en el mapa del SIF cuando hace alguna de estas cosas:

1. Permite cerrar una factura, emitirla al cliente o generar una factura simplificada desde sus pantallas.
2. Decide la serie o el número que identifica la factura y controla que la expedición avance.
3. Genera una rectificativa o una anulación como continuación de una factura expedida, en vez de registrar simplemente el documento que otro sistema ya creó.
4. Recibe la información de facturación antes de la expedición y la procesa para producir la factura, el registro de alta o una salida que dirige ese cierre.
5. Usa la información de las facturas expedidas para generar directamente libros registro, contabilidad u otros resultados tributarios cuando la propia herramienta también realiza las funciones de entrada, conservación y expedición.

La quinta situación necesita cuidado. La AEAT ofrece el ejemplo de una hoja de cálculo que, además de introducir, expedir, imprimir y conservar facturas, usa una macro para generar el libro registro de facturas expedidas. La FAQ de ámbitos de aplicación recoge este ejemplo: en ese caso considera la hoja un SIF. No significa que cualquier programa contable que importe un asiento posterior quede dentro. La misma FAQ distingue esta recepción posterior. El sistema que participa en la expedición no pasa a ser una simple base de datos porque el procesamiento se haya movido a otra pestaña.

Una interfaz no explica por sí sola el reparto de funciones

“Exporta a contabilidad” describe una conexión, no su calificación jurídica. Antes de decidir, pregunta qué se exporta, en qué momento y con qué efecto. Una exportación de registros ya cerrados no tiene el mismo significado que una exportación de datos que permite a la aplicación contable construir y expedir la factura.

Contrato de salida: factura y registro ya generados

Este es el caso más sencillo. Los registros de facturación ya generados por un SIF pueden transferirse posteriormente a otro sistema para llevar la contabilidad. La contabilidad crea asientos, libros internos, informes de márgenes o conciliaciones. La AEAT confirma que los registros pueden enviarse posteriormente a sistemas distintos, incluidos los de contabilidad. Como control interno, conviene conservar una referencia que permita relacionar la importación con la factura y revisar que el traspaso no altere sus datos; esta es una recomendación operativa, no una condición añadida a la FAQ.

Compruébalo con una factura de prueba: anota el momento de expedición y compara el registro del SIF, el fichero exportado y el asiento. Si la importación cambia base, IVA, serie o número, también hay un problema de conciliación.

Contrato de entrada: datos pendientes de facturar

Ahora cambia el punto de origen. Un CRM entrega cliente y líneas al programa contable; allí se calculan impuestos, se asigna serie, se crea el PDF y se marca “expedida”. El CRM puede ser una fuente auxiliar, pero el programa contable está implementando o dirigiendo funciones del SIF. La exportación inicial no lo convierte en un sistema receptor porque la factura aún no había sido expedida.

Lo mismo puede ocurrir con una aplicación que crea una factura preliminar, la manda a contabilidad para obtener el asiento y solo después devuelve el número definitivo al emisor. En ese diseño, la empresa debe decidir qué componente es principal y corregir el flujo si dos aplicaciones pueden cerrar la misma factura. La Orden exige identificar los componentes y sus funcionalidades en la declaración responsable del sistema; pedir esa documentación al proveedor ayuda a resolver la ambigüedad.

Contrato de transformación: libros y resultados fiscales

La tercera situación es un módulo que toma la información de facturas y genera directamente un libro registro de IVA, un libro de IRPF, la contabilidad o una salida preparada para una obligación tributaria. La FAQ de la AEAT sobre ámbitos utiliza precisamente esos resultados para explicar cuándo una hoja de cálculo deja de tener un uso limitado.

Exportar a un fichero CSV para que otra persona revise datos no equivale a generar automáticamente el libro fiscal con la información de facturación. La diferencia está en la función que ejecuta el sistema y en el momento del flujo en el que interviene. Documenta si el archivo es una copia fidedigna de registros ya cerrados, un listado de trabajo o el resultado que sustituye al registro y al libro.

Sigue una operación por sus cambios de estado

Haz tres preguntas.

1. Localiza el evento de expedición

¿Puede el usuario introducir una operación y obtener desde esa aplicación una factura completa o simplificada que se entrega al cliente? ¿Puede crear una factura rectificativa, una anulación o una nueva serie? ¿Aparecen un número, una fecha de expedición, un QR o una mención asociada al sistema? Si la respuesta es sí, la aplicación hace más que contabilizar. La AEAT explica que el RRSIF afecta a los sistemas utilizados para expedir facturas.

No te quedes en el botón “imprimir”. Un botón que genera un documento interno no es lo mismo que uno que expide una factura; una pantalla puede esconder el cierre detrás de una integración. Reproduce una venta en un entorno de prueba y conserva el registro técnico y el documento resultante, sin usar datos reales de clientes.

2. Separa el original de las copias contables

¿Dónde queda la información que el sistema usó para la factura? El artículo 1.2 permite conservarla dentro del sistema, sacarla a un soporte físico o remitirla a otro sistema. Esa amplitud técnica no elimina la necesidad de saber quién mantiene la copia que corresponde al SIF. Si el componente emisor exporta y después borra su copia, hay que revisar si la exportación es completa, legible y segura conforme a los requisitos aplicables.

El artículo 8 del Real Decreto 1007/2023 exige conservación, accesibilidad y legibilidad de los registros generados por el sistema. Consulta el artículo 8 en el texto consolidado del BOE. Para un programa contable que solo recibe datos, la prueba de alcance debe mostrar que no es el generador original. Para el SIF emisor, la prueba debe permitir localizar factura, registro, versión, fecha y estado de remisión o conservación.

3. Identifica quién transforma la información

¿Qué produce el sistema a partir de la información de facturación? Un asiento posterior, un informe de ventas o una consulta pueden ser salidas contables del sistema destinatario. Una función que calcula los datos definitivos de la factura, genera su registro o construye directamente el libro fiscal desde la herramienta emisora debe mapearse dentro del SIF. La FAQ de conceptos de la AEAT sitúa el procesamiento en los resultados derivados de la información capturada y guardada de las facturas.

Incluye en el mapa macros, tareas programadas, APIs y reglas de transformación aunque el proveedor no las llame “módulos”.

Diseña la arquitectura desde las responsabilidades

La normativa admite que intervengan varios programas o componentes. La FAQ técnica de la AEAT para desarrolladores describe arquitecturas mixtas con terminales, backoffice y componentes de fabricantes distintos, siempre que cumplan los requisitos y se documenten las responsabilidades.

Una arquitectura mixta bien definida tiene al menos cuatro capas:

• una fuente comercial, como un comercio electrónico, un CRM o un TPV, que recoge pedido o servicio;
• un componente principal que controla la expedición y genera el registro de facturación;
• un canal de remisión o conservación conforme con la modalidad elegida;
• un destino contable que recibe registros para asientos, conciliación y reporting.

Un mismo programa puede cubrir varias capas, y un TPV puede ser un componente del SIF central o un SIF separado si expide de forma autónoma. La AEAT explica que los registros se encadenan por cada SIF y obligado tributario. El diagrama debe coincidir con el comportamiento y no dejar dos puntos capaces de expedir la misma operación sin coordinación.

Si una gestoría emite las facturas en su propia plataforma y después las importa a tu programa contable, la plataforma de la gestoría es la que debe analizarse como SIF emisor. La delegación material no elimina la responsabilidad del obligado por las operaciones documentadas. El artículo 6 del Real Decreto 1007/2023 permite que el cumplimiento material lo realice un tercero, pero mantiene esa responsabilidad en quien realiza la entrega o presta el servicio.

Matriz de interfaces y decisiones

La matriz orienta, pero no resuelve sola. La evidencia debe describir el uso real y revisar cualquier función accesible que permita emitir después de la fecha de adaptación.

Caso de arquitectura: comercio electrónico, ERP y contabilidad

Supón que una empresa recibe pedidos en un comercio electrónico, los pasa a un ERP y desde allí crea el asiento. Si el ERP recibe una factura ya expedida, su trabajo empieza después del cierre: valida cliente, IVA y cobro, y envía el asiento. El PDF y el registro son evidencias del origen, no una nueva expedición.

Ahora cambia un detalle: el comercio electrónico solo envía el pedido y el ERP decide si la operación es facturable, asigna la serie, calcula los impuestos, crea la factura y devuelve el documento al cliente. Aunque el proveedor llame al módulo “contabilidad”, ese módulo dirige el momento en que la factura nace. La revisión debe incluirlo en el mapa del SIF y pedir la declaración de la versión que controla esa función. La definición de componente principal de la Orden HAC/1177/2024 ayuda a describir esta arquitectura.

Hay un tercer diseño: el ERP recibe facturas cerradas, pero transforma sus datos en el libro de facturas expedidas. Documenta fichero, regla, salida y si sustituye o complementa los registros. Sin una muestra explicable, no afirmes que la integración queda fuera.

El expediente técnico mínimo de la integración

Un expediente breve evita muchas discusiones. Para cada canal de venta, anota:

1. quién introduce el pedido, el servicio o la entrega;
2. qué aplicación asigna serie y número;
3. en qué punto se considera expedida la factura;
4. qué componente genera y encadena el registro;
5. si se remite a la AEAT o se conserva en modalidad no verificable;
6. qué copia recibe contabilidad y con qué identificador;
7. quién puede rectificar, anular o reintentar una operación;
8. qué proveedor responde de la versión y de sus componentes.

Después, prueba una factura ordinaria, una simplificada si existe, una rectificativa y una anulación o incidencia equivalente. No uses clientes reales. Conserva capturas de configuración, una exportación de prueba, el registro generado, la respuesta de la AEAT cuando proceda y el asiento contable. Así podrás explicar el recorrido meses después, aunque cambie la persona que implantó el software.

Solicita al proveedor la declaración responsable de la versión que realmente está instalada. La Orden HAC/1177/2024 exige que la declaración identifique el sistema, su versión, sus componentes y funcionalidades principales, además de indicar si puede utilizarse por varios obligados tributarios. No confundas una declaración de otra versión con una garantía para el despliegue actual. Si existe un módulo de facturación contratado aparte, pide su declaración y su relación con la contabilidad.

Modalidad y calendario pertenecen al componente emisor

VERIFACTU no es el nombre de toda la contabilidad ni una obligación que se active por instalar un ERP. Es una modalidad de cumplimiento de los requisitos del RRSIF para el sistema que expide facturas. En esa modalidad, el SIF remite los registros a la Sede electrónica de la AEAT inmediatamente después de producirlos. La alternativa NO VERIFACTU conserva los registros en el sistema emisor y añade controles como firma y registro de eventos. La AEAT describe las dos modalidades y sus diferencias.

El calendario vigente tampoco convierte a un sistema contable receptor en SIF. El Real Decreto-ley 15/2025 modificó la disposición final cuarta del Real Decreto 1007/2023: los contribuyentes del Impuesto sobre Sociedades del artículo 3.1.a deben tener adaptados sus sistemas antes del 1 de enero de 2027, y el resto de obligados del artículo 3.1 antes del 1 de julio de 2027. Consulta el Real Decreto-ley 15/2025 en el BOE. Son fechas para los obligados y sistemas dentro del perímetro; no una fecha universal para comprar un módulo contable.

Si la empresa usa un SIF emisor y un programa contable separado, prepara la adaptación del primero y comprueba la interfaz del segundo. Si el programa contable contiene un botón de expedición que se dejó de usar, revisa qué puede hacer realmente la versión instalada. Como recomendación operativa limitada, documenta el bloqueo de la expedición, los permisos, la fecha del cambio y el acceso al histórico. Ese expediente ayuda a explicar el alcance observado, pero no es una exigencia específica de acreditación atribuida a la AEAT ni garantiza por sí solo que el programa quede fuera del RRSIF. La calificación sigue dependiendo de las funciones y del uso efectivo descritos en las preguntas frecuentes generales sobre VERI*FACTU.

Lo que este mapa no resuelve

Quedar fuera del RRSIF como sistema contable receptor no elimina la obligación de emitir facturas correctamente cuando exista esa obligación. Tampoco sustituye las reglas de numeración, contenido, conservación, rectificación, IVA, IRPF, Impuesto sobre Sociedades o contabilidad que correspondan. El perímetro del software y el cumplimiento de la operación son dos preguntas distintas.

La remisión de un registro no garantiza que el precio, el cliente, el IVA o la fecha sean correctos. La contabilidad debe mantener el vínculo entre documentos y revisar el tratamiento que proceda.

Hay límites territoriales y subjetivos. El Reglamento se aplica en territorio español sin perjuicio de los regímenes forales y de especialidades de Canarias, Ceuta y Melilla. El artículo 3 incluye a distintos obligados y excluye a quienes llevan los libros registro de IVA por el SII en los términos previstos. La FAQ de ámbitos de la AEAT debe leerse junto con la situación de la empresa y la operación concreta.

Preguntas frecuentes

Si mi programa contable no emite facturas, ¿tengo que adaptarlo a VERI*FACTU?

No necesariamente. Si solo recibe registros ya generados por otro SIF y los usa para asientos, conciliación o informes, la AEAT lo trata como un sistema destinatario. Debes comprobar, aun así, que no haya una ruta alternativa de expedición, rectificación o anulación dentro del programa. La clasificación depende del uso real y de la versión instalada, no del nombre comercial.

¿Una exportación de facturas a contabilidad convierte al receptor en SIF?

No por sí sola. La exportación posterior de registros producidos por el SIF emisor puede llegar a un sistema de contabilidad sin que a este se le exijan los requisitos propios del SIF. La respuesta cambia si el receptor calcula los datos definitivos, genera la factura o produce el registro antes del cierre de la expedición. La FAQ de trazabilidad de la AEAT explica esta diferencia.

¿Y si el módulo contable genera el libro de IVA?

Hay que separar dos casos. Si recibe registros cerrados y crea un informe contable posterior, actúa como destino. Si la herramienta que expide también procesa la información para generar directamente libros de IVA, IRPF, contabilidad u otros resultados tributarios, la AEAT considera ese procesamiento en el análisis del SIF. Una macro o automatización puede ser relevante aunque no tenga el nombre “facturación”.

¿Quién responde si factura la gestoría y yo solo llevo la contabilidad?

La gestoría puede realizar materialmente el cumplimiento si tiene las facultades y la condición que exige el Reglamento, pero la delegación no borra la responsabilidad del obligado que realiza la entrega o presta el servicio. Deja por escrito qué plataforma expide, qué versión usa, cómo se conserva el registro y cómo recibirás rectificativas e incidencias. No des por hecho que el programa contable es el sistema emisor solo porque la gestoría te envíe después un asiento.

¿Puedo mantener un programa antiguo solo para consultar el histórico?

La norma no convierte por sí sola una base histórica en un SIF activo: hay que comprobar las funciones que conserva la versión instalada y su uso real. Como recomendación operativa, documenta si la expedición está deshabilitada, qué permisos quedan y cómo se consulta o exporta el histórico. Esta cautela ayuda a describir el alcance, pero no es una exigencia específica de acreditación atribuida a la AEAT ni sustituye la revisión del caso.

Próximo paso: valida el contrato de cada interfaz

Empieza con una factura reciente y síguela desde el pedido hasta el asiento: aplicación que recoge los datos, componente que decide serie y número, momento de expedición, registro generado, remisión o conservación y copia que recibe contabilidad. Repite la prueba con una rectificativa y con el canal que menos se utiliza. Ahí suelen aparecer módulos olvidados y rutas duplicadas.

El hub de recursos fiscal-contables reúne más guías y la página sobre VERI*FACTU y sistemas de facturación para pymes explica el marco general. Para ordenar tu caso, el servicio fiscal-contable de TaxFactory puede revisar el perímetro de facturación, la conciliación con contabilidad y la documentación de la versión instalada. La guía sobre VERI*FACTU con varios programas y TPV explica cómo separar varios emisores. Si la contabilidad está integrada con un desarrollo propio, la página sobre software a medida e integraciones VERI*FACTU ayuda a preparar el inventario técnico.

Para delimitar otras configuraciones, revisa la guía de VERI*FACTU para sociedades con software de facturación y la alternativa de facturación manual sin programa.

La decisión final debería quedar en una ficha sencilla: “este componente expide”, “este componente conserva o remite”, “este sistema solo recibe registros” y “estas funciones están bloqueadas o fuera de alcance”. Si la ficha no coincide con lo que puede hacer el software en una prueba, todavía no hay una separación fiable.