Desde que se dio a conocer la intención de la puesta en marcha de esta nueva solución por parte de nuestro país y de la unión europea, para ayudar a mejorar la eficiencia y control de la facturación empresarial (incluyendo por su puesto reducir lo máximo posible la morosidad) han surgido cambios respecto a los estándares para la misma.
Necesidad de interoperabilidad
La implementación de la factura electrónica y el sistema Verifactu, cuyo objetivo es garantizar la seguridad de la información para que llegue de manera fiable a la administración tributaria, está generando más de un quebradero de cabeza entre los desarrolladores de software. Uno de los principales desafíos técnicos y regulatorios en la implementación de la factura electrónica es la interoperabilidad entre los distintos sistemas y plataformas. Esta interoperabilidad se ve dificultada por la falta de estándares comunes, lo que hace necesario establecer una coherencia entre la factura electrónica impulsada por el Ministerio de Economía y Competitividad y el sistema Verifactu desarrollado por la Agencia Tributaria (AEAT).
Inicialmente, se había sugerido el uso de “Facturae” como estándar, pero considerando las futuras iniciativas de las instituciones europeas, se está evaluando la posibilidad de adoptar la sintaxis UBL (lenguaje universal que se está implementando en la UE y posibilita la descripción estructurada de la información presente en una factura electrónica), que se alinea mejor con estas perspectivas.
Dos alternativas
Para lograr una solución única e interoperable, es esencial trabajar hacia una armonización que permita a clientes y empresas de software adaptarse a los cambios de forma simplificada. Esta solución debe ser aplicable tanto al proceso de facturación de pequeños negocios, principal foco de supervisión a través de Verifactu, como al de grandes empresas.
Ante este problema, la AEAT ofrece dos alternativas a las empresas proveedoras de software de facturación. En primer lugar, estaría el sistema Verifactu (“Sistemas de emisión de facturas verificables”) es decir, la posibilidad de envío de los registros de facturación generados a la Administración tributaria de forma voluntaria por los sistemas informáticos. Esto supone remitir de forma continuada, segura, correcta, íntegra, automática, consecutiva, instantánea y fehaciente todos los registros de facturación generados. A los efectos de este Reglamento, se presumirá que los “Sistemas de emisión de facturas verificables” cumplen por diseño con los requisitos. En este caso, si tuviésemos el caso de que un agente externo accediese al software y borrase la información, la AEAT ya tendría de antemano los registros de facturación por lo que no supondría un problema mayor.
Pero existe la circunstancia de que el contribuyente decida no enviar las facturas automáticamente. Entonces, el software tendrá la obligación de realizar la firma electrónica de los registros y enviar las facturas cuando la AEAT lo solicite. Es decir, aunque el contribuyente decida no enviarlas, el software debe ser capaz de hacerlo. Entonces, las características de seguridad, control, firma electrónica de las facturas, conservación de registros, etc. deben ser garantizados por los sistemas informáticos. Esta segunda posibilidad es la que puede causar más problemas a las empresas desarrolladoras de software, en cuanto a costes de desarrollo y responsabilidad ya que, si un contribuyente elige la vía de “no conexión”, la seguridad puede quedar comprometida al abrir la puerta a que agentes externos accedan de forma relativamente sencilla a modificar la información.
La tecnología ayuda, pero todas las medidas que se implementen en un sistema donde el cliente no envíe las facturas automáticamente a la AEAT tiene su complejidad, y no puede garantizarse al 100% la inalterabilidad de los datos. Lo que las empresas tecnológicas pueden asegurar es la implementación de los requisitos técnicos definidos en el proyecto para cumplir con la ley. Sin embargo, lo que suceda con el software fuera de su control es otra cuestión.