Cómo hacer un agente de comprobantes de pago y cobranzas

En 60 segundos: Un agente de comprobantes es un flujo acotado que recibe una imagen o PDF, conserva el original, extrae campos candidatos, consulta pedidos o cuentas por cobrar y explica por qué propone una asociación. El ERP o sistema de CxC sigue siendo la fuente de verdad. Un umbral de confianza sirve para enrutar el caso, pero no concede permisos: nunca se aplica un pago sin reglas aprobadas, validaciones vigentes y el nivel de autorización definido por Finanzas. Los ilegibles, duplicados, importes distintos y casos sin pedido van a cuarentena con evidencia y responsable. Probalo dos semanas en modo sombra y medí auto-match validado, excepciones y tiempo hasta conciliación antes de ampliar su autonomía.

Los comprobantes pueden llegar por WhatsApp, correo o Teams, pero el trabajo central cambia poco: identificar el documento, leerlo, encontrar la cuenta correcta y dejar una decisión trazable. El error habitual es comenzar por el canal o el modelo y llamar «agente» a una secuencia de automatizaciones sin contrato operativo.

Este playbook empieza por ese contrato. La ruta específica para comprobantes recibidos por WhatsApp explica el ingreso por chat. La guía de Outlook y Teams desarrolla la orquestación con Microsoft 365. Acá diseñamos la pieza que ambos canales alimentan.

1. Definí el objetivo como un trabajo verificable

Una primera versión razonable hace cinco trabajos:

1. recibe el archivo y el contexto mínimo del canal;
2. extrae campos candidatos sin alterar el original;
3. busca pedidos, facturas o partidas abiertas elegibles;
4. propone un match o marca una excepción con un motivo concreto;
5. prepara el payload de registro para revisión o ejecución autorizada.

«Gestionar cobranzas» es demasiado amplio. Incluye seguimiento, promesas de pago, disputas, crédito, conciliación y decisiones que este agente no debería asumir. Escribí en cambio una salida comprobable, por ejemplo: «crear un caso con los campos normalizados, un candidato de CxC y la evidencia de cada regla».

Acotá el piloto a un canal, una entidad legal, una moneda y un tipo de comprobante. Definí también qué queda fuera: pagos parciales, combinaciones de varias facturas, notas de crédito o documentos de otra filial pueden empezar como excepciones aunque después se incorporen.

2. Asigná una fuente de verdad a cada dato

El chat o correo demuestra que se recibió un archivo. No demuestra que el dinero llegó ni decide qué saldo cambia. Cada componente conserva una parte distinta del estado:

Componente	Responsabilidad	No debe convertirse en
Chat o correo	Canal, identidad permitida, mensaje y momento de recepción	Libro de cobranzas
Almacenamiento temporal	Original inmutable, hash, metadatos y política de retención	Carpeta que define si un pago fue aplicado
OCR o visión	Texto, campos candidatos y evidencia de lectura	Autoridad financiera
Cola de revisión	Motivo, responsable, prioridad, decisión y antigüedad	Segundo ERP desconectado
ERP o CxC	Cliente, pedido/factura, saldo, aplicación, reversión e historial oficial	Fuente que el agente puede reescribir sin controles

Usá identificadores estables para relacionar mensaje, archivo, caso, candidato y transacción. La guía sobre el coste de recapturar datos entre sistemas ayuda a medir el trabajo que desaparece y el que solo cambia de pantalla.

3. Diseñá permisos y control por acción

Asigná el nivel de autonomía por acción, porque recepción, lectura, recomendación y escritura tienen riesgos diferentes:

Acción	Permiso mínimo	Nivel inicial recomendado	Control
Recibir y conservar el archivo	Lectura del canal y escritura en staging	Ejecución acotada	Formatos, tamaño, malware, hash y retención
Extraer campos	Lectura de la copia de trabajo	Lectura	Esquema, valores originales y confianza por campo
Consultar pedidos o CxC	Vista de solo lectura y campos limitados	Lectura	Entidad, cliente, estado, moneda y fecha de corte
Proponer un match	Sin permiso de escritura financiera	Recomendación	Reglas visibles, candidatos y diferencias
Preparar un asiento o aplicación	Crear borrador, sin contabilizar	Borrador	Payload fijo, saldo actualizado y comprobación de duplicados
Aplicar el pago	Operación específica y revocable	Ejecución aprobada, si la política lo permite	Persona autorizada, segregación de funciones, límites y log

Un umbral de confianza solo clasifica la evidencia. Puede permitir que un caso de alta confianza llegue a match_propuesto; no debería transformar una predicción en permiso financiero. Inmediatamente antes de cualquier escritura autorizada, volvé a consultar saldo, estado, moneda, referencia y duplicados. Si cambió el payload aprobado, la autorización deja de ser válida.

La guía de niveles de control para agentes de IA explica cómo separar lectura, recomendación, borrador y ejecución. En las excepciones, la revisión humana es obligatoria; en los casos normales, la empresa todavía debe decidir si el agente solo prepara el registro o puede ejecutar dentro de un control financiero existente.

4. Elegí herramientas con contratos estrechos

Construí operaciones pequeñas, con entradas y salidas validables, en lugar de conceder acceso general al escritorio o una herramienta genérica para «usar el ERP»:

Tool	Entrada	Salida	Límite importante
ingest_receipt	Archivo e ID del mensaje	case_id, hash y ubicación controlada	No procesa un formato o tamaño no permitido
extract_fields	case_id	Importe, moneda, fechas, referencia, identificadores y confianza por campo	No decide el match ni inventa faltantes
lookup_customer	Identificadores normalizados	Clientes candidatos con IDs internos	El nombre visible del canal no es identidad suficiente
lookup_receivables	Cliente, entidad y filtros aprobados	Pedidos, facturas o partidas abiertas elegibles	Solo lectura y resultado con hora de consulta
enqueue_review	Caso, motivo, evidencia y prioridad	Ítem con responsable y SLA	No acepta una excepción sin causa enumerada
prepare_erp_entry	Candidato y campos validados	Borrador exacto del cambio	No aplica el pago
post_payment	Payload aprobado y autorización vigente	ID y respuesta del ERP	Solo si la política lo permite; idempotencia y log obligatorios

El OCR o la visión documental pueden leer diseños variables. Las reglas deterministas deben normalizar decimales, fechas, moneda, referencias y estados. El modelo puede explicar una discrepancia o proponer candidatos cuando el texto es ambiguo, pero la ausencia de un identificador sigue siendo una ausencia, no una invitación a inventarlo.

5. Modelá un caso antes de modelar una conversación

Como mínimo, guardá:

• case_id, canal, ID del mensaje, hora de recepción y remitente autorizado;
• nombre, tipo, tamaño y hash del archivo original;
• importe y texto original, importe normalizado y moneda;
• fecha de operación separada de la fecha de recepción;
• referencia original y normalizada;
• cliente y documentos candidatos con ID estable;
• resultado de cada regla, diferencia y confianza por campo;
• estado, motivo de excepción, responsable y plazo;
• decisión, actor, versión de política y respuesta del sistema destino.

No reduzcas el caso a un único porcentaje. Un importe puede estar perfectamente leído y pertenecer a otra factura. La calidad de extracción, la fuerza del match y la autorización para escribir son evaluaciones distintas.

6. Construí primero el flujo feliz

Un caso normal debería poder explicarse de punta a punta:

1. El conector recibe una imagen o PDF desde un origen permitido.
2. El ingreso crea case_id, calcula el hash y conserva el original.
3. La extracción devuelve campos candidatos y marca los ausentes o dudosos.
4. Las reglas normalizan formatos sin perder los valores recibidos.
5. El agente resuelve el cliente mediante identificadores acordados.
6. Una consulta de solo lectura recupera documentos elegibles del ERP o CxC.
7. El matching compara referencia, cliente, moneda, importe, fecha, estado y duplicados.
8. Si existe un candidato único dentro de la política, el agente presenta la evidencia y prepara el registro permitido.
9. Una validación final comprueba datos vigentes; la persona o control externo autorizado decide la escritura, y se guarda la respuesta del ERP.

Usá una clave de idempotencia que sobreviva reintentos. Una confirmación enviada al cliente debe depender del resultado aceptado por el sistema de registro, no de que el agente haya terminado de redactarla.

7. Tratá las excepciones como salidas de primera clase

La cuarentena es parte del producto. Cada entrada necesita una causa, evidencia, propietario y próxima acción:

Excepción	Detección	Qué ve la persona	Resolución posible
Ilegible	Faltan campos obligatorios o una zona no puede leerse	Original y campos dudosos	Pedir otro archivo o transcribir bajo el control definido
Posible duplicado	Coinciden hash, referencia o una operación ya registrada	Caso anterior, importe, fecha y estado	Confirmar duplicado o justificar una operación distinta
Importe distinto	El comprobante y el saldo difieren fuera de política	Ambos importes, moneda y diferencia	Mantener pendiente, asociar según política o pedir aclaración
Sin pedido o CxC	No hay candidato elegible	Identidad usada, filtros y búsquedas realizadas	Corregir identidad, asociar manualmente o devolver al remitente
Varios candidatos	Más de un documento supera el filtro inicial	Lista acotada y diferencias por campo	Elegir con justificación o solicitar información
Error de destino	El ERP rechaza o no confirma la escritura	Payload, respuesta y estado antes del intento	Reintentar con idempotencia o escalar sin duplicar

La persona debe poder corregir la extracción, cambiar el candidato, pedir aclaración o cerrar el caso con un motivo. Su decisión vuelve al expediente; no puede quedar solamente en un mensaje. El playbook de Excel a gestión de excepciones muestra cómo convertir estas correcciones en una cola operativa, y no en limpieza invisible.

8. Conservá evidencia, parada y recuperación

El registro debe responder qué llegó, qué leyó el extractor, qué candidatos devolvió el ERP, qué reglas pasaron, qué propuso el agente, quién decidió y qué respondió el sistema. Minimizá datos sensibles en logs y aplicá la retención definida al original, los campos extraídos y las trazas.

Colocá el control de parada fuera del razonamiento del agente. Debe bloquear nuevas escrituras, pausar la cola y permitir revocar la credencial técnica. Prepará también una recuperación manual: identificar la última transacción confirmada, separar casos inciertos, conciliar contra el ERP y reanudar sin repetir operaciones.

Probá al menos archivos repetidos, eventos duplicados, caída del OCR, consulta vencida, cambio de saldo entre propuesta y aprobación, timeout del ERP y respuesta ambigua del destino.

9. Ejecutá un piloto de dos semanas

Empezá en modo sombra: el agente recibe, extrae, busca y propone, mientras el equipo mantiene el proceso vigente. No uses el piloto para probar todos los canales y documentos a la vez.

Semana 1: cobertura y reglas

• Documentá una línea base de tiempo hasta conciliación, excepciones y retrabajo.
• Procesá una muestra autorizada y minimizada; usá documentos sintéticos para desarrollo.
• Compará campos y matches propuestos con la decisión real del equipo.
• Clasificá cada fallo por extracción, identidad, reglas, datos del ERP o política ausente.
• Ajustá esquema, candidatos y tarjeta de revisión; no ocultes errores aumentando el umbral sin analizar la causa.

Semana 2: operación y recuperación

• Abrí la cola a sus responsables y medí capacidad, antigüedad y resolución.
• Permití preparar borradores solo para el alcance que funcionó en sombra.
• Probá reintentos, duplicados, parada y recuperación con casos controlados.
• Conciliá casos recibidos, propuestas aceptadas, excepciones y respuestas del ERP.
• Decidí si continuar, corregir el alcance o mantener el proceso manual.

Métrica	Definición útil
Tasa de auto-match validado	Casos con candidato único confirmado por el equipo ÷ casos recibidos elegibles
Tasa de excepción	Casos enviados a cuarentena ÷ casos recibidos, separada por causa
Tiempo hasta conciliación	Desde la recepción hasta la asociación correcta confirmada en CxC
Falsos positivos	Matches propuestos o aceptados que la validación determina incorrectos
Retrabajo	Casos corregidos, reabiertos, recapturados o conciliados manualmente
Antigüedad de cola	Tiempo abierto por causa, prioridad y responsable

Un auto-match alto no compensa un falso positivo financiero. Publicá resultados solo con la muestra, el periodo y el alcance propios; no prometas una precisión de OCR ni un retorno extrapolado desde una demo.

10. Reconocé cuándo no construirlo

No empieces por un agente si el volumen es bajo y una bandeja compartida con un formulario resuelve el problema; si el ERP no expone IDs y estados confiables; si Finanzas todavía no acordó cómo tratar diferencias, parciales o duplicados; o si nadie puede operar la cola.

Tampoco avances a escritura cuando no existe una API o mecanismo soportado, no podés limitar permisos, no hay idempotencia ni respuesta verificable, o el equipo no sabe detener y conciliar el proceso. En esos casos, una primera mejora puede ser estandarizar el canal, exigir campos mínimos, limpiar datos maestros o producir una vista de solo lectura.

El agente tiene sentido cuando conecta un trabajo frecuente y acotado con fuentes confiables, reglas explícitas y responsables disponibles. Cada comprobante debe terminar asociado, en revisión o rechazado con una razón que el equipo pueda comprobar.