Centrales de paiement : le logiciel des pros de la tréso

payment factory 2

Une Payment factory est un logiciel développé pour les cadres de l’univers de la finance, plus précisément du département Trésorerie, et dont le mission est la centralisation des paiements. Dans le jargon de la trésorerie est également utilisé le terme Payment/Collection Factory pour définir ce genre d’outil.
L’audience de cette gamme de progiciel peut même être réduite aux départements trésorerie des multinationales et à leurs collaborateurs. De fait, ces applications sembleront sans nul doute surdimensionnés aux petites entreprises et à toutes celles qui n’ont pas à gérer une multitude de flux et de paiements durant chaque journée travaillée.

Les grandes entreprises sont des entreprises multinationales qui possèdent des entités à travers le monde et qui veulent réorganiser et centraliser leur département trésorerie, de la façon suivante :

  • flux de travail à un seul niveau : importation ou saisie manuelle des entrées via l’entité fille avant la communication bancaire
  • processus montant : import ou saisie des écritures depuis l’entité fille suivi de l’envoi à la maison-mère qui approuve/réprouve le lot avant d’envoyer aux établissements bancaires
  • workflow central : l’ensemble des opérations se déroulent dans la direction de la trésorerie, de la création du flux jusqu’à son envoi aux partenaires bancaires

Flux de travail et concentration centrale des paiements

En fonction des stratégies organisationnelles internes à l’entreprise, les actions à effectuer dans le progiciel de paiements avant d’effectuer la transmission à l’outil de communication bancaire s’élèvent à un chiffre plus ou moins important.
Ce faisant, on peut considérer :

  • la saisie ou l’importation des paiements dans la plateforme (depuis une application du SI) au sein d’ une entité de l’entreprise
  • la constitution automatisée ou manuelle en lots de paiements selon des critères communs aux paiements
  • les lots seront transférés à un premier décideur qui acceptera ou pas la fabrication de chaque paquet (en fonction du genre et de la sévérité de la procédure de validation décidée, un lot peut être réprouvé si un seul des paiements du lot est désapprouvé, voire se voir approuvé après l’élimination du paiement mis en cause)
  • ce premier responsable enverra à son N+1 ces lots de paiements entérinés ; celui-ci acceptera numériquement (via un identificateur, un objet connecté, voire simplement avec un clic) ces paquets
  • un 5ème utilisateur sera alors averti par le module que des paquets seront transférés à la trésorerie centrale située dans la holding
  • dans la holding, un second processus peut ainsi être mis en place au sein de la payment factory et dupliquer la totalité ou une partie des actions indiquées auparavant
  • finalement, un dernier valideur enverra le paquet ou les batches de paiements ayant passé avec succès les différentes étapes d’approbation (cf supra) vers la banque, toujours par le logiciel si ce dernier inclut bien un dispositif de communication aux banques

Chaque user qui se situe dans le workflow d’autorisation est le plus communément averti par le système d’une nouvelle action à exécuter par email (envoi automatique par l’application), et simplement dans l’application par le biais d’une console et/ou des interfaces dédiés aux démarches auxquelles l’utilisateur est affecté.

Certaines multinationales ont une approche des workflows dans d’un progiciel de paiement complètement contraire à la vision qui est présentée dans ce document. Ces groupes choisissent une automatisation globale jusqu’à la la finale ou l’avant-dernière phase du flux de travail, en amont de l’envoi aux établissements bancaires, et donc demandent au progiciel de transmettre les paquets aux statuts suivants (un statut réfère à une action) sans intervention humaine ou presque.

Lots de paiements ou paiements unitaires

Comme vu précédemment, les meilleures payment factories mettent à disposition l’envoi aux partenaires bancaires non seulement des paiements unitaires, mais aussi de lots de paiements. En effet, pour des raisons d’efficacité évidentes, quand de nombreuses transactions relatives à des paiements et à des encaissements circulent dans le module, le traitement par batch engendre un gain de temps remarquable. Les paiements sont alors rassemblés dans un même référentiel, puis groupés.

La payment factory permet ainsi grâce à des programmes permettant d’automatiser des opérations récurrentes d’indiquer quels types de paiement seront versés dans un lot. Par exemple, on peut concevoir qu’un paquet sera fait, au choix :

  • de tous les paiements journaliers à effectuer vers un même compte bancaire
  • des paiements effectués par une société donnée à une autre société
  • de tous les virements RH
  • de tous les paiements quotidiens relatifs à une entreprise particulière

Le user qui y est autorisé peut être sélectionné par rapport à ses compétences spécifiques en rapport avec les particularités des paiements insérés dans un batch distinct.
On peut en outre noter dans quelques payment factories, en revanche, que le niveau de caractérisation des informations traité est capable d’aller à un niveau plus fin que les paiements et des batches de paiements avec, par exemple :

  • des notes liées au paiement
  • des groupes de lots de paiements à envoyer à la banque

Transmission aux établissements bancaires et paiements

La payment factory est chargée de concentrer en un point unique et de communiquer les paiements et les batches de paiements aux différents établissements bancaires renseignés dans le référentiel, de collecter les messages de réponse des établissements bancaires (acceptation, refus, demande d’informations…) et autres messages bancaires, enfin de les transmettre au destinateur, soit au user de la payment factory qui a occasionné la communication aux partenaires bancaires.

A la manière des protocoles Web – http, sftp, smtp… – il existe de nombreux protocoles de communication aux établissements bancaires. Les plus populaires et sécurisés sont :

  • SWIFTNet : réseau de communication avec les établissements bancaires à échelle internationale, géré par l’entreprise SWIFT
  • EBICS (Electronic Banking Internet Communication Standard) : protocole de communication reposant sur la version sécurisée de http (https) choisi par le CFNOB pour suppléer les protocoles ETEBAC (ETEBAC 3 et ETEBAC 5), jugés trop lents et moins sûrs, à la fin des années 2000

Ces protocoles sont actuellement mis en oeuvre massivement par toutes les grandes compagnies internationales quant à la transmission bancaire de leurs paiements.

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *