Une Payment/Collection Factory est une solution dédiée aux professionnels de la finance, plus précisément ceux de la Trésorerie qui a pour but la centralisation des paiements. On peut aussi utiliser l’expression usine de paiements en ce qui le concerne en français.
L’utilisateur type de ce sorte de applications informatiques peut même se réduire à une poignée et aux cellules trésorerie des grandes sociétés et à leurs collaborateurs. De fait, ces solutions logiciels sembleront sans nul doute trop sophistiquées aux entreprises dont le chiffre d’affaires est limité et à toutes celles qui ne gèrent pas des flux et paiements par dizaines de milliers au quotidien.
Les grandes entreprises sont des sociétés basées dans de nombreux pays qui ont des filiales sur plusieurs continents et qui souhaitent réorganiser et grouper leur trésorerie, au choix, comme suit :
- workflow mono-niveau : importation ou saisie des paiements au niveau de la filiale avant l’envoi à la banque
- flux de travail local + central : importation ou saisie des écritures dans la société fille avant l’envoi à la centrale qui approuve/désapprouve|confirme/réprouve le lot le lot de procéder à la communication bancaire
- workflow central : l’ensemble des actions se déroulent dans la maison-mère, depuis la saisie du paiement à sa transmission au partenaire bancaire
Flux de travail et centralisation de paiements
En fonction des décisions organisationnelles à la société, les phases à mettre à exécution dans l’application de paiement en amont le passage à l’outil de communication bancaire s’élèvent à un chiffre plus ou moins haut.
De fait, nous pouvons penser à :
- l’enregistrement ou encore l’import de lignes de paiements dans le logiciel (depuis un module amont) au sein d’ une entité de la société
- la fabrication automatique ou à la main en lots de paiements en fonction de caractères communs aux paiements
- les batches vont être transmis au décideur qui confirmera ou non la fabrication de chaque lot (selon le type et de la complexité de la procédure de validation choisie, un lot peut être rejeté si un seul des paiements compris dans le paquet est invalidé, ou être approuvé malgré cela après la suppression du paiement mis en cause)
- ce premier valideur expédiera à son propre N+1 ces paquets de paiements approuvé ; ce dernier « signera » par voie numérique (via un identificateur, une clé, ou via une action sur le clavier) ces lots
- l’intervenant suivant sera alors prévenu par le module que des lots peuvent être transférés à la centrale de trésorerie au sein de la holding
- dans la holding, un autre flux de travail peut ainsi être mis en action dans le progiciel et répliquer tout ou fraction des étapes indiquées supra
- enfin, un dernier décideur enverra le paquet ou les lots de paiements qui ont réussi les différentes opérations de approbation commentées supra vers le partenaire bancaire, toujours à travers l’application s’il comprend bien un dispositif de communication aux établissements bancaires
Flux de travail et centralisation de paiements
Chaque user qui se situe à l’intérieur du flux de travail d’approbation est le plus fréquemment prévenu par l’outil d’une opération à exécuter par messagerie électronique (envoi programmé via l’outil), et/ou simplement au sein de le module grâce à une console et/ou des interfaces destinés aux opérations auxquelles l’intervenant est affecté.
Certaines multinationales ont une approche des workflows dans une payment factory strictement opposée à l’approche qui est exposée sur cette page. Celles-ci privilégient par contre une totale automatisation jusqu’à l’ultime ou la pénultième étape du flux de travail, avant l’envoi aux établissements bancaires, et donc laisser l’outil transmettre les batches aux étages suivants (un échelon réfère à une action) sans intervention d’un user ou approximativement.
Lots de paiements vs paiements unitaires
Comme vu à l’instant, les payment factorys (ou factories) les plus efficaces jouissent de la transmission aux banques non pas des paiements à l’unité, mais aussi de lots de paiements. Ainsi, pour des raisons d’efficacité évidentes, quand des milliers de transactions liées à des paiements et à des encaissements circulent au sein de l’outil, le traitement par lot permet de gagner un temps avantageux. Les paiements sont ainsi centralisés, puis inclus dans des lots.
La plateforme de paiement permet donc via des macros de préciser les types de paiements qui seront mis dans un lot. Entre autres, on peut penser qu’un batch sera fait :
- de tous les paiements du jour à effectuer vers un même compte en banque
- des paiements effectués par une filiale à destination d’ une autre société
- de tous les virements RH
- de tous les paiements du mois liés à une entreprise particulière
- etc.
Le user qui se verra accorder le droit de approuver peut alors être choisi par rapport à ses connaissances spécifiques en rapport avec les particularités des paiements insérés dans une sorte de lot distinct.
On peut également remarquer dans quelques payment factories, en revanche, que le détail des informations analysées peut arriver par-delà les paiements et des lots de paiements avec, notamment :
- des bordereaux relatives à un paiement
- des packs de lots de paiements à envoyer à la banque
La Payment Factory en 2016
Quelques progiciels de paiement utilisent encore des technologies client-serveurs et nécessitent de fait des implémentations sur chacune des machines utilisateurs, en plus du serveur logiciel et de la database (Visual Basic, SQL Server pour Windows).
Obsolètes et dépassées depuis longtemps maintenant, ces méthodes de développement ont été substituées au fur et à mesure par les développeurs de logiciels par les technologies conçus pour le Web (Java, PHP, Python…) et associées aux serveurs d’applications (Borland, WebLogic, Oracle Application Server…) et aux Système de Gestion de Base de Données : DB2, PostgreSQL, MariaDB…) les plus puissantes et les plus répandues du marché.
Les applications fondés sur les technologies Web présentent avantage d’être implémentés facilement et de n’exiger aucune mise en place sur les systèmes utilisateurs clients finaux.
De fait, un simple explorateur Web (Microsoft Internet Explorer, Google Chrome, Firefox, Safari…) est alors suffisant pour accéder à l’outil de paiement, dès lors que l’utilisateur a ses informations de connexion à disposition et que l’administrateur du logiciel lui a accordé des privilèges.
Communication à l’outil de communication bancaire et paiements
L’outil payment factory est en charge de rassembler à un seul endroit et de communiquer les paiements et les lots de paiements aux différentes banques inscrits dans la base de données (BDD), de recueillir les messages de réponse des partenaires bancaires (acceptation, refus, demande d’informations…) et autres messages bancaires émanant des établissements, enfin de les soumettre à l’envoyeur, à savoir à l’utilisateur de la centrale de paiement qui a engendré l’exécution de la communication bancaire.
A la manière des protocoles du Net – http, https, smtp… – il existe différents protocoles de communication avec les partenaires bancaires. Les plus répandus et solides sont :
- SWIFTNet : réseau d’échange de flux avec les banques à échelle mondiale, managé par la société SWIFT
- EBICS : réseau de communication basé sur la version sécurisée de http (https) adopté par le CFONB pour remplacer les protocoles ETEBAC (ETEBAC 3 et ETEBAC 5), considérés pas assez rapides et moins sûrs, à la fin des années 2000
Ces protocoles sont aujourd’hui employés massivement par tous les grandes entreprises internationales pour leurs paiements et leurs encaissements dans leurs outils de communication avec les banques.
Payment factory ou Progiciel d’encaissement ?
L’expression « payment factory » est diminutif, puisqu’effectivement il ne couvre que la moitié des opérations de cette sorte de logiciel. De fait, l’application gère et regroupe ensemble les paiements de la compagnie, mais également les encaissements. On devrait ainsi davantage parler de « payment et collection factory » ou « plateforme de paiement et encaissement » (ces termes peuvent également être mis au pluriel en français, pour donner « plateforme de paiements et encaissements »).
Ainsi, les flux financiers et paiements gérés dans les payment factories renferment une importante hétérogénéité de méthodes de paiement et de natures comptables, relatifs au fonctionnement de l’entreprise, à son public et à ses décisions stratégiques :
- prélèvements (TIP, prélèvements SEPA, c’est-à-dire les SDD qui signifie SEPA Direct Debit, mais aussi non SEPA, en particulier pour les prélèvements non européens) et encaissements (abonnés, clientèle…)
- virements (masse, RH et salaires, approvisionneurs, internes…)
- activités de netting, de marché, comptable
- LCR
- etc.
Autorisations et prérogatives des users dans le système
Une payment factory possède une interface d’administration et un paramétrage des users qui permet de configurer précisément des possibilités d’action et de visibilité attribuées à un utilisateur, telles que :
- la connexion à l’outil
- la sévérité de son password (caractères spéciaux, majuscules, chiffres…)
- l’arrivée à expiration de ses identifiants (avec des dates d’entrée et de sortie du logiciel, par exemple)
- l’autorisation de voir certaines entrées de menu
- la permission de voir certains types de paiement
- la permission de voir des spécificités dans certaines transactions (ex : patronyme d’une personne ou RIB)
- l’impossibilité de voir certains éléments (ex : si l’user Marie n’a pas accès à une filiale X et si X se rapporte à un paiement que l’user est censé avoir le droit de visualiser, ce dernier peut s’en voir interdire la visualisation)
- la validation de certaines opérations ou de certaines modifications
- l’affiliation à un regroupement d’users qui a des Droits et pouvoirs en commun
- le profil d’administration
- la validation numérique
- le transfert au partenaire bancaire
- la création de macros (scripts informatisés permettant l’exécution de routines planifiées sans l’intervention d’un humain)
- la réception de communications provenant des banques
- etc.
Référentiel intégré à la centrale de paiement
Pour s’assurer de la productivité d’un logiciel de paiement, il faut bien entendu procéder à l’import de tous les paiements, et par extension de tout type de données, pour les centraliser. Néanmoins, ce n’est pas assez pour constituer un système taillé pour la route, et un nombre conséquent de données doivent être incluses à la base de données du module. Ces datas sont généralement importées depuis un progiciel amont par le biais d’un moteur d’importation-export qui traduit les données aux formats souhaités par l’outil de paiements. Il s’agit, notamment, des :
- filiales
- banques
- comptes divers
- pays
- devises
- jours fériés bancaires
- structures IBAN et codes BIC
- catégories de transactions
- limites de signature
- types de paiements
- …
Cette basse de données est ensuite exploitée dans les paiements ou dans la configuration des diverses opérations du process inhérent à chaque sorte de transactions.
Payment factories et logiciels mixtes
Les payment factories peuvent être incluses dans des gammes applicatives qui offrent un panel plus large de modules conçus pour les trésoriers, voire les traders et aux services comptables.
Les différents sujets étant complexes et les relations entre les différentes composantes des trésoriers étant parfois peu manifestes, ces suites d’outil sont rares. Elles ont pour mission d’ajouter au progiciel destiné nativement à grouper les paiements différentes solutions spécialisés métiers :
- le progiciel de trésorerie « basique » (rapprochement des prévisions et des réalisations, gestion des placements, fiches en valeur, netting, reporting de trésorerie, pooling…)
- la réconciliation comptable (matching automatisé des extraits de comptes bancaires et des entrées)
- le TMS (Treasury Management System) ou, smart TMS (Treasury Management System) ou TRM (Treasury and Risk Management) qui permet, selon son approche, de gérer tous les aspects du trading groupe depuis la stratégie de création de l’opération (Front Office) à l’écriture comptable (Back Office) mais aussi la vérification (Middle Office) et la gestion des risques qui en découlent
Payment factory et logiciels mixtes
Types d’offre et tarifications
On trouve 3 typologies d’offres de payment factory, valables également pour l’ensemble de la gamme de logiciels orientés Trésoreries entreprises :
- licences + maintenance
- offre PaaS (Platform as a Service), souvent appelée à tort SaaS : offre la plus actuelle, qui permet d’accéder à l’application de paiement mise en place sur un serveur partagé maintenu par le distributeur. La tarification est mensuelle ou trimestrielle le plus souvent, et son tarif est calculé sur le volume des flux et la quantité d’users
- hébergement simple
Si l’utilisation du PaaS (variante améliorée du SaaS reposant sur l’informatique en nuage) a désormais le vent en poupe dans de nombreuses activités, les décideurs des Trésoreries sont toujours peu enclins à la pensée d’avoir des datas confidentielles (informations financières et données users) loin de leurs locaux et de l’informatique interne.
Quelle que soit la solution sélectionnée, le logiciel de paiement sera amenée à évoluer, et des versions ultérieures de l’outil seront proposées sous forme de mises à jour aux décisionnaires par l’entreprise conceptrice de l’application.
Notre offre Payment Factory regroupe bien entendu l’ensemble de ces possibilités, pour un choix sur-mesure.
