VERI*FACTU en empresas con procesos complejos: cuando facturar es solo una parte del sistema
VERI*FACTU en empresas con procesos complejos: cuando facturar es solo una parte del sistema
Cuando una empresa se plantea adaptar sus sistemas a VERI*FACTU, la primera pregunta suele centrarse en el software de facturación: ¿puede mi programa emitir las facturas conforme a los nuevos requisitos?
En una empresa con una operativa sencilla, esa pregunta puede acercarse bastante al problema que hay que resolver. Pero cuando la facturación forma parte de procesos comerciales, administrativos y operativos más amplios, conviene ampliar el foco.
Una factura puede ser el resultado final de información que ha pasado previamente por pedidos, entregas, contratos, suscripciones, almacenes, devoluciones o diferentes aplicaciones. Puede haber sido preparada por distintos departamentos y utilizar datos procedentes de un ERP, un CRM, un ecommerce o una aplicación sectorial.
Por eso, cuanto más integrada esté la facturación en la operativa de una empresa, menos sentido tiene abordar VERI*FACTU como un cambio aislado del programa que finalmente emite la factura.
La cuestión pasa a ser otra: ¿qué procesos y qué sistemas intervienen realmente hasta que se expide esa factura?
VERI*FACTU afecta al sistema que soporta el proceso de facturación
VERI*FACTU afecta al sistema que soporta el proceso de facturación
Conviene empezar haciendo una precisión. Aunque habitualmente se utiliza VERI*FACTU para referirse de forma general a esta nueva regulación, la propia Agencia Tributaria señala que se trata de una denominación coloquial. El Real Decreto 1007/2023 regula los requisitos que deben cumplir determinados sistemas informáticos de facturación (SIF).
La norma establece requisitos para garantizar, entre otros aspectos, la integridad, conservación, accesibilidad, legibilidad, trazabilidad e inalterabilidad de los registros de facturación. Además, considera sistema informático de facturación al conjunto de hardware y software utilizado para expedir facturas que admite la entrada de información de facturación, la conservación y el procesamiento para producir los resultados correspondientes.
Los sistemas incluidos en el ámbito de aplicación pueden cumplir el reglamento mediante dos modalidades: VERI*FACTU, con remisión de los registros de facturación a la Agencia Tributaria, o mediante un sistema no VERI*FACTU, de emisión de facturas no verificables, que debe conservar esos registros y cumplir los requisitos adicionales establecidos para esta modalidad.
Por tanto, no estamos únicamente ante un cambio en la apariencia de una factura. Hay requisitos que afectan al sistema informático utilizado para soportar su expedición y a los registros que genera.
A fecha de publicación de este artículo, y tras la ampliación de plazos aprobada en diciembre de 2025, los contribuyentes del Impuesto sobre Sociedades incluidos en el ámbito de aplicación deben tener adaptados sus sistemas antes del 1 de enero de 2027. Para el resto de obligados incluidos en el artículo 3.1 del reglamento, la fecha es el 1 de julio de 2027.
Estas obligaciones no deben confundirse con la futura factura electrónica B2B, que responde a una regulación diferente. Si quieres situar ambas iniciativas dentro del proceso más amplio de digitalización fiscal, puedes consultar nuestro artículo sobre VERI*FACTU, factura electrónica y ViDA y el papel del software de gestión.
También es importante comprobar primero si la empresa está dentro del ámbito de aplicación: por ejemplo, los contribuyentes que llevan sus libros registro mediante el Suministro Inmediato de Información (SII) están excluidos del RRSIF en relación con su facturación propia.
¿Qué significa que una empresa tenga un proceso de facturación complejo?
¿Qué significa que una empresa tenga un proceso de facturación complejo?
No existe un único modelo.
En algunas empresas, la persona responsable introduce los datos directamente en una aplicación y genera la factura. En otras, la emisión es únicamente el último paso de un proceso mucho más largo.
Pensemos en un ejemplo hipotético:
pedido → preparación → albarán → factura
Los datos utilizados para facturar no aparecen de repente en el último paso. Parte de la información puede haberse generado cuando se registró el pedido, otra puede proceder de las condiciones comerciales del cliente y otra puede depender de las cantidades que finalmente se hayan entregado.
El circuito puede complicarse todavía más si existen devoluciones, varios almacenes, diferentes centros de trabajo, contratos recurrentes, suscripciones o distintas líneas de negocio.
Nada de esto significa que VERI*FACTU imponga requisitos específicos a un pedido o un albarán por el mero hecho de existir. La obligación normativa se refiere a los sistemas informáticos de facturación incluidos en su ámbito y a los registros de facturación.
La importancia de analizar las fases anteriores es operativa: permiten comprender de dónde proceden los datos que terminarán utilizando los sistemas que intervienen en la facturación.
¿De dónde proceden los datos que utiliza el sistema de facturación?
¿De dónde proceden los datos que utiliza el sistema de facturación?
En una empresa mediana, Administración puede ser el departamento que finalmente factura, pero eso no significa necesariamente que genere toda la información utilizada en la factura.
Ventas puede haber establecido las condiciones comerciales.
Operaciones puede confirmar que un servicio se ha realizado.
Almacén puede registrar la mercancía expedida.
Un ecommerce puede originar un pedido.
Un CRM puede contener determinados datos del cliente.
Una aplicación especializada puede gestionar una operación propia del sector que posteriormente debe trasladarse al sistema de gestión.
Son ejemplos, no una arquitectura universal. Cada empresa organiza de forma distinta sus procesos y sistemas.
Lo relevante para abordar VERI*FACTU es identificar cómo llega la información hasta el punto en el que se produce la expedición de la factura y qué sistema o sistemas intervienen realmente en ese proceso.
De hecho, la definición reglamentaria de SIF no se limita a una aplicación con un botón para imprimir una factura. El Real Decreto contempla la entrada, conservación y procesamiento de la información de facturación, incluso cuando determinada información se remite a otro sistema para su procesamiento.
Esto hace especialmente importante no identificar automáticamente «sistema de facturación» con «pantalla desde la que Administración genera la factura».
ERP, CRM, ecommerce y aplicaciones sectoriales: ¿qué sistemas intervienen realmente?
ERP, CRM, ecommerce y aplicaciones sectoriales: ¿qué sistemas intervienen realmente?
Una empresa puede utilizar un único ERP para centralizar gran parte de su actividad o trabajar con varias aplicaciones conectadas.
Por ejemplo, podría existir un circuito hipotético en el que:
ecommerce → ERP → facturación
o:
CRM → ERP → facturación
También puede haber aplicaciones sectoriales que gestionen procesos específicos y transfieran después información al ERP.
La existencia de estas conexiones no significa que VERI*FACTU convierta automáticamente cada una de esas aplicaciones en un sistema informático de facturación. Determinar qué componentes tienen esa consideración exige analizar su función real dentro del proceso y contrastarla con la definición y los requisitos establecidos por el RRSIF.
La pregunta técnica, por tanto, no debería formularse únicamente como:
«¿Qué programa imprime la factura?»
Conviene reconstruir el flujo:
¿Dónde se origina la operación? ¿Dónde se introducen o modifican los datos de facturación? ¿Qué aplicaciones los procesan? ¿Cuál expide finalmente la factura?
Responder a esas preguntas permite dibujar la arquitectura real antes de decidir qué debe adaptarse.
¿Qué ocurre cuando los sistemas están integrados?
¿Qué ocurre cuando los sistemas están integrados?
Las integraciones merecen una atención especial porque pueden hacer menos evidente dónde empieza y termina el sistema que soporta la facturación.
Imaginemos que un pedido se crea en una aplicación comercial, pasa automáticamente a un ERP y desde allí termina generando una factura.
Desde una perspectiva empresarial, no basta con saber que el último sistema es capaz de producir un determinado documento. Conviene entender qué información recibe, qué transformaciones se producen y qué componente asume cada función dentro del proceso.
Esto es una recomendación técnica, no una obligación adicional impuesta por VERI*FACTU.
Sin embargo, la propia Agencia Tributaria plantea escenarios en los que diferentes módulos de un ERP emiten facturas. Su criterio distingue entre módulos interconectados dentro de un sistema centralizado y módulos inconexos o parcialmente inconexos que podrían llegar a considerarse SIF diferentes.
Por tanto, en arquitecturas empresariales complejas, la forma en que están conectadas las aplicaciones puede ser relevante para determinar cómo está configurado realmente el sistema de facturación.
Este problema merece un análisis específico y será objeto de otro artículo dedicado a VERI*FACTU, ERP e integraciones.
Una empresa puede tener más de un circuito de facturación
Una empresa puede tener más de un circuito de facturación
La complejidad tampoco procede únicamente del número de aplicaciones.
Una misma empresa puede tener distintas líneas de negocio o procesos que terminan generando facturas por caminos diferentes.
Por ejemplo, puede existir un circuito para operaciones recurrentes y otro para ventas puntuales. Una línea de negocio puede estar gestionada desde un sistema central y otra utilizar una aplicación distinta. También pueden existir varios centros con sistemas separados.
Aquí aparece una cuestión importante: tener varios sistemas de facturación no está prohibido por el RRSIF.
La Agencia Tributaria indica expresamente que un obligado puede disponer de varios SIF cuando sus necesidades empresariales lo justifiquen, citando como ejemplos varios centros de negocio no interconectados o líneas de producto diferenciadas. Cada uno de esos sistemas deberá cumplir los requisitos que le correspondan.
Esto refuerza la necesidad de realizar un inventario previo.
Antes de hablar de «adaptar el programa», puede ser necesario responder a una pregunta anterior:
¿Cuántos procesos y sistemas de facturación tiene realmente la empresa?
La respuesta no siempre coincide con el número de aplicaciones instaladas ni con el número de departamentos que intervienen.
¿Qué debería revisar una empresa antes de adaptar sus sistemas a VERI*FACTU?
¿Qué debería revisar una empresa antes de adaptar sus sistemas a VERI*FACTU?
Para una empresa con procesos complejos, una buena práctica consiste en mapear primero el proceso de facturación de extremo a extremo.
No porque VERI*FACTU obligue expresamente a elaborar ese mapa, sino porque resulta difícil evaluar una arquitectura compleja sin saber cómo funciona.
El análisis puede comenzar con algunas preguntas concretas:
¿Qué operaciones terminan generando una factura?
Identificar las distintas líneas de negocio y tipos de operaciones que desembocan en facturación.
¿Dónde se originan los datos?
Determinar qué aplicaciones y departamentos introducen información que posteriormente se utiliza para facturar.
¿Qué documentos aparecen antes de la factura?
Pedidos, albaranes, contratos, devoluciones u otros documentos pueden formar parte del circuito empresarial, aunque no por ello estén sometidos individualmente a VERI*FACTU.
¿Qué aplicación expide finalmente cada factura?
No dar por supuesto que todas las facturas salen del mismo sistema.
¿Existen integraciones entre aplicaciones?
Identificar qué información se intercambia, en qué dirección y en qué momento.
¿Hay varios módulos, centros o sistemas capaces de facturar?
La AEAT contempla expresamente la posibilidad de que existan varios SIF y también analiza el supuesto de varios módulos de un ERP que emiten facturas.
¿Qué ocurre cuando una operación cambia después de haberse facturado?
Conviene identificar cómo se gestionan actualmente anulaciones, rectificaciones, devoluciones y otros cambios que puedan afectar a operaciones ya facturadas, para posteriormente comprobar su tratamiento conforme a la normativa aplicable.
El resultado debería ser una representación suficientemente clara de:
operación → datos → sistemas → factura
Solo después tiene sentido decidir qué componentes necesitan adaptación y cómo debe abordarse técnicamente.
VERI*FACTU puede ser un proyecto de sistemas, no solo de facturación
VERI*FACTU puede ser un proyecto de sistemas, no solo de facturación
Para Administración, el cambio es visible en el proceso de facturación.
Para IT, sin embargo, puede requerir comprender la arquitectura que hay detrás.
Y para Operaciones, puede ser necesario identificar qué procesos alimentan esa arquitectura.
Esa diferencia de perspectiva es importante.
VERI*FACTU no obliga por sí mismo a una empresa a rediseñar su ERP, sustituir su CRM o modificar todos sus procesos comerciales. Tampoco significa que cualquier aplicación conectada con la facturación esté automáticamente sometida a todos los requisitos del RRSIF.
Pero sí hace necesario que los sistemas informáticos de facturación incluidos en su ámbito cumplan los requisitos establecidos por la normativa.
Y cuanto más distribuido esté el proceso entre departamentos, módulos y aplicaciones, más importante resulta saber exactamente cuál es ese sistema y cómo se relaciona con el resto de la operativa.
Ahí está la diferencia entre abordar VERI*FACTU como una actualización aislada y abordarlo como un proyecto dentro del sistema de gestión empresarial.
Integrar la facturación dentro del sistema de gestión empresarial
Integrar la facturación dentro del sistema de gestión empresarial
Esta visión integrada forma parte también del planteamiento con el que funciona Merkurio ERP.
Merkurio ERP no se limita a la emisión de facturas. Contempla procesos de gestión empresarial, finanzas, compras, ventas, fabricación, inventario y distribución. También permite trabajar con circuitos de compras y ventas y centralizar documentos administrativos como presupuestos, pedidos, albaranes y facturas.
Esta amplitud funcional resulta relevante al analizar VERI*FACTU porque permite entender la facturación dentro de los procesos que la preceden y no únicamente como la generación de un documento final.
La adaptación concreta de cada empresa, no obstante, debe partir de su propia arquitectura, sus circuitos y las obligaciones que efectivamente le resulten aplicables.
Antes de adaptar VERI*FACTU, hay que saber cómo factura realmente la empresa
Antes de adaptar VERI*FACTU, hay que saber cómo factura realmente la empresa
En una organización donde la factura es el último paso de una cadena de operaciones, centrarse únicamente en el documento final puede dejar fuera una parte importante del problema.
El punto de partida debería ser conocer:
qué procesos generan la información, qué sistemas la intercambian y qué sistema o sistemas terminan expidiendo las facturas.
A partir de ahí puede determinarse qué componentes están afectados, cómo encajan los requisitos del RRSIF en la arquitectura existente y qué adaptación tecnológica resulta adecuada.
En Grupo Dana trabajamos con sistemas de gestión que abarcan procesos empresariales más amplios que la propia facturación.
Si quieres analizar cómo puede afectar VERI*FACTU a los sistemas y circuitos concretos de tu empresa, puedes contactar con nuestro equipo para revisar tu escenario.
No esperes más, adelántate al cambio y convierte los cambios en la normativa en una ventaja competitiva. Solicita más información sobre Merkurio ERP ahora.
No esperes más, adelántate al cambio y convierte los cambios en la normativa en una ventaja competitiva. Solicita más información sobre Merkurio ERP ahora.
No esperes más, adelántate al cambio y convierte los cambios en la normativa en una ventaja competitiva. Solicita más información sobre Merkurio ERP ahora.
Otras noticias relevantes...
