Cuentas por pagar: un agente nunca debe proponer, aprobar y contabilizar la misma transacción
Por Equipo Quantum Developers
Resumir:
Tesis operativa
El riesgo de un agente de cuentas por pagar no empieza cuando interpreta mal una factura. Empieza cuando una misma identidad puede crear la propuesta, aprobarla y hacer que llegue al libro o al pago. La tesis es categórica: la autonomía segura exige tres autoridades separadas para proponer, aprobar y contabilizar, con identidad, evidencia y estado verificables en cada transición.
Los Standards for Internal Control in the Federal Government de GAO presentan segregación de funciones, autorización y documentación como actividades de control para responder a riesgos. El principio no desaparece porque una tarea la ejecute software. Si varios pasos se ejecutan bajo el mismo principal técnico, con el mismo permiso y sin una aprobación independiente, tres pantallas no equivalen a tres controles.
Tres autoridades, no tres mensajes del mismo agente
El diseño mínimo distingue:
| Función | Puede hacer | No puede hacer |
|---|---|---|
| Propuesta | extraer datos, validar duplicados, cotejar orden y recepción, sugerir codificación | aprobar su propuesta, cambiar banco, contabilizar |
| Aprobación | revisar evidencia, aceptar, rechazar, devolver o pedir excepción | alterar silenciosamente el documento, ejecutar pago |
| Contabilización | verificar aprobación vigente y escribir al ERP | crear aprobación, cambiar beneficiario, omitir un bloqueo |
Cada función necesita una identidad diferente y permisos mínimos. La aprobación debe provenir de una persona o servicio de política independiente del agente proponente. La contabilización debe rechazar cualquier objeto que no tenga aprobación válida, versión coincidente y controles previos completos.
Separar modelos o prompts no basta. Tampoco basta que el mismo orquestador invoque tres herramientas con nombres distintos si conserva credenciales capaces de hacer todo. La frontera se implementa en autorizaciones del sistema de registro, no solo en instrucciones lingüísticas.
Una máquina de estados que el ERP pueda hacer cumplir
Una factura puede recorrer estados explícitos:
recibida → validada → propuesta → en revisión → aprobada → lista para contabilizar → contabilizada → programada para pago.
Las transiciones de rechazo, devolución, bloqueo y cancelación deben ser igualmente visibles. Cada transición guarda actor, rol, hora, versión del objeto, regla aplicada y artefacto de evidencia. Una modificación material —importe, proveedor, cuenta bancaria, moneda, orden o centro de costo— invalida la aprobación anterior y devuelve el objeto al estado requerido.
La guía de Oracle indica que las facturas y líneas sujetas a aprobación deben completarla antes de quedar disponibles para pago en su documentación de Invoice Approval Workflow. La implementación concreta varía por ERP, pero el diseño debe aprovechar esas restricciones nativas. Un agente no debería “recordar” respetarlas; el sistema debe impedir que las salte.
El cambio bancario es otro proceso
Una factura aparentemente válida puede desviar fondos si el beneficiario fue modificado. Por eso, la cuenta bancaria del proveedor no es un dato editable dentro del mismo caso. Es un objeto protegido con su propio solicitante, evidencia, verificación por canal independiente y aprobador.
Microsoft documenta un flujo en el que cambios de cuenta bancaria de proveedor protegidos se envían a aprobación y los valores propuestos no se usan hasta ser aprobados en Dynamics 365 Finance. El patrón es más importante que el producto: “cambio propuesto” y “dato activo” son estados distintos.
El agente de factura puede detectar que la cuenta difiere y bloquear el caso. No debe crear la nueva cuenta, aprobarla y continuar. Incluso una aprobación de factura válida debería quedar invalidada si cambia el beneficiario antes del pago.
El paquete de evidencia por transacción
Cada propuesta debería conservar:
- identificador de factura, proveedor y entidad legal;
- hash o referencia inmutable del documento recibido;
- orden de compra, recepción y tolerancias aplicadas;
- detección de duplicado y población consultada;
- codificación sugerida y regla o evidencia que la respalda;
- versión de datos maestros y estado bancario;
- excepciones, conflicto de interés y señales de riesgo;
- identidad de proponente, aprobador y contabilizador;
- aprobaciones, comentarios, marcas de tiempo y expiración;
- identificador de asiento y, después, resultado del pago.
El paquete no necesita exponer datos sensibles en un panel general. Debe permitir que un revisor autorizado reconstruya la decisión sin depender de la memoria del agente.
Ejemplo ilustrativo: factura con cambio de beneficiario
Una factura llega con orden y recepción coincidentes. El agente extrae importe, propone codificación y detecta que la cuenta indicada no coincide con el maestro. Aunque todo lo demás pase, crea una excepción y bloquea la transición a aprobación de pago. Un responsable de datos maestros verifica la solicitud por un canal previamente registrado; otro rol aprueba el cambio. Solo entonces se genera una nueva versión del proveedor.
La propuesta de factura anterior no continúa automáticamente: vuelve a validación porque cambió un dato material. El aprobador revisa la nueva versión y el servicio de contabilización confirma que el token de aprobación corresponde exactamente a esa versión. Este ejemplo no afirma que toda organización requiera el mismo número de personas. Demuestra que una identidad no puede controlar todos los puntos de decisión.
Controles técnicos que hacen real la separación
Use credenciales por función, permisos de corta duración, doble control para cambios críticos y validaciones en el lado del ERP. Una política debe comparar actor proponente con aprobador y rechazar coincidencias prohibidas. Otra debe validar monto, entidad, moneda, beneficiario y versión antes de contabilizar. Los logs deben ser resistentes a alteración y las alertas llegar a alguien fuera de la cadena ejecutora.
El modo degradado también importa. Si la aprobación o el sistema de evidencia no está disponible, la factura queda en cola; no pasa por una ruta “temporal” con permisos mayores. Las cuentas de emergencia requieren autorización, tiempo limitado y revisión posterior.
En Quantum Automation Center, la cronología, los artefactos, las aprobaciones humanas y los estados de ejecución pueden reunir la vista operativa. La separación efectiva sigue viviendo en identidades y permisos de los sistemas conectados. Quantum debe mostrarla y orquestarla, no simularla.
Métricas que no premian el atajo
Tiempo de ciclo y costo por factura son útiles, pero insuficientes. Añada tasa de propuestas aceptadas, cobertura de resultado, duplicados evitados, excepciones por causa, aprobaciones expiradas, cambios materiales posteriores a aprobación, intentos bloqueados por segregación y tiempo de resolución de discrepancias.
Reporte automatización por estado. “Procesada automáticamente” no debe mezclar extracción, propuesta, aprobación y contabilización. Una tasa alta puede ser peligrosa si se logra reduciendo revisiones o ampliando permisos. El ROI se calcula sobre mejora atribuible y costo total de control, no sobre documentos tocados por el agente.
El mejor contraargumento
En una empresa pequeña, separar tres funciones puede ser lento y costoso cuando pocas personas cubren todo el ciclo. El control puede producir acumulación y pagos tardíos, mientras un propietario ya revisa personalmente los movimientos bancarios.
La objeción es real. La respuesta no es fingir separación. Se aplican controles compensatorios: límites de importe, aprobación externa para excepciones, conciliación diaria independiente, alertas bancarias, revisión posterior y prohibición absoluta de cambios bancarios dentro del flujo de factura. Si una persona debe acumular funciones, otra evidencia debe detectar oportunamente el abuso o error.
Cuándo no usar este enfoque
No permita ejecución autónoma cuando no existe separación efectiva, la identidad del proveedor no está verificada o el ERP no puede hacer cumplir estados y permisos. Mantenga al agente como extractor y proponente hasta que esos controles existan.
Tampoco automatice pagos de excepción para “recuperar” velocidad. El mejor uso inicial suele estar antes del punto irreversible: reunir evidencia, detectar duplicados, proponer codificación y enrutar. El éxito no es eliminar personas del flujo; es reservar su juicio para la autorización que ninguna misma identidad debe concederse a sí misma.
Sources
Temas del artículo
