Gérer un grand volume de paiements : traitez les exceptions, pas toute la liste

Automatisation des paiements

Gérer un grand volume de paiements : traitez les exceptions, pas toute la liste

Gérer un grand volume de paiements, c'est encaisser de nombreux paiements par mois sans vérifier chacun à la main : chaque paiement est créé depuis votre propre système avec votre référence, porte son propre statut, et seuls les paiements qui échouent ou qui sont retournés demandent votre attention.

Le volume change le problème. Avec un petit nombre de paiements, vous pouvez regarder chacun d'eux. Quand leur nombre augmente, ce n'est plus possible, et le vrai travail devient de repérer les paiements qui exigent une décision. Cet article s'adresse aux entreprises et aux plateformes qui encaissent de nombreux paiements par mois, comme des loyers, des remboursements de prêts, des cotisations ou des factures. Il traite de la création des paiements depuis votre propre système, de leur création en lots et de la façon de garder chacun associé à vos registres.

Ce qui se brise quand le volume augmente

Peu d'équipes décident de gérer leurs paiements dans des chiffriers. Cela se fait petit à petit, et quelques habitudes apparaissent souvent ensemble.

• Un chiffrier devient le registre. Une liste de qui doit quoi, modifiée par plusieurs personnes, où l'on ne sait pas toujours quelle version est la bonne.
• Les paiements sont saisis ou téléversés à la main. Les mêmes renseignements sont entrés plus d'une fois, et chaque saisie est une occasion de faire une faute de frappe.
• Vérifier la banque tient lieu de suivi des statuts. Quelqu'un lit les relevés pour voir ce qui est arrivé et ce qui ne l'est pas.
• Un problème n'est qu'une ligne parmi d'autres. Un paiement échoué ressemble à tous les autres jusqu'à ce que quelqu'un le remarque par hasard.

Ces habitudes reposent aussi sur des personnes. Quand celle qui connaît le chiffrier est absente, ou passe à autre chose, la routine part avec elle. Et l'effort augmente avec le nombre de paiements, pas avec la difficulté de chacun.

Rien de cela n'est un problème de déplacement d'argent. C'est un problème de connaissance : quels paiements vont bien, et lesquels demandent de l'attention. Notre article sur les tâches bancaires manuelles dont vous pouvez vous passer couvre la liste plus large des routines que cela remplace.

Créer les paiements depuis votre propre système

Votre système sait déjà qui doit quoi : le client, la facture ou le contrat, le montant. Une façon fiable de créer des paiements en grand nombre est de laisser votre système les créer par l'API, plutôt que de les faire saisir par quelqu'un.

Chaque paiement est lié à une référence issue de votre système. Chez TIB Finance, le montant dû est enregistré sous forme de facture (« bill » dans l'API), et une facture peut porter des champs de référence qui vous appartiennent, comme un numéro de facture ou de contrat. Le paiement peut lui aussi porter une référence. Cette référence reste avec le paiement, de sa création jusqu'à son résultat, de sorte qu'un résultat n'est jamais une ligne anonyme : il renvoie à un client et à une facture.

Chaque client est enregistré une seule fois, avec sa langue préférée, le français ou l'anglais, et les pages de paiement et les courriels de demande de paiement suivent cette langue. Les paiements sont ensuite créés pour ce client, de sorte que son historique reste regroupé.

Les paiements qui se répètent peuvent être programmés selon une fréquence, par exemple chaque semaine, aux deux semaines ou chaque mois. Pour les débits bancaires récurrents, l'accord du client est nécessaire au préalable, et nos guides sur les débits préautorisés et sur les paiements récurrents au Canada expliquent ce que cela comprend. Votre système peut aussi créer le paiement de chaque cycle comme un paiement distinct, si vous préférez garder ce contrôle.

Les paiements peuvent être encaissés par débit de compte bancaire (EFT, y compris le débit préautorisé), par Interac ou par carte de crédit. Ces modes coexistent sur une même plateforme, ce qui donne un seul processus pour tous.

Les lots, en bref

Quand de nombreux paiements sont créés en même temps, deux options méritent d'être connues.

• Des lots sur des modes de paiement enregistrés. Des paiements peuvent être créés en lot sur des modes de paiement déjà enregistrés chez le client. Un lot peut être programmé pour se répéter et peut porter un identifiant de groupe pour que les paiements d'un même lot restent ensemble.
• Un fichier de paiements. Un fichier de paiements dans un format bancaire standard peut être téléversé. Chaque ligne devient un paiement par compte bancaire, et les paiements d'un même fichier restent ensemble sous un même identifiant de groupe.

Les lots et les fichiers sont des façons de créer des paiements en grand nombre, pas un remplacement du reste de cet article. Chaque paiement garde sa propre référence et son propre statut, et c'est ce qui rend l'étape suivante possible.

Un statut par paiement

Chaque paiement porte son propre statut, par exemple en attente, en cours ou complété, ou une erreur ou une annulation avec la raison. Un paiement réussi ne cache jamais un paiement qui ne l'est pas, parce que chacun a son propre résultat. C'est ce qui vous permet de traiter les exceptions plutôt que toute la liste : les paiements réussis n'exigent rien de vous, et vous regardez ceux qui affichent une erreur ou une annulation.

Quand un paiement échoue ou revient, le résultat s'affiche sur ce paiement seulement, à côté de votre référence. Vous savez de quel client et de quelle facture il s'agit sans parcourir les lignes bancaires, et la suite est la décision de votre équipe.

Une routine qui tient à grand volume est courte : ouvrir les exceptions, lire la référence, décider quoi faire, puis consigner la décision dans votre propre système. Le reste de la liste n'a pas besoin d'être ouvert.

Le rapprochement à grande échelle

Rapprocher à la main ne suit pas quand les paiements se multiplient, et il n'est pas nécessaire de le faire à la main. Chaque paiement se relie à vos registres grâce à la référence que vous lui avez donnée. Son statut parvient à votre système par l'API, et par webhook, c'est-à-dire une notification quand le statut d'un paiement change. Votre système met ensuite vos registres à jour : la facture apparaît comme payée, ou le contrat affiche un paiement échoué ou annulé. Notre guide du rapprochement automatisé des paiements va plus loin.

Le rapprochement s'applique aux paiements liés à une référence que vous fournissez, ce qui est une raison de plus de la définir dès la création.

La même structure pour différents paiements

Le modèle ne dépend pas de ce qui est encaissé. Ce qui change, c'est la référence et le rythme.

• Le loyer. Un paiement par locataire par mois, lié à un bail ou à une unité.
• Les remboursements de prêts. Un paiement par date d'échéance, créé par votre système et lié au prêt. Un remboursement échoué ou annulé indique de quel prêt il s'agit.
• Les cotisations. Un paiement par membre par période, lié à l'adhésion.
• Les factures. Un paiement par facture, lié au numéro de facture. Notre guide sur l'automatisation des comptes clients présente ce modèle plus en détail.

Dans chaque cas, la question à grand volume est la même : quels paiements ont besoin de moi? Une référence et un statut sur chaque paiement aident à y répondre, peu importe les modes de paiement de vos clients.

Par où commencer

Commencez dans le bac à sable, un environnement distinct pour tester en toute sécurité, avec un petit ensemble de paiements. Créez-les depuis votre système avec vos propres références et observez ce que vos écrans et vos registres font de chaque statut qui revient. Quand tout se comporte comme prévu, ajoutez des paiements étape par étape.

La connexion à votre système repose sur l'API et les webhooks, et elle est mise en place client par client. Les développeurs peuvent commencer par la documentation pour développeurs, puis lire notre guide pour tester les intégrations de paiement pour la méthode et le guide d'intégration de l'API de paiement pour l'intégration elle-même.

Pour voir les mêmes idées appliquées à un type de paiement précis, il y a l'automatisation des paiements pour les gestionnaires immobiliers et l'automatisation des paiements pour les prêteurs. Pour la vue plateforme, consultez notre article sur la façon dont les entreprises de logiciels ajoutent les paiements.

Si vous cherchez comment cela s'intègre à votre système et à votre processus, communiquez avec notre équipe.

Questions fréquentes

Que signifie gérer un grand volume de paiements?

C'est encaisser de nombreux paiements par mois sans vérifier chacun à la main. Chaque paiement est créé depuis votre propre système avec votre référence et a son propre statut, ce qui vous permet de ne traiter que les paiements qui échouent ou qui sont retournés.

Comment créer les paiements quand ils sont nombreux?

Par l'API, depuis votre propre système, plutôt que de les saisir à la main. Chaque paiement est lié à une référence qui vous appartient, comme un numéro de facture, ce qui permet de l'associer à vos registres de sa création jusqu'à son résultat.

Comment chaque paiement est-il associé à nos registres?

Chez TIB Finance, le montant dû est enregistré sous forme de facture (« bill » dans l'API), et une facture peut porter des champs de référence qui vous appartiennent. Le paiement peut lui aussi porter une référence. La référence reste avec le paiement, de sorte que le résultat peut être inscrit auprès du bon client et de la bonne facture dans votre système.

Peut-on créer des paiements en lots?

Oui. Des paiements peuvent être créés en lot sur des modes de paiement déjà enregistrés chez le client. Un lot peut être programmé pour se répéter et peut porter un identifiant de groupe pour garder ses paiements ensemble.

Peut-on téléverser un fichier de paiements?

Oui. Un fichier de paiements dans un format bancaire standard peut être téléversé, et chaque ligne devient un paiement par compte bancaire.

Les paiements peuvent-ils se répéter selon un calendrier?

Oui. Les paiements récurrents peuvent être programmés selon une fréquence, par exemple chaque semaine, aux deux semaines ou chaque mois. Pour les débits bancaires récurrents, le client donne d'abord son accord.

Comment savoir quels paiements demandent de l'attention?

Chaque paiement a son propre statut, comme en attente, en cours ou complété, ou une erreur ou une annulation avec la raison, ce qui vous permet de traiter les exceptions plutôt que toute la liste.

Que se passe-t-il quand un paiement échoue ou est annulé?

Le résultat s'affiche sur ce paiement seulement, à côté de votre référence, de sorte que vous savez de quel client et de quelle facture il s'agit. La suite dépend de vous.

Comment notre système connaît-il le résultat d'un paiement?

TIB Finance transmet les mises à jour de statut par l'API et par webhook, c'est-à-dire une notification quand le statut d'un paiement change, pour que vos propres registres puissent refléter le résultat.

Peut-on tester avant de passer à un grand volume?

Oui. Le bac à sable permet d'essayer tout le parcours avec des paiements de test avant tout vrai paiement. Commencez avec un petit ensemble et observez comment votre système réagit à chaque statut reçu.