Instrucción, registro, ejecución, rechazo o devolución y conciliación tratados como estados distintos de un mismo recorrido — cada uno con su fuente, su responsable y la confirmación que lo da por ocurrido.
01 · El problema
Una nómina de pagos se autoriza el martes. El jueves el proveedor pregunta por su transferencia, contabilidad ve un cargo que no reconoce y tesorería revisa si el archivo llegó a enviarse. Son tres preguntas distintas y ninguna se responde mirando el mismo lugar.
El problema es de tesorería y de cuentas a pagar, y reaparece en cada ciclo: cuando se envía la nómina, cuando el canal devuelve un rechazo y cuando hay que cerrar el período. Contabilidad y control financiero lo heredan al final, con partidas que nadie puede explicar sin reconstruir el camino conversación por conversación.
El seguimiento se arma con lo que hay a mano: planillas de Microsoft Excel donde se lleva la nómina de pagos y sus observaciones, correo para pedir el comprobante o avisar de un rechazo, y reporting en Microsoft Power BI sobre el saldo pendiente de pago. Cada pieza cumple una función útil y ninguna deja constancia de quién instruyó, quién autorizó, qué devolvió el canal y qué quedó conciliado.
Mostrar estados financieros no desarrolla por sí solo un proceso de conciliación: un tablero informa el saldo, y todavía falta el recorrido que lleva cada pago hasta su confirmación.
02 · La solución
El recorrido separa lo que en la práctica viaja junto: la instrucción de pago, su registro en el sistema responsable, la ejecución por el canal acordado, el rechazo o la devolución cuando ocurren, y la conciliación contra el movimiento real. Cada estado tiene su fuente, su responsable y su evidencia, y ninguno se da por ocurrido porque el anterior haya avanzado.
El recorrido nace de las definiciones aprobadas del Operational Graph: cada instrucción queda conectada con el documento que la origina, la sociedad, la cuenta de cargo, el beneficiario y el responsable autorizado del tramo. BPMflow sostiene el trabajo del caso —bandeja, asignación, plazos, autorizaciones y evidencia—, de modo que el proceso nace del grafo y no de un diagrama aislado.
La excepción de factura es la antecesora de este recorrido: mientras la diferencia no está resuelta y autorizada, no hay instrucción que emitir —ese trabajo vive en Invoice Exception Resolution—. El proveedor pregunta por el estado de su pago en Supplier Service Desk for Shared Services, y cuando el desembolso proviene de una autorización presupuestaria, ese antecedente llega desde Finance Shared Services — Budget Approval Workflow.
03 · Capacidades
Las instrucciones quedan en una bandeja única, con su estado, su fuente de confirmación, su antigüedad y su autorización pendiente a la vista. Max responde sobre el caso dentro del contexto autorizado: explica en qué estado está el pago, muestra la evidencia registrada y señala al responsable siguiente.
Abre el caso desde la factura conformada, la nómina programada, el anticipo acordado, el reembolso aprobado o la instrucción puntual, con el documento que la sustenta a la vista.
Aplica la regla que corresponde al monto, a la sociedad y a la cuenta de cargo, y conserva la autorización con su autor y su momento.
Un cambio de cuenta del beneficiario se trata como un evento aparte, con comprobación por el canal y los responsables que define la organización. La revisión documental no equivale por sí sola a confirmar la titularidad.
Deja constancia de qué se envió, cuándo y por qué canal, y registra el acuse o el número de operación que devuelve la fuente autorizada.
Clasifica el motivo devuelto —cuenta inválida, beneficiario observado, límite excedido, retención— lo asigna a quien puede corregirlo y reabre la autorización cuando el dato cambia.
Relaciona el cargo del extracto con la instrucción y el documento, y deja las diferencias y las partidas sin identificar como trabajo asignado, con responsable y plazo.
04 · Confirmación por estado
No hay un único confirmador para todo el recorrido. Cada estado se da por ocurrido con la evidencia y la fuente acordadas para ese evento: en unos casos responde el sistema responsable y en otros, la persona autorizada.
01
Fuente
El documento que la origina —factura conformada, nómina, contrato o solicitud— y la regla de autorización aplicable.
Quién o qué confirma
El responsable autorizado del tramo, con su aprobación registrada. Antes de eso hay una solicitud, no una instrucción.
02
Fuente
El ERP o el sistema de tesorería donde queda asentada la orden.
Quién o qué confirma
El propio sistema, con el número de documento y el estado que devuelve. Una autorización que no llegó a asentarse sigue pendiente.
03
Fuente
El canal de pago que la organización tenga acordado con su entidad.
Quién o qué confirma
El estado explícito de ejecución que devuelve ese canal, o el movimiento correspondiente en la fuente autorizada. Un acuse de recepción confirma el envío, no la ejecución. EAFlow no ejecuta el pago ni sustituye ese canal.
04
Fuente
El motivo devuelto por el canal, o el hallazgo en la revisión del movimiento.
Quién o qué confirma
Quien registra el motivo: el canal cuando lo informa, o el analista de tesorería cuando lo identifica. En ambos casos el caso queda reabierto.
05
Fuente
El extracto o el archivo de movimientos de la cuenta, contrastado con la instrucción y el documento.
Quién o qué confirma
El responsable de conciliación, y el cierre contable cuando la organización lo exige para ese período.
05 · Roles
Un mismo pago pasa por manos distintas y cada una responde por un tramo del recorrido. Ninguna confirma los estados de las otras, y esa separación es la que permite saber, sin preguntar, dónde quedó detenido.
Arma la nómina y sostiene el caso hasta su cierre.
Qué ve
El recorrido de cada pago por estado, vencimiento, sociedad, cuenta de cargo y canal, con el documento que lo sustenta.
Qué hace
Prepara la solicitud, la eleva a autorización, envía por el canal acordado y registra el acuse, el rechazo o la devolución.
Autoriza dentro del alcance que le corresponde.
Qué ve
Las solicitudes pendientes de su tramo, con el documento de origen, el beneficiario, la cuenta y el monto en juego.
Qué hace
Autoriza, rechaza o devuelve con observación. La decisión del desembolso permanece en la organización.
Cierra el recorrido contra el movimiento real.
Qué ve
Los cargos del período con su instrucción asociada, y las partidas que todavía no tienen documento ni explicación.
Qué hace
Relaciona el movimiento con la instrucción y el documento, abre la diferencia como caso y confirma la conciliación del período.
Corrige el dato o el documento que detiene su pago.
Qué ve
El estado del pago que lo involucra y qué información falta, en su propio caso y con acceso acotado.
Qué hace
Responde la observación, actualiza su documentación y sigue el avance sin llamar por teléfono a cada área.
06 · Implementación
El trabajo parte del proceso actual: alcanza con el contexto mínimo del primer tipo de pago, sin un proyecto de arquitectura previo y sin tocar el canal que la organización ya tiene acordado con su entidad. El alcance se define por tipo de pago, no por volumen: un ciclo de pocas operaciones puede concentrar todo el riesgo de error del período.
1 · Acordar el resultado
Qué pagos entran, qué regla autoriza cada tramo, qué evidencia cierra cada estado y quién o qué sistema lo confirma en esa organización.
2 · Conectar la fuente de cada estado
Toma el documento de origen y la orden desde el ERP y el sistema de tesorería, y recibe el acuse y el movimiento desde el canal y el extracto acordados como fuente autorizada.
3 · Probar el recorrido e incorporarlo
Se prueba con una nómina del período en curso hasta conciliarla, se ajustan reglas, motivos de rechazo y plazos, y la operación diaria queda bajo control del equipo del cliente.
07 · Escenarios típicos
Varias sociedades, varias cuentas de cargo y más de un canal; nóminas periódicas conviviendo con pagos puntuales urgentes. Los escenarios siguientes son ilustrativos: los tipos de pago y los motivos que aplican se acuerdan con cada organización.
Un pago se cierra cuando cada estado tiene su confirmación: la instrucción autorizada, el registro asentado, la ejecución confirmada por el canal y el cargo conciliado contra el documento que lo originó. Un rechazo o una devolución devuelve el pago al recorrido antes de llegar ahí. Conviene empezar por un tipo de pago y seguirlo hasta conciliarlo.
Corporate Payments and Reconciliation es una solución transversal de EAFlow sobre el Operational Graph, sostenida por las capacidades de automatización de BPMflow. Coordina el recorrido y registra la confirmación de cada estado; la decisión del desembolso, la ejecución del pago y la infraestructura bancaria permanecen en la organización y en sus entidades. Los tramos de autorización, los motivos de rechazo y las fuentes de confirmación se configuran con cada organización.
