Automatizar cobros con Stripe e IA: incidencias, dunning y conciliación

Automatizar cobros con Stripe e IA consiste en poner un agente a vigilar el flujo de pagos que hoy nadie mira: detecta el pago fallido en el momento en que ocurre, decide si conviene reintentar o escribir al cliente, redacta el mensaje con el motivo real del rechazo, concilia lo cobrado contra tus facturas y escala a una persona solo cuando hay una decisión comercial que tomar. Stripe ya te da los eventos; lo que falta casi siempre es alguien que reaccione a ellos.

En una empresa con suscripciones o pagos recurrentes, el dinero que se pierde no está en las ventas que no se cierran: está en los cobros que fallan y nadie persigue. Una tarjeta caducada, un rechazo por fondos insuficientes, un pago que se queda pendiente de autenticación. Cada uno de esos eventos es recuperable si alguien actúa en las primeras horas, y prácticamente irrecuperable a las tres semanas. Esta guía recorre el montaje completo del agente sobre Stripe, con lo que cuesta y lo que no debe tocar.

¿Qué eventos de Stripe debe vigilar el agente?

Los que representan dinero en riesgo o trabajo manual pendiente. Stripe emite eventos para prácticamente todo lo que ocurre en la cuenta, y la tentación de escucharlos todos es el primer error: el agente debe reaccionar a un conjunto acotado, con una acción definida para cada uno.

La diferencia entre esto y una automatización de las de siempre está en la clasificación. Un flujo tradicional trata todos los pagos fallidos igual: reintenta a los tres días y manda el mismo correo. Un agente distingue un rechazo por fondos insuficientes —que se resuelve reintentando en la fecha correcta— de una tarjeta caducada —que solo se resuelve si el cliente actualiza el método— de un rechazo del emisor por sospecha de fraude —que suele requerir que el cliente hable con su banco—. Cada caso pide un mensaje distinto y un calendario distinto.

¿Cómo se diseña la recuperación de pagos fallidos?

Combinando los reintentos automáticos de Stripe con una secuencia de comunicación que el agente adapta al motivo del rechazo. Stripe ya reintenta de forma inteligente según el historial del método de pago; lo que el agente aporta es la capa humana: avisar, explicar y facilitar la solución.

Una secuencia que funciona bien en pymes con suscripción tiene esta forma:

1. Hora 0. Falla el cargo. El agente clasifica el motivo. Si es un rechazo temporal, no molesta al cliente todavía: deja actuar al reintento automático.
2. Día 1. Si el reintento no ha funcionado, primer mensaje: tono neutro, motivo concreto y un enlace directo para actualizar el método de pago. Nada de lenguaje de morosidad en el primer aviso.
3. Día 3-4. Segundo aviso por un canal distinto —si el primero fue email, ahora SMS o WhatsApp—, más breve y con el mismo enlace.
4. Día 7-10. Aviso de que el servicio se verá afectado, con fecha concreta. Aquí es donde la mayoría de recuperaciones se cierran.
5. Día 14. Escalado a una persona. Si el cliente es relevante, la llamada la hace alguien del equipo, no un mensaje más.

Lo importante es la salida limpia: en cuanto el pago entra, la secuencia se detiene. Suena obvio y es el fallo más común en las automatizaciones de cobro montadas a mano — el cliente paga y sigue recibiendo recordatorios durante días, lo que destruye más confianza de la que recupera el cobro. Este mismo diseño de cadencia, aplicado a facturación B2B con vencimientos y no con suscripciones, lo desarrollamos en la guía de cobros y morosidad con agentes de IA.

¿Cómo encaja la conciliación?

Es la mitad silenciosa del proyecto y la que más horas administrativas devuelve. Cada cobro que entra por Stripe tiene que casar con una factura de tu sistema, y el desfase entre lo que Stripe liquida y lo que tú facturas es donde se acumula el trabajo manual.

Hay tres desajustes que aparecen siempre. El primero es la comisión: Stripe liquida el importe neto, tu factura está en bruto, y la diferencia hay que registrarla como gasto. Con la tarifa estándar publicada para tarjetas del EEE —1,5% + 0,25 € por transacción, consultada en agosto de 2026— esa diferencia es pequeña por operación y significativa al cabo del mes; en tarjetas de fuera del EEE la tarifa publicada sube de forma notable, así que conviene comprobar cuál te aplica antes de dar por buenos los cuadres. El segundo es el agrupamiento de liquidaciones: Stripe transfiere varios cobros en un solo ingreso bancario, y casar ese ingreso con las facturas individuales a mano es tedioso. El tercero son las devoluciones y reclamaciones, que aparecen días después y descuadran periodos ya cerrados.

El agente resuelve los tres leyendo tanto el detalle de Stripe como el extracto bancario y proponiendo el asiento, con las excepciones marcadas para revisión humana. El planteamiento general es el mismo que aplicamos en la conciliación bancaria automática con IA, con la ventaja de que aquí una de las dos fuentes es una API limpia y no un extracto en PDF.

¿Y la facturación?

Stripe emite sus propias facturas, pero rara vez son las que necesita tu contabilidad española: series, numeración correlativa, datos fiscales completos, retenciones cuando aplican. El montaje habitual es que Stripe gestione el cobro y tu sistema de facturación emita el documento fiscal, con el agente haciendo de puente entre los dos.

Ese puente hace tres cosas: crea la factura en tu sistema cuando el cobro se confirma, la enlaza con el identificador de la transacción de Stripe para que la trazabilidad exista en ambos sentidos, y gestiona los casos raros —abonos parciales, cambios de plan a mitad de periodo, prorrateos— marcándolos para revisión en lugar de inventarse el criterio. Si tu flujo de facturación tiene además entrada de facturas de proveedor, el enfoque de extracción y validación está en la guía de automatización de facturas con IA.

¿Qué NO se debe automatizar en los cobros?

Cortar el servicio, condonar deuda y responder a una reclamación de cargo. Las tres tienen consecuencia comercial o legal directa y ninguna debe depender de una regla automática.

• Suspender el servicio a un cliente. El agente puede avisar de que va a ocurrir y preparar la decisión; ejecutarla es de una persona, sobre todo si la cuenta es relevante.
• Perdonar, aplazar o fraccionar deuda. Es una negociación comercial. El agente aporta el histórico del cliente y el importe en juego; la decisión no se delega.
• Responder a una reclamación de cargo. El agente reúne el expediente —comunicaciones, evidencia de entrega, términos aceptados— y lo deja listo. Presentar la respuesta es de alguien que entienda las consecuencias de perderla.
• Reintentar sin límite. Reintentar un cargo demasiadas veces puede penalizarte con los emisores. Los reintentos van acotados y con criterio.
• Mover dinero. Ningún agente debería tener permisos para emitir devoluciones o transferencias sin aprobación explícita.

Sobre la detección de patrones sospechosos en los cobros, la línea es la misma: el agente señala, la persona decide. Lo hemos desarrollado en detección de fraude en pagos con IA.

Cómo se monta, paso a paso

1. Mide la línea base. Porcentaje de cobros fallidos, cuántos se recuperan hoy y en cuántos días, horas mensuales dedicadas a conciliar. Sin esta foto no podrás demostrar la mejora.
2. Crea una clave restringida en Stripe con los permisos mínimos: leer eventos, facturas y clientes; escribir solo lo imprescindible. Nunca uses una clave con permisos completos.
3. Escucha los eventos en un endpoint propio y verifica la firma de cada notificación. Es el punto donde más integraciones caseras se hacen mal.
4. Empieza solo por recuperación de pagos fallidos. Es el flujo con retorno más rápido y el más fácil de medir.
5. Añade la conciliación cuando la recuperación esté estable, y déjala en modo propuesta —el agente sugiere el asiento, una persona lo aprueba— durante las primeras semanas.
6. Revisa a las 4-6 semanas contra la línea base: tasa de recuperación, días medios hasta el cobro y horas de conciliación.

Preguntas frecuentes

¿Esto sustituye a las herramientas de recuperación que ya trae Stripe?

No, se monta encima. Los reintentos inteligentes y los correos automáticos de Stripe cubren el caso estándar y conviene mantenerlos. El agente aporta lo que esas herramientas no pueden: adaptar el mensaje al motivo concreto del rechazo, cambiar de canal, consultar el histórico del cliente en tu CRM y decidir cuándo deja de tener sentido insistir y hay que llamar.

¿Cuánto cuesta montar algo así?

Un agente acotado a un proceso —recuperación de fallidos, por ejemplo— se construye entre 3.000 y 15.000 € en una pyme según integraciones y volumen, con mantenimiento anual del 10-20% sobre esa cifra. El factor que más mueve el presupuesto no es Stripe, que tiene una API excelente, sino el sistema de facturación o el ERP con el que haya que casar los cobros.

¿Qué pasa con los datos de tarjeta?

No pasan por el agente ni deben hacerlo. Stripe custodia el dato de pago y tu sistema trabaja con identificadores, no con números de tarjeta. Ese es precisamente el motivo por el que este montaje es viable sin asumir una carga de cumplimiento desproporcionada: el agente ve estados, importes y motivos de rechazo, nunca el medio de pago.

¿Sirve si cobro por transferencia y no con tarjeta?

La lógica de recuperación sirve igual, pero la detección cambia: sin evento de rechazo hay que apoyarse en el vencimiento de la factura y en la conciliación bancaria para saber quién no ha pagado. Es un montaje algo más lento de construir y con la misma mecánica de secuencia y escalado.

¿Cuánto se recupera de verdad?

Depende de tu base de clientes y del motivo dominante de tus rechazos, así que desconfía de quien te dé un porcentaje sin conocer tus datos. Lo que sí es consistente es la forma de la curva: la probabilidad de recuperar un cobro cae de forma acusada con los días transcurridos, así que la mejora viene sobre todo de reaccionar antes, no de insistir más.