TL;DR: Un ERP robusto debe permitir crear una orden de pago, enviarla a una bandeja “por aprobar” para un rol aprobador, y confirmar la ejecución mediante estados como “aprobado” y “procesado”, dejando trazabilidad (quién aprobó, cuándo, y qué se aprobó). iSiore GO soporta este enfoque de control para tesorería, con visibilidad de estados y un flujo pensado para operación real (incluyendo confirmación de procesamiento cuando el banco acepta la propuesta).
Por qué este tema importa (y por qué no es “solo tesorería”)
En empresas medianas y grandes, el pago a proveedores es un proceso donde se cruzan tres cosas que a dirección le importan muchísimo:
- Control interno: quién autoriza la salida de dinero, bajo qué reglas y con qué evidencia.
- Riesgo: un pago mal enviado (importe incorrecto, duplicado, retención ignorada, proveedor equivocado) no se “deshace” con facilidad.
- Velocidad con orden: el volumen crece, pero no quieres que el proceso se vuelva una cadena de correos, WhatsApps y “yo pensé que ya lo aprobaste”.
Por eso, cuando alguien busca “flujo de aprobaciones de pagos en ERP”, rara vez está buscando teoría. Normalmente está comparando software y quiere asegurarse de que el ERP que está evaluando tenga estas capacidades:
- Bandeja por aprobar.
- Roles claros.
- Estados claros (por aprobar, aprobado, procesado)
- Evidencia (bitácora/historial)
Este post no es un manual, es una guía para que valides rápido si tu ERP tiene el workflow que tu operación realmente necesita.
Respuestas rápidas
¿Qué es una orden de pago en un ERP?
Es el documento interno que agrupa uno o varios comprobantes y define cómo se realizará un desembolso: desde qué cuenta sale, a quién se paga, cuándo se paga y qué conceptos se están pagando. En un ERP serio, la orden de pago no es solo “una pantalla”; es el punto de control del proceso.
¿Qué significa “por aprobar”?
Significa que la orden de pago está lista desde el punto de vista operativo, pero aún no está autorizada. Debe esperar la revisión/confirmación de un usuario con rol aprobador. Si no existe esta etapa (o si es informal), el control se va fuera del sistema.
¿Qué significa “aprobado”?
Que un aprobador ya dio el visto bueno para ejecutar el pago. A nivel de control interno, este estado debería quedar registrado con: quién aprobó, cuándo aprobó y qué aprobó.
¿Qué significa “procesado/procesada”?
En la práctica, “procesado” es el estado que más le interesa a dirección porque responde a la pregunta real: ¿ya se ejecutó?
En flujos integrados con banca, “procesado” suele aparecer cuando el banco acepta la propuesta y el pago pasa el punto de no retorno (en tu operación pueden existir matices, pero el concepto es el mismo: “aprobado” no siempre equivale a “ejecutado”).
Aprobado vs procesado: ¿cuál es la diferencia práctica?
- Aprobado = autorizado internamente.
- Procesado = ya aceptado/ejecutado en el circuito bancario (o al menos ya pasó el hito operativo que confirma ejecución).
Si el ERP no diferencia estos estados, tu equipo termina confirmando pagos “a ojo”.
¿De qué depende el tiempo hasta “procesado”?
Depende del banco, del canal, de horarios de corte y de la ventana operativa. La clave no es prometer “X minutos”, sino que el ERP tenga estado visible y manejo de casos donde se aprueba fuera de horario (porque eso pasa más seguido de lo que cualquiera admite).
Mapa de estados: el lenguaje que tu tesorería debería hablar
Un flujo de aprobaciones no es robusto si no se entiende en qué etapa está cada pago. Como mínimo, deberías ver algo equivalente a esto:
| Estado | Qué significa | Qué decisión habilita |
|---|---|---|
| Creado / Programado | La orden existe, aún puede editarse | Completar datos y enviarla a aprobación |
| Por aprobar | Está lista, pero espera autorización | El aprobador revisa, aprueba o rechaza |
| Aprobado | Autorizada internamente | Puede enviarse al banco / ejecutarse según tu flujo |
| Procesado | Confirmación de ejecución/aceptación en el circuito bancario | Cerrar la ejecución y registrar evidencia |
| Observado / Rechazado (si aplica) | Falta algo o no cumple criterio | Corregir y reenviar a aprobación |
Si tu ERP muestra los estados, el siguiente paso natural es que también puedas ver el “pipeline” mensual: qué está por aprobar, qué ya se aprobó y qué ya está procesado. Esa visibilidad, aunque suene básica, es lo que evita que la tesorería funcione como caja negra.
Dato que suele delatar un workflow débil: cuando el sistema no distingue “aprobado” de “procesado”, tu equipo termina revisando en banca web o en estados de cuenta para confirmar. Eso se puede convertir en rutina… hasta que un día no cuadra.
Matriz de roles: quién puede hacer qué (y por qué a dirección le importa)
La palabra elegante es “segregación de funciones”. La traducción a español de empresa es: no debería ser la misma persona la que prepara y la que autoriza (salvo empresas muy pequeñas).
Un esquema mínimo sano:
- Operador de tesorería: arma la orden de pago, adjunta/comprueba, propone fecha, deja todo listo.
- Aprobador: revisa, valida criterios (montos, proveedor, retenciones si corresponde, prioridad) y aprueba.
En iSiore GO este concepto se refleja en algo práctico: el aprobador ve la lista “por aprobar” y tiene la acción de aprobar; el operador ve su trabajo operativo, pero no necesariamente la acción final de aprobación.
¿Qué debería ver el aprobador?
No basta con una lista. Idealmente, un aprobador debería poder revisar:
- proveedor y concepto,
- importe y moneda,
- comprobante asociado,
- fecha de desembolso,
- observaciones,
- y cualquier regla interna (por ejemplo, retenciones o límites).
¿Qué evidencia mínima debería quedar?
La evidencia no es “para auditoría” solamente. También es para el día a día:
- quién aprobó,
- cuándo aprobó,
- qué se aprobó (detalle de la orden),
- y cuál fue el estado final (procesado).
Esa bitácora es la que te salva cuando, dos meses después, alguien pregunta por qué se pagó algo o por qué se pagó en determinada fecha.
El flujo correcto dentro del ERP: orden → por aprobar → aprobado
Aquí es donde conviene mirar el proceso sin distracciones.
1) Creación de la orden de pago
En la práctica, una orden de pago bien hecha debería incluir como mínimo:
- cuenta de salida (chequera/cuenta corriente),
- fecha de desembolso,
- proveedor,
- periodo/mes (si el proceso se organiza así),
- y la relación de comprobantes/conceptos a pagar.
Lo importante no es solo que “se pueda crear”. Es que sea natural hacerlo mes a mes sin que el equipo sienta que está llenando formularios eternos.
2) Envío a bandeja “por aprobar”
Este es el hito que le da estructura al proceso. Mientras esté “por aprobar”, el pago no debería ejecutarse.
En empresas sanas, esta bandeja se vuelve la pantalla principal del aprobador: entra, revisa, aprueba y despeja el pipeline.
3) Aprobación
Aprobar no es “dar ok”. Aprobar es un acto de control. Por eso, el sistema debería registrar la acción y reflejarla en el estado.
En este punto, si tu operación trabaja con bancos como BCP, lo común es que la aprobación habilite el envío al banco (según el flujo configurado) y el pago empiece a transitar hacia el estado procesado.
Dónde se confirma el “ya se ejecutó”: el estado procesado
La diferencia entre un proceso que se siente profesional y uno que se siente artesanal es esto: confirmación.
Un directivo suele preguntar: “¿Ya está pagado o aún no?”. Y esa pregunta no debería depender de:
- entrar a banca web,
- llamar a alguien,
- o revisar el estado de cuenta manualmente.
En flujos como el descrito, el hito es “procesado/procesada”. Cuando el ERP te muestra procesado, te está diciendo: “esto ya pasó el punto operativo de ejecución”.
Evidencia exportable (para comité, socios o auditoría)
Aunque no todos lo pidan, es una de esas cosas que cuando la tienes, se nota. Lo ideal es poder exportar o mostrar:
- listado de pagos por estado,
- bitácora de aprobación,
- y trazabilidad del documento (orden de pago → aprobación → procesado).
FAQs
¿Puedo tener más de un aprobador?
Lo ideal es que sí, porque en empresas reales hay vacaciones, viajes, comités o montos que requieren segunda firma. Si tu operación lo necesita, pregunta por aprobación por niveles o por montos.
¿Se puede aprobar por niveles o por montos?
No todas las empresas lo requieren, pero cuando hay límites de autorización, el ERP debería permitirlo o al menos permitir roles diferenciados.
¿Qué pasa si está aprobado pero aún no está procesado?
Pasa. Y por eso existe la diferencia entre estados. Lo importante es que el ERP te lo muestre y que el proceso de excepción esté claro (horarios de corte, reintentos, cambios de fecha, etc.).
¿Cómo audito un pago aprobado meses después?
Con dos cosas: bitácora de aprobación (quién/cuándo) y trazabilidad del documento (orden de pago y sus comprobantes asociados) más el estado final (procesado).
Si estás en etapa de evaluación, no te quedes con “sí, sí tiene aprobaciones”. Pide ver:
- la bandeja por aprobar,
- la separación de roles,
- los estados (incluido procesado),
- y la evidencia de quién aprobó.
Ese es el corazón del control interno en tesorería.
- Crea tu cuenta gratis por 7 días en iSiore GO y prueba el flujo con tus roles reales (operador/aprobador) y tus comprobantes de ejemplo.
- O si prefieres ir acompañado: escríbenos por WhatsApp (tienes el botón flotante) y un asesor te ayuda a mapear tu flujo actual y cómo se vería en iSiore GO.
