Relances et suivi
Ce qui relance une facture impayée, quand cela se produit et ce que vous devez faire vous-même.
Une facture ouverte au paiement puis oubliée est un cas courant, pas une exception. Wajub peut la relancer pour vous selon un calendrier défini dans le code. Il n'existe aucune règle par facture ni aucun réglage. Vous devez surtout savoir quand ce mécanisme est activé, car il ne l'est jamais pour de nombreuses intégrations.
Une facture envoyée par l'API n'est jamais relancée
Les relances sont programmées par le bouton Send du Dashboard, dans le même traitement qui génère
le PDF et envoie la facture par e-mail. POST /invoices/{id}/send ne fait rien de tout cela : l'API
ne contient aucun mécanisme de relance. Si votre logiciel émet lui-même les factures, leur suivi
vous revient aussi. Lisez alors la dernière section de cette page.
Quand le calendrier est activé
Il est activé au premier envoi depuis le Dashboard, et uniquement à ce moment. Trois conditions doivent toutes être remplies. Si l'une manque, cette facture n'aura jamais de relance.
| Condition | En cas d'échec |
|---|---|
| L'envoi a lieu dans le Dashboard | Rien n'est programmé |
La facture quitte le statut draft | Un nouvel envoi ne programme rien, la programmation d'origine reste valable |
La facture contient une due_date | Rien n'est programmé, aucune date ne permet de lancer le décompte |
Toutes les relances sont enregistrées en une seule fois à ce moment, chacune avec son créneau, son destinataire et son texte. L'adresse e-mail du client est copiée en même temps. Une correction ultérieure sur sa fiche ne s'applique donc pas aux relances déjà programmées.
Le calendrier
Quatre relances, toutes par e-mail, toutes à 09 h 00 et toutes calculées à partir de la date d'échéance.
| Relance | Créneau | Type |
|---|---|---|
| Échéance aujourd'hui | due_date à 09 h 00 | upcoming |
| Trois jours de retard | due_date + 3 | overdue |
| Une semaine de retard | due_date + 7 | overdue |
| Deux semaines de retard | due_date + 14 | final |
Une file d'attente s'exécute toutes les heures et envoie les relances dont le créneau est arrivé. Une relance part donc dans l'heure qui suit son créneau, pas exactement à 09 h 00. Après la quatrième, plus rien n'est envoyé : il n'existe aucune escalade au-delà de deux semaines.
La relance avant l'échéance ne part pas
Une cinquième relance devrait être envoyée trois jours à l'avance. Sa condition mesure l'écart entre la date d'échéance et la date actuelle dans un sens qui rend toujours la comparaison fausse avec la bibliothèque de dates utilisée. Cette relance n'est jamais créée. En pratique, votre client reçoit le premier message le jour de l'échéance, pas avant.
Envoyer une facture déjà en retard
Les trois créneaux de retard sont calculés depuis due_date sans vérifier si cette date est passée.
Si vous envoyez une facture un mois après son échéance, les trois créneaux sont déjà dépassés. La
prochaine exécution horaire envoie donc les trois relances en même temps. Attribuez à une facture
en retard une date d'échéance qui permet encore un décompte vers l'avenir, sinon le client recevra
trois e-mails en une minute.
Ce qui arrête les relances
Deux choses les arrêtent, et aucune autre.
Une facture payée les arrête. Le système relit la facture avant chaque envoi et annule la relance si le total a été réglé. La file d'attente se vide donc dès la réception de l'argent.
L'annulation de la facture les arrête. Elle supprime toutes les relances en attente avec le document.
Une facture partiellement payée continue d'être relancée. C'est le comportement prévu, puisqu'un montant reste dû. Une relance dont l'envoi échoue ne fait l'objet d'aucune nouvelle tentative : un mécanisme existe avec un maximum de trois tentatives, mais rien ne l'exécute. Une adresse rejetée met donc fin à cette relance.
Les réglages de relance ne font rien
Settings → Invoice contient une section Reminders avec un interrupteur, le nombre de jours avant et le nombre de jours après. Ces trois réglages sont enregistrés pour votre équipe et relus uniquement par ce même écran. Le programmateur ne les consulte jamais : désactiver les relances ne les désactive pas, et ajouter un jour n'ajoute aucun créneau. Le calendrier ci-dessus est celui qui s'applique à tous les comptes.
Effectuer le suivi depuis votre propre code
Si vous émettez les factures par l'API, vous disposez de deux signaux qui fonctionnent différemment.
Le premier est la liste, filtrée sur les montants encore dus.
curl "https://api.wajub.com/invoices?status=overdue&payment_status=unpaid" \
-H "Authorization: sk.kZ3qP8mWvL2xR7tB5nY4hC6dF9jS1aG0eU3i…"payment_status accepte unpaid, partially_paid ou fully_paid. Il filtre selon ce qui a
réellement été reçu, pas selon le libellé du statut. due_date_from et due_date_to délimitent la
période lorsque vous cherchez les factures échues cette semaine plutôt que leur totalité.
Le statut overdue peut avoir un jour de retard
Rien ne fait passer une facture à overdue à minuit. Une tâche s'en charge une fois par nuit à
01 h 00. Une facture arrivée à échéance ce matin reste donc au statut sent jusqu'au lendemain.
Pour faire la distinction le jour même, comparez vous-même due_date à la date actuelle au lieu
de filtrer sur le statut.
Le second signal est le webhook. Il présente une lacune dont vous devez tenir compte.
invoice.updatedévénementCette lacune concerne le statut overdue. La tâche nocturne l'attribue en masse, sans passer par
le mécanisme des événements. Aucun webhook n'est donc émis lorsqu'une facture devient en retard.
Vous devez rechercher cette situation, elle ne vous est pas signalée.
Le modèle qui fonctionne consiste à conserver votre propre liste de factures ouvertes, à la contrôler selon votre propre calendrier et à envoyer vous-même une relance sur le canal que le client consulte vraiment. Le message doit contenir l'URL de paiement, que vous reconstruisez à partir de l'identifiant de la facture.
https://invoice.wajub.com/inv_LRQqYvlhrgUOE225KMKUPages associées
- FacturesLe document, sa page de paiement et son cycle de vie complet.
- Démarrage rapideÉmettre une facture et obtenir son paiement, du début à la fin.
- Factures récurrentesCe que configure l'indicateur de récurrence, et ce qu'il ne fait pas.
- WebhooksLa place d'invoice.updated aux côtés de payment.succeeded.
- Référence API des facturesTous les filtres de l'endpoint de liste.