Cette migration peut s'effectuer avec ou sans utilisation de logiciels du marché. Outre les impacts principaux énumérés dans "Obligations et impacts", il est important de traiter correctement les sujets suivants :

• la version XML du pain.001 à implémenter : 2 versions sont en général supportées par les banques, les versions 2006 et 2009, mais une 3ème version va bientôt s'ajouter : la "future" version 2012.
• les produits bancaires : les banques proposent aujoud'hui une multitude de produits de type "virement", ces produits ont été déclinés dans le monde XML et diffèrent d'une banque à l'autre.
• Les spécificités d'implémentation des formats XML : pour traiter des problèmes d'architecture ou supporter ces "produits" bancaires, certaines banques exigent la présence de certaines données optionnelles SEPA ou de données non SEPA.

SEPA_NDAT traite tous ces sujets par simple paramétrage. L'entreprise n'a besoin de discuter que des modalités de bascule avec ses différentes banques (big bang, par produit...). SEPA_NDAT n'ajoutera pas de contrainte à cette migration, il traitera tous les flux qui lui seront soumis.

Remarque : Pour les entreprises émettant principalement des virements, il est possible de fournir une licence SEPA_NDAT sans limite de relation (le socle du produit ayant été conçu pour générer des remises de plusieurs millions d'opérations), mais ce point est à traiter au cas par cas.

Le passage à SEPA des prélèvements est en général plus complexe et nécessite parfois une refonte du système d'information lorsque l'entreprise ne souhaite pas utiliser des logiciels du marché :

• un nouveau modèle de données : la notion de mandat SEPA et celle de demande et autorisation de prélèvement sont proches mais les données décrivant la relation et les données échangées dans l'ordre de paiement diffèrent
• de nouvelles responsabilités côté créancier : elles nécessitent dans certains cas le développement de nouvelles fonctionnalités autour de la gestion des mandats
• l'existence de deux types de mandats SEPA : le récurrent et l'unitaire. L'unitaire n'est utilisable qu'une fois et le récurrent doit se conformer aux règles de séquence et de délai d'échange (le premier, les suivants, le dernier)
• la présence de deux schemes opérationnels : le CORE (service de base) et le B2B (service entre entreprises, certaines règles d'échange sont spécifiques à ce scheme), un nouveau instrument (COR1) risque d'être mis en oeuvre prochainement, certains pays commencent à l'implémenter.

Migrer ses prélèvement oblige également l'entreprise à définir sa gestion des nouveaux clients jusqu'au 1er février : le maintien de la procédure actuelle (demande de prélèvement national) ou la gestion des nouveaux mandats SEPA.

La complexité de la bascule dépend principalement de la gestion actuelle des demandes d'autorisation. Les entreprises se regroupent en deux catégories :

• Celles n'ayant qu'un produit ou regroupant sous une seule demande de prélèvement, un ensemble de produits ou services
• Celles ayant fait signer à leurs clients autant de demandes de prélèvement que de produits ou services.

La logique du monde SEPA correspond à la seconde catégorie mais il est possible de garder - dans le cadre de la migration au SEPA - le mode de fonctionnement actuel mais la révocation de ce mandat migré bloquera les recouvrements de tous les services et produits sous-jacents.

SEPA_NDAT s'adapte à toutes les situations :

• Si l'entreprise est mono-produit ou gère tous ses produits via une seule demande de prélèvement (c'est la situation la plus simple car la relation avec un client peut être définie par le numéro de compte à débiter)
  • Alors la bascule des flux en mode SEPA est immédiate et ne nécessite pas d'adaptation côté système d'information de l'entreprise, néanmoins pour les entreprises "multi-produits", les futurs mandats SEPA ne devraient pas suivre cette logique.
• Si l'entreprise gère autant de demandes de prélèvement que de produits
  • Alors les applications générant ces ordres de paiement devront subir une petite évolution pour intégrer au niveau de chaque ordre, une référence unique permettant d'identifier cette relation.
  • Ce mode de fonctionnement nécessite une initialisation préalable des relations gérées dans SEPA_NDAT avant toute émission de prélèvement.

L'entreprise peut choisir un mode "big bang" ou une migration progressive mais comme pour les virements, ces modalités sont à définir avec les banques. Un ordre soumis à SEPA_NDAT sera automatiquement converti si la relation correspondante a été initialisée ou si celle-ci peut être créée automatiquement.

L'obligation de notification aux débiteurs nécessite l'entreprise :

• soit gérer en interne la référence mandat et à l'imposer à SEPA_NDAT
• soit à soumettre ses demandes de prélèvement suffisamment à l'avance pour respecter les délais de notification
• soit à soumettre la liste de clients migrant dans un palier à SEPA_NDAT et ainsi récupérer la référence mandat créée par l'application.

Avec ou sans une telle application, l'entreprise doit préalablement collecter et/ou traiter certains points avec les banques teneuses de ses comptes :

• son nouvel identifiant d'émetteur de prélèvement (si émetteur)
• les produits SEPA correspondant à ses flux actuels
• les versions ISO supportées par ses banques et les spécificités qu'il devra implémenter
• les modalités de bascule
• les capacités de test de la banque.

Si l'entreprise dialogue avec ses banques au travers d'un logiciel de communication bancaire, elle devra certainement acquérir la version supportant les flux XML.