El reclamo de cobro resuelto antes de que llegue: doble cobro, pago que no aparece y débito no reconocido con IA y MCP

Un reclamo de cobro tiene una característica que lo distingue de cualquier otra queja: la información para resolverlo ya estaba en el sistema antes de que el cliente llamara. El pago duplicado, el pago aprobado que nunca generó recibo, el recibo registrado en el contrato del vecino, el débito que siguió corriendo después del retiro: todos dejaron rastro en el ERP horas o días antes de la llamada. Lo que faltó fue alguien que mirara. Y en una funeraria con decenas de miles de contratos de previsión, varias pasarelas, corresponsales y cobradores en calle, nadie puede mirar todo.

Este artículo es un caso de uso concreto de inteligencia artificial conectada al ERP por MCP, escrito para la dirección financiera, la gerencia de recaudo y la jefatura de servicio al cliente. No explica qué es MCP (para eso está la página del módulo SFUN MCP). Responde una sola pregunta: ¿cuántos reclamos de cobro de este mes se habrían podido resolver antes de que el titular los notara? Es el complemento de dos casos ya publicados: la mora involuntaria trata el cobro que no entró; este trata el cobro que entró mal.

1. El problema de negocio: el cliente audita mejor que la funeraria

En la previsión exequial, el titular paga una cuota pequeña muchas veces al año, casi siempre sin hablar con nadie. Esa relación silenciosa tiene dos momentos de verdad: el día del servicio y el día en que algo sale mal con un cobro. Un reclamo de cobro mal atendido cuesta en cuatro frentes a la vez:

• Tiempo del equipo. Cada caso obliga a alguien a reconstruir a mano la historia: buscar el contrato, los recibos, la transacción de la pasarela, el extracto y la conversación. Es el trabajo más caro del call center porque nadie lo hace igual dos veces.
• Dinero mal ubicado. Un pago duplicado es un pasivo con el cliente; un pago en el contrato equivocado deja a un titular en mora que no debe y a otro al día que no pagó; un pago sin aplicar es caja sin dueño.
• Cobertura en riesgo. Si el pago que «no aparece» era el que mantenía vigente el contrato, el error deja de ser administrativo el día en que la familia necesita el servicio.
• Retiro del plan. Para quien paga un plan que espera no usar, un cobro que no entiende es la razón más a mano para cancelarlo.

No existe una cifra pública de reclamos de cobro en el sector funerario de Latinoamérica, así que conviene mirar a los sectores que cobran igual: cuotas pequeñas, recurrentes y masivas. En suscripciones, la plataforma Recurly publica que, de una tasa de cancelación total del 3,60 %, 1,25 puntos son cancelación involuntaria, es decir, originada en el cobro y no en la decisión del cliente (benchmarks de Recurly, actualizados a julio de 2026; se miden sobre su propia red de clientes). En energía, un estudio de la Universidad de Cambridge sobre el mercado británico encontró que los hogares que entienden menos su factura son más propensos a cambiar de proveedor (He y Reiner, 2015; es una asociación estadística, no una prueba de causalidad). Y en cuentas por pagar, la referencia comparativa de APQC ubica los desembolsos duplicados o erróneos entre el 0,8 % de los mejores y el 2 % de los rezagados (APQC, citado por su director financiero en 2020): el pago repetido no es una rareza, es una tasa.

Ninguna de esas cifras se traslada a una funeraria. Lo que se traslada es la conclusión: una parte de los retiros nace en el cobro, y el error de cobro tiene una frecuencia medible. Además, en varios países el reclamo tiene reloj legal. En Colombia, el Estatuto del Consumidor exige responder la reclamación directa en 15 días hábiles (Ley 1480 de 2011, artículo 58) y reconoce el derecho a reversar pagos de obligaciones periódicas hechos por débito automático (artículo 51, parágrafo 2). En Perú, el plazo para atender un reclamo es de 15 días hábiles improrrogables (Ley 31435, que modificó el Código de Protección y Defensa del Consumidor). En Chile, el mandato de pago automático se puede revocar en cualquier momento y seguir cobrando después tiene consecuencias (Ley 19.496, artículo 17 I). El detalle cambia por país y debe revisarse con el área jurídica; el punto es que el plazo empieza a correr cuando el cliente reclama, no cuando la funeraria se entera.

2. La distinción que falta: cuatro reclamos que parecen uno

El titular dice «me cobraron mal». Detrás hay cuatro situaciones con causa, rastro y corrección distintos. Separarlas es el primer aporte del caso, porque cada una se busca en un lugar diferente del ERP:

La primera fila merece una explicación, porque contradice la intuición. En un contrato de previsión el pago no se imputa a una cuota con número: avanza la vigencia. Por eso un doble pago no «sobra» en ningún lado; simplemente el contrato queda pagado un mes más adelante. Contablemente está bien. Para el titular, que quería pagar un mes y le salieron dos de su cuenta, no. Ese es el reclamo más frecuente y el más invisible, porque ningún control lo marca como error.

3. Qué datos del ERP intervienen

Lo más importante de esta sección es lo que SFUN ya impide sin ayuda de ningún asistente. Si la pasarela notifica dos veces el mismo pago, el sistema reconoce que ese intento ya quedó en estado final y no lo procesa de nuevo; y antes de emitir un comprobante verifica que no exista ya uno para ese intento. Las redes de recaudo y los corresponsales llegan con un identificador de transacción único, de modo que un reenvío por caída de la conexión no abona dos veces. El recibo del cobrador que se reenvía desde la aplicación móvil se reconoce por su número y no se duplica. Y una tarea automática revisa cada quince minutos los pagos pendientes y los aprobados que no tienen comprobante. Es exactamente el problema que describimos en el reintento que crea dos registros, resuelto del lado de los pagos.

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

El caso lo usa recaudo o tesorería (quien corre el cruce y corrige), servicio al cliente (quien habla con el titular) y la dirección financiera (quien aprueba devoluciones y mira las causas). La frecuencia natural es diaria para el cruce y semanal para las causas.

Paso 1. El inventario de lo que ya llegó

Antes de anticipar reclamos hay que saber cuántos hay. La primera consulta lee el registro de PQRSF por categoría y estado, y calcula la antigüedad con la fecha de radicación, porque el registro no trae fecha límite propia:

«Lista las PQRSF de tipo reclamo o devolución de los últimos 60 días cuya categoría sea de cobros, métodos de pago, facturación o devolución de dinero. Agrúpalas por categoría y estado, y marca las que llevan más de diez días hábiles abiertas.»

El resultado suele traer dos sorpresas: cuántos reclamos de cobro siguen abiertos más allá del plazo legal del país, y cuántos casos nunca se radicaron porque se quedaron en una conversación de WhatsApp. Para estos últimos, lo práctico es que servicio al cliente adopte una etiqueta única de conversación —«reclamo de cobro»— y la aplique siempre; con ella, el asistente puede contar y leer esas conversaciones. Ese análisis se detalla en análisis de conversaciones de WhatsApp con IA y MCP.

Paso 2. El cruce diario: cinco listas

Aquí está el corazón del caso. Cada mañana, el asistente produce cinco listas, una por cada forma en que un cobro puede haber salido mal sin que nadie lo sepa todavía:

1. Posible doble pago. Contratos con dos o más recibos válidos en una ventana corta (por ejemplo, siete días) por el valor de una cuota, sobre todo si entraron por canales distintos, y cuya vigencia quedó más adelantada que su patrón habitual de pago. No es un error del sistema: es una pregunta para el titular.
2. Pago aprobado sin comprobante. Intentos de pago en estado aprobado que siguen marcados con comprobante pendiente o con error al generarlo. La tarea automática resuelve la mayoría; los que sobreviven más de unas horas necesitan a una persona.
3. Valor que no coincide. Casos que la conciliación con la pasarela marcó porque el valor pagado no es el del recibo. El sistema los señala y deliberadamente no los corrige solo.
4. Pago en el contrato equivocado. Recibos anulados con el motivo «pago aplicado a contrato equivocado» que todavía no tienen un recibo nuevo por el mismo valor en otro contrato; y contratos que reciben un pago de un valor distinto al de su cuota mientras otro contrato de un titular parecido entra en mora el mismo día.
5. Cobro automático que no debería estar corriendo. Cobros automáticos aprobados en contratos retirados o suspendidos, en contratos con un reclamo de cobro abierto, o hechos pocos días después de que el titular cambiara su medio de pago.

Dos límites prácticos. El primero es de permisos: en SFUN, los intentos de pago y los medios de pago tokenizados los lee, de fábrica, solo el rol administrador del sistema, y el asistente ve exactamente lo que ve el usuario que consulta. Lo correcto no es ampliar ese permiso a todo recaudo, sino que un administrador guarde un reporte de cruce con los campos necesarios —sin datos de tarjeta— y lo habilite a quien corre el caso. El segundo es de volumen: la lectura directa de documentos devuelve hasta 50 filas y la agregación hasta 20 grupos por consulta, mientras que un reporte guardado entrega hasta 200 filas por lectura. Un cruce diario sobre miles de pagos se hace con reportes guardados, no con preguntas sueltas; así la lista de hoy es comparable con la de ayer.

Y un límite que no es del conector sino de la realidad: el cobro que el cobrador recibió sin conexión y aún no sincroniza no existe para el servidor. Ninguna consulta lo va a encontrar. Ese hueco se cierra con disciplina de turno y de cierre de caja, como se explica en efectivo del cobrador, faltantes y dinero en tránsito.

Paso 3. El expediente de cada caso

Por cada fila de las cinco listas, el asistente arma una ficha de una página: el contrato con su estado y su vigencia antes y después del pago; los recibos involucrados con canal, fecha, valor y usuario; el intento de pago con su referencia y la secuencia de eventos de la pasarela; el reclamo o la conversación si ya existen; y las anotaciones previas del contrato. Es el mismo trabajo que hoy hace un agente del call center en veinte minutos con cuatro pantallas abiertas, hecho antes de que el teléfono suene.

«Para el contrato CT-10482, muéstrame los recibos de los últimos 30 días con canal, fecha, valor y meses pagados; la vigencia actual; los intentos de pago del mismo período con su estado; y si hay una PQRSF o una conversación etiquetada como reclamo de cobro. Resume en cinco líneas qué pasó y qué opciones de corrección hay.»

Paso 4. La corrección la decide y la ejecuta una persona

El asistente propone; no corrige. Y en SFUN esto no depende de la buena voluntad del modelo: las funciones de reverso, de reembolso y de débito están deshabilitadas para el conector, y la anulación de un recibo de previsión está reservada al rol administrador. Cada corrección tiene su camino en el ERP:

Una recomendación de configuración que sale de este paso: activa la exigencia de motivo al anular recibos. Es una opción por compañía y viene apagada. Con ella encendida, cada anulación deja motivo, observación, usuario y hora, y alimenta el informe de cancelaciones, que es la fuente del paso siguiente.

Paso 5. Avisar primero

Lo que convierte una corrección en una buena experiencia es el orden: que el titular reciba el mensaje de la funeraria antes de ver el doble cargo en su extracto. El asistente redacta el borrador con los datos del expediente —qué pasó, qué se hizo, qué puede elegir el titular— y lo deja listo. El envío lo hace una persona de servicio al cliente, por el canal y con la plantilla que la compañía tenga aprobados. En un sector donde el titular puede estar pagando el plan de un familiar que acaba de fallecer, ese mensaje no se delega.

5. El bucle de mejora continua

La revisión más valiosa es la última línea del día: los reclamos que llegaron sin estar en ninguna lista. Cada uno enseña una regla que faltaba —una ventana demasiado corta, un canal que no se estaba cruzando— y es lo que hace que el cruce mejore en lugar de repetirse. La revisión trimestral ataca dos causas que vienen documentadas en la guía de los propios procesadores de pago: los cargos que el titular no reconoce porque el nombre que aparece en el extracto no es el de la marca que conoce, y los pagos repetidos porque la confirmación no llegó a tiempo y el cliente lo intentó de nuevo (documentación de Stripe sobre prevención de disputas y sobre reintentos).

6. Gobierno y límites: lo que nunca se automatiza

• El asistente no mueve dinero. No anula recibos, no reembolsa, no pausa cobros y no emite notas crédito. En SFUN esas funciones están cerradas para el conector, y así deben quedarse. Ver acciones irreversibles y agentes de IA.
• La aprobación humana es un proceso de la compañía, no una función del conector. El conector MCP no trae un paso propio de «aprobar antes de ejecutar». El control real es el modo de solo lectura, los permisos de cada usuario y la lista de funciones habilitadas. Para este caso, el conector se habilita en solo lectura.
• Datos de pago fuera de la consulta. El cruce necesita el estado, el valor y la referencia de la transacción; no necesita la tarjeta enmascarada, el token ni el documento del tarjetahabiente. El reporte guardado no debe incluirlos.
• Permisos por rol. El cruce lo ve recaudo, tesorería y finanzas; el expediente de un caso, además, el agente de servicio que lo atiende. Ver gobierno de agentes de IA en el ERP funerario.
• Un «posible doble pago» no es un error hasta que el titular lo dice. Hay familias que pagan adelantado a propósito. El asistente marca; la pregunta la hace una persona, y la respuesta se anota en el contrato.
• El contexto del titular. Antes de contactar a alguien por un cobro, se revisa si el contrato tiene un servicio en curso o reciente. A una familia en duelo no se le escribe por un cruce de pagos como si fuera un trámite cualquiera.
• Quien corrige no es quien aprueba. La devolución la aprueba alguien distinto de quien anula el recibo, y el informe mensual de cancelaciones lo revisa contraloría.

7. KPIs: línea base y meta

La línea base se mide en el primer mes con las mismas definiciones que se usarán después. Las metas son orientativas.

El segundo indicador es el que da nombre al artículo y el que dice si el caso funciona. Estos indicadores encajan en el cuadro de mando del grupo funerario, junto a los de cartera y cobranza.

8. Hoja de ruta de adopción

Errores comunes

• Creer que «el sistema ya evita los duplicados». Evita que la misma transacción se registre dos veces. No evita —ni puede— que el titular pague dos veces.
• Medir solo lo radicado. Buena parte de los reclamos de cobro se queda en una conversación y nunca llega al registro de PQRSF. Sin etiqueta, no existen para la estadística.
• Tratar el doble pago como dinero a favor. Es un pasivo con el titular hasta que él decida.
• Anular sin motivo. Una anulación sin motivo no se puede analizar después. La exigencia es una casilla; actívala.
• Abrir los datos de pago a todo el equipo para que el asistente «vea más». El camino es un reporte guardado con los campos justos, no un permiso más amplio.
• Dar de baja el contrato y olvidar el cobro automático. El retiro y la baja del medio de pago deben ser un solo trámite.
• Pedirle al asistente que devuelva el dinero. Encontrar el caso es automatizable. Devolver, no.

Lo que otros sectores ya hacen con IA sobre disputas de cobro

La inspiración directa de este caso viene de las telecomunicaciones. En agosto de 2026, TM Forum publicó una prueba de concepto liderada por Mauritius Telecom en la que agentes especializados detectan anomalías de facturación, investigan la causa cruzando sistemas de facturación, clientes, producto y red, y recomiendan la resolución antes de que el cliente se queje. El título lo resume bien: la mejor disputa es la que nunca ocurre. Sus cifras —hasta 35 % menos quejas de facturación, hasta 40 % menos tiempo de resolución y hasta 30 % menos costo— son resultados esperados de una prueba de concepto, no mediciones en producción, y así hay que leerlas.

En fintech, Klarna informó que su asistente de IA, que atiende entre otros temas reembolsos, disputas e inexactitudes de facturas, resolvió las consultas en menos de dos minutos frente a once y redujo un 25 % las consultas repetidas en su primer mes (comunicado de la empresa, febrero de 2024; cifras propias, sin auditoría externa). Y del lado de la infraestructura, los procesadores de pago ya publican servidores MCP con una regla que vale la pena copiar como criterio de diseño: en el de Stripe, los reembolsos y los pagos salientes requieren confirmación de una persona, y esa confirmación caduca. Chargebee, por su parte, publica un catálogo de consultas por MCP que incluye disputas de factura y auditoría de notas crédito, sin cifras de resultado.

La homologación es directa: lo que en un operador de telecomunicaciones es una factura con un cargo que no corresponde, en una funeraria es un contrato de previsión con un pago de más, de menos o en el lugar equivocado. Lo que no encontramos es ningún caso publicado en 2026, con método y cifras medidas, de agentes de IA que resuelvan disputas de cobro antes del reclamo, ni en el sector funerario ni fuera de él. Por eso este artículo presenta el caso como método, no como resultado probado.

Preguntas frecuentes

¿Qué hago si un cliente pagó dos veces la cuota de su plan exequial?

Primero, confirma que son dos pagos reales y no el mismo registrado dos veces. Si son dos, el contrato quedó pagado un período más adelante: pregunta al titular si prefiere dejarlo como pago adelantado o recibir la devolución, y deja su respuesta anotada en el contrato. Si pide devolución, el recibo se anula con su motivo y la devolución la aprueba finanzas.

¿SFUN evita los cobros duplicados?

Evita que una misma transacción se registre dos veces: la notificación repetida de la pasarela, el reenvío de una red de recaudo o el recibo que la aplicación del cobrador envía de nuevo. No impide que un titular pague dos veces por dos canales distintos, porque para el sistema son dos pagos válidos. Ese caso se detecta con el cruce diario que describe este artículo.

¿Se puede pasar un pago de un contrato a otro?

No con un traslado directo. Se anula el recibo en el contrato equivocado, con el motivo correspondiente y su observación, y se emite uno nuevo en el contrato correcto. La anulación revierte la vigencia y los asientos, y queda en la bitácora de recibos cancelados.

¿El asistente de IA puede devolver el dinero o anular el recibo?

No. En SFUN las funciones de reverso, reembolso y débito están deshabilitadas para el conector MCP, y la anulación de recibos está reservada a un rol administrador. El asistente encuentra el caso, arma el expediente y redacta el mensaje; la corrección la hace una persona.

¿Cuánto tiempo tengo para responder un reclamo de cobro?

Depende del país. Como referencia, Colombia y Perú fijan 15 días hábiles para responder la reclamación del consumidor, y varias legislaciones dan al titular derechos específicos sobre los débitos automáticos. Revisa la norma de consumo de cada país con tu área jurídica y mide el tiempo de resolución contra ese plazo, con margen.

¿Aplica igual en todos los países de Latinoamérica?

El método sí. Cambian las pasarelas y redes de recaudo de cada mercado, el peso del cobrador en calle frente al pago en línea, y las normas de protección al consumidor y de débito automático. Las cuatro familias de reclamo y el cruce diario son los mismos en cualquier país.

En resumen

Un reclamo de cobro es un error que el titular encontró primero. SFUN ya impide que una misma transacción se registre dos veces y concilia cada pago con su pasarela; lo que queda por fuera —el doble pago, el pago sin comprobante, el recibo en otro contrato, el cobro automático que debió detenerse— no lo marca ningún control, pero deja rastro. Un asistente conectado por MCP lee ese rastro cada mañana y entrega a recaudo los casos con su expediente; una persona decide, corrige y avisa. Si quieres ver cómo se vería con los pagos de tu grupo, conoce la plataforma de pagos y recaudo, el recaudo móvil y SFUN MCP.

Fuentes de este artículo

• TM Forum Inform — «The best dispute is the one which never happens», 10 de agosto de 2026, sobre el Catalyst de resolución de disputas de facturación con agentes liderado por Mauritius Telecom. Cifras esperadas de una prueba de concepto: inform.tmforum.org.
• Klarna — comunicado sobre el primer mes de su asistente de IA, 27 de febrero de 2024. Cifras publicadas por la propia empresa: klarna.com.
• Recurly — Churn rate benchmarks (cancelación voluntaria e involuntaria en suscripciones), actualizado a julio de 2026; medido sobre su propia red de clientes: recurly.com.
• He, X. y Reiner, D. — Why Do More British Consumers Not Switch Energy Suppliers?, Cambridge EPRG Working Paper 1515, 2015: jbs.cam.ac.uk (PDF).
• APQC, citado en CFO.com — «Metric of the Month: Detect and Prevent Duplicate or Erroneous Payments», 3 de marzo de 2020. Se refiere a desembolsos de cuentas por pagar, no a cobros a clientes: cfo.com.
• Stripe — documentación sobre solicitudes idempotentes, prevención de disputas y servidor MCP: idempotencia, prevención de disputas y MCP.
• Chargebee — recetas de consultas por MCP (disputa de factura, auditoría de notas crédito), sin cifras de resultado: chargebee.com.
• Colombia — Ley 1480 de 2011 (Estatuto del Consumidor), artículos 51 y 58: secretariasenado.gov.co.
• Perú — Ley 31435, que modifica el artículo 24 del Código de Protección y Defensa del Consumidor (Ley 29571): leyes.congreso.gob.pe (PDF).
• Chile — Ley 19.496 sobre protección de los derechos de los consumidores, artículo 17 I: bcn.cl.
• Advertencia de alcance: no existe ninguna cifra publicada sobre reclamos de cobro en el sector funerario de Latinoamérica, ni un caso con resultados medidos de agentes de IA resolviendo disputas de cobro antes del reclamo. Las cifras de otros sectores se citan por el patrón, no para estimar resultados en una funeraria. El ejemplo de la imagen de portada es ilustrativo.
• Las capacidades de SFUN descritas aquí se verificaron el 1 de octubre de 2026 contra el código del producto: el registro de PQRSF y sus categorías; el recibo de caja de previsión, su anulación con motivo y su bitácora; los intentos de pago, la conciliación con la pasarela y las protecciones contra el registro repetido de una transacción; el cobro automático con tarjeta tokenizada; las conversaciones y sus etiquetas; y las herramientas del conector MCP con sus límites, su modo de solo lectura y sus funciones deshabilitadas. La configuración de cada compañía puede variar. Lo que se presenta como algo que hace el asistente o como hoja de ruta no existe hoy como función estándar.