Quels sont les pays SEPA ?

Les pays concernés par les virements et prélèvements SEPA sont des pays qui font déjà partie de la zone euro, des pays membres de l’Union Européenne et qui utilisent des devises qui ne sont pas l’euro, mais aussi de pays qui ne font pas partie de l’UE.

Nous présentons ici les pays, banques nationales ou établissements financiers directement concernés par le SEPA et responsables de l’émission des identifiants bancaires BIC et IBAN, ainsi que les personnes physiques responsables et les moyens de les contacter.

Carte de l'Union Européeene
L’Union Européenne au 01/01/2016

Pays de la zone euro

Les pays répondant à ces critères et qui ont rejoint le SEPA sont au nombre de 19 :

Pays membres de l’UE avec devise autre que l’euro

Les pays de l’Union Européenne n’utilisant pas l’euro mais qui font néanmoins partie de la zone SEPA sont :

Pays non-membres de l’UE

Les pays hors UE qui ont néanmoins décidé de participer au SEPA sont les suivants :

Améliorer la gestion des paiements avec une payment factory

On emploie de plus en plus l’expression Payment Factory pour définir les conditions permettant une gestion et un traitement des paiements les plus efficaces possibles dans une entreprise. On examinera ici les pré-requis nécessaires à la mise en place d’un outil de centralisation de paiement les différentes formes prises par une application de type « usine de paiements ».

Payment factory

Le terme de payment factory est largement utilisé dans les trésoreries groupe et est souvent interprété de différentes manières.
D’une manière générale, une Payment factory est une application installée dans une grande une organisation et destinée à centraliser et à contrôler la direction et le traitement des flux de paiement auparavant décentralisés.

Une Payment Factory est constituée de facteurs internes (processus type workflows, configuration et paramétrage, utilisateurs, technologies disponibles en interne – bases de données, SI et serveurs associés…) et de facteurs externes, tels que les contreparties bancaires, les comptes, la connectivité et les filiales, engendrant des modèles différents.

Une interprétation indique que la Payment Factory serait le résultat d’une centralisation et du regroupement des processus de paiement des dettes et du personnel dans un endroit unique, tandis que d’autres entreprises la considère comme une plaque tournante centralisée, seule responsable de l’exécution des paiements à destination des
partenaires bancaires et facilitée par les processus décentralisés des comptes créditeurs. Nulle interprétation est erronée, et nous avons donc besoin de comprendre les facteurs qui influencent la mise en place d’une Payment factory et les avantages qui peuvent en être tirés.

Périmètre d’entreprise

Aujourd’hui, de nombreuses entreprises continuent de gérer leurs comptes de traitement des paiements et leurs comptes bancaires au niveau de la business unit ou au niveau des filiales. Bien que ces méthodes peuvent offrir un degré de flexibilité, ils entraînent souvent dans le même temps une mauvaise visibilité et des coûts de maintenance non maîtrisés. La multiplicité des systèmes, des processus et des relations bancaires ont en effet tendance à introduire des coûts plus élevés, un manque de visibilité sur les flux de trésorerie, une complexification des processus d’approbation et de validtion,
les risques opérationnels, des problèmes de reporting et un manque général de normalisation.

La méthode de gestion de trésorerie sera influencée par divers facteurs, y compris la nature de l’entreprise, le modèle de négociation, l’emplacement des acheteurs et des fournisseurs, les relations bancaires, le degré de centralisation du processus, etc.
La mise en place des paiements sera induite par les relations avec les fournisseurs, les devises de travail, la connectivité bancaire et leurs services, la technologie déjà présente dans les systèmes d’information ainsi que les logiciels amont et aval et ERP déjà en place.

Ainsi, l’évaluation les structures de paiement sera probablement différente pour la plupart des entreprises et fera fluctuer les avantages potentiels de la centralisation.
Alors que la pression pour réduire les coûts va généralement conduire les entreprises à évaluer leurs processus, la mise en place du SEPA va entraîner les grandes organisations à regarder du côté des usines de paiement.
En effet, depuis que le Parlement européen a adopté une loi obligeant les États membres de la zone Euro à migrer vers les normes SEPA en 2014 pour faciliter les virements et prélèvements, de nombreuses entreprises ont évalué leurs flux de paiement afin de comprendre l’impact du SEPA sur leur organisation et de se préparer aux ajustements nécessaires.

Dans le cadre de cet effort SEPA, qui a engendré une normalisation, une plus grande efficacité et une diminution des comptes en euros, de nombreuses sociétés ont étudié la possibilité d’évaluer leur infrastructure de paiement plus largement.

Quels avantages pour une Payment factory ?

Une approche centralisée des activités de paiement peut aider une entreprise à obtenir des avantages dans un certain nombre de domaines en fonction de leurs activités actuelles et de la stratégie de gestion de trésorerie. Parmi ces avantages, on trouve :

Plus grande normalisation et efficacité

  • meilleure cohérence dans le processus de paiement permettant l’automatisation avec des taux de STP plus élevés, une activité manuelle réduite et la réduction des coûts qui en résulte
  • possibilité de réduire le nombre de relations bancaires et de rationaliser les structures de compte
  • normalisation du traitement de l’Euro grâce à l’utilisation du virement SEPA
  • harmonisation de la connectivité et des formats de fichiers bancaires en utilisant SWIFT, eBICS et ISO 20022 XML

Visibilité et contrôle accrus

  • visibilité sur le paiement et le contrôle interne conduisant à l’optimisation de la liquidité
  • déclaration simplifiée à des fins internes et réglementaires puisque les informations de paiement sont centralisées donc disponibles de partout
  • réduction de la fraude grâce à la gestion des processus, la visibilité accrue et la mise en œuvre des politiques de contrôle
  • visibilité des fournisseurs consolidée permettant une meilleure gestion de la chaîne d’approvisionnement et une négociation optimisée des tarifs

Réduction des coûts

  • coûts de transaction réduite et meilleure gestion bancaire
  • amélioration du et consolidation des flux de paiement
  • meilleure utilisation des fonds disponibles en tant que processus de financement et les conditions d’intérêt optimisées

Les chemins menant à une payment factory

La structure d’une payment factory varie en fonction de la stratégie de paiement en place et de la future stratégie de gestion de la trésorerie de cette organisation.

Les entreprises partant d’une base décentralisée et qui sont multi-bancarisées, auront probablement pour priorité la recherche, le contrôle, la visibilité et la normalisation de leurs flux de paiement.
Ceci est généralement réalisé en utilisant soit une application bancaire partagée soit en adoptant un système qui facilite la réception des instructions en provenance des business units et qui crée les fichiers de paiement pour les partenaires bancaires. Ainsi, tous les paiements extérieurs sont envoyés et tous les relevés bancaires sont reçus via un canal de distribution unique.

Les organisations qui ont déjà atteint un certain degré de centralisation des paiements, elles, se concentreront davantage sur la réalisation de nouveaux gains d’efficacité grâce à l’amélioration du straightthrough processing (STP) des taux, sur l’amélioration de l’efficacité du financement et sur l’automatisation des processus.
Les in-House Banks, les compensations et les paiements « pour compte de » (payment-on-behalf-of, dits POBOs) sont aussi souvent utilisé pour faciliter des activités intersociétés, pour gérer des positions de trésorerie et agréger les obligations de paiement.

Certaines questions importantes doivent être abordées à ce stade, et notamment :

  • Comment les paiements sont-ils traités aujourd’hui ?
  • Combien de banques fournissent de services de paiement ?
  • Comment la communication avec les fournisseurs s’effectue-t-elle ?
  • Quelles sont les devises de base ?
  • Les encaissements constituent-ils des activités de paiement ?
  • La visibilité et le contrôle sur les activités de paiement sont-ils totaux ?
  • Quelle est l’efficacité du processus de financement ?
  • Qu’en est-il des fonds de roulement ?

Gérer les priorités de l’entreprise

Après avoir étudié l’existant, l’étape suivante est la définition d’une approche structurelle pour la gestion de trésorerie et les activités de paiement. Cela permettra de définir les priorités de la Payment Factory, servira de support dans la conduite des discussions internes et externes et impactera positivement le processus de décision menant au choix de la payment factory.

Pour certains groupes, la priorité sera d’augmenter l’utilisation du cash, pour d’autres ce sera la réduction des effectifs ou encore l’adoption d’une infrastructure agnostique bancaire. Cette vision est souvent dictée par l’identification des principaux défis immédiats et les budgets alloués aux processus de paiement. Les discussions
avec des partenaires bancaires et technologiques peuvent aussi aider à guider le processus de prise de décision et à informer les entreprises des solutions et logiciels capables de répondre à leur modèle de Payment Factory.

Avant toutes choses, les sociétés devraient envisager les mesures suivantes :

  • périmètre (par exemple zones géographiques et unités d’affaires à cibler, impact du changement, processus, effectifs / localisation, l’activité inter-entreprise)
  • stratégie bancaire (par exemple nombre de partenaires dans traitement des paiements, capacités bancaire, exigences en matière de services de comptes locaux)
  • gestion des liquidités (par exemple devises, comptes et lieux préférés, modalités de financement, agrégation des passifs, contrôle des business units)
  • connectivité et formats de fichiers (par exemple méthode de communication préférée de la banque, importance relative des canaux bancaires et formats agnostiques SWIFT / ISO 20022 XML)
  • préparation interne à la conduite des changements dans les processus (par exemple, changements technologiques nécessaires, capacité d’appuyer les changements dans les délais souhaités, projets contradictoires, obstacles culturels tels que l’autonomie de l’unité d’affaires locale)
  • juridique et fiscal (par exemple, changements des structures comptables, les répercussions fiscales, rapports souhaités)

Les modèles d’usine de paiement souhaités peuvent varier en fonction de plusieurs facteurs. Alors même que tous s’accordent sur l’efficacité des payment factories, l’utilisation des nouvelles technologies sert également de catalyseur et permet de rassembler ERP, TMS, applications de banque en ligne et middleware supplémentaire afin d’atteindre objectifs des paiements.

paiements transitant via une payment factory
Schéma possible d’une payment factory

Le modèle le plus classique est celui de la payment factory facilitant la réception des instructions et créant les fichiers de paiement avant communication bancaire : les business units envoient l’instruction de paiement à la payment factory, la communiquent à l’ERP / au TMS / au middleware, qui l’envoie aux partenaires bancaires. La banque paie les bénéficiaire en débitant la business unit.

Mise en place d’une usine de paiements

Comme pour tout projet de changement, la mise en place d’une Payment Factory nécessite une planification et une préparation interne. La participation de la trésorerie, des comptes créditeurs, des départements juridique / fiscal, technologique, de la gestion de projet et des équipes seront nécessaires.

De nombreux facteurs doivent être pris en considération à considérer lors de l’implémentation d’une Payment Factory :

  • gestion des risques :
    • change
    • gestion de crédit
    • risque de contrepartie
    • gestion de projet
  • infrastructure technique :
    • configuration ERP / TMS
    • In house bank / Compensation / Pobo
    • Connectivité
  • Efficacité et optimisation du process :
    • STP
    • conduite du changement
    • relations bancaires
    • structure de compte
    • prévision
  • sécurité et conformité :
    • processus d’approbation
    • gestion de compte bancaire
    • SLA / accords inter-juridique et fiscaux

Vers la rationalisation des banques

Malgré l’incertitude économique et une inquiétude accrue des entreprises sur la contrepartie bancaire liée au risque, la tendance à la centralisation des activités de paiements persiste et les entreprises envisagent avec toujours plus d’optimisme des la réduction des banques avec lesquelles elles collaborent dans le cadre des paiements.

En effet, la multiplication des relations bancaires engendre une perte d’efficacité dans le processus de paiements, la duplication des processus et de la connectivité, des exigences différentes selon les banques, de traitement de coupure, etc. et conduisent systématiquement à des coûts plus élevés, à un manque de visibilité et de contrôle et donc à une inefficacité générale.
Les organisations multinationales exigent donc des partenaires bancaires mondiaux qui peuvent soutenir les multiples exigences bancaires du pays, capables d’être des conseils sur les structures de paiement, et d’offrir des solutions permettant aux entreprises de réaliser leurs objectifs de gestion de trésorerie.

En résumé, une payment factory peut prendre différentes formes, mais le tronc commun est universel et mène l’entreprise à une plus grande visibilité, un meilleur contrôle et une efficacité accrue. Avoir une vision et une compréhension claire dès l’initialisation de votre projet de paiement et travailler avec les bons partenaires peut aider à générer ces avantages.

SEPA : qu’est-ce que c’est ?

Définition du SEPA

SEPA désigne l’espace unique de paiement en euro (Single Euro Payments Area en anglais), c’est-à-dire les pays de l’Union Européenne dans lesquels les paiements s’effectuent uniquement en euros, quels que soient les méthodes de paiement, les conditions, outils, banques, pays, lois ou règlements en vigueur localement. Il est entré en vigueur le 1er août 2014 et a permis la légitimation du concept de Payment Factory.
Cet espace concerne plus de 20000000 d’entreprises européennes et plus de 500000000 d’individus, quelle que soit leur nationalité. Il a été défini afin de permettre la simplification des paiements dans toute l’Europe, quel que soit le pays dans lequel l’émetteur ou le destinataire du paiement se situe, et de rendre les tarifications de ce type de paiement plus transparentes pour tous. Ainsi, tout paiement  dans l’espace SEPA devient aussi aisé que n’importe quel paiement en espèce dans son pays d’origine.

Logo officiel du SEPA
Logo officiel du SEPA

Jusqu’alors, les paiements par carte ou par virement électronique transfrontaliers européens engendraient des surcoûts, des lenteurs (date de valeur très éloignées de la date d’opération), voire des erreurs (somme partielle reçue par le destinataire.

Un règlement depuis 2012

La collaboration des banques européennes a permis d’élaborer un règlement et de le ratifier en 2012, comme l’indique le site officiel.  L’objectif, comme indiqué ci-dessus, était de rendre les paiements dans la zone Euro SEPA aussi souples que dans le pays de domiciliation des différentes parties (banque, émetteur, destinataire).
Le règlement, à l’origine, prévoyait une fin de migration, donc un passage total aux virements SEPA et prélèvements SEPA le 1er février 2014, mais il dut être repoussé au 1er août 2014 à cause d’un défaut de communication sur le sujet. En effet, de nombreuses entreprises europénnes ont été prévenues très tardivement (fin 2013) par les institutions de ce que le SEPA allait être mis en place définitivement quelques semaines plus tard. Pour permettre aux différentes institutions et aux entreprises de choisir des solutions adéquats et compatibles avec SEPA, le lancement fut donc repoussé de 6 mois.
Pour les plus grandes entreprises, le passage à un véritable outil de centralisation de paiement et à une payment factory fut le choix le plus évident dans le cadre de la migration, dans la mesure où certaines de ces usines à paiement permettent nativement de gérer SDD (SEPA Direct Debit : prélèvement SEPA) et SCT (SEPA Credit Transfer : crédit SEPA).

Les banques européennes, représentée par le Conseil européen des paiements (EPC), furent soutenues dans cette quête par la Banque centrale européenne et la Commission européenne.

Qu’est-ce qu’une payment factory ?

Payment factory : un logiciel pour professionnels

English version

Une payment factory est un logiciel destiné aux professionnels (ie progiciel) de la finance, et plus précisément de la Trésorerie qui a pour but la centralisation des paiements. Il peut être traduit par « plateforme de paiement » en français.
La cible et les utilisateurs de ce type de solutions informatiques peut même être réduite à une niche se limitant aux trésoriers des grandes entreprises et à leurs collaborateurs. En effet, ces progiciels paraîtront sans doute surdimensionnés aux petites entreprises et à toutes celles qui ne gèrent pas une multitude de flux et de paiements chaque jour.

Payment factory - Schéma
Schéma d’une payment factory

Par « grandes entreprises », on entend le plus souvent les grands groupes, c’est-à-dire des sociétés souvent multinationales qui possèdent des filiales dans de nombreux pays, voire sur plusieurs continents, et qui organisent leur trésorerie et veulent centraliser leur trésorerie, au choix, de la manière suivante :

  • workflow local : import ou saisie des paiements au niveau de la filiale puis transmission à la banque
  • workflow local + central : import ou saisie des paiements au niveau de la filiale puis envoi à la maison-mère qui valide puis transmet à la banque
  • workflow central : l’ensemble des opérations se déroulent au niveau de la maison-mère, de la création du paiement à sa transmission à la banque

Workflow et centralisation des paiements

Selon les procédures internes de l’entreprise, le nombre d’étapes à effectuer dans l’application de paiement avant la transmission bancaire peut être plus ou moins élevés.
En effet, on peut imaginer :

  • la saisie manuelle ou l’import des paiements dans le logiciel (depuis une application amont) au sein d’une filiale
  • la constitution automatisée ou manuelle en lots de paiements selon des critères communs aux paiements
  • ces lots seront envoyés à un premier responsable qui validera ou non la constitution de chacun de ces lots (en fonction du type et de la sévérité de la validation mise en place, un lot peut être rejeté si un seul des paiements inclus est rejeté, ou se voir validé malgré tout après le retrait du paiement incriminé)
  • ce premier responsable enverra à son propre N+1 ces lots de paiements validé ; celui-ci signera numériquement (via un token, une clé, ou simplement via un clic) ces lots
  • un 5e intervenant sera alors prévenu par le logiciel que des lots peuvent être envoyés à la centrale de trésorerie située dans la maison-mère
  • au sein de la maison-mère, un nouveau workflow peut alors se mettre en place au sein de la payment factory et calquer tout ou partie des étapes indiquées ci-dessus
  • enfin, un dernier responsable enverra le lot ou les lots de paiements ayant passé avec succès les différentes étapes de validation décrites ici vers l’établissement bancaire, toujours via le logiciel si celui-ci intègre bien un module de communication bancaire

Chacun de ces utilisateurs intervenant dans le processus de validation est le plus souvent prévenu par le système d’une nouvelle action à effectuer par messagerie électronique (envoi automatique par le système), et/ou directement dans le logiciel via un tableau de bord et/ou des écrans dédiés aux actions auxquels l’utilisateur est affecté.

Certaines sociétés ont une approche des workflows au sein d’une payment factory diamétralement opposée à celle qui est décrite ici. Celles-ci préfèrent au contraire tout automatiser jusqu’à la dernière ou l’avant-dernière étape du processus, juste avant l’envoi en banque, et ainsi laisser l’application faire passer les lots aux statuts supérieurs (un statut correspondant à une étape) sans intervention humaine ou presque.

Lots de paiements vs paiements unitaires

Comme on vient de le voir, les meilleures payment factories proposent l’envoi en banque non pas de simples paiements unitaires, mais de lots de paiements. En effet, pour des raisons de productivité évidentes, lorsque des milliers d’opérations liées à des paiements et à des encaissements sont versées dans le logiciel, le traitement par lot permet de gagner un temps précieux. Les paiements sont donc centralisés, puis groupés.
La payment factory permet ainsi grâce à des macros (programmes permettant d’automatiser des tâches, le plus souvent récurrentes) de définir quels types de paiements seront versés dans un lot. Par exemple, on peut imaginer qu’un lot sera constitué, au choix :

  • de tous les paiements du jour à effectuer vers un même compte en banque
  • de tous les paiements effectués par une entité donnée à une autre entité
  • de tous les virements de paye
  • de tous les encaissements de la semaine liés à un fournisseur particulier
  • etc.

L’utilisateur qui sera autorisé à valider peut ainsi être choisi en fonction de ses connaissances spécifiques liées aux caractéristiques des paiements inclus dans un type de lot précis.

On peut aussi noter dans certaines payment factories, à l’inverse, que le niveau de détail des flux financiers traiter peut aller au-delà des paiements et des lots de paiements avec, par exemple :

  • des factures attachées à un paiement
  • des groupes de lots de paiements à envoyer à la banque

Communication bancaire et paiements

La payment factory est chargée de centraliser et de communiquer les paiements et les lots de paiements aux différentes banques renseignées dans le référentiel, de recevoir les réponses de ces banques (acceptation, refus, demande d’informations…) et autres messages bancaires, puis de les transférer à l’initiateur, c’est-à-dire à l’utilisateur de la payment factory qui a impulsé l’exécution de la communication bancaire.
A l’instar des protocoles Internet – http(s), (s)ftp, smtp, pop, imap… – il existe différents protocoles de communication bancaire. Les plus fameux, sécurisés, mais aussi les plus utilisés sont :

  • SWIFTNet : protocole d’échange d’informations bancaires à échelle mondiale, géré par la société SWIFT (Society for Worldwide Interbank Financial Telecommunication)
  • EBICS (Electronic Banking Internet Communication Standard) : protocole de communication basé sur https choisi par le CFNOB (Comité français d’organisation et de normalisation bancaires) pour remplacer les protocoles ETEBAC (ETEBAC 3 et ETEBAC 5), jugés trop lents et moins sécurisés, au début des années 2010
Logo officiel de SWIFT
Logo officiel de SWIFT

Ces protocoles sont aujourd’hui (2016) utilisés en masse par l’ensemble des grands groupes internationaux dans le cadre de leurs paiements et encaissements.

Payment factory ou Collection factory ?

Le terme « payment factory » est en fait restrictif, car il ne recouvre que la moitié des activités de cette catégorie de logiciels. En effet, « l’usine » traite et centralise à la fois les paiements de l’entreprise, mais aussi ses encaissements. On devrait donc plutôt parler de « payment and collection factory » ou « plateforme de paiement et encaissement ».

En effet, les flux et paiements traités dans les payment factories couvrent une grande diversité de moyens de paiement et de types comptables, relatifs au domaine d’activité de l’entreprise, à sa clientèle (B2C vs B2B) et à ses choix stratégiques :

  • virements (masse, RH et salaires, fournisseurs, internes…)
  • prélèvements (TIP, bientôt remplacé par les prélèvements SEPA, dits SDD pour SEPA Direct Debit, mais aussi non SEPA, notamment pour les prélèvements non européens) et encaissements (abonnés, clients…)
  • opérations de netting, de marché, de trésorerie
  • LCR
  • chèques

 Droits et privilèges des utilisateurs dans la centralisation

Une bonne payment factory possède une administration et un paramétrage des utilisateurs permettant de définir finement les possibilités d’action et de visualisation données à un utilisateur, comme :

  • l’accès au logiciel
  • la complexité de son mot de passe
  • l’expiration de ses identifiants
  • la visualisation de certains menus
  • la visualisation de certaines opérations
  • la visualisation de certains détails au sein de certains opérations (ex : nom d’une personne ou montant versé dans un virement)
  • l’interdiction d’accès à certaines données (ex : si l’utilisateur Dupont n’a pas accès à une entité X et si X est concernée par un paiement que Dupont est supposé avoir le droit de voir, ce dernier peut s’en voir refuser la visualisation)
  • la validation de certaines opérations ou de certains changements
  • l’appartenance à un groupe d’utilisateurs possédant des droits et privilèges communs
  • le droit d’administration
  • la signature électronique
  • l’envoi à la banque
  • la création de macros
  • la réceptions de messages bancaires

Référentiel intégré à la payment factory

Pour pouvoir obtenir une payment factory efficace, il faut bien entendu récupérer tous les paiements pour les centraliser. Néanmoins, c’est insuffisant pour constituer un logiciel prêt à l’emploi, et de nombreuses données doivent être versées à la base de données du logiciel. Elles sont souvent récupérées depuis un logiciel amont par le biais d’un moteur d’import-export qui retranscrit les données au formats demandés par la plateforme de paiements. Il s’agit, entre autres, des :

  • entités (filiales, émettrices ou bénéficiaires)
  • banques
  • comptes
  • pays
  • devises
  • jours fériés
  • structures IBAN
  • codes BIC
  • type d’opérations
  • plafonds de signature
  • types de paiements

Ce référentiel de données est alors utilisé dans les paiements ou dans le paramétrage des différentes étapes du workflow spécifique à chaque type d’opérations.

Technologies et Payment Factories en 2016

Quelques plateformes de paiement utilisent encore des technologies clients-serveur et nécessitent donc des installations sur chacun des postes utilisateurs, en plus du serveur logiciel et de la base de données (VB, C++, SQL Server pour Windows).
Lourdes et dépassées depuis plusieurs années, ces technologies ont été remplacées progressivement par les éditeurs de logiciels par les technologies et langages Web (Java J2EE, php, python…) et associées aux serveurs d’applications (Tomcat, WebSphere, WebLogic…) et aux SGBD (Système de Gestion de Base de Données : Oracle, DB2, MySQL, SQL Server…) les plus robustes et les plus répandues sur le marché.

Les logiciels basés sur les technologies Web présentent l’avantage de pouvoir être déployés rapidement et de ne nécessiter aucune installation sur les postes utilisateurs.
En effet, un simple navigateur Web (Microsoft IE ou Edge, Google Chrome, Mozilla Firefox, Apple Safari…) est alors suffisant pour accéder et se connecter à la payment factory.

Payment factories et progiciels hybrides

Les payment factories peuvent être intégrées à des gammes de logiciels offrant un panel plus large d’outils dédiés aux trésoriers, voire aux traders, aux DAF (Directeur Administratif et Financier) et aux comptables.
Les métiers étant complexes et les ponts entre les différentes responsabilités et tâches des trésoriers étant parfois peu évidents, ces suites d’applications sont rares. Elles se font fort d’adjoindre à la plateforme de centralisation de paiement différentes solutions spécifiques :

  • le logiciel de trésorerie « basique » (rapprochement des prévisions et des réalisations, gestion des placements et crédits, fiches en valeur, voire netting, reporting de trésorerie…)
  • le rapprochement bancaire-comptable (matching automatisé des extraits de comptes bancaires et des écritures)
  • le TMS (Treasury Management System) ou smart TMS 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 financière (Front Office) à sa comptabilisation (Back Office) en passant par le contrôle (Middle Office) et la gestion des risques associés

Typologie de l’offre et pricing

On trouve 3 grands types d’offres de payment factory, qui valent également pour toute la gamme de logiciels orientés Trésoreries grands groupes :

  • achat sec de licences + maintenance : la société acquiert auprès de l’éditeur de logiciels ou de son distributeur un nombre de licences permettant d’installer le logiciel in house (serveur dans ses propres locaux), de créer N utilisateurs et/ou administrateurs et/ou types de flux financiers sans limite de temps, et achète une maintenance à l’année (correction de bugs, support…) renouvelable
  • offre SaaS (Software as a Service) ou PaaS (Platform as a Service) : offre la plus moderne et la plus simple, permettant d’accéder à la plateforme de paiement installée sur un serveur mutualisé géré et maintenu par l’éditeur ou le distributeur, sans limite de temps. Paiement mensuel ou trimestriel le plus fréquemment, dont le montant est calculé sur la volumétrie et le nombre d’utilisateurs.
  • offre hébergée simple : accès à la payment factory installée sur un serveur dédié, géré et maintenu par l’éditeur ou le distributeur, sans limite de temps. Paiement mensuel ou trimestriel le plus fréquemment, dont le montant est calculé sur la volumétrie et le nombre d’utilisateurs.

Si le SaaS ou PaaS (version évoluée du SaaS basée sur le cloud computing) a aujourd’hui le vent en poupe dans de nombreux secteurs, les Trésoriers demeurent réticents à l’idée d’héberger des données sensibles (flux de paiements et informations utilisateurs) hors de leur infrastructure et de leur DSI.

Quelle que soit la solution choisie, la payment factory sera amenée à évoluer, et de nouvelles versions, mineures ou majeures, du logiciel seront proposées sous forme de mises à jour aux décideurs par les commerciaux ou consultants de l’entreprise conceptrice de l’application.