Comment choisir une plateforme agréée (PA) pour SAP en France

Un guide pratique pour évaluer les plateformes agréées dans un environnement SAP en France : intégration ERP, architecture de conformité, évolutivité et coût total de possession.

La réforme française de la facturation électronique est désormais entrée en vigueur. Depuis le 1er septembre 2026, les entreprises établies en France et assujetties à la TVA doivent être en mesure de recevoir des factures électroniques. Les grandes entreprises, les ETI ainsi que les assujettis uniques relevant du régime français des groupes TVA doivent également émettre leurs factures sous forme électronique et respecter les obligations d’e-reporting qui leur sont applicables. Ces échanges reposent sur une plateforme agréée (PA), nouvelle appellation des anciennes plateformes de dématérialisation partenaires (PDP).

Pour les entreprises utilisant SAP, le choix d’une PA dépasse donc largement les seules questions de conformité ou d’achat de solution. La plateforme devient un composant à part entière de l’architecture de facturation. Elle influe sur les échanges de données entre SAP, les clients, les fournisseurs et l’administration fiscale, mais aussi sur la gestion des statuts de facture, des exceptions, des données de reporting et des processus de support.

Le choix doit avant tout tenir compte de la capacité de la plateforme à s’intégrer à l’environnement SAP de l’entreprise, à ses flux transactionnels, à son modèle opérationnel et à son architecture globale de conformité.

Vous souhaitez mieux comprendre la réforme française de la facturation électronique et de l’e-reporting ?

Découvrez les principales obligations, le calendrier de mise en œuvre, les implications pour SAP et les priorités à prendre en compte pour préparer votre organisation.

Lire l’article

Pourquoi le choix d’une plateforme agréée relève désormais de l’architecture SAP

Une plateforme agréée s’insère entre les systèmes d’information de l’entreprise et l’écosystème français de la facturation électronique. Son rôle ne se limite pas à transmettre des fichiers de facturation. Elle peut émettre, transmettre et recevoir des factures électroniques, extraire les données requises par l’administration fiscale, transmettre les données de transaction et de paiement dans le cadre de l’e-reporting et assurer l’acheminement des factures à partir des informations de l’annuaire national. Seules les plateformes immatriculées par l’administration fiscale française peuvent exercer l’ensemble des fonctions réglementaires dévolues à une PA. D’autres solutions peuvent intervenir dans le dispositif technique, sans pour autant bénéficier du même statut ni assumer les mêmes fonctions réglementaires.

Dans un environnement SAP, la PA devient ainsi un composant à part entière de l’architecture de facturation. Une facture client peut être générée dans SAP, transmise à la PA retenue, puis acheminée vers la plateforme du destinataire, tandis que les données requises sont communiquées à l’administration. Pour les factures fournisseurs, la plateforme du fournisseur transmet le document à la PA de l’entreprise, qui met ensuite les données nécessaires à disposition du processus de traitement concerné dans SAP.

Les plateformes doivent également pouvoir échanger entre elles et avec l’infrastructure publique française. Les tests d’interopérabilité font partie du processus d’immatriculation.

L’architecture doit couvrir à la fois la facturation électronique et l’e-reporting. La facturation électronique concerne les opérations B2B entrant dans le champ de la réforme entre entreprises établies en France et assujetties à la TVA. L’e-reporting des transactions porte sur certaines opérations qui ne relèvent pas de la facturation électronique B2B domestique. La transmission des données de paiement constitue une obligation distincte pour les opérations concernées, notamment certaines prestations de services pour lesquelles la TVA est exigible lors de l’encaissement.

L’environnement SAP doit donc être en mesure de fournir les données attendues pour chaque flux et de récupérer les statuts et informations nécessaires à la poursuite des traitements dans les applications concernées.

Les conséquences opérationnelles vont bien au-delà de la simple transmission des factures. Le choix d’une PA peut notamment avoir un impact sur :

• l’acheminement des factures et la gestion des données de l’annuaire ;
• la remontée des statuts et leur synchronisation avec SAP ;
• le traitement des rejets, corrections et nouvelles soumissions ;
• la qualité des données de base et des données de facturation ;
• le suivi des échanges et la traçabilité nécessaire aux contrôles ;
• la répartition des responsabilités en cas d’erreur métier ou technique ;
• l’organisation du support entre les équipes Finance, Fiscalité et IT.

Les spécifications techniques françaises encadrent également les messages relatifs aux factures, les statuts associés au cycle de vie ainsi que les API utilisées pour les échanges entre les systèmes d’entreprise et les plateformes agréées. La PA doit donc être intégrée à la conception globale du système d’information, et non traitée comme un simple service de transmission.

Un changement de plateforme peut, par ailleurs, avoir des conséquences importantes sur l’architecture existante. Les interfaces, règles de transformation, mécanismes d’acheminement, dispositifs de supervision, scénarios de test, procédures de support et connexions avec les systèmes SAP ou non-SAP peuvent devoir être adaptés.

L’enjeu ne consiste donc pas uniquement à assurer la conformité au démarrage. Il s’agit de mettre en place une architecture capable de prendre en charge durablement les processus de facturation électronique et d’e-reporting, avec un niveau de maîtrise opérationnelle compatible avec les besoins de l’entreprise.

Calendrier de la facturation électronique en France

• 1er septembre 2026
  Les entreprises soumises à l’obligation de réception doivent être en mesure de recevoir des factures électroniques. Les grandes entreprises, les ETI ainsi que les assujettis uniques au sens de l’article 256 C du Code général des impôts doivent également émettre des factures électroniques et respecter les obligations d’e-reporting qui leur sont applicables.
• 1er septembre 2027
  Les PME et les microentreprises qui ne sont pas soumises à l’échéance antérieure en tant que membres d’un assujetti unique deviennent, à leur tour, soumises aux obligations de facturation électronique et, le cas échéant, d’e-reporting.

Comment les équipes SAP peuvent-elles aborder l’e-reporting dans le cadre de la réforme française ?

Découvrez la place de l’e-reporting dans le dispositif français et les points à prendre en compte pour préparer les flux de données, les intégrations et les processus de reporting dans un environnement SAP.

Lire l’article

Commencer par le paysage SAP, pas par la liste des plateformes agréées

Avant de comparer les prestataires, l’entreprise doit d’abord déterminer à quels systèmes la plateforme devra réellement se connecter. Une même PA peut entraîner des exigences de mise en œuvre très différentes selon que les factures proviennent d’un environnement SAP S/4HANA unique, d’un système SAP ECC fortement personnalisé ou de plusieurs applications SAP et non-SAP.

La première étape consiste donc à cartographier les systèmes qui génèrent, reçoivent, enrichissent et traitent les données de facturation, et pas uniquement l’ERP cible de l’entreprise.

Environnements SAP ECC et SAP S/4HANA on-premise

Dans les environnements SAP déjà en place, il faut partir des processus et des interfaces existants. Les configurations eDocument, les logiques de facturation spécifiques, les middleware, les connexions EDI et les intégrations avec des prestataires externes de facturation peuvent tous influer sur la manière dont la PA devra être intégrée.

La version du système et sa configuration ont également leur importance. SAP propose des fonctionnalités de conformité documentaire et réglementaire pour SAP ERP et SAP S/4HANA, mais les processus disponibles et les modalités de mise en œuvre varient selon le produit et la version concernés. Pour la France, par exemple, la documentation SAP prévoit une intégration avec SAP Document and Reporting Compliance (SAP DRC), cloud edition, pour l’échange de factures électroniques et de données de reporting.

La question n’est donc pas simplement de savoir si la PA peut se connecter à SAP. Il faut surtout déterminer quelle part de l’architecture de facturation existante peut être conservée et à quels endroits des adaptations, des règles de transformation ou des intégrations complémentaires seront nécessaires.

Environnements SAP S/4HANA Cloud

Les environnements SAP S/4HANA Cloud offrent un cadre plus standardisé pour mettre en œuvre les processus de conformité pris en charge par SAP. En France, SAP S/4HANA Cloud Public Edition prend en charge la facturation électronique et l’e-reporting via SAP DRC, cloud edition, qui peut assurer le rôle de plateforme agréée de l’entreprise. Le dispositif couvre aussi bien l’émission des factures clients que la réception des factures fournisseurs.

Cela ne dispense pas pour autant de faire des choix d’architecture. Les entreprises doivent encore déterminer où sont produites les données de facturation, quels processus entrent dans le périmètre de la réforme française, comment les exceptions seront traitées et si SAP DRC jouera le rôle de PA ou coexistera avec un autre prestataire. Les organisations restées proches des standards SAP peuvent toutefois avoir moins d’interfaces historiques et de développements spécifiques à prendre en compte.

Environnements hybrides et multi-ERP

Les grandes entreprises disposent rarement d’un paysage ERP parfaitement homogène. Une entité française peut déjà fonctionner sous SAP S/4HANA tandis qu’une autre reste sur SAP ECC. Des sociétés acquises peuvent utiliser des ERP non-SAP, certaines applications externes peuvent générer des factures et des centres de services partagés peuvent traiter les opérations de plusieurs entités juridiques.

Dans ce type d’environnement, la PA doit couvrir le paysage de facturation réel, et pas uniquement l’ERP cible retenu dans la feuille de route.

Avant de choisir une plateforme, il convient de cartographier :

• les systèmes qui génèrent les factures clients ;
• les points de réception et de traitement des factures fournisseurs ;
• les entités utilisant SAP ECC, SAP S/4HANA ou des systèmes non-SAP ;
• les flux de facturation qui transitent déjà par un middleware ou un prestataire externe ;
• les systèmes dans lesquels sont gérées les données fiscales, clients, fournisseurs et de paiement nécessaires aux obligations françaises.

Cette analyse montre souvent que l’intégration d’une PA ne se résume pas à une connexion unique entre SAP et une plateforme. Elle implique plusieurs flux qui doivent s’inscrire dans un modèle commun d’acheminement, de supervision et de support.

Paysages SAP multi-pays

Pour les groupes internationaux, les choix réalisés en France doivent également s’inscrire dans l’architecture globale de conformité. Une entreprise qui utilise déjà SAP DRC dans plusieurs pays n’abordera pas nécessairement la France de la même manière qu’un groupe ayant standardisé sa facturation électronique à l’échelle internationale autour d’un prestataire externe.

SAP DRC est précisément conçu pour prendre en charge les documents électroniques et les obligations de reporting réglementaire dans plusieurs pays et régions, avec des processus locaux activés au sein d’un même environnement de conformité.

Les questions d’architecture dépassent donc le seul périmètre français :

• La France sera-t-elle traitée comme une solution locale autonome ou intégrée à un modèle global de conformité ?
• SAP DRC est-il déjà utilisé dans d’autres entités du groupe ?
• Existe-t-il déjà un prestataire international de facturation électronique auquel l’architecture française doit s’intégrer ?
• La solution envisagée ajoutera-t-elle une nouvelle couche d’intégration spécifique à la France, à exploiter et à maintenir séparément ?

Une solution adaptée à une instance SAP française peut perdre de son intérêt si elle multiplie les interfaces et les dispositifs de supervision dans un paysage SAP international.

Les groupes internationaux utilisant SAP peuvent-ils intégrer les exigences françaises dans une stratégie de transformation plus large ?

Découvrez comment répondre aux exigences locales en France dans le cadre d’un modèle de transformation SAP plus global, combinant expertise locale, capacités de delivery internationales et gouvernance à l’échelle du groupe.

En savoir plus

Comment le paysage SAP fait évoluer les critères de choix d’une PA

L’analyse du paysage applicatif ne permet pas, à elle seule, de choisir une PA. Elle sert à définir les critères selon lesquels les différentes plateformes devront ensuite être évaluées, notamment la profondeur de l’intégration, l’interopérabilité, le modèle de support opérationnel, la sécurité, la capacité à accompagner l’évolution du périmètre et le coût total de possession.

Quels critères évaluer pour choisir une plateforme agréée dans un environnement SAP ?

Une fois le paysage SAP et l’architecture cible définis, les plateformes présélectionnées peuvent être comparées sur la base de critères opérationnels concrets : périmètre réglementaire, intégration avec SAP, interopérabilité, support opérationnel, sécurité, capacité à accompagner l’évolution du périmètre et coût total de possession.

Statut réglementaire et couverture fonctionnelle

La première vérification consiste à s’assurer que le prestataire figure sur la liste de la DGFiP des plateformes ayant obtenu leur immatriculation définitive. La DGFiP distingue ces plateformes des opérateurs dont le dossier est complet et conforme, mais dont l’immatriculation définitive reste conditionnée à la réussite des tests d’interopérabilité. Les supports commerciaux d’un prestataire ne suffisent donc pas, à eux seuls, à attester de son statut réglementaire actuel.

L’immatriculation ne constitue toutefois qu’un premier filtre. Les équipes SAP doivent également vérifier que le service proposé couvre bien les transactions et les entités juridiques concernées, notamment :

• l’émission et la réception de factures électroniques ;
• l’e-reporting des transactions ;
• la transmission des données de paiement, le cas échéant ;
• les formats de facture requis et les statuts du cycle de vie ;
• Les entités françaises et les scénarios métiers concernés.

Cette distinction est importante : être habilité à exercer le rôle de PA ne signifie pas nécessairement que la couverture fonctionnelle répond à l’ensemble des besoins de l’entreprise.

Niveau d’intégration avec SAP

L’expression « s’intègre à SAP » peut recouvrir des réalités très différentes, depuis une connexion standard jusqu’à un projet d’intégration reposant largement sur des API spécifiques. Le modèle d’intégration doit donc être examiné en détail.

Il convient notamment d’identifier les produits et versions SAP pris en charge, la disponibilité éventuelle de contenus d’intégration standard, les solutions middleware nécessaires et les développements spécifiques à prévoir. L’analyse doit couvrir les flux entrants et sortants, les accusés de réception et mises à jour de statut, la remontée des erreurs, les dépendances liées aux données de base ainsi que les factures générées en dehors du système SAP principal.

L’envoi d’une facture depuis SAP ne représente qu’une partie du processus. L’architecture doit également permettre de restituer dans SAP les informations nécessaires à la poursuite du traitement métier.

À titre de comparaison, le dispositif SAP prévu pour la France avec SAP DRC, cloud edition, prend en charge les factures clients et fournisseurs électroniques ainsi que les échanges avec l’infrastructure publique française et les plateformes agréées des partenaires commerciaux.

Interopérabilité et acheminement des factures

Une entreprise ne choisit pas la PA utilisée par ses clients ou ses fournisseurs. La plateforme retenue doit donc pouvoir échanger de manière fiable avec les autres plateformes agréées et exploiter correctement les informations nécessaires à l’acheminement des factures vers leur destinataire.

L’évaluation doit notamment porter sur la gestion des recherches dans le référentiel, de l’adressage, des changements de routage et des échecs d’acheminement. Il est également important de comprendre ce qui se passe lorsqu’un client change de PA ou lorsque les informations du référentiel ne correspondent plus aux données enregistrées dans SAP.

Ce point est directement lié à la qualité des données de base. Lorsque SAP DRC, cloud edition, est utilisé comme PA, SAP permet, par exemple, de contrôler en ligne les partenaires commerciaux : vérifier qu’ils sont correctement enregistrés et que leurs données d’adressage sont valides.

Gestion des exceptions et visibilité opérationnelle

Le traitement nominal d’une facture est généralement le cas le plus simple. La véritable difficulté apparaît lorsque le processus s’écarte du scénario prévu.

Une PA doit permettre de savoir clairement :

• où apparaissent les factures rejetées, bloquées ou en échec ;
• si les équipes Finance peuvent consulter les statuts utiles sans dépendre systématiquement de l’IT ;
• comment les erreurs métier sont distinguées des incidents techniques ;
• qui peut corriger et relancer une transaction ;
• si une nouvelle soumission entraîne des traitements manuels inutiles ou la création de doublons ;
• quelles informations restent disponibles à des fins de contrôle, d’audit et de support ?

Ces fonctionnalités ont un impact direct sur la charge d’exploitation après la mise en production. Une interface techniquement fonctionnelle peut malgré tout générer des coûts élevés si chaque exception nécessite une analyse manuelle entre SAP, le middleware et le portail de la PA.

Sécurité, gouvernance des données et continuité de service

Les factures électroniques contiennent des informations commerciales et financières sensibles, et la PA devient un composant externe d’un processus critique pour l’entreprise. L’évaluation de la sécurité ne doit donc pas se limiter à vérifier la présence d’une certification ou d’un label.

Les entreprises doivent examiner les contrôles d’accès, les mécanismes de chiffrement et de protection des données, les lieux d’hébergement et de traitement, le recours à des sous-traitants, les procédures de gestion des incidents, les engagements de disponibilité, les dispositifs de continuité d’activité et les capacités de reprise après incident. La répartition des responsabilités doit également être clairement définie lorsqu’un incident concerne à la fois SAP, une couche d’intégration et la PA.

La question essentielle n’est donc pas de savoir si le prestataire peut afficher une certification particulière, mais si ses dispositifs de contrôle et son modèle de service répondent aux exigences de l’entreprise en matière de sécurité, de gestion des risques et de continuité d’activité.

Capacité à accompagner des besoins au-delà de la France

Pour une entreprise opérant uniquement en France, une couverture réglementaire locale peut suffire. Pour un groupe international utilisant SAP, la question se pose à plus long terme : l’architecture retenue permettra-t-elle de prendre en charge de nouvelles obligations sans devoir recréer un modèle d’intégration spécifique dans chaque pays ?

Il convient notamment d’examiner la capacité de la plateforme ou de l’architecture associée à prendre en charge :

• de nouvelles entités juridiques et instances ERP ;
• d’autres obligations nationales de facturation électronique ;
• des dispositifs de contrôle continu des transactions et de reporting réglementaire ;
• différents réseaux et modèles d’échange de factures ;
• l’intégration de sociétés acquises ou de nouveaux pays dans le paysage SAP.

Cela ne signifie pas qu’un même prestataire doive nécessairement être retenu partout. L’objectif est plutôt d’éviter les doublons inutiles lorsque le groupe dispose déjà d’une architecture de conformité plus globale.

SAP DRC illustre cette logique : SAP propose des processus de conformité par pays ou par région et positionne la solution comme un moyen d’harmoniser la gestion des documents électroniques et du reporting réglementaire tout en répondant aux exigences locales. La couverture doit néanmoins être vérifiée pour chaque pays et chaque scénario, et ne doit pas être présumée de manière globale.

Coût total de possession (TCO)

Le tarif de la PA doit être évalué en tenant compte de l’architecture nécessaire à son utilisation. Les frais d’abonnement ou de transaction ne représentent souvent qu’une partie du coût total.

Une analyse réaliste du TCO doit intégrer l’intégration avec SAP, les middleware, les développements spécifiques, la remise en qualité des données, les tests, la migration, la supervision, le support, la gestion des exceptions, les montées de version et les futurs déploiements. Lorsque plusieurs solutions de conformité coexistent, il faut également prendre en compte le coût lié à la maintenance d’interfaces redondantes, de dispositifs de supervision distincts et de responsabilités de support dispersées.

Une plateforme moins chère à l’achat peut donc revenir plus cher si elle nécessite de nombreux développements spécifiques ou génère une charge manuelle importante. À l’inverse, une intégration plus standardisée peut justifier un modèle tarifaire différent si elle réduit l’effort de mise en œuvre et les coûts d’exploitation.

Ces critères permettent ensuite d’aborder la décision d’architecture : utiliser SAP DRC comme PA, connecter SAP à une plateforme agréée externe ou mettre en place un modèle multi-plateforme maîtrisé.

Choisir son architecture de plateforme agréée : SAP DRC, PA externe ou modèle multi-plateforme

Une fois les besoins définis, l’enjeu devient architectural : quelle place la plateforme agréée doit-elle occuper dans le dispositif de conformité SAP de l’entreprise ? Selon le paysage applicatif, l’organisation peut utiliser SAP Document and Reporting Compliance comme PA, connecter SAP à une plateforme agréée externe ou mettre en place un modèle multi-plateforme maîtrisé selon les entités, les systèmes ou les pays concernés.

Ce choix doit intervenir avant la comparaison détaillée des prestataires. Dans le cas contraire, l’entreprise risque d’évaluer les plateformes à partir de critères qui ne correspondent pas à l’architecture qu’elle prévoit réellement d’exploiter.

Utiliser SAP DRC comme plateforme agréée

SAP Document and Reporting Compliance, cloud edition, peut lui-même assurer le rôle de plateforme agréée en France. SAP a finalisé les validations d’interopérabilité requises et a été officiellement reconnu comme PA en février 2026. Pour les processus français pris en charge, l’édition cloud assure les échanges avec le Portail public de facturation (PPF) et avec les plateformes agréées utilisées par les partenaires commerciaux.

Dans un paysage principalement centré sur SAP, ce modèle peut être pertinent car il permet de rapprocher le traitement des obligations réglementaires des processus financiers déjà gérés dans SAP. Parmi les points à examiner :

• l’utilisation de processus de conformité et d’intégration pris en charge par SAP ;
• la réduction du nombre de couches distinctes de transformation ou de connectivité ;
• la centralisation des flux de facturation et de reporting ;
• la cohérence avec une stratégie SAP DRC déjà en place pour d’autres obligations réglementaires ;
• la possibilité d’éviter une intégration PA distincte, spécifiquement dédiée à la France.

Ces avantages ne doivent toutefois pas être considérés comme acquis. Leur portée dépend des systèmes qui émettent et reçoivent les factures, de l’architecture de conformité existante et de la part des flux effectivement gérée dans SAP.

Une analyse plus large est particulièrement importante lorsque l’entreprise dispose de volumes significatifs de facturation hors SAP, de plusieurs ERP, d’un prestataire international de facturation électronique déjà en place ou de standards définis au niveau du groupe pour les échanges réglementaires.

Connecter SAP à une autre plateforme agréée

Le recours à une autre PA est tout aussi possible. Le dispositif français n’impose pas aux entreprises d’utiliser la plateforme proposée par leur éditeur ERP ; elles peuvent choisir une ou plusieurs plateformes agréées parmi celles immatriculées par l’administration fiscale.

Une PA externe peut être adaptée lorsque l’entreprise travaille déjà avec un prestataire international de facturation électronique, utilise un paysage applicatif mêlant SAP et des systèmes non-SAP, s’appuie sur une couche d’intégration centralisée pour plusieurs ERP ou dispose déjà d’une architecture de facturation électronique déployée à l’échelle du groupe, à laquelle la France doit venir s’intégrer.

SAP n’a d’ailleurs pas nécessairement besoin d’être connecté directement à la PA. Une solution compatible existante, un hub EDI ou une couche d’intégration peuvent continuer à s’intercaler entre l’ERP et la plateforme agréée, à condition que la PA conserve bien les fonctions réglementaires qui lui sont réservées dans le dispositif français.

Dans cette configuration, il faut définir précisément comment circulent les données de facturation, les statuts, les accusés de réception, les erreurs et les documents entrants entre SAP, l’éventuelle couche d’intégration intermédiaire et la PA, ainsi que le rôle de chaque composant dans le traitement.

Dans quels cas un modèle multi-plateforme peut-il être pertinent ?

Une troisième option consiste à utiliser plusieurs PA. La réglementation française permet aux entreprises de recourir à une ou plusieurs plateformes agréées ; la plateforme utilisée pour la facturation électronique n’a donc pas nécessairement à prendre en charge l’ensemble des flux ou obligations de reporting.

Cette configuration peut se rencontrer dans les groupes où plusieurs entités juridiques disposent de paysages ERP différents, où des sociétés récemment acquises conservent leurs prestataires historiques ou encore lorsque des architectures locales coexistent avec un modèle global de facturation électronique. Elle peut également apparaître dans le cadre d’une transformation progressive, lorsque SAP ECC, SAP S/4HANA et les systèmes non-SAP sont migrés à des rythmes différents.

Un modèle multi-plateforme n’est donc pas intrinsèquement préférable à une architecture reposant sur une seule PA, ni moins adapté. Son intérêt dépend de sa capacité à répondre à un besoin réel du paysage applicatif sans ajouter de complexité inutile.

Comparaison des principaux modèles d’architecture

L’objectif n’est pas d’identifier une architecture qui serait préférable dans tous les cas, mais de retenir celle qui définit le plus clairement les relations entre les processus SAP, les obligations réglementaires, les responsabilités de chaque plateforme et la stratégie globale de facturation électronique de l’entreprise.

Les erreurs les plus fréquentes lors du choix d’une plateforme agréée

Les difficultés apparaissent souvent après le choix de la plateforme, lorsque l’intégration, l’exploitation ou le support se révèlent plus complexes que prévu. Dans de nombreux cas, elles trouvent leur origine dans une évaluation initiale trop étroite.

Choisir principalement en fonction du prix par transaction

Un tarif attractif peut donner une vision incomplète si le modèle retenu génère des coûts importants d’intégration, de support ou d’exploitation. Le prix de la PA doit donc être évalué dans le cadre du coût total de possession, et non de manière isolée.

Tester uniquement l’émission des factures

La réussite d’un test d’émission ne suffit pas à démontrer que le modèle fonctionnera correctement en production. Les tests réalisés pendant la sélection doivent également couvrir l’ensemble du cycle de vie, notamment les scénarios de rejet, de correction ou d’échec identifiés lors de l’analyse des besoins, ainsi que la gestion des statuts associés.

Considérer la mention « compatible SAP » comme une garantie d’intégration simple

Une solution présentée comme « compatible SAP » ne permet pas d’évaluer l’effort d’intégration réellement nécessaire. Il faut examiner le modèle d’intégration prévu, la charge de mise en œuvre, les besoins de maintenance et l’impact des montées de version, plutôt que de déduire ces éléments de la seule compatibilité annoncée.

Reléguer la qualité des données de base au second plan

Même une intégration techniquement robuste peut échouer si les données métiers sont incomplètes ou incohérentes. Les identifiants clients et fournisseurs, les données de TVA, les entités juridiques, les adresses de facturation et les informations nécessaires à l’acheminement conditionnent à la fois la bonne réception des factures et la production des données de reporting requises.

La qualité et la complétude des données de base doivent donc être évaluées avant la mise en production, et non au fil des erreurs rencontrées sur les factures.

Traiter le choix de la PA comme un sujet exclusivement IT

Le choix d’une PA concerne plusieurs fonctions de l’entreprise. Les équipes IT prennent en charge l’intégration, tandis que les équipes Finance et Fiscalité définissent une partie des exigences de reporting. Les équipes de comptabilité fournisseurs et de comptabilité clients gèrent les exceptions opérationnelles. Les équipes Sécurité évaluent les risques liés à la plateforme et les responsables de l’architecture d’entreprise s’assurent de la cohérence de la solution avec le système d’information global.

Si ces fonctions ne sont associées qu’une fois la conception technique achevée, l’entreprise risque de disposer d’une intégration qui fonctionne sur le plan technique, mais qui ne correspond pas à son modèle opérationnel.

Concevoir une architecture uniquement pour la France

Une solution conçue exclusivement pour répondre au dispositif français peut satisfaire l’obligation immédiate tout en créant une nouvelle couche de conformité isolée au sein d’un groupe international.

Avant d’introduire une nouvelle plateforme ou un nouveau schéma d’intégration, les équipes SAP d’un groupe multinational doivent vérifier comment l’architecture envisagée pourra coexister avec les prestataires de facturation électronique déjà en place, les déploiements de SAP DRC, les obligations applicables dans d’autres pays et les futurs projets de consolidation ERP. L’objectif n’est pas d’imposer un modèle unique à toutes les juridictions, mais d’éviter les doublons inutiles.

Sous-estimer les besoins après la mise en production

La phase de mise en œuvre concentre l’essentiel de l’attention, mais l’exploitation de la PA se poursuit bien au-delà du démarrage. Les responsabilités doivent être clairement définies pour le traitement des factures rejetées, les incidents de plateforme, les écarts de rapprochement, l’intégration de nouvelles entités, les évolutions réglementaires et les escalades auprès du prestataire.

Sans ce cadre opérationnel, des exceptions relativement simples peuvent entraîner des délais entre les équipes Finance, IT, le fournisseur de la PA et les autres partenaires d’intégration. Le modèle de support doit donc être défini dès la sélection de la plateforme, et non après sa mise en production.

Une méthode pratique pour sélectionner une plateforme agréée dans un environnement SAP

Une démarche structurée permet de transformer les exigences réglementaires, architecturales et opérationnelles en critères de sélection concrets, puis en un plan de mise en œuvre maîtrisé.

Étape 1. Définir le périmètre réglementaire et organisationnel

Commencez par préciser ce que l’architecture mise en place pour la France doit réellement couvrir. Identifiez les entités juridiques concernées, leur catégorie d’entreprise, les types de transactions traités ainsi que les obligations de facturation électronique et d’e-reporting qui leur sont applicables.

Étape 2. Cartographier les sources de facturation et les systèmes SAP

À partir de l’analyse du paysage applicatif, établissez une cartographie de bout en bout des flux de facturation. Elle doit permettre d’identifier l’origine des documents et des données de reporting, leur destination, les intégrations qui relient les différents systèmes ainsi que les équipes responsables des données utilisées.

L’objectif est de passer d’un simple inventaire des systèmes à une vision par processus, suffisamment précise pour évaluer les modalités d’intégration de la PA et répartir les responsabilités opérationnelles.

Étape 3. Définir l’architecture cible de conformité

Avant de consulter les prestataires de PA, déterminez le rôle que la plateforme devra jouer dans l’environnement SAP global.

L’architecture cible peut notamment reposer sur :

• SAP Document and Reporting Compliance utilisé comme PA ;
• une PA externe connectée à SAP ;
• une plateforme de facturation électronique commune aux systèmes SAP et non-SAP de l’entreprise ;
• un modèle multi-plateforme maîtrisé selon les entités ou les paysages applicatifs.

Définir cette architecture en amont permet d’éviter que la liste des prestataires disponibles ne finisse, par défaut, par dicter les choix de conception.

Étape 4. Établir une liste restreinte de PA

La liste des plateformes ayant obtenu leur immatriculation définitive auprès de la DGFiP constitue le point de départ réglementaire. Cette immatriculation définitive n’est accordée qu’après la réussite des tests d’interopérabilité requis. La DGFiP distingue par ailleurs les opérateurs encore en attente d’une immatriculation définitive : leur présence sur une page générale de la DGFiP ne suffit donc pas à confirmer leur statut.

La liste peut ensuite être resserrée en fonction des critères déjà définis : couverture des systèmes SAP, modèle d’intégration, périmètre transactionnel, architecture à l’échelle internationale, exigences de sécurité, dispositif de support et volumétrie attendue.

Étape 5. Tester des scénarios métiers représentatifs

Les tests doivent couvrir aussi bien les scénarios nominaux que les cas d’exception identifiés lors de l’analyse des besoins. L’objectif est de vérifier que l’architecture envisagée fonctionne sur l’ensemble du cycle de vie de la facture, et pas uniquement pour les flux standards d’émission.

Étape 6. Comparer le modèle opérationnel et le TCO

Appliquez aux différentes options présélectionnées le modèle de coût total de possession défini précédemment, puis comparez l’effort nécessaire pour mettre en œuvre, exploiter, maintenir et faire évoluer chaque architecture.

À ce stade, l’enjeu est surtout d’identifier les écarts entre les options, sans reconstruire entièrement le modèle de coûts.

Étape 7. Préparer la mise en œuvre et le passage en production

L’architecture retenue doit ensuite être traduite en un plan de mise en œuvre structuré. Les principaux chantiers peuvent notamment inclure :

• la configuration de SAP et de la PA ;
• le développement ou l’activation des interfaces ;
• la remise en qualité des données de base ;
• la préparation de l’acheminement et des données de l’annuaire ;
• les tests d’intégration et d’interopérabilité ;
• les tests de recette utilisateur ;
• la définition des procédures opérationnelles et des circuits d’escalade ;
• la préparation du dispositif de support ;
• un déploiement progressif lorsque plusieurs entités ou systèmes sont concernés.

L’objectif final ne se limite pas à établir une connexion technique fonctionnelle. Au moment du passage en production, l’entreprise doit savoir comment les factures seront suivies, comment les exceptions seront traitées et comment les responsabilités seront réparties lorsqu’une transaction passe par SAP, la PA et d’autres systèmes externes.

Comment LeverX accompagne les entreprises dans le choix et la mise en œuvre d’une plateforme agréée

Le choix d’une plateforme agréée ne constitue qu’un volet du programme de facturation électronique. L’enjeu principal consiste à s’assurer que la solution retenue s’intègre correctement au paysage SAP de l’entreprise, à son périmètre réglementaire, à son modèle d’intégration et aux processus financiers utilisés au quotidien. LeverX peut accompagner cette démarche depuis l’analyse initiale jusqu’à la mise en œuvre, puis dans l’évolution de l’architecture de conformité.

Analyse du paysage SAP et du dispositif de conformité

La démarche commence par une compréhension précise de la manière dont les données de facturation et de reporting circulent aujourd’hui dans l’entreprise. LeverX peut analyser les environnements SAP S/4HANA, les applications connectées, les interfaces et middleware existants, les sources de facturation, les entités juridiques françaises, les flux de facturation électronique et d’e-reporting ainsi que les solutions de conformité déjà en place.

Cette analyse permet d’établir une base claire pour l’architecture cible et d’identifier les contraintes d’intégration avant même le choix de la PA.

Architecture cible et choix de la PA

À partir de cette analyse, LeverX peut aider à définir la place de la PA dans l’environnement SAP global. Cela peut notamment consister à comparer un modèle reposant sur SAP DRC avec une plateforme agréée externe, à clarifier la répartition des responsabilités entre les systèmes et à définir les principes d’intégration, puis à traduire les besoins métiers et réglementaires en exigences techniques et en scénarios d’évaluation des prestataires.

L’objectif est de faire découler le choix de la plateforme de l’architecture cible, et non de laisser la liste des prestataires disponibles orienter la conception du dispositif.

Intégration et mise en œuvre

Une fois le modèle cible défini, LeverX peut accompagner l’intégration de SAP avec la PA retenue. Selon l’architecture choisie, cela peut impliquer SAP DRC, SAP S/4HANA, SAP Business Technology Platform (SAP BTP), des API ou des connexions avec une plateforme agréée externe.

La mise en œuvre peut couvrir les flux de factures entrantes et sortantes, l’e-reporting, la gestion des statuts ainsi que les tests de bout en bout entre les différents systèmes concernés.

Faire évoluer l’architecture de conformité dans la durée

L’architecture peut être amenée à évoluer à mesure que l’entreprise intègre de nouvelles entités juridiques, modernise ses systèmes SAP ou s’adapte à des évolutions réglementaires. LeverX peut accompagner ces changements tout en contribuant à préserver la cohérence des principes d’intégration, de supervision et de support à l’échelle du dispositif de conformité.

Conclusion

Le choix d’une plateforme agréée en France doit partir du paysage SAP de l’entreprise, de ses flux transactionnels et de son modèle opérationnel, plutôt que d’une simple comparaison des fonctionnalités proposées par les prestataires. L’architecture à retenir dépend de la manière dont les données de facturation sont produites, échangées, supervisées et prises en charge dans SAP et les systèmes qui lui sont connectés.

L’enjeu ne consiste pas uniquement à répondre aux exigences actuelles de la facturation électronique en France. Il s’agit aussi de mettre en place une architecture de conformité capable de prendre en charge durablement la facturation électronique, l’e-reporting, la gestion des exceptions et les évolutions réglementaires, sans introduire de complexité inutile. LeverX peut accompagner les entreprises dans l’analyse de leur environnement SAP existant, la définition de l’architecture cible ainsi que le choix et la mise en œuvre de la plateforme agréée.

Foire aux questions