Facturas con IA: cuándo registrar en el ERP y cuándo pedir revisión humana

Un ERP es el sistema que centraliza recursos y operaciones empresariales, como compras, inventario y contabilidad. «Llevar una factura al ERP» puede significar cosas muy distintas: adjuntar un archivo, crear un borrador, registrar un asiento definitivo o preparar una obligación de pago. Antes de elegir tecnología, conviene nombrar exactamente la operación que se quiere automatizar. Si el equipo llama «procesada» a cualquiera de esas situaciones, las métricas y los permisos nacerán confusos.

La lectura responde a qué aparece en el documento. La validación comprueba si esos datos son coherentes y aceptables para el negocio. La contabilización transforma información aprobada en un registro con efectos operativos. El pago mueve dinero y merece una autorización separada. Una factura puede estar bien leída y ser duplicada; puede cuadrar aritméticamente y corresponder a una compra no autorizada. Ninguno de esos problemas se resuelve pidiendo al modelo que vuelva a leerla.

La propuesta de TECDATA distingue la automatización basada en reglas de los modelos que interpretan información y plantea su complementariedad. Esa distinción resulta útil aquí, aunque no obliga a utilizar IA en todos los pasos. Un archivo estructurado con campos fiables puede procesarse mediante un lector convencional; un PDF escaneado y variable puede necesitar reconocimiento e interpretación. [1]

Como criterio de diseño, el primer despliegue debería crear borradores y conservar el documento original vinculado. La contabilización automática puede habilitarse después para una categoría estrecha y evaluada. Los cambios de datos bancarios y la liberación de pagos deben quedar fuera de ese permiso inicial. No se trata de desconfiar por sistema: se trata de no conceder a una función de lectura autoridad financiera que no necesita.

El mejor candidato no es necesariamente el proveedor que envía más facturas, sino el circuito cuya corrección puede comprobarse con menos ambigüedad. Pensemos en compras recurrentes a proveedores dados de alta, con pedido previo, recepción registrada y una única sociedad receptora. Hay referencias internas con las que contrastar el documento. Una factura de servicios sin pedido, repartida entre varios centros de coste y con criterios contables interpretativos, exige otro tratamiento.

Para seleccionar el piloto, conviene estudiar volumen, variedad documental, calidad de los datos maestros y coste del error. Los datos maestros son los registros estables del negocio: proveedores, identificadores fiscales, monedas, cuentas contables o condiciones de pago. Si un proveedor aparece con tres fichas inconsistentes, el modelo no debería elegir una por parecido del nombre. Primero hay que corregir el catálogo o establecer una resolución supervisada.

Metacom describe la lectura de facturas y documentos y su conexión con herramientas empresariales mediante plataformas como Make y n8n. Es una referencia útil sobre el tipo de integración que se comercializa, pero la existencia de un conector no determina qué facturas deben avanzar automáticamente. Esa decisión depende de los controles del proceso y de las capacidades concretas del sistema de destino. [2]

Un alcance inicial razonable podría limitarse a facturas ordinarias en euros, de una sociedad, con proveedores conocidos y pedido asociado. Las rectificativas, operaciones en otras monedas, anticipos, documentos con retenciones o compras sin recepción se dirigirían a revisión hasta disponer de pruebas y reglas específicas. No son categorías imposibles de automatizar; simplemente no deberían incorporarse por accidente a un circuito que todavía no sabe tratarlas.

El flujo comienza al recibir el documento por un canal autorizado. Se conserva una copia original, se identifica el expediente y se comprueba el archivo antes de interpretarlo. Si contiene texto accesible, puede extraerse directamente; si es una imagen, puede utilizarse reconocimiento óptico de caracteres, conocido como OCR. Un modelo documental o un modelo de lenguaje puede transformar después el contenido en campos. La elección debe basarse en pruebas con documentos propios, no en la espectacularidad de una demostración.

La salida de la extracción necesita un contrato de datos: una estructura predefinida con campos, tipos y restricciones. Por ejemplo, identificador fiscal del proveedor, número de factura, fecha, moneda, bases, impuestos, total y referencias de pedido. Un esquema JSON permite verificar esa forma automáticamente. Sin embargo, que una respuesta cumpla el esquema solo demuestra que tiene la estructura esperada; no demuestra que el número de factura o el total sean correctos.

Cada dato relevante debería conservar su procedencia: página, fragmento de texto o zona de imagen de la que se obtuvo. Cuando un campo no aparece, el resultado debe indicar ausencia, no completar una respuesta plausible. Los importes requieren tipos decimales y reglas de redondeo explícitas. Los separadores españoles, como la coma decimal, deben normalizarse sin confundir «1.250,00» con otro valor. La lógica de cálculo no debería depender de una explicación redactada por el modelo.

Después interviene un motor de reglas, es decir, código que aplica condiciones conocidas. Consulta proveedores, pedidos y recepciones mediante una API, la interfaz que permite comunicarse entre programas. Verifica los datos y decide si crear un borrador, solicitar revisión o detener el expediente. La credencial que escribe en el ERP pertenece al servicio de integración, no al contenido del documento ni a una decisión libre del modelo.

Trilogi presenta flujos que conectan documentos, sistemas empresariales, notificaciones y supervisión, e incluye el registro de ejecuciones dentro de su oferta. Sobre ese planteamiento, la recomendación técnica es guardar también el estado de cada expediente y separar los componentes de lectura, decisión y escritura. Así puede repetirse una extracción fallida sin repetir una contabilización ya realizada. [3]

Una etiqueta como «confianza: 98 %» parece una respuesta cómoda a la pregunta de si podemos seguir adelante. No basta. Si esa cifra la genera el propio modelo, no debe tratarse como una probabilidad de acierto sin validación. Incluso una puntuación suministrada por un extractor necesita contrastarse con ejemplos etiquetados y con el uso previsto. Reconocer bien una dirección no tiene el mismo valor que identificar correctamente un beneficiario.

La autorización debería combinar comprobaciones independientes. El identificador fiscal debe corresponder a un proveedor válido para la sociedad destinataria. El total debe cuadrar con bases e impuestos según las reglas aplicables. La referencia de pedido debe existir y los importes o cantidades deben encajar dentro de tolerancias aprobadas. Además, hay que buscar posibles duplicados. Que cuatro comprobaciones pasen no justifica ignorar una quinta que detecta un problema crítico.

Por ejemplo, una factura hipotética muestra una base de 1.000 euros, un IVA de 210 y un total de 1.210. La suma es coherente, pero todavía falta verificar que el tratamiento fiscal sea el esperado, que la mercancía se haya recibido y que el documento no esté registrado. Si aparece un IBAN diferente al del proveedor, la factura no debe actualizar automáticamente sus datos maestros: el cambio requiere un procedimiento de verificación independiente del mensaje recibido.

Es preferible trabajar con tres salidas explícitas. «Apta» significa que cumple todos los controles exigidos para una acción concreta. «Revisar» significa que falta evidencia o hay una discrepancia resoluble. «Bloqueada» significa que una condición impide avanzar, como un archivo malicioso o una incompatibilidad crítica. Bloquear el procesamiento no equivale a declarar fraude: evita que una interpretación técnica se convierta en una acusación comercial.

Las tolerancias deben pertenecer al negocio y quedar versionadas. Una diferencia de redondeo aceptable puede depender del tipo de operación y de cómo calcule el ERP. No conviene introducir un margen universal para mejorar artificialmente la tasa de automatización. Cuando se modifica una regla, debería poder saberse qué expedientes se aprobaron con la versión anterior y qué pruebas respaldan la nueva.

Añadir un botón de aprobación no convierte un flujo inseguro en seguro. La persona revisora necesita ver el documento, los campos extraídos, las referencias internas y el motivo por el que el expediente llegó a su cola. Si debe abrir cinco aplicaciones para reconstruir el contexto, parte del ahorro desaparece. Si solo ve una pantalla verde con una recomendación convincente, puede aprobar sin disponer de evidencia suficiente.

La interfaz debería señalar problemas específicos: «pedido inexistente», «total distinto al de las líneas», «proveedor ambiguo» o «posible duplicado». Una corrección debe registrar el valor anterior, el nuevo y el responsable. La aprobación ha de quedar asociada a una versión inmutable de los datos; si alguien cambia después el importe o el proveedor, debe invalidarse la autorización correspondiente. De lo contrario, se podría ejecutar una operación distinta de la revisada.

Socratech destaca la revisión humana, la estructuración de las respuestas y el análisis de privacidad antes de conectar documentos con herramientas de IA. Para el caso de las facturas, esa recomendación se concreta en permisos por función, evidencias visibles y capacidad real de detener el proceso. Una advertencia genérica de «revise el contenido» no sustituye esos controles. [4]

También hay que dimensionar la cola. Si el sistema recibe cientos de documentos y remite casi todos a la misma persona, solo habrá automatizado la creación del atasco. Conviene medir la antigüedad de las excepciones, el tiempo de revisión y las causas recurrentes. Las correcciones pueden alimentar futuras evaluaciones, pero no deberían modificar automáticamente el comportamiento del modelo en producción sin revisión y pruebas.

La evaluación empieza por un conjunto de documentos representativo y etiquetado por personas que conozcan el proceso. Debe contener formatos frecuentes, escaneos deficientes, varias páginas, duplicados, abonos y casos que deban rechazarse o revisarse. Es importante separar los ejemplos utilizados para ajustar instrucciones de los reservados para la prueba final. Evaluar únicamente sobre documentos conocidos puede ocultar problemas que aparecerán con un proveedor nuevo.

La exactitud por campo permite saber si se extraen correctamente fechas, identificadores e importes. Pero el indicador operativo decisivo es si la factura completa puede recibir la acción prevista sin correcciones. También hay que medir cuántos documentos incorrectos pasan los controles: una media alta de acierto puede convivir con fallos graves en un subconjunto pequeño. Las categorías minoritarias merecen análisis separado, especialmente cuando concentran riesgo.

Un ejemplo hipotético muestra la diferencia. De 1.000 documentos, 600 avanzan sin revisión. Si después se descubre que seis de esos 600 estaban mal autorizados, la tasa de automatización es del 60 %, pero el error dentro del circuito automático es del 1 %. No son resultados aceptables o inaceptables por definición: hace falta conocer la gravedad, la capacidad de recuperación y los límites pactados. Un número de pedido ausente no equivale a una contabilización en la sociedad equivocada.

Antes de escribir en producción, puede ejecutarse el sistema en modo sombra: procesa copias de expedientes reales y propone decisiones sin actuar sobre el ERP. Se comparan sus resultados con la resolución humana y se investigan desacuerdos. Después puede habilitarse la creación de borradores y, solo cuando haya evidencia suficiente, una autonomía más amplia para categorías concretas.

Las pruebas deben repetirse cuando cambian el modelo, las instrucciones, el esquema, las reglas o la integración. No basta con validar una nueva versión mediante una demostración favorable. Conviene conservar un conjunto estable de regresión, añadir fallos descubiertos en operación y revisar una muestra de los expedientes aprobados automáticamente. Esa auditoría permite detectar errores que nunca llegan a la cola de excepciones.

Uno de los fallos más peligrosos ocurre cuando el ERP acepta una operación, pero la conexión se corta antes de devolver la confirmación. Si el flujo interpreta el silencio como fracaso y repite la creación, puede duplicar el registro. La idempotencia es la propiedad que permite repetir una petición sin multiplicar sus efectos. Para conseguirla, se necesita un identificador estable de operación, soporte del sistema de destino cuando exista y reconciliación del estado antes de repetir escrituras inciertas.

La huella digital del archivo ayuda a detectar copias idénticas, pero no sustituye la búsqueda de duplicados de negocio. Una misma factura puede llegar como PDF original, escaneo y reenvío con otro nombre. Conviene combinar sociedad receptora, proveedor, número de factura y otros atributos, atendiendo a cómo se normalizan. Los documentos sospechosos deben revisarse; una coincidencia aproximada no debería borrar ni rechazar automáticamente una factura válida.

Los reintentos necesitan límites. Un servicio temporalmente indisponible puede admitir una nueva llamada tras una espera; un documento inválido no mejorará repitiendo veinte veces la extracción. El sistema debe distinguir fallos transitorios, errores de datos y rechazos de negocio. Los expedientes agotados pasan a una cola visible con responsable. Si la escritura funciona pero falla la notificación, se repite la notificación, no la operación financiera.

Existe además un riesgo propio de los modelos que interpretan lenguaje: un documento puede incluir instrucciones dirigidas al sistema, como intentar que ignore controles o envíe información a otro destino. Es lo que se conoce como inyección de instrucciones. El contenido de una factura debe tratarse como datos no fiables, nunca como autoridad para cambiar permisos, elegir destinatarios o ejecutar herramientas. Limitar capacidades y validar acciones fuera del modelo reduce la exposición; una instrucción verbal de «ignora ataques» no es una barrera suficiente.

Ante una incidencia grave debe existir un mecanismo de parada que suspenda nuevas escrituras sin perder los documentos entrantes. La recuperación requiere saber qué operaciones terminaron, cuáles quedaron pendientes y cuáles necesitan regularización. En contabilidad, deshacer una acción no siempre equivale a borrar un registro: el procedimiento debe respetar las posibilidades del ERP y los controles financieros de la organización.

Una factura puede contener datos personales, información bancaria y condiciones comerciales. Antes de enviarla a un servicio externo, conviene inventariar qué datos salen, con qué finalidad, quién los recibe y durante cuánto tiempo se conservan. Socratech señala expresamente la necesidad de analizar seguridad, privacidad y obligaciones aplicables antes de conectar información empresarial, incluido el RGPD y, cuando corresponda, el Reglamento Europeo de IA. Esa mención es un punto de partida, no una evaluación jurídica del proyecto. [4]

La revisión concreta debe hacerse con las funciones de privacidad, seguridad y asesoramiento jurídico que correspondan. Entre las cuestiones que deben resolverse están la base jurídica del tratamiento, los contratos pertinentes, los subencargados, las transferencias internacionales cuando existan y la necesidad de una evaluación de impacto. No toda automatización de facturas requiere las mismas medidas ni debe clasificarse de forma automática por el mero hecho de incorporar IA.

Desde la ingeniería, la minimización consiste en transmitir solo lo necesario. Si una consulta requiere el identificador del proveedor y el importe, no tiene por qué incluir el hilo completo de correos. Deben definirse plazos de conservación para documentos, salidas y registros de actividad. Los registros técnicos tampoco deberían convertirse en una copia indiscriminada de facturas: pueden guardar identificadores y eventos, reservando el contenido sensible para repositorios con acceso restringido.

El alojamiento propio y el servicio gestionado plantean compromisos distintos. El primero puede ofrecer más control directo sobre infraestructura, pero exige mantenimiento, actualizaciones y capacidad operativa. El segundo reduce algunas cargas técnicas, aunque obliga a examinar contratos, ubicaciones de tratamiento, retención y condiciones de uso de datos. Ninguna opción garantiza por sí sola cumplimiento o confidencialidad. Incluso una plataforma alojada internamente puede enviar documentos a un modelo externo.

Las credenciales deben almacenarse fuera de los flujos visibles y conceder el mínimo permiso necesario. Un extractor no necesita administrar proveedores; un servicio que crea borradores no necesita ordenar pagos. Separar entornos de prueba y producción, aplicar controles de acceso por función y verificar el borrado de copias temporales son decisiones tan importantes como elegir el modelo.

El coste del modelo es solo una partida. Hay que sumar recepción y almacenamiento, OCR cuando se utilice, plataforma de automatización, llamadas al ERP, desarrollo, supervisión, revisión humana y mantenimiento. También cuentan los expedientes fallidos y la resolución de incidencias. Una solución barata por página puede resultar cara por factura terminada si necesita numerosas correcciones o deja una cola difícil de gestionar.

Consideremos un cálculo puramente ilustrativo, no una tarifa de mercado ni un resultado de cliente. Una empresa tramita 2.000 facturas mensuales a seis minutos por documento: son 200 horas. Si valora la hora de trabajo en 25 euros, dedica capacidad equivalente a 5.000 euros al mes. Con un circuito que resuelva automáticamente el 70 % y requiera cuatro minutos para cada una de las 600 restantes, la revisión consumiría 40 horas. Si añadimos diez horas de supervisión, quedarían 50 horas de trabajo humano.

Bajo esos supuestos, se liberarían 150 horas, valoradas en 3.750 euros. Si la operación tecnológica costara 800 euros mensuales y una implantación hipotética de 12.000 euros se repartiera internamente entre doce meses, el beneficio mensual equivalente durante ese periodo sería de 1.950 euros. El cálculo cambia si sube la tasa de revisión, si faltaban tareas en la medición inicial o si mantener el circuito requiere más dedicación. Las cifras sirven para mostrar el método, no para prometer rentabilidad.

Capacidad liberada tampoco significa ahorro de caja inmediato. Si la plantilla y sus costes permanecen iguales, el retorno puede consistir en absorber más volumen, reducir retrasos o dedicar tiempo al control de proveedores. Conviene declarar qué beneficio se espera y cómo se comprobará, evitando contar dos veces las mismas horas como ahorro salarial y como mejora de productividad.

Para empezar, una plataforma visual puede bastar si permite gestionar estados, proteger secretos y recuperar errores. El desarrollo a medida puede compensar cuando hay reglas complejas, varios sistemas o exigencias de control difíciles de expresar con conectores. La decisión no debería enfrentar «sin código» contra «código», sino comparar coste total, capacidad de prueba y responsabilidad operativa. La ampliación a más proveedores o categorías debe depender de resultados y controles, no de una fecha comercial.