Votre banque peut désormais envoyer un virement en dix secondes. Votre ERP peut émettre une facture électronique normalisée. Mais entre ces deux capacités, il manque encore un maillon : qui déclenche le paiement, et comment ? C’est précisément l’espace que comble le SEPA Request-to-Pay (R2P), le nouveau schéma de l’European Payments Council (EPC) qui renverse l’initiative dans le cycle Order-to-Cash.
R2P n’est pas une mise à jour technique marginale. C’est un changement structurel dans la relation financière entre créancier et débiteur — avec des implications directes pour vos modules Accounts Receivable, votre gestion du DSO et la configuration de vos workflows de rapprochement. Ce guide fait le point sur ce que R2P est concrètement, où en est son déploiement en 2026, et ce que vos équipes Finance doivent préparer.
SEPA Request-to-Pay — de quoi s’agit-il exactement ?
La différence fondamentale avec le virement, le prélèvement et le paiement instantané
Pour comprendre R2P, il faut d’abord distinguer quatre mécanismes que l’on confond fréquemment.
Le virement SEPA (SCT) est initié par le débiteur : c’est lui qui entre dans son interface bancaire, saisit le montant et l’IBAN, et valide l’opération. Le créancier attend — sans garantie de délai.
Le prélèvement SEPA (SDD) est initié par le créancier, mais sur la base d’un mandat préalable : une autorisation permanente qui lui permet de débiter le compte du débiteur sans action de sa part à chaque opération. La contrepartie est un risque de contestation élevé : le débiteur dispose d’un délai de huit semaines pour contester un prélèvement non autorisé.
Le SEPA Instant Credit Transfer (SCT Inst) est un virement standard exécuté en moins de dix secondes, 24h/24 — c’est la vitesse de règlement, pas un nouveau type d’initiation.
Le SEPA Request-to-Pay (SRTP) est fondamentalement différent : il est initié par le créancier, mais il n’est pas un prélèvement. Il envoie une demande de paiement structurée au débiteur, qui doit activement l’accepter, la refuser ou la reporter depuis son interface bancaire. Si le débiteur accepte, le règlement est déclenché — typiquement via SCT Inst — en temps réel. L’initiative revient au créancier, mais le consentement reste au débiteur à chaque transaction.
Le Rulebook EPC SRTP version 4.0
L’EPC a publié la version 4.0 du SEPA Request-to-Pay Scheme Rulebook, qui est la version de référence actuelle du schéma. Elle introduit notamment l’obligation pour les participants de s’inscrire dans l’EPC Directory Service (EDS), un annuaire centralisé permettant à l’expéditeur d’une demande R2P de localiser le PSP destinataire.
Les messages échangés sont standardisés en ISO 20022 : pain.013 pour la requête de paiement initiale, pain.014 pour la réponse du débiteur. Ces formats s’inscrivent dans la même famille que les messages de virement (PAIN.001) et de prélèvement (PAIN.008) déjà connus des modules ERP Finance.
Calendrier de déploiement 2025-2027
Le SRTP n’est pas obligatoire, contrairement au SEPA Instant Credit Transfer dont la réception est obligatoire depuis janvier 2025 et l’émission depuis octobre 2025 pour les banques de la zone euro. Le schéma R2P repose sur l’adhésion volontaire des PSP.
Selon les documents publiés par l’EPC à la 24e réunion de l’Euro Retail Payments Board (ERPB), le déploiement suit ce calendrier :
- 1er octobre 2025 : lancement d’un processus d’homologation simplifié pour les PSP.
- Vague 1 d’homologation 2026 : 1er février — 30 avril 2026.
- Vague 2 d’homologation 2026 : 1er avril — 30 juin 2026.
- Vague 3 d’homologation 2026 : 1er septembre — 30 novembre 2026.
- Fin septembre 2026 : ouverture de l’EPC Directory Service (EDS) aux participants SRTP.
Au moment de la rédaction, trois PSP et trois Referenced Technical Solution Providers (RTSP) ont été homologués et publiés dans le registre EPC des participants. L’adoption reste embryonnaire, mais les vagues d’homologation de 2026 devraient marquer l’accélération réelle du schéma.
Pourquoi R2P change les règles pour les équipes Finance
Le créancier reprend l’initiative du paiement
Dans le cycle O2C traditionnel, le créancier émet une facture et attend. Le virement arrive quand le débiteur le décide — souvent à J+30, J+45, voire J+60 selon les pratiques sectorielles. Ce modèle passif génère l’essentiel des dérives de DSO dans les entreprises B2B.
R2P renverse structurellement ce schéma : dès la facturation, le créancier peut envoyer une demande de paiement directement dans l’interface bancaire du débiteur. Le débiteur est notifié — dans son application bancaire, son portail de trésorerie, ou son ERP si son PSP dispose d’une API de notification. Il doit répondre activement.
Cette notification active transforme le processus de recouvrement : au lieu d’envoyer des e-mails de relance en espérant une réaction, le créancier pousse la demande dans l’interface de décision du débiteur.
Confirmation en temps réel, meilleure prévisibilité du cash
Quand le débiteur accepte la demande, le règlement via SCT Inst arrive en moins de dix secondes. Quand il refuse ou diffère, le créancier reçoit immédiatement la réponse structurée — avec un motif optionnel. Dans les deux cas, l’équipe Finance sait exactement où en est chaque facture sans attendre la clôture d’un relevé bancaire.
Ce flux de confirmation en temps réel améliore mécaniquement la prévision de trésorerie : les positions de cash ne sont plus calculées sur la base de délais supposés, mais sur des confirmations réelles reçues transaction par transaction.
La combinaison gagnante : facturation électronique Peppol + SEPA R2P
La connexion la plus stratégique est celle entre la facturation électronique normalisée (Peppol BIS, Factur-X) et R2P. Dans ce flux, la facture électronique contient déjà toutes les informations nécessaires : montant, IBAN, référence structurée, échéance. L’ERP créancier peut extraire ces données et générer automatiquement le message pain.013 sans saisie manuelle.
C’est le modèle “invoice pulls payment” : la facture déclenche automatiquement la demande de paiement, et la réponse du débiteur déclenche le règlement. Le potentiel d’un cycle O2C sans intervention manuelle est réel — à condition que les deux parties soient équipées et que leurs PSP respectifs aient rejoint le schéma SRTP.
Avantage pour le B2B vs les cartes bancaires
Le R2P présente un avantage de coût structurel par rapport aux paiements par carte bancaire en B2B. Les virements SEPA (et donc SCT Inst en sous-jacent) ne comportent pas de commission d’interchange, contrairement aux cartes où les frais de traitement peuvent atteindre 1 à 3 % du montant. Pour les transactions B2B de montants élevés, l’économie est significative.
Comment R2P s’intègre dans le cycle Order-to-Cash
Le flux R2P comporte cinq étapes dans le cycle O2C :
Étape 1 — Émission de la facture : la facture est générée dans le module AR de l’ERP (format Factur-X, Peppol BIS ou PDF selon le canal de transmission). Le module AR extrait montant, IBAN créancier, référence structurée et date d’échéance.
Étape 2 — Envoi du message R2P (pain.013) : le module trésorerie ou AR de l’ERP génère un message ISO 20022 pain.013 et le transmet au PSP créancier, qui le route vers le PSP débiteur via le réseau SRTP et l’EDS.
Étape 3 — Notification au débiteur : le PSP débiteur notifie son client — notification push dans l’application bancaire, ou notification dans son ERP si le PSP expose une API de notification. Le débiteur dispose d’un délai configurable pour répondre (la durée maximale est définie dans le Rulebook v4.0).
Étape 4 — Réponse du débiteur (pain.014) : il accepte (déclenche immédiatement un SCT Inst), refuse (avec motif structuré), ou diffère (en indiquant une date de règlement ultérieure).
Étape 5 — Rapprochement automatique : la confirmation de règlement (CAMT.054) alimente immédiatement le module AR de l’ERP créancier. Le lettrage est automatique si la référence structurée ISO 20022 est correctement configurée en amont.
Cas d’usage B2B prioritaires
Facture ponctuelle à court délai : un prestataire peut envoyer une demande R2P dès l’émission de la facture et obtenir un règlement le jour même si le client accepte — sans attendre le cycle J+30 standard.
Acompte de projet : au lieu d’attendre un virement manuel sur bon de commande, le responsable de projet envoie la demande R2P sur l’acompte et reçoit la confirmation de paiement avant le démarrage des travaux.
Abonnement B2B récurrent : contrairement au prélèvement automatique (contestable huit semaines après), le R2P repose sur un consentement actif à chaque échéance. Les débiteurs peuvent configurer une acceptation automatique pour leurs fournisseurs référencés, ce qui combine l’automatisation du prélèvement et la transparence du virement.
État de préparation des ERP en 2026
La réalité de 2026 est que les grands ERP généralistes ne disposent pas encore de module SRTP natif. Le schéma est trop récent et l’adoption bancaire encore trop limitée pour avoir justifié un développement natif dans les roadmaps publiées.
SAP S/4HANA
SAP ne dispose pas d’un module SRTP natif dans S/4HANA à la date de cet article. Le module Advanced Payment Management intègre progressivement les formats ISO 20022, mais le support explicite du schéma EPC SRTP (pain.013/014) n’est pas documenté dans les release notes S/4HANA 2025 ou 2026. En octobre 2026, SAP a lancé SAP Pay, un service de paiement embarqué dans SAP Cloud ERP fonctionnant en Europe — mais son périmètre actuel couvre les virements et compensations, pas encore le schéma SRTP.
Microsoft Dynamics 365 Finance
Dynamics 365 Finance supporte ISO 20022 via les fichiers GER (Generic Electronic Reporting) et les formats SEPA Credit Transfer. Le support explicite du schéma SRTP (pain.013/014) n’apparaît pas dans les Release Plans publiés à ce jour. Les équipes Finance devront passer par un connecteur partenaire ou une solution de payment orchestration.
Oracle Fusion Cloud Financials
Même constat pour Oracle Fusion : le module Payments supporte ISO 20022 et SEPA SCT/SDD, mais la roadmap R2P officielle n’est pas documentée publiquement.
Sage, Cegid, Odoo
Les éditeurs de mid-market français et européens n’ont pas encore annoncé de module SRTP natif. Odoo 17/18 supporte le module SEPA via l’extension l10n_sepa (SCT classique) — l’extension vers SRTP est possible via API partenaire mais non intégrée en standard.
Solutions intermédiaires
Pour les équipes Finance qui souhaitent activer R2P sans attendre un module ERP natif, trois types de solutions permettent de gérer les messages pain.013/014 de façon centralisée :
- Kyriba : plateforme de trésorerie centralisée avec connectivité ISO 20022 multi-banque, utilisable comme orchestrateur R2P en pont entre l’ERP et le PSP.
- Cobase : connecteur bancaire cloud compatible SAP S/4HANA, Oracle NetSuite et Dynamics 365, connecté via SWIFT, EBICS et API.
- TIS (Treasury Intelligence Solutions) : solution de payment factory avec support des formats ISO 20022 et intégration ERP multi-éditeur.
Ce que les équipes Finance doivent préparer maintenant
R2P n’est pas encore obligatoire et son adoption bancaire reste naissante en 2026 — mais les vagues d’homologation EPC sont en cours et l’EDS ouvre fin septembre 2026. Les équipes Finance qui veulent bénéficier des premiers avantages opérationnels ont intérêt à se préparer avant que la mise en oeuvre devienne urgente.
Checklist 5 points
-
Vérifier la compatibilité SRTP de votre banque principale : interrogez votre gestionnaire de compte sur le statut d’homologation SRTP de votre PSP. Vous pouvez consulter le registre public EPC des participants.
-
Auditer votre module AR : peut-il générer des messages pain.013, ou s’interfacer avec une solution de payment orchestration ? Posez la question à votre intégrateur ERP avec une demande écrite de position officielle.
-
Vérifier vos références structurées ISO 20022 : R2P exige des références de facture normalisées pour le rapprochement automatique. Si vos factures utilisent encore des références libres non structurées, une mise à niveau est nécessaire avant toute intégration R2P.
-
Mettre à jour les CGV clients : R2P implique que vos clients reçoivent des demandes de paiement dans leur interface bancaire. Prévenez-les et envisagez une clause contractuelle.
-
Prévoir 3 à 6 mois de mise en oeuvre : entre l’audit, le choix de la solution (module natif ou connecteur tiers), les tests avec le PSP, et la formation des équipes Credit Management, le délai réaliste est de 3 à 6 mois.
Questions à poser à votre intégrateur ERP
- “Votre roadmap inclut-elle un support natif du schéma EPC SRTP (pain.013/014) ?” et pour quelle version ou release ?
- “Quelle est votre recommandation pour une mise en oeuvre R2P intermédiaire sans attendre le module natif ?”
- “Comment gérez-vous l’intégration CAMT.054 en mode push pour le rapprochement temps réel ?”
- “Notre référentiel tiers est-il conforme aux adresses structurées ISO 20022 ?” — rappel : le format d’adresse non structuré est interdit dans tous les messages EPC depuis novembre 2025.
Pour approfondir l’impact du SEPA Instant sur votre module trésorerie ERP, consultez notre guide SEPA Instant Payment 2026 : pourquoi votre module trésorerie ERP n’est probablement pas prêt. Pour optimiser l’ensemble du cycle Order-to-Cash, lisez notre article Order-to-Cash dans l’ERP : réduire votre DSO et automatiser le recouvrement B2B et notre guide Comptes clients ERP : Credit Management, relances et réduction du DSO.
