Automatizar cobranzas: cuándo enviar y frenar recordatorios

Una factura vencida puede seguir abierta en el ERP aunque el cliente haya avisado que pagó. También puede tener un pago parcial, una nota de crédito pendiente o una conversación que requiere intervención de Finanzas. Programar una secuencia por fecha no resuelve esas diferencias.

Para Finanzas, Operaciones e IT, la pregunta concreta es si el próximo contacto sigue siendo válido. Llamamos elegibilidad del envío a esa decisión basada en información actual y reglas aprobadas. Los criterios que siguen son recomendaciones para evaluar una solución; no son requisitos legales.

Definí qué fuente manda para cada dato: saldo en el ERP, señal de pago en el canal correspondiente, disputa en la herramienta de gestión y contacto realizado en el historial de comunicaciones. Si dos fuentes discrepan, hace falta una regla de resolución, no elegir la que permita enviar.

Esta matriz propone condiciones de pausa y de reanudación que podés pedir como pruebas de aceptación:

La fecha prevista de una promesa no debe convertirse por sí sola en una nueva exigencia de pago. Dejá registrado quién revisa ese compromiso y qué regla autoriza retomar. Tampoco alcanza con que un dato sea reciente: debe corresponder a la misma factura, empresa y moneda.

La tolerancia a datos desactualizados necesita una definición operativa. Pedí que Finanzas e IT acuerden qué fuente se consulta antes del envío, cómo se detecta una falla y cuándo se bloquea. Un valor copiado ayer puede seguir pareciendo válido si nadie conserva la hora de actualización.

Supongamos una empresa que actualiza facturas una vez al día. Después de esa actualización, un cliente informa una transferencia. El recordatorio ya estaba preparado con el saldo anterior y todavía no salió.

En este ejemplo ficticio, el resultado esperado es retirar ese mensaje de la cola, conservar la señal recibida y pedir revisión. El aviso no demuestra por sí mismo que el dinero esté acreditado ni que corresponda a esa factura. Pero sí aporta un motivo para frenar el contacto hasta aclararlo.

Si Finanzas confirma un pago parcial, el borrador anterior pierde validez. Si el pago cubre todo, no corresponde continuar la secuencia. Si no se puede identificar, la excepción queda visible para su responsable; no se transforma automáticamente en una afirmación de deuda confirmada.

La conciliación bancaria resuelve la relación entre movimientos y registros internos. El seguimiento de cobranzas consume ese resultado y otras señales para decidir la próxima comunicación. Son responsabilidades conectadas, con criterios distintos.

Primero comprobá si el recordatorio del sistema actual alcanza. Colppy anuncia recordatorios automáticos de cobranza. La documentación estadounidense de Zoho Books describe recordatorios y opciones para detenerlos o pausarlos según una fecha prevista de pago. Verificá las funciones de tu edición, país y configuración; esas páginas no prueban compatibilidad con tu operación.

Una plataforma especializada puede tener sentido si el equipo necesita gestionar disputas, promesas y responsables en un lugar compartido. Intiza describe avisos automáticos y seguimiento de situaciones como disputas o pagos no acreditados. Pedí ver cómo esos estados afectan un mensaje ya preparado, no sólo que existan en una pantalla.

La integración acotada sirve cuando la función de cobranza funciona, pero falta una conexión para actualizar o detener el envío. Un detalle documentado por Cobrofy ilustra por qué hay que preguntar por cada sistema: para facturas ya importadas de Contabilium, su página indica que pagar allí no actualiza automáticamente ese estado en Cobrofy; el pago debe registrarse en Cobrofy. Importar una factura no garantiza conocer su pago.

Fuentes consultadas el 7 de noviembre de 2026. Son ejemplos de capacidades y límites publicados, no un ranking. Mantené el recordatorio nativo si pasa tus pruebas; comprá gestión de equipo si eso es lo que falta; integrá sólo el tramo que no transmite el estado necesario.

La demostración debería cubrir cambios entre la preparación y el envío. Estas son pruebas propuestas para acordar con el proveedor, no pruebas ejecutadas sobre los productos citados:

1. Cambio de saldo. Preparar un mensaje y registrar después un pago parcial o nota de crédito. Resultado esperado: el contenido anterior queda invalidado y se consulta el nuevo saldo.

2. Pago informado y disputa. Introducir cada señal antes del envío. Resultado esperado: pausa visible, motivo registrado y un responsable de revisión.

3. Promesa vigente y vencida. Comprobar la pausa y luego la revisión prevista. Resultado esperado: reanudación según regla aprobada, sin inventar un acuerdo nuevo.

4. Fuente caída. Interrumpir la actualización del estado. Resultado esperado: bloquear los mensajes afectados y alertar, aunque el borrador ya exista.

5. Respuesta incierta. Simular un envío cuyo resultado no se conoce. Resultado esperado: consultar el historial del proveedor antes de permitir otro intento.

6. Contacto duplicado. Registrar un contacto manual mientras otro sistema prepara el mismo recordatorio. Resultado esperado: un solo componente conserva permiso para enviar. Repetir además la ejecución del proceso o webhook con la misma clave de acción, definida por factura, canal y etapa: esa repetición no debe generar un segundo envío.

7. Corte operativo. Activar la pausa general con mensajes pendientes. Resultado esperado: no salen nuevos contactos y el reinicio requiere un responsable autorizado.

Pedí evidencia que permita reconstruir cada decisión: identificador de factura, versión del saldo, fecha de consulta, motivo del bloqueo, aprobación aplicable e identificador del mensaje. Un contador de envíos no demuestra que los contactos hayan sido correctos.

Un primer alcance posible conecta las fuentes relevantes y genera una cola de casos con motivos verificables. Finanzas revisa las propuestas mientras IT confirma que se actualizan los estados y se registran las fallas. Recién después se habilitan los envíos rutinarios expresamente aprobados.

Ese paso requiere límites de destinatarios, canales y frecuencia, un responsable operativo y un mecanismo para frenar la cola. La autorización para leer el ERP no equivale a autorización para contactar a todos sus clientes. Los cambios de condiciones, descuentos, negociación y reclamos legales quedan fuera del envío rutinario y requieren intervención humana competente.

La IA puede resumir un historial o redactar una propuesta a partir de campos aprobados. No debe inventar saldos, interpretar un comprobante como pago confirmado ni prometer recuperación. Las reglas de pausa, destinatario e importe deben poder comprobarse sin depender de una respuesta generada. Este alcance tampoco incluye ejecutar pagos bancarios, scoring ni decisiones de crédito.

Llevá a la evaluación el nombre del sistema que conserva el saldo, cómo llega una señal de pago y quién resuelve cada excepción. Preguntá quién es dueño del envío cuando conviven ERP, plataforma y gestión manual, y qué pasa con los mensajes preparados si se cae una conexión.

Duotach ofrece automatización con n8n e integración de sistemas. Si el problema está en conectar el estado de una factura con la cola de comunicaciones, ese tramo puede ser el objeto de una integración a definir. El primer contacto puede describir sistemas y proceso; no hace falta incluir datos de deudores, comprobantes ni credenciales.