A partir du 1er février 2014, les formats de fichiers actuels pour les ordres de virement et de prélèvement ne devraient plus être acceptés par les banques. Les formats nationaux (AFB ou CFONB pour la France) sont abandonnés au profit de formats européens basés sur la norme XML ISO20022.

Sept pays de la zone Euro (Estonie, Grèce, Italie, Portugal, Chypre et Slovaquie) ont demandé le report de cette contrainte à 2016. Dans tous les autres dont la France, toutes les entreprises émettant des fichiers de virements et/ou des prélèvements sont dans l'obligation de migrer leurs flux de paiement avant cette date sous peine de ne plus pouvoir payer leurs employés, leurs fournisseurs ou collecter leurs créances.

Cette obligation possède quelques exceptions :

• La France et cinq autres pays peuvent encore les utiliser pour les seuls produits de niche jusqu'en 2016 (en France seul le virement spécifique de trésorerie - VSOT - est concerné mais certaines banques propose déjà un tel virement en XML).
• Ces formats continueront à être utilisés pour les LCR et les BOR mais la décision de bascule de ces instruments au "SEPA" a été enterrinée le 3 juin. La durée de vie de ces formats nationaux est donc comptée.

Cette contrainte oblige les entreprises à changer les formats techniques des fichiers d'ordres (les virements selon le format « pain.001 » et les prélèvements selon le format « pain.008 », « pain » pour payment initiation). Elles doivent éventuellement supporter de nouveaux formats XML pour les retours bancaires (si elles choisissent de recevoir les nouveaux formats XML) et elles doivent prendre en compte les aspects financiers et organisationnels .

Les entreprises vont également être confrontées aux principales difficultés suivantes dans leur projet de migration :

• La qualité des fichiers actuellement produits : les formats français et leurs alimentations (souvent très anciennes) ne facilitent pas leur bascule vers les modèles SEPA : références parfois non présentes ou non uniques, structuration des données différentes. Le modèle de données SEPA est plus riche.
• Les règles d'implémentation des banques : les préconisations d'implémentation européennes (exposées via les guides d'implémentation de l'EPC - European Payments Council) et les implémentations adoptées par les banques diffèrent, certaines banques exigent la présence de certaines données optionnelles même pour les services de base.
• L'arrivée de nouveaux produits bancaires d'échange liés au contexte SEPA et au format ISO20022. Les offres sont différentes d'une banque à l'autre et leur implémentation est souvent spécifique. On trouve désormais des produits purement SEPA et des produits plus étendus basés sur la même norme XML mais utilisant des données hors du modèle SEPA.
• La gestion des retours bancaires : les nouveaux formats XML de type "camt" (le camt.054 remplace pour la France le CFONB240 et le camt.053 le CFONB120) ne seront renvoyés vers les entreprises qu'à leur demande mais ont-elles réellement le choix, les longueurs des données sont incompatibles, la richesse des données différente ? Quant aux PSR qui remplacent les ARA, le sujet est complexe à traiter du fait des différentes versions XML et d'une implémentation variable selon les banques. L'enjeu principal sera de choisir les bonnes offres de restitution bancaire pour en extraire les "rejets" ou "impayés".

Si on exclut le problème des retours, la migration des virements ne devrait pas poser de difficulté. Il s'agit avant tout d'une bascule technique (changement de format). Un produit comme SEPA_NDAT permet de traiter cet aspect par paramétrage en quelques minutes.

Pour les entreprises émettrices de prélèvements, les impacts sont plus importants. Le système d'information doit évoluer pour prendre en compte les changements imposés par le SEPA :

• de nouveaux délais d'encaissement
• un cycle de vie à respecter (séquence du mandat)
• les notifications aux débiteurs
• les nouveaux types de mandat (one-off, récurrent, CORE, B2B) 
• les nouvelles données portées par le mandat
• le traitement des nouveaux rejets, la gestion des litiges
• les demandes de vérification des mandats (existence et validité).

La gestion du BIC et de l'IBAN et l'abandon progressif du BIC dans les 2 prochaines années ne doivent pas être oubliés mais ces points ne sont pas propre au SDD.

L'avantage de la mise en place d'une application intermédiaire comme SEPA_NDAT est de prendre en charge une grande partie de ces points en minimisant les impacts sur le SI de l'entreprise.