Mora involuntaria: cómo separar el cobro que falló del titular que decidió no pagar, con IA y MCP

Hay una pregunta que casi ninguna dirección de cartera puede responder con un número: ¿cuántos de los contratos que se cayeron el año pasado se cayeron porque el titular decidió dejar de pagar, y cuántos porque el cobro falló? No es una pregunta retórica ni un matiz contable. Son dos poblaciones distintas, con causas distintas, que exigen intervenciones distintas y que se recuperan a costos radicalmente distintos. Y sin embargo, en la inmensa mayoría de los grupos funerarios de Latinoamérica, el sistema las marca con la misma etiqueta —no pagó—, la consola de cartera las mete en la misma cola y el gestor las trabaja igual.

Este es un caso de uso más de nuestra serie sobre IA y MCP aplicados al ERP funerario, y es probablemente el de mejor relación entre esfuerzo y retorno de toda la serie, por una razón simple: no hay que convencer a nadie de nada. En la mora involuntaria el cliente ya decidió pagar; lo que falló fue el mecanismo. Recuperarla no requiere un descuento, ni un argumento de venta, ni una visita, ni tocarle la puerta a una familia. Requiere entender por qué falló el cobro y hacer lo que corresponde a esa causa concreta. El artículo complementario sobre cobranza de cartera con IA y MCP se ocupa de a quién gestionar cuando el titular sí decidió no pagar; este se ocupa del problema anterior y más barato: no gestionar a quien nunca dejó de querer pagar.

1. El problema de negocio y cuánto cuesta hoy

Un grupo funerario con previsión exequial vive de una cartera de cuotas pequeñas y recurrentes: decenas de miles de contratos que pagan mes a mes durante años. Ese modelo tiene una virtud —ingreso predecible— y una fragilidad que casi nadie mide: cada cuota es una oportunidad de que el cobro falle por una razón que no tiene nada que ver con la voluntad de pago del titular. La tarjeta se venció. El banco marcó un límite de monto. La cuenta quedó inhabilitada tras un cambio de producto bancario. El titular entró a pagar por PSE, llegó a la página del banco y se le cortó antes de confirmar.

En un cobro puntual, eso es una molestia. En un cobro recurrente sobre un producto que se presta veinte años después de venderse, es una fuga silenciosa: nadie llama a decir “no me pasó el débito”, porque el titular no siempre se entera. El contrato acumula mora, entra a los tramos de gestión, escala a los canales más caros y en algún punto caduca. En el informe de bajas aparece como un retiro más. Nadie escribió nunca que murió por una tarjeta vencida.

El costo tiene tres capas, y solo la primera es obvia:

• La cuota que no entró. Es el costo visible y el menor de los tres. Se contabiliza como cartera vencida y en muchos casos se recupera solo.
• La gestión desperdiciada. Cada contrato con mora involuntaria que entra a la cola de cobranza consume una llamada, un mensaje o una visita de cobrador que se le quitó a un contrato que sí necesitaba gestión. Es el costo que nunca aparece en un estado financiero porque es costo de oportunidad puro. Y es peor que neutro: el titular que sí pagó y recibe una llamada de cobranza percibe un error de la empresa, no un servicio.
• El contrato que caduca. El más caro de todos, y el único irreversible. Es cartera ya vendida, ya comisionada, con costo de adquisición ya pagado, que se pierde por una falla de plomería. Reponerlo cuesta el precio completo de vender un contrato nuevo.

La evidencia sobre el tamaño del problema no viene del sector funerario —ahí no hay estudios publicados—, sino de la industria que lleva quince años midiéndolo con obsesión porque vive de lo mismo que la previsión: el cobro recurrente de cuotas pequeñas.

2. La distinción que falta: cuatro familias, no una lista de errores

Conviene decir algo antes de entrar: al revisar la literatura para este artículo no encontramos un solo caso publicado de agentes de inteligencia artificial aplicados a la recuperación de cobros en el sector funerario o de previsión exequial, dentro o fuera de la región. No hay contra qué compararse. Eso significa que lo que sigue no es la síntesis de un consenso, sino una propuesta construida sobre evidencia de sectores vecinos y sobre el dato que el ERP ya guarda — y conviene leerla así.

Dicho eso, aquí está el aporte central, y conviene explicar por qué la literatura de reintentos inteligentes —escrita para tarjetas de crédito en mercados anglosajones— no se puede copiar tal cual en Latinoamérica. En la región, buena parte del recaudo recurrente no ocurre sobre una tarjeta tokenizada que la empresa puede volver a cobrar en silencio, sino sobre rieles con redirección al banco, tipo PSE y equivalentes, donde el titular tiene que estar presente, autenticarse y confirmar. Y eso cambia la naturaleza del fallo: cuando alguien no termina en la página del banco, no hay nada que reintentar, porque no hay token ni autorización. Lo que hay es una intención de pago viva que se quedó a mitad de camino y que tiene una ventana corta para rescatarse.

Por eso la clasificación útil no es la lista de códigos de la pasarela —que puede tener decenas de entradas—, sino cuatro familias definidas por la acción que corresponde a cada una. Si dos causas se resuelven igual, van en la misma familia; si se resuelven distinto, no pueden compartirla.

3. Qué datos del ERP intervienen

Todo lo que hace falta para armar la clasificación ya se está guardando. Este es el inventario real de la app pago_express, verificado contra el código en producción:

Vale la pena detenerse en por qué esto es un problema de datos y no de modelos. El trabajo académico sobre los límites de la detección de fraude en redes de tarjetas —otro problema, pero con la misma estructura— formaliza algo que la práctica confirma: la retroalimentación que recibe cualquier sistema de autorización llega demorada, censurada y muchas veces sin el contrafactual —nunca sabes qué habría pasado si hubieras reintentado otro día—, y esas degradaciones de calidad del dato se multiplican en el aprendizaje. La conclusión práctica es incómoda para quien quiere empezar por la parte vistosa: mejorar la calidad del registro rinde más que aumentar la sofisticación del modelo. Traducido a un plan de trabajo, el primer entregable de ingeniería de este caso no es un algoritmo, es persistir bien el código exacto de rechazo, la marca de tiempo, el emisor y el resultado de cada reintento. En SFUN ese registro ya existe y es de buena calidad; lo que falta es la capa que lo clasifica.

4. Cómo se arma el caso con MCP, paso a paso

El MCP de SFUN expone los doctypes de pagos en lectura, con los permisos del usuario que se conecta. Eso alcanza para todo este caso, porque —conviene subrayarlo— el agente no cobra nada. La secuencia es esta:

1. Traer los fallos del período. Se listan los Payment Attempt del último ciclo cuyo estado no fue aprobado, junto con sus Payment Event Log. El interés está en el código y el mensaje de la pasarela, no en los datos del titular.
2. Construir el diccionario de causas una sola vez. Se agrupan los mensajes distintos que devolvió la pasarela y se le pide al modelo que asigne cada uno a una de las cuatro familias, con una justificación en una línea. El resultado lo revisa una persona —tesorería o cartera— y queda como una tabla fija. Es trabajo de una tarde y no se repite: a partir de ahí la clasificación es determinista, una búsqueda en una tabla, y el modelo solo interviene cuando aparece un mensaje nuevo que nadie ha clasificado.
3. Contar. Con la tabla lista, el agente responde por fin la pregunta del primer párrafo: cuántos fallos hubo por familia, sobre cuántos contratos, por cuánto dinero y en qué sedes. Esta es la línea base, y suele ser el momento incómodo del proyecto.
4. Cruzar con el estado del contrato. A cada fallo se le pega el contexto: días de atraso, vigencia, valor. Aquí aparece la lista que importa de verdad, la de contratos que están a punto de caducar por una causa de la familia C y que nadie está trabajando porque en la consola se ven idénticos a los morosos por decisión.
5. Entregar tres colas, no un informe. La salida no es un PDF: son tres listas con dueño y plazo. Los de intención viva, a reenviar enlace hoy. Los estructurales, a re-vincular medio de pago. Los transitorios, a reprogramar con fecha. La cuarta familia no genera cola: genera un ticket de sistema.
6. Revisar los medios de pago que van a vencer. Una consulta aparte sobre Tokenized Card lista las tarjetas que vencen el mes entrante. Es el único frente preventivo del caso y el de mejor retorno, porque evita el fallo en vez de perseguirlo.

5. El bucle de mejora continua

Un caso de uso que se corre una vez es un diagnóstico, no un sistema. Lo que lo vuelve un activo es la cadencia, y aquí la cadencia es naturalmente asimétrica: hay algo que hacer todos los días, algo que revisar todas las semanas y algo que decidir cada mes.

Una advertencia sobre el último punto, porque es donde más proyectos se engañan solos: si cambias la política y a la vez cambias el mensaje al cliente, no vas a saber cuál de las dos cosas funcionó. Cambia una por vez, deja correr un ciclo completo de facturación y compara contra el mismo mes del año anterior o contra las sedes donde no cambiaste nada. Sin esa disciplina, cualquier mejora se la atribuye la última cosa que alguien tocó.

6. Gobierno y límites

Este caso toca datos financieros de personas y, en el sector funerario, toca además a familias que pueden estar atravesando una pérdida. Los límites no son opcionales:

• El agente no ejecuta cobros ni cambia medios de pago. Clasifica y prioriza. Cobrar, reintentar, tokenizar y cancelar débitos siguen siendo operaciones del motor determinista, con su registro y su responsable.
• Los datos de la tarjeta no salen del sistema. Para clasificar una causa de rechazo no hace falta el número, ni el token, ni el titular: hace falta el código y el mensaje de la pasarela. El acceso a los medios de pago está protegido por permisos y los datos sensibles se guardan cifrados; el flujo de clasificación no los necesita y no debe pedirlos.
• Nunca se contacta sobre un contrato con un servicio en curso. Es el límite más importante y el más fácil de olvidar al automatizar. Si la familia está usando el servicio o acaba de usarlo, ese contrato sale de toda cola de cobro automatizada y pasa a manos de una persona. Una gestión de cartera disparada por un sistema en mitad de un velatorio es un daño que no se repara con una disculpa.
• La IA no conversa con el titular sobre su deuda. No es una precaución de estilo: hay evidencia experimental en cobranza de consumo de que contactar primero con inteligencia artificial recupera menos que hacerlo con personas —los contactados primero por IA repagaron alrededor de un 1 % menos del monto vencido un año después— y de que devolver el caso a un humano de forma temprana, hacia el sexto día de mora, cierra buena parte de esa brecha. En un sector donde el interlocutor puede ser un deudo reciente, el patrón defendible es el mismo que sostiene todo este caso: la IA decide y redacta, la persona habla, y el paso a humano es temprano, no el último recurso.
• Un fallo técnico no genera un mensaje que culpe al titular. Cuando el cobro se cayó por la familia D —error nuestro— o por una incidencia del banco, el titular no debe recibir un aviso de mora. Recibe, si acaso, un aviso neutro de que el pago no se completó y un enlace para hacerlo.
• Frecuencia y horario acotados. Varios países de la región regulan la cobranza extrajudicial en frecuencia, horario y canal, y esas reglas aplican aunque el mensaje lo dispare un sistema. La política de contacto se configura una vez y se respeta igual para todas las familias.
• La clasificación es auditable. Cada causa clasificada guarda quién la aprobó y cuándo. Si mañana alguien pregunta por qué un contrato dejó de reintentarse, la respuesta tiene que ser una regla revisada por una persona, no una inferencia irrepetible de un modelo.

7. KPIs: línea base y meta

Los cinco indicadores que hacen falta. Ninguno existe hoy como informe en el sistema; los tres primeros se pueden calcular desde la primera semana con los datos ya guardados.

8. Hoja de ruta de adopción

Errores comunes

• Empezar por el modelo predictivo. El retorno de este caso está casi todo en clasificar y actuar. Elegir el momento óptimo del reintento con aprendizaje automático es la última milla, y no tiene sentido antes de tener meses de datos ya clasificados.
• Construir el motor de reintentos antes de revisar la credencial. Es el error de secuencia más caro, y la evidencia de la aseguradora brasileña lo muestra sin ambigüedad: actualizar la tarjeta y tokenizar rindieron mucho más que insistir con el cobro. Antes de programar nada, pregúntale a tu pasarela si ya soporta actualización automática de credencial y tokens de red en tus países — en varios mercados de la región el salto de aprobación por tokenizar se mide en puntos porcentuales enteros, y es el mismo resultado con una fracción de la ingeniería.
• Subir el número de reintentos porque “así se recupera más”. Más intentos sobre una causa estructural es más fricción para el titular y, en algunas redes, más costo por transacción rechazada. Lo que sube la recuperación es acertar la causa, no insistir.
• Tratar el abandono en el flujo como mora. Es el error más caro en Latinoamérica, por el peso de los rieles con redirección al banco. Alguien que llegó a la página del banco no es un moroso: es un pago a medio terminar.
• Dejar el diccionario sin dueño. Las pasarelas cambian sus mensajes. Si nadie revisa los no clasificados cada semana, en seis meses la clasificación cubre la mitad de los casos y el tablero miente.
• Presentarle el proyecto a la dirección como un proyecto de IA. Es un proyecto de recaudo. La inteligencia artificial aparece en un paso —clasificar mensajes nuevos— y el resto es una tabla y tres colas de trabajo.

Qué existe hoy en SFUN y qué es hoja de ruta

Como en el resto de la serie, la frontera va explícita. Todo lo de la columna izquierda está verificado contra el código en producción; nada de la derecha se debe presentar como disponible.

Preguntas frecuentes

¿Esto aplica si mi operación cobra sobre todo con cobrador en calle y efectivo?

Aplica parcialmente, y conviene ser honesto con eso. La clasificación por causa de rechazo existe solo donde hay una pasarela devolviendo un código, es decir, en los pagos por canal digital, débito automático y recaudo en línea. Si el grueso de tu recaudo entra por cobrador o por red de recaudo física, el caso de uso relevante para esa porción es otro —el de priorización de la cola de gestión—, y este te sirve para la porción digital, que en casi todos los grupos de la región viene creciendo año a año. Un buen orden es empezar por donde ya hay dato estructurado.

¿Por qué no simplemente reintentar más veces y ya?

Porque el reintento solo funciona cuando la causa se cura sola con el paso del tiempo, y eso pasa únicamente en la familia B. Sobre una cuenta inhabilitada o una tarjeta revocada puedes reintentar veinte veces con el mismo resultado, mientras el contrato sigue acumulando mora y acercándose a la caducidad. Y sobre un abandono en la página del banco no hay siquiera nada que reintentar: no existe una autorización que reutilizar. Insistir es la respuesta intuitiva y es la que las compañías que más han medido este problema abandonaron después de medirlo.

¿Cuánto tarda la clasificación inicial?

Menos de lo que parece, porque el universo de mensajes distintos es pequeño: una pasarela devuelve unas pocas decenas de textos diferentes, y unos pocos concentran la enorme mayoría de los casos. Clasificar los que cubren el 95 % del volumen es trabajo de una sesión con la persona de tesorería que ya los reconoce de memoria. La cola larga de mensajes raros se resuelve sobre la marcha, en la revisión semanal.

¿Se puede avisar al titular antes de que se le venza la tarjeta?

El dato para hacerlo está: la fecha de vencimiento se guarda con la tarjeta tokenizada, así que la lista de las que vencen el mes entrante se puede obtener hoy mismo por consulta. Lo que hoy no existe es el envío automático de ese aviso: la tarea que corre en el sistema desactiva las tarjetas después de vencidas, no antes. Por eso en la hoja de ruta el aviso previo aparece como pendiente, aunque la consulta que lo alimenta ya se pueda correr de forma manual cada mes. Es, con diferencia, la acción de mejor retorno del caso completo, porque evita el fallo en lugar de perseguirlo.

¿Necesito un modelo de aprendizaje automático para esto?

No para la parte que produce el retorno. La clasificación, una vez hecho el diccionario, es una búsqueda en una tabla; las tres colas son consultas; el aviso de vencimiento es una fecha. El modelo de lenguaje aporta en un punto acotado —traducir mensajes nuevos de la pasarela a familias, y explicar en lenguaje natural qué cambió esta semana— y un modelo predictivo tendría sentido más adelante, para elegir el momento del reintento. Empezar por ahí es invertir el orden y es la razón por la que muchos de estos proyectos no llegan a producción.

Referencias

• Recurly — Churn rate benchmarks (julio de 2026): descomposición de la baja mensual en voluntaria e involuntaria, por vertical. Es la fuente de la proporción de aproximadamente un tercio: recurly.com.
• CQCS — Digitalização: como modernizar uma seguradora com pagamentos recorrentes (14 de julio de 2026): el caso de HDI Seguros, con el efecto medido por separado del actualizador de tarjeta, de los reintentos y de la tokenización: cqcs.com.br.
• Stripe — How we built it: Smart Retries, sobre el uso de aprendizaje automático para elegir el momento del reintento: stripe.com.
• Dropbox — Optimizing payments with machine learning, sobre el reemplazo de reglas fijas de reintento por un modelo que optimiza la secuencia completa en 192 intervalos horarios: dropbox.tech.
• Recurly — Failed payment recovery: a data-based strategy: origen del dato de que cerca del 90 % de lo recuperado ocurre en los primeros diez días: recurly.com.
• Baremetrics — Subscription payment recovery benchmarks (mayo de 2026): la única referencia con muestra y denominador declarados —119 empresas y 123.810 correos de gestión—, con una mediana de recuperación del 12,7 % sobre intentos: baremetrics.com.
• TC Cloud Partners / Debi — Índices de cobrabilidad (Argentina, 2022): tasas de rechazo sobre cartera completa contra cartera depurada e índice de mortalidad de cobranza del orden del 1 % mensual: tc-cloud-partners.net.
• J. Choi, Y. Huang, D. Yang y Y. Zhang, How Good is AI at Twisting Arms? Experiments in Debt Collection, NBER Working Paper 33669 (2025): la IA recupera sustancialmente menos que los cobradores humanos, y devolver el caso a una persona hacia el día 6 cierra buena parte de la brecha: nber.org.
• G. Dhama, The Fundamental Limits of Fraud Detection in Card Payment Networks, arXiv 2605.27557 (2026): plantea la autorización de tarjeta como problema de decisión secuencial y demuestra que la retroalimentación demorada, censurada, corrompida o ausente limita el aprendizaje de forma multiplicativa, y que el cuello de botella es la calidad del dato y no la complejidad del modelo. El trabajo es sobre detección de fraude, no sobre reintentos: lo que se toma prestado aquí es el argumento sobre la calidad del registro: arxiv.org.
• Adyen — Optimizing payment conversion rates with contextual multi-armed bandits: arquitectura publicada de una política que decide por transacción si reintentar y cómo, con reentrenamiento semanal. La compañía no publica el aumento obtenido: adyen.com.
• Model Context Protocol — especificación de herramientas y prácticas de seguridad, incluida la persona en el circuito con capacidad de denegar la invocación: modelcontextprotocol.io.