Payment Factory : les meilleurs logiciels et éditeurs

Le marché des payment factories est désormais suffisamment dense pour pouvoir ébaucher un classement et tirer des conclusions de l’utilisation par les entreprises de ces logiciels dédiés à la rationalisation de leurs flux de paiement et à l’optimisation de la visibilité globale de leur trésorerie.

Afin de définir au mieux les logiciels les plus efficaces, nous nous sommes basés sur plusieurs éléments :

  • l’utilisation en situation réelle de la plupart de ces progiciels
  • les données statistiques de l’Association Française des Trésoriers (AFTE), sur lesquels nous reviendrons
  • l’opinion des trésoriers et des staffs des trésoreries
  • des tests personnels
  • une veille métier quotidienne active

Pour rappel, notre définition d’une payment factory requiert les éléments suivants :

  • installable dans les grands groupes
  • relations intragroupe natives sans ajout de module
  • gestion des paiements, mais aussi des encaissements
  • gestion des paiements SEPA, prélèvements SDD, virements SCT…
  • communication bancaire et gestion des principaux protocoles de communication avec les banques (SWIFTNet, eBICS…)
  • administration poussée des utilisateurs

Idéalement, la payment factory est de surcroît un outil Web, ne nécessitant pas d’installation lourde et coûteuse. En ce sens, les offres des progiciels SaaS sont avantagées.

Comparaison et remise en question des données

Le sondage AFTE relatif à l’utilisation d’une centrale de paiements ou d’une plateforme de traitement de fichiers de paiement donne les résultats suivants :

  • pour les ETI (entreprises de taille intermédiaire) :
utilisation-ETI.png
Répartition des logiciels de paiement dans les ETI
  • pour les GE (grandes entreprises) :
utilisation-GE.png
Répartition (erronée) des Centrales de paiement dans les grandes entreprises

Sans surprise, ce sont les 2 marques les plus célèbres (Sage et Kyriba) et les plus communicantes qui se tirent la bourre sur le marché des ETI, jouissant d’un réseau dans le monde entier, de moyens marketing sans commune mesure avec la concurrence et de logiciels adaptés aux entreprises de cette taille.

De façon beaucoup plus curieuse, Kyriba arrive également en tête du classement des grandes entreprises, devant la payment factory CashPooler, du français DataLog Finance, et bien que les logiciels de l’éditeur américain ne remplissent pas complètement la fonction de payment factory et ne soient pas installés dans les grands groupes.
La confusion vient sans doute du fait que le sondage de l’association française des trésoriers d’entreprise a été envoyé à tous les membres directs ou indirects de l’association, y compris les trésoriers de petites entreprises ou de filiales de grandes entreprises. En répondant en masse à ce sondage, ils ont donc fait ressortir des logiciels et des éditeurs plutôt spécialisés dans les ETI voire PME dans chacune des catégories de ce sondage, le faussant en partie. Ainsi, dans la partie GE, seuls DataLog et Diapason, ou presque, devraient apparaître, les autres éditeurs répondant peu aux appels d’offres de grandes entreprises, pour des raisons stratégiques ou plus sûrement techniques.
Par ailleurs, cette « erreur » peut s’expliquer également par l’intitulé de la catégorie, qui mixe à la fois payment factory et « plateforme de traitement de fichiers de paiements ». Il y a fort à parier que certains sondés y ont vu là un simple logiciel de traitement, et non une solution s’intégrant dans le SI, depuis l’import des fichiers dans le progiciel, jusqu’à l’envoi en banque, traitement des réponses bancaires et des workflows inclus.
L’omniprésence de Kyriba, pourtant moins bien loti et moins présent que les logiciels DataLog Finance chez les entreprises émargeant à plus de 2 milliards de chiffre d’affaires, tend à confirmer un problème dans ce sondage :

ge.png
Répartition des éditeurs dans les grandes entrerprises

On peut étendre cette remarque à d’autres données du sondage, comme celles qui concernent la gestion des comptes et des pouvoirs bancaires (BAM et par extension eBAM), qui font la part belle à Microsoft Excel chez les GE, ce qui est fort peu crédible étant donné les masses de données qu’ils sont susceptibles de gérer en la matière. Par exemple, on imagine mal Orange coupler Excel à leurs logiciels professionnels pour gérer les dizaines de millions de comptes bancaires et les prélèvements de ses clients… Au contraire, le géant de la télécommunication a préféré passer par la fonction native BAM et eBAM de la payment factory CashPooler (qui n’est pourtant même pas mentionnée dans les résultats ci-dessous) pour éviter tout interfaçage ou déploiement complexes et chronophages à réaliser :

BAM-GE.png
Logiciel utilisé pour le BAM

Offres sur mesure et fidélité

On note que les entreprises de toute taille demeurent encore réticentes à l’idée de confier leurs données sensibles de paiement à un hébergement, et privilégient donc le self-hosting, ou hébergement en interne.

hebergement.png
Répartition de l’offre hébergement par taille d’entreprise

Il est à noter toutefois que ces chiffres sont nettement en baisse, une étude de 2004 montrant à l’époque un ratio de 4 hébergements internes pour 5 logiciels installés.

Une fois que les projets de paiement sont déployés, le taux de renouvellement devient très faible, plus d’1/3 des logiciels frisant les 10 ans d’utilisation, faisant de la clientèle des éditeurs de logiciels de trésorerie des clients fidèles :

fidelite.png
Durée d’installation du logiciel de trésorerie dans l’entreprise

Ces progiciels nécessitant des budgets d’acquisition, de formation et de maintenance à l’année (en hébergement interne) ou trimestrielle (en SaaS) très important, il est évident que la question de l’éventualité d’un changement ne se pose que rarement, si tant est que le logiciel réponde au moins à une partie des besoins, et malgré le caractère déceptif de certains logiciels nécessitant moult développements complémentaires et interfaçages pour s’intégrer dans le système d’informations de l’entreprise ou tout simplement faire vivre les fonctions comme cela était prévu à l’amorce du projet.
L’opacité des coûts chez chaque éditeur et pour chaque typologie de projet ne permet malheureusement pas de se faire une idée précise de la fourchette à prévoir dans l’enveloppe destinée à la réalisation et à la mise en place de ces processus d’optimisation de trésorerie.

Et le gagnant est…

… difficile à déterminer sans gloser ! Il semble qu’un petit nouveau soit voué à se taillé la part du lion dans les années à venir, profitant de l’évolution du marché de la payment factory vers celui du smart TMS (Treasury Management System) intégré, regroupant l’ensemble des fonctions attendues par les trésoreries des grandes entreprises :

  • payment factory
  • gestion de trésorerie (cash management)
  • récupération et intégration automatique et native des données du SI
  • gestion des opérations financières
  • gestion des risques associés
  • rapprochement bancaire
  • netting
  • gestion personnalisable des workflows
  • comptabilisation des écritures
  • module comptable
  • stricte séparation des fonctions Front, Middle et Back Office (décision, validation et administration, comptabilisation)

Ce nouveau marché est encore jeune, les entreprises préférant encore se reposer sur des solutions classiques, bien que vieillissantes, comme Calypso, en attendant l’avènement et l’arrivée à maturité d’outsiders comme Treasury Line ou d’autres solutions

  • Full Web
  • capables de gérer des volumétries importantes
  • bénéficiant d’une offre flexible (interne ou SaaS)
  • faciles d’implémentation
  • fonctionnellement riches

Celles-ci, si elles ne ne sont pas légion actuellement, sont vraisemblablement l’avenir des trésorerie d’entreprise d’une taille importante, pour un gain de productivité toujours plus prégnant.

A suivre…

Publicités

SEPA : Etat des lieux

Que signifie SEPA ?

Comme indiqué dans un article sur ce site, le terme SEPA signifie Single Euro Payments Area. C’est la zone où plus de 500 millions de citoyens et plus de 20 millions d’entreprises et autorités publiques européennes peuvent effectuer et recevoir des paiements en euros dans les mêmes conditions, droits et obligations, indépendamment de leur emplacement.

L’introduction de l’euro a contribué à la facilitation des paiements en espèces partout dans la région, les rendant aussi simples que dans son pays d’origine. Jusqu’à récemment, il était pas si facile de payer pour des biens ou des services par voie électronique dans un autre pays de la zone euro, par exemple avec une banque carte de débit, le moyen de paiement privilégié par de nombreux Européens aujourd’hui. Et quand vous vouliez transférer de l’argent à partir d’un compte bancaire domicilié dans votre pays d’origine vers un compte dans un autre pays de la zone euro, le paiement pouvait prendre beaucoup plus de temps, et le bénéficiaire ne pas obtenir la totalité du montant.

Quels sont les avantages de SEPA ?

SEPA rend tous les paiements électroniques effectués dans la zone euro aussi simples que les paiements en espèces. Vous pouvez effectuer des transferts rapides et sûrs entre comptes bancaires partout dans la zone euro. Et si vous faites des emplettes à l’étranger, vous pouvez également utiliser votre carte de débit bancaire pour effectuer un paiement en euros, comme vous le feriez dans votre pays d’origine.

bonhomme avec une loupe faisant un état des lieux

SEPA implique également de meilleurs services bancaires pour tous : une tarification transparente, de précieuses garanties assurant que vos paiements sont reçus rapidement et intégralement, et les banques assument la responsabilité si quelque chose se passe mal avec votre paiement.
Les gains globaux attendus de SEPA pour toutes les parties prenantes a été évalué à 21,9 milliards € par an par PWC en 2014 confirmant une étude Capgemini de 2008 l’évaluation de ces avantages à 123 M € cumulés sur 6 ans.

Réglementation SEPA

La réglementation SEPA (EC 260/2012) adoptée en 2012, vise à créer un véritable marché unique européen des paiements de détail.
Le passage définitif à SEPA date du 1er août 2014. Depuis cette date, tous les virements et les prélèvements en euros sont faits sous le même format : les virements SEPA (SCT) et les prélèvements SEPA (SDD).
A l’origine, le passage devait se faire le 1er août 2014, mais une modification du règlement SEPA a introduit une période de transition de six mois – jusqu’au 1er Août 2014, donc – pour assurer un minimum de perturbations pour les consommateurs et les entreprises.

SEPA : un travail collaboratif

Le Single Euro Payments Area (SEPA) est une initiative du secteur bancaire européen qui a permis de rendre tous les paiements électroniques dans l’ensemble de la zone euro – par exemple, par carte de crédit, carte de débit, virement bancaire ou prélèvement – aussi facile que les paiements nationaux dans son pays d’origine.

Le projet SEPA a fortement été soutenu par la Commission européenne et la Banque centrale européenne. Le Conseil SEPA, qui sera bientôt remplacé par un nouvel organe de gouvernance, le conseil paiements de détail Euro (ERPB), rassemble tous les acteurs du marché du paiement et vise à faciliter la mise en place et la transition en douceur vers le SEPA.

La migration SEPA

La Commission européenne, en collaboration avec la BCE, a surveillé de près la migration de chaque État membre vers le SEPA.

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.