Vérification du bénéficiaire (VoP) un an après : ce que cela change pour le référentiel fournisseurs de l'ERP

Depuis le 9 octobre 2025, chaque virement SEPA en euros émis depuis la zone euro peut être soumis à un contrôle de concordance entre le nom du bénéficiaire et son IBAN. Un an plus tard, la vérification du bénéficiaire (Verification of Payee, VoP) n’est plus un sujet bancaire lointain : elle révèle sans pitié la qualité du référentiel fournisseurs de votre ERP. Ce point d’étape fait le bilan pour les DAF, trésoriers et DSI, et propose une checklist en huit points.

Rappel : ce que prévoit le règlement et ce qui s’applique

La VoP découle du règlement (UE) 2024/886, le règlement sur les paiements instantanés qui modifie le règlement SEPA. Il impose aux prestataires de services de paiement (PSP) de proposer un service de vérification du bénéficiaire pour les virements en euros, y compris les virements classiques et pas seulement instantanés. Selon Deutsche Bank, le service s’applique à partir du 9 octobre 2025 dans la zone euro, et la réglementation impose de le proposer gratuitement. Le calendrier pour les États membres hors zone euro est décalé : si vous payez des fournisseurs en dehors de la zone euro, vérifiez auprès de vos banques la date applicable à chaque pays.

Le dispositif technique repose sur le schéma VoP du Conseil européen des paiements (EPC), entré en vigueur début octobre 2025 d’après les informations publiées par l’EPC. Ce schéma définit le dialogue entre la banque du payeur et celle du bénéficiaire. Pour l’entreprise, ce qui compte est ce que sa banque lui retourne et ce que son ERP en fait.

À noter : le texte parle de la vérification des virements, pas de celle des prélèvements ni des paiements par carte. Votre périmètre est donc le flux sortant de virements en euros : fournisseurs, notes de frais, paies, remboursements clients.

Ce que voit l’entreprise : match, close match, no match

La banque du payeur reçoit une réponse parmi quatre issues, que décrit notamment Deutsche Bank :

• Match : le nom fourni correspond au titulaire du compte.
• Close match : le nom est proche, et la banque communique le nom réel du titulaire au payeur.
• No match : le nom diffère de celui enregistré pour cet IBAN.
• Vérification impossible : banque indisponible, compte introuvable ou indisponibilité technique.

Point essentiel pour la gouvernance : en cas de « no match » ou de « close match », le payeur peut malgré tout lancer le paiement, mais il assume alors le risque de fraude, comme le rappelle la même source. Cette bascule de responsabilité transforme chaque exception en décision tracée, donc en sujet d’audit.

Le cas des paiements en masse et des fichiers

Les entreprises paient rarement à l’unité. Elles transmettent des fichiers pain.001 depuis l’ERP ou le logiciel de trésorerie. Deux éléments à connaître :

• L’option de renoncement (opt-out) : selon Deutsche Bank, les entreprises (hors consommateurs) peuvent renoncer à la VoP pour les fichiers de paiements en masse. Zanders précise que cette option ne vise que les lots, pas un fichier contenant un seul paiement, et qu’elle doit être convenue contractuellement avec la banque.
• Le retour des résultats : Zanders signale de nouveaux codes de statut ISO 20022 (RCVC, RVCM, RVNA, RVNM, RVMC) que la banque doit restituer. Chez Deutsche Bank, les résultats détaillés sont disponibles dans un portail ou en pain.002 v.10 selon le canal.

Zanders relève aussi une contrainte de délai : pour un fichier de 100 000 opérations, la vérification complète prendrait de l’ordre de 4 minutes, ce qui doit être confronté à vos heures limites de remise. Le même article indique que, faute de pouvoir traiter proprement les exceptions dans les flux, le groupe CGI-MP recommandait au départ de renoncer à la VoP pour les fichiers. Renoncer est possible, mais cela retire à l’entreprise un contrôle gratuit contre la fraude au RIB : la question mérite une décision explicite, pas un défaut subi.

Impacts ERP : de la donnée de base au rapprochement

La VoP compare un nom et un IBAN. Votre ERP doit donc fournir un nom exploitable en face de chaque IBAN.

1. Qualité du nom du tiers. Beaucoup de fiches fournisseurs portent un nom commercial, un sigle ou une saisie historique, alors que la banque compare avec le titulaire du compte, souvent la raison sociale. Un nettoyage du référentiel est le chantier le plus rentable : raison sociale légale, nom du titulaire du compte, et distinction claire des deux champs. Si votre ERP n’a qu’un seul champ « nom », il faudra peut-être ajouter un champ « titulaire du compte bancaire » sur la fiche de coordonnées bancaires.

2. Workflow de modification d’IBAN. Un changement de coordonnées bancaires doit suivre un circuit dédié : demande tracée, contrôle indépendant, validation par une personne distincte de celle qui saisit. L’ERP doit empêcher qu’un même utilisateur crée le fournisseur, modifie l’IBAN et lance le paiement.

3. Double validation. Au-delà d’un seuil que vous fixez, la modification de RIB déclenche une seconde validation. Ce seuil relève de votre politique interne, pas du règlement.

4. Historisation. Conservez pour chaque IBAN : date de création, auteur, validateur, justificatif, date de dernier changement, et résultat de la dernière vérification VoP si votre banque le restitue. Cet historique vous sert en cas de litige de fraude, puisque la responsabilité dépend de ce qui a été fait au moment du paiement.

5. Retours banque et rapprochement. Les statuts de vérification remontent par les retours de fichier. Si votre ERP ou votre connecteur bancaire ne sait qu’ingérer un simple « accepté / rejeté », les « close match » seront invisibles. Faites cartographier par votre intégrateur les statuts reçus dans le journal de paiement, et vérifiez ce que votre éditeur supporte réellement, sur la base de sa documentation officielle, avant d’engager un développement. Je ne cite ici aucune fonctionnalité éditeur : la couverture varie selon les versions et les connecteurs bancaires, et elle se valide dans votre environnement de test.

Ces chantiers prolongent le travail sur la trésorerie décrit dans notre guide SEPA Instant et module trésorerie ERP, notamment sur l’exécution en continu et la qualité des données de paiement.

Processus fournisseurs : « close match », exceptions, délais

Le risque principal n’est pas technique, il est opérationnel. Quand un paiement revient en « close match », quelqu’un doit décider vite, avec une règle claire.

Un protocole simple fonctionne bien :

• Close match sur un fournisseur connu et stable (différence de forme juridique, abréviation, accent) : contrôle du nom communiqué par la banque contre le K-bis, le contrat ou la facture, puis validation par le comptable fournisseurs senior, avec mise à jour de la fiche.
• Close match sur un IBAN récemment modifié : escalade systématique, rappel du fournisseur sur un numéro déjà connu, validation du responsable.
• No match : paiement bloqué par défaut. Libération uniquement après vérification par un canal indépendant, avec traçabilité de la décision.
• Vérification impossible : traitement comme un paiement non vérifié, selon la politique interne, avec contrôle renforcé au-delà d’un seuil.

Sur les délais, une exception non traitée retarde le paiement. Or les règles sur les retards de paiement se durcissent : consultez notre analyse de la réforme des délais de paiement B2B et de la configuration de l’ERP. Une file d’exceptions VoP non pilotée peut transformer un contrôle anti-fraude en source de pénalités. Prévoyez des indicateurs : nombre d’exceptions par run de paiement, âge moyen des exceptions, taux de résolution sous 24 heures.

Lutte contre la fraude au RIB : les contrôles qui restent indispensables

La VoP est un filet, pas une solution complète. Un fraudeur qui contrôle un compte ouvert au bon nom (ou une société écran au nom crédible) peut obtenir un « match ». Les contrôles préventifs restent donc nécessaires :

• Rappel (callback) : toute demande de changement d’IBAN est confirmée par un appel à un numéro déjà présent dans l’ERP, jamais celui indiqué dans le courriel de demande.
• Séparation des tâches : la personne qui modifie les données bancaires n’est ni celle qui valide les paiements ni celle qui rapproche les relevés. Notre guide sur les contrôles SoD à implémenter avant l’audit annuel détaille la matrice de conflits à paramétrer.
• Alertes d’anomalie : changement d’IBAN suivi d’un paiement dans les jours qui suivent, IBAN d’un pays différent de celui du fournisseur, IBAN partagé par plusieurs fournisseurs.
• Contrôle des habilitations : limitez le nombre d’utilisateurs autorisés à modifier les coordonnées bancaires et revoyez leurs droits régulièrement.

L’intérêt de combiner VoP et ces contrôles : le premier attrape les erreurs de saisie et les fraudes grossières à grande échelle, les seconds traitent les fraudes ciblées qui passent le contrôle automatique.

Bilan à un an : checklist 8 points DAF/DSI

1. Décider du périmètre : VoP activée ou opt-out pour les fichiers, par banque, avec la décision écrite et signée par la trésorerie.
2. Nettoyer le référentiel : raison sociale légale et titulaire du compte distincts, doublons supprimés, fournisseurs inactifs bloqués.
3. Revoir le workflow de changement d’IBAN : demande tracée, callback, validation par un tiers.
4. Contrôler la SoD : aucun utilisateur ne cumule création de fournisseur, modification de RIB et lancement de paiement.
5. Brancher les retours banque : statuts VoP lisibles dans l’ERP ou le logiciel de trésorerie, pas seulement dans le portail bancaire.
6. Écrire la procédure d’exception : règles pour close match, no match et vérification impossible, avec responsables et délais.
7. Mesurer : taux de match, volume d’exceptions, délai de résolution, tentatives de fraude détectées.
8. Tester la capacité : confirmer avec la banque que les temps de traitement des gros fichiers restent compatibles avec vos heures limites.

Un an après, la VoP a surtout montré que la donnée tiers était un actif de contrôle interne. Les entreprises qui avaient déjà un référentiel propre l’ont vécue comme une formalité ; les autres découvrent le coût d’une donnée de base négligée.

Pour approfondir l’adaptation de l’ERP aux nouveaux flux de paiement, lisez notre guide SEPA Instant et trésorerie ERP et recevez les prochaines analyses réglementaires en vous abonnant à la newsletter.