Revisar facturas con IA parece un caso perfecto: llega un PDF, se leen proveedor, CIF, fecha, base imponible, IVA, total, pedido y vencimiento, y alguien deja de picar datos a mano. En una demo suele funcionar bastante bien.
El problema llega con las facturas reales. Una viene escaneada torcida. Otra trae varios albaranes. Otra no coincide con el pedido. Otra mezcla suplidos, descuentos o retenciones. Y alguna llega de un proveedor nuevo que todavía no existe en el ERP.
Para una empresa de Donostia - San Sebastián, Gipuzkoa o Euskadi, el primer piloto no debería intentar pagar facturas automáticamente. Debería preparar una revisión más rápida y más segura: extraer datos, comparar contra reglas simples, marcar dudas y dejar una persona al mando antes de registrar o aprobar nada.
Al final tienes un PDF descargable con un checklist básico para diseñar ese piloto sin abrir permisos de más.
El error: confundir extracción con revisión
Leer datos de una factura es solo una parte del trabajo. La revisión empieza después.
Hace falta saber si el proveedor está dado de alta, si el pedido existe, si el importe entra dentro de una tolerancia razonable, si el IVA cuadra, si el vencimiento tiene sentido y si la factura ya se había recibido antes. La IA puede ayudar con mucha de esa lectura, pero conviene separar bien tres pasos: extraer, comprobar y decidir.
Si esos pasos se mezclan, la automatización se vuelve peligrosa. Un modelo puede leer bien el total y aun así no saber si debe aprobarlo. Puede detectar el CIF y no saber que ese proveedor necesita una validación especial. Puede resumir la factura y pasar por alto que el pedido está cerrado.
Un buen primer piloto
Yo empezaría con facturas de proveedores recurrentes y reglas sencillas. Nada de casos raros al principio.
Un alcance razonable podría ser este: el sistema lee una bandeja concreta, extrae campos mínimos, compara contra una lista de proveedores y pedidos, marca incidencias y prepara una ficha para que administración revise. Si todo cuadra, la persona aprueba el registro. Si algo no cuadra, se escala con una razón clara.
No hace falta conectar todo el ERP desde el día uno. A veces basta con exportar pedidos abiertos, proveedores activos y una tabla de tolerancias. El piloto aprende mucho sin tocar todavía el circuito de pago.
Campos que conviene extraer
La lista mínima depende del negocio, pero casi siempre aparecen estos datos:
- proveedor y CIF;
- número de factura;
- fecha de emisión y vencimiento;
- base imponible, impuestos y total;
- moneda;
- pedido, albarán o centro de coste;
- forma de pago;
- email o canal de entrada;
- duplicados posibles.
La pregunta importante no es solo si la IA los puede leer. La pregunta buena es qué pasa cuando no los lee con confianza. Si el campo es crítico, no se inventa. Se marca para revisión.
Reglas de comprobación
Antes de hablar de modelos, escribe las comprobaciones que ya hace una persona.
Por ejemplo: el CIF debe coincidir con el proveedor. El número de factura no puede estar repetido. El total puede desviarse un pequeño porcentaje si hay portes, pero no si cambia la base principal. El vencimiento no debería saltarse las condiciones pactadas. Una factura sin pedido asociado puede entrar en revisión, pero no debería pasar como si nada.
Estas reglas parecen aburridas. Son justo lo que convierte una demo de lectura de PDFs en un flujo de trabajo útil.
Dónde debe entrar una persona
La aprobación humana no debería ser un botón simbólico al final. Tiene que estar puesta donde aporta control.
En un piloto de facturas, yo pondría revisión humana en cuatro puntos:
- cuando la confianza de extracción sea baja;
- cuando falte un campo crítico;
- cuando importe, proveedor, pedido o IVA no cuadren;
- cuando la acción siguiente toque el ERP o el pago.
Ese diseño permite ahorrar tiempo sin pedir fe ciega al sistema. La IA prepara el trabajo. La persona decide.
Permisos y trazabilidad
Una automatización de facturas toca datos sensibles: proveedores, importes, condiciones, cuentas, pedidos, centros de coste y a veces información de clientes. No conviene darle acceso amplio solo porque el conector lo permite.
El piloto debería leer únicamente lo necesario, guardar qué documento procesó, qué campos extrajo, qué reglas fallaron y quién aprobó cada paso. Si dentro de dos meses aparece una factura discutida, la empresa necesita reconstruir qué ocurrió sin depender de memoria humana.
Señales de que el caso encaja
El caso suele tener buen encaje si hay volumen suficiente, proveedores repetidos, facturas relativamente legibles, reglas que administración puede explicar y un punto claro de revisión antes del registro final.
También ayuda que el equipo odie la tarea. No por capricho, sino porque la adopción es más fácil cuando la IA quita trabajo pesado de verdad.
Señales de que conviene esperar
Yo esperaría si la empresa no tiene proveedores limpios, si cada factura necesita interpretación comercial, si los pedidos no están actualizados, si hay muchos casos con condiciones especiales o si nadie puede decidir qué tolerancia es aceptable.
Esperar no significa tirar la idea. A veces el mejor paso previo es ordenar proveedores, cerrar pedidos antiguos, definir centros de coste o separar la bandeja de facturas de otros correos administrativos.
Descarga el checklist básico
Hemos preparado un PDF breve para revisar este caso con administración, compras e IT. Incluye campos mínimos, reglas de comprobación, excepciones, permisos, trazabilidad y una ficha de decisión para cerrar el alcance del piloto.
Descarga el how-to básico
PDF breve para preparar un piloto de revisión de facturas: campos, tolerancias, permisos, excepciones, ERP y aprobación humana.
Cómo lo trabajamos en Umintia
En Umintia solemos plantear estos pilotos con un alcance pequeño: una bandeja, un tipo de proveedor, unas reglas claras y una revisión humana bien puesta. Si funciona ahí, se amplía. Si no funciona, se aprende barato.
Si tu empresa está en Donostia - San Sebastián, Gipuzkoa o Euskadi y está valorando automatizar facturas, pedidos o backoffice, podemos ayudarte a separar lo que conviene automatizar ahora de lo que necesita orden previo.