Cuando el agente de IA en n8n genera datos de factura incorrectos sin fallar

El error más caro en la extracción de datos de facturas con un agente de IA en n8n es el que no se vuelve rojo. El flujo de trabajo se ejecuta, el JSON es válido, cada campo obligatorio está lleno. Solo que en el campo de importe está el valor neto en lugar del valor bruto, o un número de factura que no aparece en el comprobante en ningún lugar. No hay un mensaje de error para ello: el error es de contenido, no técnico.

¿Por qué n8n no reporta un error cuando el valor es incorrecto en contenido?

n8n verifica la forma de la respuesta, no su corrección. El Structured Output Parser impone un esquema JSON, es decir, nombres de campos, tipos de datos y campos obligatorios. No puede saber si el importe corresponde a lo que dice en la factura. La documentación de n8n describe el nodo exactamente así: proporciona campos "basados en un esquema JSON".

El Auto-fixing Output Parser no cierra esta brecha. Según la documentación, invoca un segundo modelo de lenguaje si el primero falla. Eso repara JSON roto, no números falsos. Un conjunto de datos limpiamente formateado, pero con contenido incorrecto, se considera un éxito para ambos nodos.

¿Con qué frecuencia un agente de IA genera campos de factura incorrectos en contenido?

Los buenos modelos están en torno a un uno por ciento de tasa de error a nivel de documento, y ese uno por ciento no se anuncia por sí solo. En una tesis de maestría en la Technische Hochschule Brandenburg, Florian Pruß (18 de septiembre de 2025, asesor Prof. Dr. Emanuel Kitzelmann) verificó extracciones de LLM contra un conjunto de datos de comparación ciego independiente de 10.000 facturas realmente procesadas por aifinyo AG (TH Brandenburg, tesis de maestría). Se midió la Document Accuracy: un comprobante se considera correcto solo si el número de factura, la fecha de factura y el importe son todos correctos.

• Claude 3 Sonnet, Few-Shot con Chain-of-Thought: 99,36 por ciento Document Accuracy, el mejor valor medido.
• GPT-4.1, Few-Shot: 99,02 por ciento.
• Gemma 3 27B-IT, Few-Shot: 97,61 por ciento, interesante como modelo abierto para ámbitos críticos en protección de datos.
• Gemma 3 1B-IT: 24,97 por ciento. Los pequeños modelos locales no son una opción de ahorro para esta tarea, sino inutilizables.
• El sistema OCR implementado en producción para comparación: 87,24 por ciento.

El 99,36 por ciento suena como resuelto. En 10.000 facturas, son aproximadamente 64 comprobantes con al menos un campo central incorrecto, que todos pasan sin hacer ruido. La calidad del texto de entrada pesa tan intensamente como la selección del modelo: la misma estrategia con el mismo modelo logró 99,77 por ciento de Overall Accuracy a través de una capa de texto PDF limpia, solo 97,87 por ciento a través de una ruta de OCR de Tesseract.

¿Cómo reconoce datos de factura incorrectos del agente de IA?

Por contradicciones con datos que ya tiene. Un campo individual no se puede verificar para su corrección, pero un conjunto completo de campos sí, porque los campos de una factura están relacionados aritmética y comercialmente. Seis verificaciones cruzadas pertenecen a cada flujo de trabajo de facturación:

• Prueba aritmética: la suma de las posiciones más el impuesto facturado debe ser igual al importe bruto. Detecta la confusión de neto-bruto y las líneas de posición perdidas.
• Prueba de impuestos: importe de impuesto facturado contra importe neto por tasa de impuesto. Si no resulta una tasa común, el comprobante es un caso de revisión.
• Comparación de datos maestros: nombre del proveedor, número de identificación fiscal y IBAN contra el archivo maestro de acreedores. Un IBAN diferente de un proveedor conocido es siempre un caso de revisión.
• Verificación de duplicados: número de factura, acreedor e importe contra los comprobantes ya contabilizados.
• Plausibilidad de fechas: fecha de factura ni en el futuro ni fuera del período contable abierto, vencimiento igual a fecha de factura más plazo de pago.
• Comparación de pedidos: importe y cantidad contra pedido y recepción de mercancías, con una tolerancia establecida.

Estos controles no son una invención de la era de la IA, están en el texto legal de ayer. GoBD menciona en el párrafo 100 explícitamente "controles de entrada (mensajes de error, pruebas de plausibilidad)", "controles de conciliación en la entrada de datos" y "controles de procesamiento" como parte del sistema de control interno, el párrafo 40 exige "pruebas de plausibilidad de contenido" (Circular del BMF del 28 de noviembre de 2019). Quien racionaliza este paso de verificación al cambiar a un agente de IA elimina un control que estaba allí antes.

¿Qué umbrales pertenecen en la capa de validación?

Dos magnitudes determinan si un comprobante se ejecuta automáticamente: cuántas verificaciones cruzadas supera y cuánto dinero hay vinculado a él. Se ha demostrado que funciona un semáforo con tres rutas en lugar de un umbral único de sí-no.

• Verde: todas las pruebas aritméticas son correctas, acreedor e IBAN son conocidos, sin duplicados, importe por debajo de su límite de aprobación. Continúa automáticamente.
• Amarillo: una única desviación leve, como un nuevo acreedor o una tolerancia de pedido superada. Va a una lista de revisión, una persona confirma o corrige.
• Rojo: prueba aritmética fallida, IBAN diferente, sospecha de duplicado o un campo obligatorio vacío. Nunca se contabiliza automáticamente.

Crucial es de dónde obtiene el semáforo sus valores. No de la autoevaluación del modelo: un modelo de lenguaje preguntado por su propia confianza proporciona un número plausible, no uno medido. Los umbrales deben surgir de pruebas calculables, es decir, de aritmética y comparación de datos maestros. Cómo se ve esto organizativamente en términos de escalada está en nuestro modelo de escalada para agentes de IA.

¿A partir de qué importe debe aprobar una persona?

No hay un límite de euros establecido legalmente. GoBD exige controles y segregación de funciones, su implementación concreta es según el párrafo 100 explícitamente dependiente de la complejidad de la actividad comercial y la estructura organizativa. Por lo tanto, establece el límite usted mismo, y el punto de partida correcto es su regulación de firmas existente: si en casa la dirección firma a partir de 5.000 euros, el agente no tiene nada que decidir por su cuenta por encima de este límite.

Un ejemplo de la propia contabilidad que ningún aviso resuelve: dos clientes de NordFlux facturan según el procedimiento de nota de crédito después de § 14 Abs. 2 UStG, el cliente emite la factura para nosotros. En el comprobante dice "nota de crédito", NordFlux es el emisor de la factura, el remitente es el receptor de los servicios. Una extracción que asigna la palabra a su significado comercial la convierte en una corrección de factura con signo negativo y gira los ingresos reales hacia menos. El documento se lee limpiamente, cada campo es correcto, solo el significado está invertido. Una regla en la capa de validación ayuda contra ello: si el propio número de identificación fiscal aparece en el campo del emisor de la factura, es una factura de salida, sin importar lo que diga el encabezado.

¿Cómo construye la capa de validación en n8n?

Como su propia sección entre la extracción y el sistema de destino, no como un aviso más largo. Cinco componentes son suficientes para empezar:

• Encapsular la extracción: sub-flujo propio, retorno estrictamente a través del Structured Output Parser, sin campos de texto libre.
• Verificar en Code-Node, no en el LLM: las pruebas aritméticas son aritmética. Un modelo de lenguaje que verifica agrega una segunda fuente de error.
• Llevar el resultado de la verificación: reglas aprobadas y fallidas como un campo propio en el conjunto de datos. Sin esta lista no se puede decir después cuál es la regla y con qué frecuencia se aplica.
• Switch-Node en el semáforo: tres rutas, verde al sistema contable, amarillo a la lista de revisión, rojo al flujo de errores con notificación.
• Protocolar en una tabla propia: documento de entrada, valores extraídos, resultado de la verificación, decisión y persona que decide. Las ejecuciones de n8n tienen una retención limitada y no sustituyen a un protocolo de revisión.

El párrafo 100 de GoBD exige que los controles no solo se establezcan y se ejerzan, sino que también se protocolicen, según el párrafo 102, la descripción del sistema de control pertenece a la documentación de procedimientos. Una capa de validación sin protocolo solo cumple la mitad de su propósito. Cómo se ve el proceso en la imagen general lo mostramos en la automatización de la recepción de facturas y en la automatización de la contabilidad.

Preguntas frecuentes

¿Puede un segundo modelo de lenguaje asumir la verificación?

Parcialmente. Una extracción independiente de un segundo modelo y una comparación campo por campo marcan comprobantes inseguros de manera confiable. Como árbitro único no funciona: dos modelos pueden cometer el mismo error de lectura, y un modelo que evalúa su propia salida no juzga de manera independiente. Las pruebas aritméticas y las comparaciones de datos maestros pertenecen al código.

¿Un modelo mejor simplemente no ayuda contra las alucinaciones?

Ayuda de manera medible, pero no resuelve el problema. Incluso el mejor valor de 99,36 por ciento deja aproximadamente 64 documentos defectuosos en 10.000 comprobantes, y la calidad del texto de entrada pesa tanto como la selección del modelo.

¿En qué se diferencia de un error en el analizador de salida?

Un error del analizador es visible: el nodo falla, la ejecución se vuelve roja, un flujo de error se activa. El error silencioso de contenido es el caso más peligroso, porque todo parece válido. Requiere su propia capa de verificación, no mejor manejo de errores.

¿Se resuelve por sí solo con la factura electrónica?

Solo en parte. Con XRechnung o ZUGFeRD lee los valores del XML incrustado en lugar de estimarlos. Los comprobantes sin datos estructurados siguen llegando, y la prueba aritmética, la comparación de acreedores y la verificación de duplicados son necesarios independientemente del formato.

¿Cuánto esfuerzo requiere modernizar la capa de validación?

La técnica es la parte menor: las pruebas aritméticas, la plausibilidad de fechas y la verificación de duplicados se construyen rápidamente en un Code-Node. El esfuerzo está en la coordinación. Qué tolerancia se aplica en la comparación de pedidos, a partir de qué importe decide una persona, quién procesa la lista amarilla. Aclare esto con la contabilidad antes de que el primer comprobante se contabilice automáticamente.