ERP y VERI*FACTU: qué revisar cuando la facturación está conectada con otros sistemas
ERP y VERI*FACTU: qué revisar cuando la facturación está conectada con otros sistemas
El ERP puede ser el sistema desde el que se expide una factura, pero los datos necesarios para generarla no tienen por qué haberse originado allí.
Un pedido puede llegar desde un ecommerce. Determinados datos comerciales pueden proceder de un CRM. Una aplicación sectorial puede iniciar una operación que posteriormente continúa en el ERP. Y, en arquitecturas más complejas, distintos componentes pueden encargarse de diferentes funciones relacionadas con la facturación.
Esto plantea una cuestión importante al preparar un ERP para VERI*FACTU: no basta con identificar qué aplicaciones están conectadas. Hay que entender qué función desempeña cada una dentro del proceso de facturación.
La propia Agencia Tributaria contempla arquitecturas de sistemas informáticos de facturación formadas por varios componentes e incluso por programas de distintos fabricantes. Por tanto, el problema no consiste necesariamente en conseguir que «todo pase por una única aplicación», sino en determinar correctamente qué componentes participan en la facturación y cómo se relacionan entre sí.
Si necesitas una visión más general sobre por qué VERIFACTU puede afectar a procesos empresariales más amplios, puedes consultar primero nuestro artículo sobre VERIFACTU en empresas con procesos complejos. Aquí vamos a centrarnos específicamente en el siguiente nivel: ERP, sistemas conectados e intercambio de información.
¿Qué significa realmente que un ERP esté conectado con otros sistemas?
¿Qué significa realmente que un ERP esté conectado con otros sistemas?
Un ERP no siempre trabaja de forma aislada.
En función de la arquitectura de cada empresa, puede recibir o enviar información a un CRM, una tienda online, una aplicación sectorial, un sistema de almacén, una plataforma de pago u otras herramientas corporativas.
Una integración permite que determinada información pase de un sistema a otro sin tener que reproducir manualmente todo el proceso.
Pensemos, por ejemplo, en una operación que nace en un ecommerce y termina facturándose desde el ERP:
Ecommerce → ERP → factura
El ecommerce puede proporcionar información sobre la operación y el ERP utilizarla posteriormente dentro de su proceso de facturación.
Pero existe una distinción fundamental: participar en el proceso empresarial no equivale necesariamente a formar parte del sistema informático de facturación a efectos del RRSIF.
Para saber qué componentes están realmente afectados hay que analizar qué hace cada uno.
¿Qué parte del ERP o de los sistemas conectados puede formar parte del SIF?
¿Qué parte del ERP o de los sistemas conectados puede formar parte del SIF?
No depende únicamente del nombre de la aplicación, sino de las funciones que realiza dentro de la facturación. Un sistema informático de facturación puede estar formado por varios componentes, incluso de distintos fabricantes, que desempeñen funciones diferentes.
El Real Decreto 1007/2023 define un sistema informático de facturación atendiendo a las funciones que realiza, no simplemente al nombre comercial de la aplicación.
La definición contempla el conjunto de hardware y software utilizado para expedir facturas que permite la entrada de información de facturación, su conservación y su procesamiento para producir otros resultados derivados. Además, ese procesamiento puede realizarse en el propio sistema o en otro sistema al que previamente se haya remitido la información.
Por tanto, en un ecosistema formado por varias aplicaciones, no debería asumirse que todo el ERP constituye automáticamente el SIF ni, en sentido contrario, que únicamente está afectada la pantalla desde la que se expide la factura.
La Orden HAC/1177/2024 introduce además dos conceptos especialmente útiles para comprender estas arquitecturas.
Por un lado, el componente de facturación, que implementa alguno de los requisitos exigidos al sistema informático de facturación o dirige, gestiona y controla su implementación.
Por otro, el componente principal de facturación, encargado de implementar las funcionalidades necesarias para expedir facturas o de dirigir, gestionar y controlar esa implementación.
Esta distinción resulta especialmente importante en sistemas empresariales modulares.
La documentación técnica de la AEAT contempla que un SIF pueda estar formado por varios componentes y que estos asuman funciones diferentes: introducción de datos, generación del registro de facturación, expedición de la factura con su QR o remisión de registros a la Agencia Tributaria.
También contempla arquitecturas en las que intervienen programas o componentes de distintos fabricantes.
Por tanto, ante un ERP conectado con otros sistemas, la pregunta adecuada que hay que hacerse es:
«¿Qué función realiza exactamente dentro de la facturación?»
El origen del dato importa, pero no determina por sí solo qué aplicación es el SIF
El origen del dato importa, pero no determina por sí solo qué aplicación es el SIF
Esta distinción permite resolver una duda habitual.
¿Qué ocurre si los datos utilizados para generar una factura proceden de otra aplicación?
Que un dato se origine fuera del ERP no convierte automáticamente a la aplicación de origen en un SIF.
Un CRM puede aportar información comercial. Un ecommerce puede originar una venta. Una aplicación sectorial puede generar datos que después recibe el ERP.
Lo determinante es la función que cada sistema desempeña en la arquitectura concreta.
La propia documentación técnica de la AEAT aborda expresamente un supuesto en el que un SIF adaptado recibe toda o parte de la información de las facturas desde otros sistemas. La Agencia admite esa integración y establece determinadas condiciones sobre la conexión cuando esos sistemas alimentan directamente al SIF.
Esto obliga a distinguir dos cuestiones.
La primera es de dónde procede el dato.
La segunda, diferente, es qué sistema realiza las funciones de facturación reguladas por el RRSIF.
Para un responsable de IT, esta diferencia es fundamental. Un inventario de aplicaciones conectadas no basta para determinar el alcance técnico de la adaptación.
Antes de modificar una integración, conviene dibujar el recorrido de la información
Antes de modificar una integración, conviene dibujar el recorrido de la información
Una forma práctica de analizar un ecosistema de aplicaciones es representar el recorrido de la información:
origen → transformación → sistema de facturación → destinos posteriores
Este mapeo no es una obligación específica establecida por VERI*FACTU. Es una buena práctica técnica y organizativa para comprender una arquitectura antes de modificarla.
Puede estructurarse alrededor de cinco puntos:
| Elemento | Pregunta que hay que resolver |
|---|---|
|
Origen |
¿Dónde nace el dato utilizado posteriormente para facturar? |
|
Transformación |
¿Qué sistemas pueden modificarlo, completarlo o procesarlo? |
|
Facturación |
¿Qué componentes expiden la factura y generan el registro de facturación? |
|
Integración |
¿Qué componentes participan en funciones del SIF y cómo se relacionan? |
|
Destino |
¿A qué sistemas continúa la información después de la facturación? |
La diferencia entre «recibir un dato» e «implementar una función de facturación» es especialmente importante.
Por ejemplo, una aplicación puede recibir posteriormente determinada información de una factura para utilizarla en analítica, contabilidad u otro proceso. Esa recepción, por sí sola, no permite concluir que dicha aplicación deba tratarse como componente de facturación.
Del mismo modo, una aplicación que interviene antes de la factura no queda automáticamente sometida a los requisitos específicos del SIF simplemente porque proporcione información que más tarde será utilizada.
La función importa más que la etiqueta de la aplicación.
Las integraciones sí pueden formar parte de la arquitectura de facturación
Las integraciones sí pueden formar parte de la arquitectura de facturación
La situación cambia cuando varios componentes participan directamente en las funciones que conforman el sistema informático de facturación.
La documentación técnica de la AEAT contempla expresamente este escenario.
Por ejemplo, admite arquitecturas en las que un componente introduce los datos, otro genera el registro de facturación y otro participa en su remisión. También contempla que un componente principal de facturación invoque mediante una API a componentes especializados.
Por tanto, utilizar una API o un servicio externo para una función de facturación no sitúa automáticamente esa función fuera del SIF.
Lo importante vuelve a ser la arquitectura.
La AEAT señala que, cuando varios componentes de facturación participan en el proceso completo, deben estar adecuadamente coordinados. También establece que no deben quedar facturas sin su correspondiente registro de facturación ni registros generados sin su correspondiente factura.
Aquí ya no hablamos únicamente de una recomendación de arquitectura. Estamos dentro de las condiciones técnicas que afectan al funcionamiento del SIF cuando este está formado por varios componentes.
Esto tiene una consecuencia práctica para empresas con ERP integrados: antes de sustituir, actualizar o conectar componentes conviene determinar si esa integración simplemente intercambia información empresarial o si alguno de sus elementos implementa funciones sujetas al RRSIF.
Tres escenarios para entender la diferencia
Tres escenarios para entender la diferencia
No todas las integraciones deben analizarse de la misma forma. Estos tres ejemplos hipotéticos ayudan a visualizarlo.
Escenario 1: CRM → ERP → factura
El equipo comercial trabaja con un CRM y parte de la información de clientes u operaciones llega posteriormente al ERP.
El ERP utiliza esos datos dentro de su proceso y expide la factura.
Que el CRM sea el origen de determinados datos no permite concluir por sí solo que sea un sistema informático de facturación.
Habrá que analizar qué información proporciona y qué funciones realiza realmente cada aplicación.
La pregunta técnica es:
¿El CRM únicamente aporta información al proceso empresarial o implementa alguna de las funciones de facturación reguladas?
Escenario 2: ecommerce → ERP → factura
Un cliente realiza una operación en una tienda online. Los datos se transfieren al ERP y posteriormente se genera la factura.
De nuevo, el hecho de que la operación nazca en el ecommerce no determina por sí mismo el alcance del SIF.
Conviene identificar dónde se consolida la información de facturación, qué sistema expide la factura, dónde se genera su registro y qué componentes intervienen en esas funciones.
La diferencia entre originar una operación comercial y formar parte de la arquitectura de facturación es esencial.
Escenario 3: ERP → componente especializado de facturación
Supongamos ahora una arquitectura diferente.
El ERP realiza parte del proceso, pero invoca otro componente mediante una API para ejecutar determinadas funcionalidades necesarias para cumplir los requisitos del sistema de facturación.
En este caso ya no estamos simplemente ante una aplicación empresarial que proporciona información al ERP.
La propia AEAT contempla arquitecturas en las que el componente principal de facturación se integra con otros componentes especializados. La consideración y las responsabilidades de cada elemento dependerán de las funciones que implemente y de cómo esté configurada la arquitectura.
Los tres ejemplos parecen integraciones desde un punto de vista visual:
Sistema A ↔ Sistema B
Pero desde el punto de vista del RRSIF pueden representar situaciones diferentes.
Por eso la existencia de una conexión no basta para determinar las obligaciones de cada aplicación.
¿Hay que adaptar a VERI*FACTU todas las aplicaciones conectadas con el ERP?
¿Hay que adaptar a VERI*FACTU todas las aplicaciones conectadas con el ERP?
No necesariamente.
La conexión con un ERP que factura no convierte automáticamente a otra aplicación en sistema informático de facturación ni en componente de facturación.
La propia AEAT distingue entre el SIF y otras partes de los programas de gestión, contabilidad u otros ámbitos que no forman parte de ese sistema.
Sin embargo, cuando un programa o componente implementa funciones sometidas a los requisitos del RRSIF, su papel debe analizarse como parte de la arquitectura de facturación.
Por eso no existe una respuesta válida basada únicamente en una lista de aplicaciones.
Dos empresas podrían utilizar aparentemente los mismos tipos de software —por ejemplo, ERP, CRM y ecommerce— y tener arquitecturas distintas.
En una, el CRM podría limitarse a proporcionar información comercial.
En otra, determinados componentes podrían participar directamente en funciones relacionadas con la facturación.
De nuevo, la función importa más que la etiqueta de la aplicación.
Qué revisar en un ERP y sus integraciones antes de abordar la adaptación
Qué revisar en un ERP y sus integraciones antes de abordar la adaptación
Para una empresa con varios sistemas conectados, resulta útil realizar una revisión técnica y organizativa antes de decidir qué modificar.
No se trata de una lista de nuevas obligaciones legales, sino de un checklist para comprender la arquitectura existente.
1. Identificar qué sistema expide cada factura.
No dar por supuesto que todas las operaciones terminan en el mismo punto.
2. Localizar dónde se genera el registro de facturación.
Factura y registro deben analizarse conjuntamente dentro del funcionamiento del SIF.
3. Identificar de dónde proceden los datos utilizados para facturar.
CRM, ecommerce, aplicaciones sectoriales u otros sistemas pueden ser fuentes de información sin que eso determine por sí solo su consideración normativa.
4. Documentar las integraciones relacionadas con la facturación.
Qué sistemas están conectados, qué información intercambian y en qué dirección.
5. Determinar qué función realiza cada componente.
Introducción de datos, procesamiento, expedición de la factura, generación del registro, remisión u otras funciones.
6. Diferenciar integraciones empresariales de componentes de facturación.
No toda conexión tecnológica tiene las mismas implicaciones respecto al RRSIF.
7. Identificar quién mantiene cada componente.
En arquitecturas con soluciones de diferentes proveedores, conocer las responsabilidades técnicas ayuda a coordinar cualquier modificación.
8. Revisar las dependencias entre componentes antes de actualizarlos.
Un cambio en una parte de la arquitectura puede requerir comprobar su compatibilidad con el resto de componentes que participan en la facturación.
Este análisis permite pasar de un inventario del tipo:
«Tenemos ERP + CRM + ecommerce»
a una representación mucho más útil:
«Este sistema origina el dato → este lo transforma → estos componentes realizan las funciones de facturación → esta información continúa hacia estos destinos».
VERI*FACTU puede exigir coordinación entre Administración, IT y proveedores tecnológicos
VERI*FACTU puede exigir coordinación entre Administración, IT y proveedores tecnológicos
En un ecosistema integrado, analizar la adaptación puede requerir la participación de distintos perfiles.
Administración conoce cómo se ejecuta realmente la facturación y las excepciones que aparecen en el trabajo cotidiano. IT conoce las integraciones, dependencias y flujos de información. Los proveedores tecnológicos conocen las funciones que implementan sus respectivos productos y componentes.
Esta coordinación no constituye una obligación específica de VERI*FACTU. Es una recomendación organizativa derivada de la complejidad técnica del escenario.
Su objetivo es evitar que la revisión se limite al componente más visible sin haber identificado antes qué otros elementos participan realmente en las funciones de facturación.
Merkurio ERP: la facturación dentro de un sistema de gestión más amplio
Merkurio ERP: la facturación dentro de un sistema de gestión más amplio
Esta perspectiva encaja con el tipo de procesos que Merkurio ERP aborda.
Merkurio ERP integra áreas de gestión empresarial, financiera, compras, ventas, fabricación, inventario y distribución. También contempla procesos como CRM, suscripciones y facturación electrónica, además de circuitos empresariales en los que intervienen pedidos, albaranes y facturas, así como pasarelas de pago y gestores de ecommerce.
Esto permite abordar la facturación desde el conocimiento de los procesos que la rodean y de las conexiones que pueden existir entre distintas áreas del negocio.
La arquitectura concreta y la adaptación a VERI*FACTU deben, no obstante, analizarse para cada instalación y escenario.
Antes de adaptar las aplicaciones, entiende qué hace cada una
Antes de adaptar las aplicaciones, entiende qué hace cada una
Cuando un ERP comparte información con otras aplicaciones, contar cuántos sistemas existen no resuelve el problema.
Hay que saber qué información nace en cada uno, cómo circula y, sobre todo, qué componentes realizan realmente las funciones relacionadas con la facturación.
La normativa y la documentación técnica de la Agencia Tributaria contemplan arquitecturas con varios componentes e incluso con software de distintos fabricantes. Esto hace que el análisis de VERI*FACTU no pueda reducirse siempre a comprobar si una única aplicación está «adaptada».
En un ecosistema conectado, el primer paso es comprender la arquitectura.
A partir de ahí puede determinarse qué elementos forman parte del sistema informático de facturación, qué integraciones deben revisarse y qué cambios corresponden a cada componente.
Si tu empresa trabaja con un ERP conectado a otras aplicaciones, en Grupo Dana podemos analizar contigo el circuito de gestión y facturación para estudiar qué implicaciones tiene VERI*FACTU en tu escenario concreto.
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...
