Lorsque toutes les tentatives de règlement d'une facture échouent, l'abonnement correspondant peut être annulé ou considéré comme « non payé », en fonction de l'action paramétrée pour l'état d'abonnement. Ce comportement peut être affecté par les calendriers de relances étendus.
Les calendriers qui s'étendent au-delà de la période de facturation d'un abonnement peuvent entraîner le chevauchement des fenêtres de tentatives de plusieurs factures. Dans les rares cas où toutes les tentatives de paiement d'une facture échouent, mais où la dernière facture faisant partie du même abonnement est réglée, l'état de l'abonnement demeure inchangé. Il n'est pas annulé ni marqué comme non payé.
Prenons l'exemple d'un abonnement dont la période de facturation est d'un mois, avec une fenêtre de relances de deux mois. Supposons la séquence d'événements suivante.
1er janvier : une facture in_1 est émise et le paiement échoue.
Du 2 au 30 janvier : plusieurs tentatives ont lieu et échouent. Il ne reste alors plus qu'une seule tentative pour in_1.
1er février : une facture in_2 est émise et le paiement est effectué avec succès.
10 février : la dernière tentative pour in_1 est effectuée et échoue.
Dans le cas ci-dessus, le calendrier de relances pour in_1 chevauche celui pour in_2, ce qui permet de régler la facture in_2 avant que toutes les tentatives pour in_1 n'aient lieu. Les tentatives pour in_1 restent toujours susceptibles d'échouer, et c'est d'ailleurs ce qu'il se produit. Cependant, dans ce cas de figure, l'état de l'abonnement n'est pas modifié en raison du décalage du paiement. En toute logique, si le paramètre d'état de l'abonnement est défini sur « Annuler l'abonnement », cette annulation n'a pas lieu. Si le paramètre est défini sur « Marquer l'abonnement comme non payé », ce marquage n'a pas lieu non plus.
Comme nous l'avons dit précédemment, c'est la dernière facture ayant l'état payé qui importe. Prenons l'exemple d'un abonnement dont la période de facturation est d'une semaine, avec une fenêtre de relances d'un mois. La séquence d'événements suivante se produit.
1er janvier : une facture in_1 est émise et le paiement échoue.
2 janvier : plusieurs tentatives ont lieu et échouent. Il ne reste alors plus qu'une seule tentative pour in_1.
7 janvier : une facture in_2 est émise et le paiement est effectué avec succès.
14 janvier : une facture in_3 est émise et le paiement échoue
15 janvier : la dernière tentative pour in_1 est effectuée et échoue.
Dans ce cas, le 15 janvier, la facture in_1 échoue pour la dernière fois et l'état de l'abonnement est modifié. L'état de la facture in_2 n'a pas d'importance ici, puisque la dernière facture est in_3, et in_3 n'a pas été payée. En toute logique, si le paramètre d'état de l'abonnement est défini sur « Annuler l'abonnement », cette annulation a lieu le 15 janvier. Si le paramètre est défini sur « Marquer l'abonnement comme non payé », ce marquage a lieu le 15 janvier.
Afin d'éviter que des tentatives ne se produisent après la finalisation de la facture suivante, la fenêtre de tentatives peut être définie sur une valeur inférieure ou égale à l'intervalle de facturation. À titre d'exemple, pour les abonnements mensuels, n'importe quelle fenêtre de relance inférieure ou égale à un mois évitera tout chevauchement potentiel.