25 Nov Uso una API de VERI*FACTU muy conocida: ¿puedo estar realmente tranquilo?
Cada vez más fabricantes de software de facturación recurren a APIs externas para integrar VERI*FACTU de forma rápida y aparentemente segura. La lógica suele ser sencilla: si la API es popular, reconocida en el mercado o cuenta con buena documentación, debería cumplir con la normativa. Sin embargo, esta confianza puede convertirse en uno de los mayores riesgos normativos para cualquier desarrollador que vaya a firmar una Declaración Responsable. La sanción siempre recae sobre el titular del sistema informático, incluso cuando utiliza componentes de terceros.
En nuestras auditorías hemos detectado vulnerabilidades importantes en APIs muy extendidas. Desde fuera todo parece funcionar con normalidad, pero a nivel técnico y jurídico hemos identificado fallos que comprometen la integridad del SIF final. La pregunta clave que debería plantearse cualquier desarrollador es simple: ¿esta API ha sido auditada y certificada por un tercero independiente?
Uno de los errores más habituales es asumir que la API ya cumple por sí sola el Reglamento SIF, la Orden Ministerial y el artículo 29.2.j) de la Ley General Tributaria. La realidad es que el único responsable ante la Agencia Tributaria es el fabricante del software que integra la API y presenta la Declaración Responsable. La API es un componente, no una exención de obligaciones.
Nuestra experiencia en www.leyantifraude.com demuestra que algunas APIs generan XML incorrectos, calculan mal el hash encadenado, aplican firmas incompletas, gestionan de forma deficiente los eventos de alteración o tratan inadecuadamente la numeración. En ocasiones encontramos problemas críticos en la custodia de certificados o en la regeneración de registros, algo incompatible con las exigencias de integridad e inalterabilidad de la normativa. Estos fallos no suelen detectarse hasta que se realiza una auditoría profunda, pero sus consecuencias pueden ser graves: la solución final puede considerarse no conforme, la Declaración Responsable puede perder validez y el desarrollador puede enfrentarse a infracciones del artículo 201 bis de la LGT por comercializar o permitir la tenencia de un sistema que no cumple.
Por este motivo, cualquier fabricante responsable debe exigir un informe independiente antes de integrar una API externa. Ese análisis debe revisar el hash encadenado, la gestión del certificado, la firma aplicada, los eventos, la conservación, el modo de pruebas, los procesos de error, la numeración, el QR y la validez real de los registros enviados a la AEAT. Solo así se puede garantizar que la API no arrastra al software completo a una situación de incumplimiento.
En nuestras auditorías revisamos cada uno de estos elementos. Validamos la estructura XML, comprobamos la integridad de los registros, analizamos la cadena de hash por instalación, evaluamos los escenarios de error y verificamos la respuesta real de la AEAT. Con ello generamos un informe completo que permite al fabricante saber si puede integrar la API con seguridad o si debe exigir modificaciones antes de continuar.
La conclusión es evidente. La popularidad de una API nunca debe considerarse una garantía de cumplimiento. La responsabilidad recae siempre en el fabricante del software, y solo una auditoría rigurosa asegura la tranquilidad necesaria para firmar una Declaración Responsable con verdadera seguridad jurídica y técnica. Una API puede ser útil, pero sin validación externa su integración es un riesgo que ningún desarrollador debería asumir.
Con más de 350 soluciones evaluadas, no recomendamos adaptar un software sin el acompañamiento de un auditor experto. Si necesitas ayuda, puedes contactar con nosotros a través de nuestro formulario y estaremos encantados de asesorarte.