Cuando la norma permite más de lo que el modelo técnico puede representar y por qué esto supone un riesgo real para fabricantes de software y empresas
La implantación de la factura electrónica obligatoria en el marco de la Ley Crea y Crece y su desarrollo reglamentario supone un avance indiscutible en la trazabilidad y control de las operaciones B2B. Sin embargo, un análisis técnico detallado de los documentos publicados, especialmente del modelo de estados definido en el Anexo II, revela una serie de inconsistencias relevantes entre lo que la norma permite conceptualmente y lo que realmente puede implementarse desde un punto de vista técnico.
Estas inconsistencias no son menores. Afectan directamente a cómo deben diseñarse los sistemas de facturación, a la forma en que se reporta la información a la Agencia Tributaria y, sobre todo, al riesgo de incumplimiento en un entorno donde las sanciones pueden ser significativas.
El modelo técnico del anexo ii: un sistema binario basado en eventos
El Anexo II define el contenido y estructura de los mensajes de estado mediante el uso de ApplicationResponse en UBL. En este modelo, los eventos principales son claros: pago, rechazo, cobro e impago. Cada uno de estos eventos se representa mediante códigos como PAYMENT, REJECTION, SETTLEMENT o DEFAULT, acompañados fundamentalmente de fechas.
El diseño es intencionadamente simple. Por ejemplo, en el caso del pago, únicamente se exige la fecha de efecto y la fecha de vencimiento del plazo de pago. No existe ningún campo relativo a importes, ni pagados ni pendientes, lo que evidencia que el modelo está pensado para reflejar estados finales y no la evolución de una factura a lo largo del tiempo.
Esto implica que, desde el punto de vista técnico, el sistema solo entiende dos situaciones: una factura está pagada o no lo está. No hay espacio para matices intermedios.
Lo que dice la orden ministerial: una visión más rica del negocio
Frente a este modelo técnico limitado, la Orden Ministerial introduce una capa conceptual mucho más avanzada. En ella se establece expresamente que se podrá informar de estados adicionales como la aceptación o rechazo parcial de la factura, el pago parcial con su importe y fecha, o incluso la cesión de la factura a un tercero para su cobro.
Esta declaración es coherente con la realidad empresarial. En el mundo B2B, los pagos parciales, las discrepancias sobre determinadas líneas de factura o las cesiones de crédito son situaciones habituales. La norma, por tanto, reconoce correctamente esa complejidad.
Sin embargo, surge aquí la inconsistencia: el modelo técnico definido no permite representar esta riqueza de información.
La incoherencia estructural: semántica sin soporte técnico
El problema central puede resumirse de forma muy clara: la norma permite informar de determinados estados, pero no define cómo hacerlo técnicamente dentro del modelo oficial.
En el Anexo II no existe ningún campo para informar del importe de un pago parcial. Tampoco hay estructuras que permitan diferenciar entre aceptación total y parcial, ni mecanismos para reflejar porcentajes, saldos pendientes o desgloses de pago.
Esto genera una situación compleja para desarrolladores y fabricantes de software. Por un lado, deben cumplir con la obligación de informar determinados estados. Por otro, no disponen de un modelo técnico estándar que soporte esa información.
La consecuencia práctica: dos realidades paralelas
Esta inconsistencia obliga, en la práctica, a trabajar con dos capas diferenciadas dentro de los sistemas de facturación.
Por un lado, la capa legal obligatoria, que es la que se reporta a la solución pública de facturación electrónica y que se limita a los eventos definidos en el Anexo II. Esta capa es simplificada, binaria y orientada a resultados finales.
Por otro lado, la capa de gestión interna, donde las empresas sí necesitan manejar la realidad completa: pagos parciales, incidencias, discrepancias comerciales, acuerdos de pago, etc. Esta información no puede trasladarse íntegramente al sistema público.
El resultado es que una misma factura puede tener una evolución compleja en el ERP, mientras que en el sistema público solo se refleja su estado final.
Riesgos legales y de cumplimiento
Esta desconexión no es solo un problema técnico, sino también jurídico. Puede dar lugar a situaciones donde la información reportada no refleje fielmente la realidad económica de la operación.
Por ejemplo, una factura parcialmente pagada puede aparecer como impagada hasta que se complete el pago total. Del mismo modo, una aceptación parcial no tendrá reflejo formal en el sistema si no se materializa en un rechazo completo o en una rectificación posterior.
Esto puede afectar a indicadores clave como los plazos de pago, la morosidad o incluso la interpretación de las relaciones comerciales entre empresas.
Además, en un escenario de inspección, la divergencia entre los sistemas internos y la información reportada puede generar dudas o requerimientos adicionales por parte de la Administración.
impacto en fabricantes de software y erp
Para los fabricantes de software, esta situación es especialmente crítica. No basta con implementar el modelo UBL del Anexo II. Es necesario diseñar soluciones que sean capaces de gestionar la complejidad real del negocio, al tiempo que cumplen con un modelo oficial simplificado.
Esto implica:
la necesidad de arquitecturas con doble capa de información
la gestión de estados internos más avanzados que los oficiales
la definición de criterios claros sobre cuándo y cómo reportar eventos
la trazabilidad completa entre lo que ocurre en el sistema y lo que se comunica a la Administración
No abordar correctamente estos aspectos puede dejar a un software fuera del mercado o exponer a sus clientes a riesgos de incumplimiento.
Por qué es imprescindible nuestra auditoría especializada
En este contexto, interpretar correctamente la norma no es suficiente. Es necesario entender cómo se traduce esa norma en un diseño técnico concreto, identificar las inconsistencias y definir cómo gestionarlas sin incumplir.
Aquí es donde cobra especial relevancia una auditoría especializada. No se trata solo de validar si un XML es correcto, sino de analizar el modelo completo del sistema:
cómo se gestionan los estados de las facturas
qué información se reporta y cuál no
cómo se gestionan los pagos parciales
cómo se asegura la coherencia entre sistemas internos y reporting oficial
qué riesgos legales existen en cada escenario
Un error en este punto no es simplemente un fallo técnico, sino un potencial problema jurídico.
cómo podemos ayudarte
Desde nuestro equipo llevamos años auditando y asesorando a fabricantes de software y empresas en materia de Ley Antifraude, VERI*FACTU y ahora Ley Crea y Crece. Hemos trabajado con cientos de soluciones y conocemos en profundidad tanto la normativa como su aplicación real.
Nuestro enfoque no se limita a revisar requisitos, sino a analizar el sistema desde una perspectiva integral: técnica, funcional y legal. Identificamos inconsistencias como las descritas, evaluamos su impacto y definimos cómo deben resolverse en cada caso.
Trabajamos con modelos de control avanzados, con cientos de verificaciones específicas, que permiten a nuestros clientes no solo cumplir, sino hacerlo con seguridad jurídica y ventaja competitiva.
Conclusión
La factura electrónica B2B no es solo una obligación normativa, sino un cambio estructural en la forma de operar de las empresas. Sin embargo, su desarrollo actual presenta inconsistencias que deben ser entendidas y gestionadas correctamente.
Ignorar estas diferencias entre norma y modelo técnico es un riesgo. Anticiparse a ellas, entenderlas y diseñar soluciones adecuadas es una oportunidad.
Y en ese camino, contar con asesoramiento experto marca la diferencia entre cumplir formalmente o cumplir de forma sólida, segura y defendible ante cualquier escenario. Contacta con nosotros en este formulario