TL;DR: iSiore GO permite gestionar el flujo de aprobaciones bancarias con BCP desde tesorería: el equipo crea órdenes de pago (incluso pagos masivos a proveedores), un aprobador revisa y aprueba, y el ERP envía la propuesta al banco para el desembolso. El proceso muestra estados como aprobado y procesado, y contempla excepciones (por ejemplo, reprocesar cambiando la fecha cuando un pago aprobado queda pendiente de procesamiento).
Lo que un directivo realmente quiere cuando habla de “aprobaciones bancarias”
Cuando una empresa mediana o grande paga decenas (o cientos) de proveedores, el problema casi nunca es “hacer el pago”. El problema es hacerlo con control y con visibilidad.
Un flujo de aprobaciones bancarias bien implementado te tiene que dar tres cosas:
- Gobierno: quién prepara, quién aprueba y bajo qué reglas.
- Velocidad: pagos masivos sin entrar a la banca web uno por uno.
- Reducción de errores: importes correctos, retenciones contempladas, y estados claros (no “creo que ya se pagó”).
Si hoy tu operación depende de entrar a Telecrédito, buscar opciones, cargar importes manuales y rezar para no equivocarte, entonces ya sabes por qué este tema aparece en las evaluaciones de ERP.
Qué es el flujo de aprobaciones bancarias (BCP) dentro del ERP
En iSiore, el módulo de tesorería está pensado para ejecutar pagos a proveedores con un proceso ordenado.
La idea general es simple:
- Operador: prepara la orden de pago (uno a uno o en masivo).
- Aprobador: revisa y aprueba.
- Banco (BCP): recibe la propuesta y, tras el proceso, se ejecuta el desembolso a la cuenta del proveedor.
Y lo que convierte esto en una herramienta para empresa “seria” es que no te deja a ciegas: puedes ver lo programado del mes, lo aprobado y lo procesado.
Cómo funciona el flujo completo
1) Crear la orden de pago
Aquí se arma el pago desde el ERP.
En la creación se define:
- Chequera / cuenta corriente: eliges desde qué cuenta va a salir el dinero (la “cuenta de la empresa que ejecuta los pagos”).
- Fecha de desembolso: cuándo quieres que se ejecute.
- Proveedor y tipo de pago: proveedores, planillas, CTS, etc. (según cómo opere tu empresa).
- Periodo/mes: para filtrar los comprobantes a pagar.
Luego el sistema te muestra una lista de comprobantes/pendientes del periodo y tú decides cómo construir el pago.
Pagos masivos (cuando el volumen ya manda)
Si tienes 50, 100 o 200 proveedores, hacerlo uno por uno en la banca web es una pérdida de tiempo y una fábrica de errores.
En el flujo descrito, puedes:
- seleccionar el grupo completo (toda la lista),
- o seleccionar algunos,
- agregarlos a la orden,
- y crear la orden de pago.
2) Enviar a aprobación
Una vez armada, se crea la orden y pasa a la bandeja “por aprobar”.
Lo importante aquí es el rol:
- quien prepara, prepara,
- quien aprueba, aprueba.
No es un detalle administrativo. Es control interno.
3) Aprobación (revisión por el aprobador)
La persona que aprueba ve la lista y tiene la opción de revisar y aprobar el pago.
En el video se nota algo muy real: el operador no ve el botón de aprobar, pero el aprobador sí. Ese diseño por perfiles es exactamente lo que una empresa mediana/grande necesita.
4) Procesamiento en el banco (BCP) y estado “procesada”
Una vez aprobado, el ERP envía la propuesta al banco. En el caso descrito, el banco toma un tiempo de procesamiento (mencionan un rango aproximado de 15 a 20 minutos) hasta que la operación quede como procesada.
Ese estado es clave: te evita el “ya lo aprobamos, pero… ¿ya se pagó?”
5) Excepción típica: aprobado, pero no procesado (por horario)
Hay un caso muy común en tesorería: programaste hoy, pero lo aprobaron tarde (por ejemplo, después de cierta hora).
En ese escenario, el pago puede quedar:
- aprobado, pero
- no procesado.
Y eso significa algo simple: el desembolso no llegó al proveedor.
6) Reproceso: cambiar fecha y volver a mandar al banco
Para resolverlo, el flujo descrito contempla:
- cambiar la fecha,
- y usar la opción de actualizar / reprocesar.
Un punto importante: en ese reproceso ya no necesariamente pides una nueva aprobación; lo reprocesas y se manda al banco.
Esto, para empresas con volumen, no es un “extra”: es lo que evita que los pagos se queden colgados por detalles operativos.
Por qué esto supera la banca web (Telecrédito) en empresas con volumen
Cuando el flujo se hace directo en la plataforma del banco, suele pasar lo siguiente:
- terminas haciendo el trabajo uno por uno,
- el armado masivo es más limitado o más manual,
- y si te equivocas con un importe, ya no hay vuelta atrás: se pagó.
En cambio, en el flujo descrito en iSiore:
- puedes agrupar y pagar masivo,
- tienes control por roles,
- y antes de mandar al banco, el sistema te permite revisar lo que estás enviando.
Controles que valen oro para dirección: importes y retenciones
Este tema parece pequeño… hasta que te pasa.
Validación de importes antes de pagar
En banca web, si cargas un importe mal y lo mandas, ya está. Pagado.
En el flujo descrito, el ERP te muestra información para validar y confrontar con el comprobante, y te da alertas/ventanas para que revises antes de ejecutar.
Pagos con retención (recibos por honorarios)
Otro ejemplo práctico: recibos por honorarios con retención.
El punto no es “pagar rápido”, sino pagar correcto. Si hay retención, el pago no debería salir completo. En el flujo descrito se puede editar para contemplar ese ajuste, en lugar de mandar el monto tal cual y recién enterarte después.
iSiore vs Telecrédito (BCP): comparación rápida
| Punto clave | Telecrédito (cuando el flujo depende de la banca web) | iSiore (flujo de aprobaciones bancarias) |
|---|---|---|
| Preparación de pagos | Cargas y procesas en la web del banco | Creas orden de pago desde tesorería |
| Pagos masivos | Más trabajo manual/uno por uno | Selección masiva de comprobantes y envío |
| Control por roles | Depende de cómo lo manejes internamente | Operador prepara / aprobador aprueba |
| Visibilidad | Difícil ver “pipeline” completo | Programado → aprobado → procesado |
| Manejo de errores | Si mandaste mal, ya fue | Revisión/validación antes de mandar |
| Excepciones por horario | Se vuelve operativo y manual | Reproceso con cambio de fecha |
| Trazabilidad | Repartida entre correos y pantallas | Estados y acciones dentro del ERP |
Qué pedir en una demo (si estás evaluando un ERP con aprobaciones bancarias BCP)
Si quieres saber si esto es real y usable en tu empresa, pide una demo con un caso de vida real. Este checklist te ahorra meses:
- Crear una orden de pago por periodo (mes) con varios comprobantes.
- Hacerlo en modo masivo (no “uno por uno”).
- Mostrar que el aprobador tiene el botón de aprobar y el operador no.
- Aprobar y ver el cambio de estado hasta procesado.
- Simular la excepción: “aprobado pero no procesado” (por fecha/horario) y ejecutar reproceso cambiando fecha.
- Editar un pago con retención (recibo por honorarios) para ver control real.
- Ver cómo queda la trazabilidad: quién creó, quién aprobó, cuándo se procesó.
Si en demo la respuesta es “sí, exportas y lo haces en el banco”, entonces no estás comprando flujo: estás comprando un atajo a medias.
FAQs
¿Esto es solo para empresas grandes?
No es por tamaño “en papel”, es por volumen y por necesidad de control. Con pocos pagos puedes sobrevivir con banca web; con volumen y equipos, un flujo con roles y estados te cambia el día a día.
¿Se puede pagar masivo y también uno por uno?
En el flujo descrito, puedes agregar comprobantes en masivo o elegirlos uno por uno según necesidad.
¿Cómo sé si ya se pagó?
Porque el sistema muestra el estado de procesamiento (por ejemplo, procesada), que te confirma que ya pasó por el banco.
¿Qué pasa si aprueban tarde y no se procesa ese día?
Puede quedar aprobado pero no procesado. En ese caso, se gestiona con cambio de fecha y reproceso.
Un flujo de aprobaciones bancarias no es “una pantalla más”. Es una forma de controlar pagos con orden: preparar, aprobar, procesar y tener estados claros.
Si tu empresa está evaluando un ERP para tesorería y trabaja con BCP, lo que quieres ver es exactamente esto: órdenes de pago, aprobación por roles, pagos masivos, estado procesado y manejo de excepciones como el reproceso.
Si quieres, lo vemos con un ejemplo real (anonimizando datos): armamos una orden con 50 proveedores, la pasamos por aprobación y revisamos el estado hasta que quede procesada. Con esa demo, la decisión se vuelve bien obvia.
