Una factura puede llegar correctamente al correo de cuentas por pagar y aun así convertirse en horas de trabajo manual. Alguien debe identificar al proveedor, encontrar la orden de compra, comprobar qué se recibió, revisar precios e impuestos, detectar duplicados y decidir quién resuelve cada diferencia. Cuando la evidencia vive en bandejas, archivos y módulos separados, el pago se retrasa o avanza con controles incompletos.
Este artículo se concentra en un caso de uso concreto: usar agentes de IA para verificar facturas de proveedores contra la orden de compra y la recepción registrada en el ERP. La IA captura y organiza datos, ejecuta comparaciones permitidas y prepara excepciones; las políticas del ERP y las personas autorizadas conservan la aprobación contable y la liberación del pago.
Qué es la verificación de facturas con IA
Es un flujo de cuentas por pagar que recibe una factura, extrae sus campos y líneas, busca los documentos operativos relacionados y compara la información antes de enviarla a contabilización o aprobación. La IA ayuda especialmente cuando el documento no llega en un formato uniforme o cuando la excepción necesita contexto de varias fuentes.
El objetivo no es que un modelo decida si una factura “parece correcta”. El objetivo es producir una verificación reproducible: qué factura se recibió, con qué orden y recepción se relacionó, qué reglas se aplicaron, qué diferencias aparecieron y quién debe actuar.
Qué significa hacer matching de dos o tres vías
La comparación depende de los documentos disponibles y de la política de compra:
- Matching de dos vías: compara la factura con la orden de compra. Sirve para validar proveedor, moneda, conceptos, cantidades, precios y condiciones autorizadas.
- Matching de tres vías: añade la recepción de bienes o la confirmación del servicio. Así evita aprobar únicamente porque algo fue ordenado cuando todavía no existe evidencia de entrega.
- Factura sin orden de compra: necesita una ruta distinta, con centro de costo, contrato, responsable y aprobación definidos. No debería forzarse dentro de una coincidencia inexistente.
Microsoft Learn documenta que las facturas de proveedor pueden relacionarse con líneas de recepción, incluso cuando hay entregas parciales. También describe procesos que emparejan automáticamente recepciones con líneas sujetas a una política de tres vías y muestran estados como completo, en espera o fallido. La lección operativa es clara: una excepción debe tener estado y motivo, no quedar oculta en una coincidencia aproximada.
Por qué el proceso manual se atasca
Las facturas no siempre llegan en el mismo orden ni con los mismos identificadores que el ERP espera:
- El número de orden aparece incompleto, en otra página o con un formato distinto.
- Una factura reúne varias recepciones parciales.
- El proveedor factura una cantidad distinta a la recibida.
- El precio unitario, descuento, flete o impuesto no coincide.
- La recepción existe, pero todavía no fue registrada en el sistema.
- El mismo documento llega por correo y por un portal.
- Un cambio autorizado en la orden no está reflejado en todos los sistemas.
- Una factura de servicios requiere confirmación del responsable, no una entrada de bodega.
Sin un expediente común, cuentas por pagar pregunta a compras, compras pregunta a operación y el proveedor vuelve a enviar el documento. Cada reenvío aumenta el riesgo de duplicidad, mientras el equipo pierde visibilidad sobre quién tiene la siguiente acción.
Flujo recomendado paso a paso
1. Recibe la factura en una entrada controlada
El documento puede entrar por un inbox de cuentas por pagar, un portal de proveedores, una integración de facturación electrónica o una API. El flujo conserva el archivo original, el canal, la fecha, el remitente y un identificador único. También analiza adjuntos y evita que un hilo reenviado cree casos nuevos sin validación.
Antes de extraer información, debe comprobarse el tipo de archivo, aplicar controles de seguridad y separar mensajes sospechosos. Una factura no debe convertirse automáticamente en una instrucción para el agente: el contenido del documento es dato por verificar, no una orden con privilegios sobre el ERP.
2. Extrae campos y conserva evidencia
El agente puede proponer proveedor, número de factura, fecha, moneda, subtotal, impuestos, total, orden de compra y líneas. Cada valor debe mantener referencia a la página o región del documento de donde salió. Si el dato es ilegible, contradictorio o de baja confianza, se marca para revisión en vez de inventarlo.
La captura debe normalizar formatos sin alterar el valor original. Por ejemplo, puede estandarizar fechas o separadores decimales para comparar, pero conserva la representación recibida para auditoría.
3. Resuelve la relación con proveedor y orden
El número escrito en la factura es una señal, no siempre una llave suficiente. El flujo contrasta proveedor, entidad legal, moneda, orden abierta, centro de costo y líneas. Si existen dos órdenes plausibles o el proveedor no coincide con el maestro autorizado, no elige silenciosamente: crea una excepción explicable.
También conviene verificar el estado del proveedor y cambios recientes en datos sensibles. Una actualización de cuenta bancaria, por ejemplo, requiere un proceso de validación separado y no debería aprobarse porque apareció dentro de una factura.
4. Compara factura, orden y recepción por línea
El matching útil ocurre a nivel de línea, no solo de total. Para cada concepto, el flujo compara SKU o servicio, descripción, unidad, cantidad ordenada, cantidad recibida, cantidad previamente facturada, precio, descuento, impuesto y cargos autorizados.
Las entregas parciales necesitan saldo acumulado. Si se ordenaron 100 unidades, se recibieron 60 y ya se facturaron 40, una nueva factura por 20 puede ser consistente; una por 60 exige revisar el historial para no exceder lo recibido. El mismo principio aplica a hitos de servicios y consumos contra contrato.
5. Aplica tolerancias explícitas
No toda diferencia representa un error. Las empresas pueden aceptar variaciones pequeñas por redondeo, peso, tipo de cambio o cargos previamente autorizados. Oracle documenta tolerancias porcentuales y por valor entre factura, orden, recepción e impuestos, y el uso de retenciones cuando la variación supera el umbral.
Las tolerancias deben estar versionadas por entidad, categoría, proveedor o tipo de compra, con un límite claro. El agente no debe ampliar el margen para lograr una coincidencia ni tratar un promedio histórico como autorización.
6. Detecta posibles duplicados
Buscar únicamente el mismo nombre de archivo es insuficiente. La detección puede combinar proveedor, número de factura, entidad, moneda, importe, fecha y referencia. SAP documenta controles de duplicados basados en atributos configurables y la generación de advertencias o errores cuando existe una coincidencia potencial.
Una alerta de duplicado tampoco equivale a fraude ni autoriza borrar un registro. El equipo debe poder comparar documentos, ver cancelaciones o notas crédito y decidir si se trata de un reenvío, una corrección válida o un documento repetido.
7. Enruta excepciones con contexto
Cada diferencia necesita un dueño según su causa. Una recepción faltante puede ir al solicitante o a bodega; un precio fuera de tolerancia, a compras; un impuesto inconsistente, a finanzas; un proveedor no reconocido, a datos maestros o cumplimiento.
El caso debería incluir factura original, documentos relacionados, líneas afectadas, regla aplicada, diferencia calculada, responsable, fecha límite y acción esperada. Así la persona resuelve la excepción sin reconstruir todo el expediente.
8. Registra la decisión y sincroniza el ERP
Cuando una persona corrige, aprueba o rechaza, el resultado vuelve al caso y al ERP con usuario, fecha, motivo y versión de los documentos. Los reintentos deben ser idempotentes: una integración repetida no puede contabilizar dos veces la factura ni duplicar una tarea de aprobación.
La contabilización y el pago permanecen detrás de permisos y segregación de funciones. El agente puede preparar o enviar una transacción permitida al workflow, pero no debe saltar una retención ni utilizar credenciales de una persona con más privilegios.
Factura estándar vs. excepción
| Situación | Automatización posible | Control necesario |
|---|---|---|
| Coincidencia completa dentro de tolerancia | Preparar y enviar al workflow definido | Validaciones del ERP y trazabilidad |
| Recepción parcial | Comparar contra saldo recibido y facturado | No superar cantidad acumulada |
| Precio fuera de tolerancia | Crear excepción para compras | Aprobación de cambio o corrección |
| Posible duplicado | Bloquear avance y mostrar coincidencias | Revisión antes de contabilizar |
| Factura sin orden | Aplicar ruta específica de no-PO | Responsable, centro de costo y aprobación |
| Cambio de cuenta bancaria | Separar del flujo de factura | Verificación independiente del proveedor |
| Datos ilegibles o ambiguos | Solicitar corrección o revisión | No completar campos inventados |
Qué puede hacer el agente y qué conserva una persona
| El agente puede apoyar | Requiere sistema o persona autorizada |
|---|---|
| Capturar campos y líneas con evidencia | Confirmar un dato ambiguo |
| Buscar orden, recepción y contrato | Crear una orden retroactiva |
| Calcular diferencias y aplicar reglas vigentes | Cambiar tolerancias o política |
| Detectar coincidencias de posible duplicado | Declarar fraude o eliminar documentos |
| Preparar y asignar una excepción | Aprobar una diferencia material |
| Actualizar estados permitidos | Contabilizar o liberar el pago fuera del workflow |
El AI RMF de NIST plantea gobernar, mapear, medir y gestionar los riesgos de los sistemas de IA durante su ciclo de vida. En cuentas por pagar, esto se traduce en probar documentos y proveedores diversos, medir errores de extracción y matching, limitar permisos, conservar evidencia, monitorear cambios y mantener revisión humana donde una decisión pueda producir un pago incorrecto o bloquear injustamente a un proveedor.
Integraciones mínimas
- Inbox o portal donde se reciben las facturas.
- ERP o sistema contable para proveedores, órdenes, recepciones, impuestos y estados.
- Repositorio documental para conservar originales y versiones.
- Workflow de aprobaciones con responsables, suplencias y límites.
- Sistema de compras o contratos cuando la orden no contiene todo el contexto.
- Webhooks o APIs con autenticación, idempotencia y permisos mínimos.
- CRM o inbox omnicanal cuando la comunicación con el proveedor debe quedar relacionada con el caso.
No siempre es necesario reemplazar el ERP. Seelai puede actuar como una capa operativa que recibe eventos, prepara verificaciones y coordina excepciones, mientras el sistema financiero conserva los registros contables y controles que ya funcionan.
Métricas para evaluar un piloto
Empieza con una entidad, un grupo de proveedores y facturas con orden de compra. Compara contra una línea base y mide:
- Tiempo desde recepción hasta primera verificación.
- Porcentaje de campos y líneas extraídos sin corrección.
- Facturas con matching completo de dos o tres vías.
- Excepciones correctas y falsos positivos por tipo.
- Duplicados detectados antes de contabilizar o pagar.
- Tiempo de resolución por compras, operación y finanzas.
- Facturas devueltas por evidencia o datos faltantes.
- Correcciones posteriores a contabilización.
- Descuentos por pronto pago aprovechados sin aumentar errores.
- Acciones sin trazabilidad o intentos bloqueados por permisos.
El objetivo no debería ser maximizar la tasa de procesamiento sin contacto humano. Una factura verdaderamente automatizable es aquella que pasa controles definidos con evidencia suficiente. Las demás deben llegar a la persona correcta más rápido y mejor explicadas.
Cómo iniciar sin automatizar todo cuentas por pagar
Selecciona un flujo estable: facturas con orden, proveedores recurrentes y recepciones registradas. Documenta las tolerancias actuales y confirma quién resuelve cada excepción. Después prueba casos normales y adversos: entrega parcial, número de orden incorrecto, factura duplicada, nota crédito, cambio de moneda, línea adicional, impuesto inesperado, archivo ilegible, proveedor inactivo, integración caída y reintento del mismo evento.
Amplía el alcance solo cuando el equipo pueda reconstruir por qué cada factura avanzó, se retuvo o se escaló. Las facturas sin orden, contratos complejos y cambios bancarios pueden incorporarse después mediante rutas y controles propios.
Preguntas frecuentes
¿La IA reemplaza el matching del ERP?
No necesariamente. El ERP puede conservar la política, las tolerancias, el workflow y la contabilización. El agente ayuda a transformar documentos, localizar relaciones y preparar excepciones para que el matching existente reciba datos más completos.
¿Una factura que coincide puede pagarse automáticamente?
La coincidencia es una condición de control, no una autorización universal de pago. La empresa debe mantener sus aprobaciones, segregación de funciones, retenciones, validaciones contables y calendario de pagos.
¿Qué ocurre con las facturas sin orden de compra?
Deben usar un flujo específico. La IA puede clasificar el gasto, buscar contrato o responsable y reunir soportes, pero no debería inventar una orden para hacer pasar la factura por un control que no cumplió.
¿Cómo se evita que el agente complete datos incorrectos?
Con extracción enlazada a evidencia, umbrales de confianza, validaciones contra datos maestros y una regla de abstención. Si hay dos valores plausibles o falta soporte, el sistema solicita revisión en lugar de elegir por conveniencia.
Dónde encaja Seelai
Seelai conecta agentes de IA, automatizaciones, inbox omnicanal y software operativo para convertir una factura en un expediente verificable. El agente captura y relaciona información; el ERP aporta órdenes, recepciones, reglas y estados; el workflow conserva aprobaciones; y las excepciones llegan al equipo con evidencia y siguiente acción.
El resultado esperado no es pagar más rápido a cualquier costo. Es reducir digitación y búsqueda manual, detectar diferencias antes de contabilizar y permitir que cuentas por pagar se concentre en excepciones reales sin perder control financiero.
Fuentes
- Microsoft Learn, Vendor invoices overview: https://learn.microsoft.com/en-us/dynamics365/finance/accounts-payable/vendor-invoices-overview
- Microsoft Learn, Automated vendor invoicing processes overview: https://learn.microsoft.com/en-us/dynamics365/finance/accounts-payable/auto-vendr-invc-process
- Microsoft Learn, Record vendor invoice and match against received quantity: https://learn.microsoft.com/en-us/dynamics365/finance/accounts-payable/tasks/record-vendor-invoice-match-against-received-quantity
- Oracle Payables Help, Invoice Tolerances: https://docs.oracle.com/cd/A60725_05/html/comnls/us/ap/toleranc.htm
- SAP Help Portal, Check for Duplication of Invoice Entry: https://help.sap.com/docs/SAP_S4HANA_ON-PREMISE/ed84b70c199d4470ae2e5ccb93b2e45b/a971b6531de6b64ce10000000a174cb4.html
- NIST, Artificial Intelligence Risk Management Framework (AI RMF 1.0): https://www.nist.gov/publications/artificial-intelligence-risk-management-framework-ai-rmf-10
Si tu equipo todavía compara facturas, órdenes y recepciones entre correos, hojas y pantallas del ERP, agenda una demo de Seelai en /demo. Revisaremos un tipo de factura, sus documentos fuente, tolerancias, responsables e integraciones para diseñar un piloto de verificación con IA sobre tu operación real.