Cada periodo de renovación debe pertenecer a una sola cuenta

El caso más visible es mantener activa la renovación del origen mientras el destino empieza a cobrar inmediatamente. También puede ocurrir si un lote se reintenta sin idempotencia, si se confunde una suscripción con un calendario ya programado, si una cancelación conserva una factura pendiente o si entran nuevas altas después de la instantánea.

La prevención comienza con un manifiesto por suscripción y una frontera que describa qué cuenta factura el periodo actual y cuál el siguiente. No uses una única acción para todos los estados sin revisar fechas, facturas, uso, pruebas y método de cobro.

Stripe aconseja crear las suscripciones de destino antes de cancelar las antiguas, para no dejar a un cliente sin continuidad. También indica que las antiguas deben cancelarse antes de que las nuevas estén previstas para cobrar. Cuando una fecha está demasiado cerca, su documentación propone programar el destino después de ese ciclo.

Esta secuencia necesita una verificación entre creación y desactivación. Confirma que el objeto apunta al cliente y precio correctos, que la próxima factura se espera en la fecha prevista y que no existe otra programación. Si falla, detén la cohorte en lugar de cancelar primero y reparar después.

Para cada cohorte registra final del periodo pagado, próxima fecha de origen, inicio de destino, acción en origen, propietario y evidencia. Añade facturas abiertas, partidas pendientes, uso medido y cancelaciones programadas. La tabla debe poder responder quién cobra cualquier fecha alrededor del corte.

Las suscripciones anuales, en prueba, atrasadas, por factura o con varias partidas necesitan reglas propias. En un plan basado en uso, decide qué sistema acumula y factura el uso anterior y cuándo empieza el medidor del comprador. Una cancelación puede afectar prorrateos y facturas, por lo que debes consultar la documentación y revisar la vista real.

Utiliza una clave idempotente estable por fila cuando el flujo emplee la API y conserva el identificador de destino. Antes de repetir, consulta el resultado. La idempotencia evita duplicar una solicitud equivalente; no corrige un precio ni una fecha erróneos.

Verifica configuración, no solo estado `active`. Inspecciona próxima factura, calendario, prueba, descuentos, impuesto y método de cobro. Completa la acción de origen aprobada y examina inmediatamente facturas abiertas, borradores y eventos en ambas cuentas.

Mantén un registro de operador, hora, versión del manifiesto y decisiones. Los mensajes de éxito de una interfaz no sustituyen la consulta independiente del objeto ni la conciliación del lote.

Vigila las primeras renovaciones con alertas para clientes, periodos e importes coincidentes. Si aparece un posible duplicado, detén nuevos solapamientos, conserva evidencia y determina cuál de los cobros corresponde al servicio. Coordina el reembolso y la comunicación según el contrato y las obligaciones aplicables.

No borres registros ni canceles masivamente mientras se investiga. Una acción precipitada puede afectar acceso, factura o disputa. Asigna un propietario de soporte y otro de facturación y registra la resolución en el expediente.

MoveMRR aporta mapeos, simulación, opciones de desactivación y resultados por elemento, pero no puede garantizar que toda configuración externa esté libre de efectos. El control final pertenece a los operadores de ambas cuentas.