Auteur : Satish Bhattrai, Consultant SAP Senior (B2G)
La facturation électronique dépend de bien plus que de la technologie utilisée pour transmettre une facture. Les numéros de TVA, les adresses, les identifiants de participant, les données fiscales et d’autres informations doivent être fiables avant d’atteindre le processus de conformité.
Lorsqu’une facture devient un document électronique structuré, les informations qui la sous-tendent doivent être suffisamment précises pour qu’un autre système, réseau commercial ou autorité fiscale puisse les traiter.
Un numéro de TVA manquant, une adresse client obsolète, un champ fiscal incorrect ou des fiches partenaires incohérentes ne sont pas seulement un problème de qualité de données interne. Cela peut affecter le document électronique généré à partir de ces informations et, selon le scénario de conformité, contribuer à des erreurs de validation, des rejets, des corrections ou un travail manuel supplémentaire.
C’est pourquoi la qualité des données doit être traitée comme faisant partie intégrante d’un programme de facturation électronique SAP, et non comme un exercice de nettoyage interne distinct.
SAP Document and Reporting Compliance prend en charge la création, le traitement et le suivi des documents électroniques et des rapports légaux. SAP les décrit comme des capacités de base de Document and Reporting Compliance, tandis que SAP Document and Reporting Compliance, cloud edition prend en charge l’échange de documents électroniques avec des parties de communication externes et la soumission de rapports dans les scénarios applicables.
Les deux dépendent toujours de la qualité des informations alimentant le processus de conformité.
Pourquoi la facturation électronique rend la qualité des données plus importante
La facturation traditionnelle laisse souvent place à l’interprétation humaine.
Une personne recevant une facture peut reconnaître un nom de client légèrement incohérent, comprendre une adresse abrégée ou résoudre manuellement une référence qui ne correspond pas parfaitement à un autre système.
La facturation électronique structurée est moins indulgente.
Les informations sont échangées via des champs et des formats prédéfinis. Selon la juridiction et le scénario, ces champs peuvent contenir des identifiants fiscaux, des détails de partenaire commercial, des adresses, des références de facture, des informations fiscales, des dates de document et d’autres informations requises pour traiter la facture.
La documentation SAP pour la facturation électronique montre comment une facture source peut être utilisée pour générer un document électronique à soumettre via le processus eDocument.
La conversion d’informations en un format électronique techniquement valide ne rend pas automatiquement les informations commerciales sous-jacentes correctes.
TJC Group a souligné le même problème dans ses directives sur l’intégration de SAP DRC. Les factures électroniques et les rapports légaux dépendent des données transactionnelles et des données de base dans l’ensemble du paysage commercial, faisant de la qualité et de la gouvernance des données une partie importante de la préparation à SAP DRC.
D’où proviennent les données de facturation électronique SAP ?
Une facture électronique ne commence pas lorsque le document est transmis à une plateforme externe. Elle commence bien plus tôt dans le processus commercial.
Dans de nombreux scénarios SAP DRC, les informations client, les données d’entreprise, les informations fiscales, les données de vente et d’achat, les adresses, les détails de facture et d’autres champs pertinents existent déjà dans SAP avant la création du document électronique.
Les processus pris en charge peuvent également impliquer des documents électroniques originaires d’applications non-SAP, de sorte que le paysage source exact dépend de l’organisation et du scénario. La documentation SAP Document and Reporting Compliance couvre explicitement les documents électroniques créés à partir de documents sources dans d’autres applications.
Pour la facturation sortante, les données de base client et entreprise sont particulièrement importantes. Les informations fournisseur deviennent plus directement pertinentes dans les scénarios de facturation fournisseur entrante et d’autofacturation, que SAP documente séparément.
Les informations impliquées peuvent être globalement regroupées en plusieurs domaines :
| Domaine de données | Exemples |
|---|---|
| Entreprise et entité juridique | Numéro de TVA de l’entreprise, identifiants légaux, détails d’enregistrement |
| Partenaire commercial | Identifiants client ou fournisseur, enregistrements fiscaux, adresses |
| Transaction | Numéro de facture, dates, montants, postes, références de document |
| Données fiscales et entrées de détermination | Codes fiscaux, catégories, taux, informations d’exonération |
| Échange électronique | Identifiants de participant Peppol ou autres identifiants électroniques requis |
Ces catégories sont importantes car la correction doit avoir lieu là où le problème prend réellement naissance. Une fiche partenaire incorrecte est différente d’une valeur de transaction erronée, et les deux sont différentes d’un mappage ou d’une configuration système incorrecte.
SAP DRC peut ensuite utiliser les informations de la transaction commerciale sous-jacente dans le cadre du processus de document électronique.
Les données de base sont tout aussi importantes. SAP documente, par exemple, que les clients identifiés sur le réseau Peppol par un GLN nécessitent que cette information soit maintenue dans les données de base client.
Au moment où un document atteint la surveillance SAP DRC, le problème sous-jacent peut donc avoir pris naissance bien plus tôt, lors de la création d’un partenaire commercial, de la saisie d’un numéro fiscal, de la modification d’une adresse ou de l’enregistrement d’une facture.
Problèmes courants de qualité des données pouvant affecter la facturation électronique SAP
Tous les pays n’exigent pas exactement les mêmes données, et l’effet d’un champ incorrect varie selon le mandat et le scénario SAP.
Il existe cependant plusieurs domaines récurrents auxquels les organisations devraient accorder une attention particulière. Voyons-les un par un.
Numéros de TVA et fiscaux incorrects ou obsolètes
Les identifiants fiscaux sont parmi les exemples les plus évidents. Un client ou un fournisseur peut avoir un numéro de TVA incorrect, un identifiant peut avoir changé sans que l’enregistrement principal pertinent ne soit mis à jour, ou différents systèmes peuvent contenir différentes versions des mêmes informations fiscales.
Cela devient important lorsque l’identifiant est requis dans le cadre d’une facture électronique ou est utilisé pour identifier un partenaire commercial dans le processus d’échange.
La documentation SAP fournit un exemple concret de cette dépendance. L’identification Peppol peut reposer sur des identifiants maintenus pour le client ou l’organisation concernée, selon le pays et le schéma d’identification.
La correction d’un document électronique individuel peut donc ne pas résoudre le problème sous-jacent.
Si l’enregistrement source reste incorrect, le même problème peut réapparaître dans les transactions futures.
Fiches client ou fournisseur incomplètes
Un enregistrement n’a pas besoin d’être complètement erroné pour causer des problèmes. Il peut simplement être incomplet. Les fiches client et fournisseur peuvent accumuler des lacunes au fil du temps, en particulier lorsque les organisations exploitent plusieurs systèmes SAP, ont connu des acquisitions, utilisent des processus locaux ou ont géré les partenaires commerciaux différemment selon les pays.
Une fiche client peut contenir le nom correct mais manquer d’un identifiant requis pour un échange électronique particulier. Une autre peut contenir des informations fiscales mais une adresse incomplète.
La documentation SAP concernant Peppol contient des exigences spécifiques aux pays en matière de données de base et d’identifiants de participant, illustrant pourquoi les informations requises peuvent différer entre les scénarios.
Les organisations doivent donc évaluer si leurs données de base existantes contiennent les informations requises par les scénarios de facturation électronique qu’elles ont l’intention de prendre en charge.
Identifiants électroniques manquants ou incorrects
Dans les scénarios de facturation électronique basés sur un réseau, le système doit également identifier électroniquement les parties émettrices et réceptrices correctes.
Peppol en est un bon exemple.
Selon le schéma et le pays applicables, l’identification du participant peut utiliser des identifiants tels que les numéros de TVA, les GLN, les Leitweg-ID ou d’autres schémas pris en charge. La documentation de SAP répertorie différents types d’identifiants par pays et fournit des mécanismes pour maintenir des identifiants de participant Peppol génériques si nécessaire.
Si l’identifiant requis est manquant, obsolète ou associé à la mauvaise entité, cela peut affecter la manière dont le participant est identifié dans le processus d’échange électronique.
Ces identifiants doivent donc être traités comme faisant partie de la préparation des données de facturation électronique plutôt que comme un détail d’intégration purement technique.
L’identifiant exact et l’endroit où il doit être maintenu dépendent du scénario, de sorte que les organisations doivent valider les exigences SAP et réglementaires actuelles pour chaque juridiction.
Champs fiscaux manquants ou incohérents
La facturation électronique dépend de plus que des informations client. La transaction sous-jacente contient également des informations fiscales qui peuvent influencer le document électronique résultant. Si les informations fiscales pertinentes sont manquantes, maintenues de manière incohérente ou incorrectement attribuées, le problème peut suivre la transaction dans le processus de conformité.
Cela devient particulièrement difficile lorsque la même organisation a des processus fiscaux différents selon les unités commerciales ou les pays. Il est également important de distinguer les données fiscales de la configuration fiscale. Une valeur ou une catégorie fiscale incorrecte dans une transaction n’est pas le même problème qu’un mappage ou une règle de détermination incorrecte dans la configuration SAP. Le document électronique résultant peut révéler l’un ou l’autre type de problème, mais l’action corrective sera différente.
Selon le mandat, les informations de poste telles que les descriptions de matériel ou de service peuvent également devoir satisfaire à des exigences documentaires particulières. Des informations transactionnelles incomplètes ou incohérentes peuvent donc créer un travail de révision ou de correction en aval.
La solution ne consiste pas simplement à introduire davantage de champs obligatoires.
Les organisations doivent d’abord comprendre quelles informations chaque scénario de conformité requiert, d’où proviennent ces informations, qui en est propriétaire et comment leur exactitude sera maintenue.
Adresses incorrectes ou incohérentes
Les adresses peuvent sembler être un champ de données de base simple, mais elles peuvent être importantes pour le traitement des documents électroniques.
Le problème ne se limite pas à un nom de rue manquant.
Une entreprise peut avoir des fiches client dupliquées contenant des adresses différentes, une adresse enregistrée obsolète, des informations de pays incohérentes ou un formatage local qui ne correspond pas aux informations attendues dans le processus pertinent.
Les exigences varient selon le scénario.
Pour les organisations multinationales, la qualité des adresses doit donc être prise en compte parallèlement aux identifiants fiscaux et autres informations de partenaire commercial lors de la préparation à la facturation électronique.
Références de facture et relations documentaires incohérentes
Une facture n’existe pas toujours de manière isolée.
Selon le mandat, le type de document et le processus commercial, elle peut devoir être associée à une commande d’achat, une facture précédente, une note de crédit, une correction, un contrat ou une autre référence transactionnelle.
Des problèmes surviennent lorsque ces relations sont maintenues de manière incohérente.
Une unité commerciale peut utiliser un champ de référence particulier de manière cohérente tandis qu’une autre saisit des informations similaires sous forme de texte libre. Les entreprises acquises peuvent utiliser des conventions différentes. Les intégrations plus anciennes peuvent renseigner les références différemment des systèmes plus récents.
Même lorsqu’une référence ne provoque pas un rejet technique immédiat, une faible cohérence peut rendre la réconciliation, la gestion des exceptions et les investigations ultérieures plus difficiles.
La qualité des données doit donc inclure le contexte et les relations, et pas seulement si les champs individuels ont été renseignés.
Toutes les factures électroniques échouées ne sont pas un problème de qualité des données
La qualité des données est importante, mais elle ne doit pas devenir l’explication par défaut de chaque document échoué.
Une facture électronique peut également échouer en raison de la configuration, du mappage, de la connectivité, de la communication avec une plateforme externe, de modifications d’un schéma requis ou d’une règle de traitement spécifique à un pays.
Le défi pratique consiste à déterminer l’origine du problème.
Un identifiant client manquant peut nécessiter une correction des données de base. Un problème de mappage peut nécessiter une investigation technique. Un échec de communication peut n’avoir rien à voir avec les données de la facture elles-mêmes.
Cette distinction est importante lorsque les équipes analysent les erreurs récurrentes.
Traiter chaque échec comme un problème DRC peut masquer des faiblesses dans le processus source. Traiter chaque échec comme un problème de données peut être tout aussi trompeur.
L’objectif est de séparer les problèmes de données sources des problèmes de configuration, d’intégration et de traitement externe, puis d’envoyer chaque problème au bon propriétaire.
Une facture techniquement acceptée n’est pas nécessairement une facture correcte
La validation peut identifier de nombreux problèmes techniques ou basés sur des règles, mais le passage d’un contrôle de validation ne prouve pas que chaque fait commercial sous-jacent est correct.
Une facture pourrait contenir un identifiant fiscal au format correct mais appartenant à la mauvaise entité.
Une adresse pourrait satisfaire aux exigences techniques tout en étant obsolète.
Une transaction pourrait contenir un code fiscal accepté alors que la classification commerciale originale était incorrecte.
Les organisations ont donc toujours besoin de contrôles sur la manière dont les informations sources sont créées et maintenues.
La facturation électronique n’élimine pas la gouvernance des données traditionnelle. Elle rend ces contrôles plus importants à mesure que les informations commerciales transitent par des processus de conformité de plus en plus automatisés.
Pourquoi la gouvernance des données de base est importante
Les corrections individuelles peuvent résoudre des erreurs individuelles.
Elles ne résolvent pas les problèmes récurrents de qualité des données.
Si le même type de numéro de TVA incorrect, d’adresse manquante, de client dupliqué ou d’informations fiscales incomplètes continue d’apparaître, l’organisation a probablement un problème de gouvernance plutôt qu’un problème de facturation isolé.
La gouvernance des données de base établit la responsabilité de la manière dont les informations commerciales importantes sont créées, modifiées, validées et maintenues.
Pour la facturation électronique, les organisations doivent savoir qui est propriétaire des informations client, fournisseur et d’entité juridique, comment les modifications des identifiants fiscaux ou des adresses sont validées, comment les enregistrements en double sont gérés et quelles équipes sont responsables de la maintenance des informations spécifiques à chaque pays.
Il en va de même lorsque de nouvelles entités ou des entreprises acquises sont introduites dans le paysage. Des normes différentes entre les équipes ou les systèmes peuvent finalement apparaître dans le traitement des documents électroniques.
Le guide plus large de TJC Group sur la gestion des données couvre la gestion des données de base, la gouvernance des données et l’intégration des données comme faisant partie d’une stratégie de gestion des données plus vaste.
Pour la facturation électronique, la gouvernance transforme la qualité des données d’un exercice de nettoyage ponctuel en un processus opérationnel continu.
Les problèmes de qualité des données apparaissent souvent lors de l’implémentation, mais ils devraient être traités plus tôt
Une implémentation de SAP DRC peut révéler des faiblesses déjà présentes dans le paysage commercial.
Le projet de facturation électronique ne les a pas nécessairement créées.
Une fiche client peut être restée incomplète pendant des années sans causer de problème opérationnel visible. Une fois que cette information fait partie d’un document électronique structuré et est vérifiée par un autre système, réseau ou autorité, la lacune devient plus difficile à ignorer.
C’est pourquoi TJC Group recommande d’évaluer les données de base et le paysage de facturation existant dans le cadre de la préparation à SAP DRC. Son guide de facturation et de reporting électroniques examine la préparation plus large requise autour des systèmes SAP et des processus de conformité.
Identifier les lacunes importantes avant la mise en service est plus facile que de les découvrir à travers une file d’attente croissante d’exceptions après que le processus soit devenu opérationnel.
Que doivent examiner les équipes SAP avant la mise en service de la facturation électronique ?
Il n’existe pas de liste de contrôle universelle de la qualité des données, car chaque mandat a ses propres exigences.
Un examen pratique peut néanmoins être organisé autour de quelques domaines clés.
| Domaine | Ce qu’il faut examiner |
|---|---|
| Entreprise et entité juridique | Noms légaux, enregistrements TVA, identifiants d’entreprise et identifiants électroniques requis |
| Partenaires commerciaux | Fiches client et fournisseur, doublons, identifiants et propriété |
| Données fiscales | Numéros de TVA, champs fiscaux pertinents, catégories et cohérence |
| Adresses | Adresses enregistrées, informations de pays et exhaustivité |
| Transactions | Données de facture, montants, dates, informations de poste et traitement fiscal |
| Références | Commandes d’achat, corrections, notes de crédit et autres relations requises |
| Échange électronique | Identifiants de participant Peppol ou autres identifiants réseau utilisés par le scénario |
| Exigences nationales | Champs et identifiants requis par chaque processus de facturation électronique pris en charge |
| Gouvernance | Qui crée, modifie, valide et approuve les données importantes |
| Surveillance | Comment les erreurs récurrentes seront retracées jusqu’aux données, à la configuration, à l’intégration ou au traitement externe |
L’objectif n’est pas de rendre chaque champ de l’ERP parfait.
Il s’agit d’identifier les informations critiques pour le processus de conformité et d’établir une qualité et une gouvernance suffisantes autour de ces informations pour prendre en charge un traitement fiable des documents électroniques.
La qualité des données doit se poursuivre après la mise en service
Le nettoyage des données avant l’implémentation est utile, mais il ne suffit pas.
Les informations commerciales continuent de changer. De nouveaux clients et fournisseurs sont créés, les adresses changent, les enregistrements fiscaux sont mis à jour, des entreprises sont acquises et de nouvelles exigences peuvent introduire des besoins en données supplémentaires.
Les erreurs et exceptions récurrentes peuvent donc être utilisées comme retour d’information.
Si le même problème de données de base contribue de manière répétée à des documents échoués, corriger chaque facture individuelle ne résout pas la source du problème. Les équipes doivent identifier où l’information entre dans le processus et déterminer si le contrôle en amont doit être modifié.
Au fil du temps, cela peut réduire les corrections manuelles répétées et rendre le processus de facturation électronique plus stable.
Comment TJC Group soutient la préparation des données pour SAP DRC
L’implémentation de SAP DRC se situe à l’intersection de la technologie SAP, des données commerciales et des exigences réglementaires.
TJC Group est un partenaire officiel SAP DRC pour le conseil et l’implémentation, avec une longue expérience dans la gestion des données et la conformité SAP.
Ses directives d’intégration SAP DRC existantes couvrent des domaines tels que la préparation du système, la qualité des données de base, les exigences nationales, les tests et la validation.
C’est important car un projet de facturation électronique ne peut pas être traité uniquement comme une connexion entre SAP et une plateforme externe.
Les équipes doivent d’abord comprendre les transactions numérisées, identifier les informations requises pour ces scénarios, déterminer d’où proviennent ces informations et combler les lacunes importantes avant qu’elles ne deviennent des problèmes de conformité opérationnels.
Pour les organisations qui examinent le paysage de conformité plus large, l’offre mondiale de facturation et de reporting électroniques de TJC Group relie ces exigences aux systèmes SAP et aux processus commerciaux qui les prennent en charge.
L’objectif n’est pas simplement de produire un document électronique techniquement valide.
Il s’agit de construire un processus de facturation électronique soutenu par des informations commerciales fiables tout au long du traitement, de la surveillance, de la correction et du reporting.
Conclusion
La facturation électronique rend la qualité des données commerciales beaucoup plus visible.
Les informations qui restaient autrefois à l’intérieur d’un ERP ou d’un autre système source peuvent désormais circuler dans des documents structurés échangés avec les clients, les réseaux commerciaux et les autorités fiscales. Lorsque les numéros de TVA, les adresses, les informations sur l’entité juridique, les identifiants de participant, les données fiscales ou les références de facture sont erronés, ces problèmes peuvent voyager avec la transaction.
SAP DRC fournit la technologie pour gérer les processus de documents électroniques et de reporting pris en charge. Il ne peut pas rendre des informations sources inexactes fiables simplement en les convertissant en un format électronique.
Pour les organisations qui se préparent à la facturation électronique SAP, la qualité des données doit donc être abordée parallèlement à l’intégration, aux exigences réglementaires et à la conception des processus.
La base la plus solide pour la facturation électronique n’est pas simplement un système capable de transmettre des documents conformes. C’est un paysage commercial où les informations derrière ces documents sont précises, gouvernées et maintenues au fil du temps.
Sources d’information
- Aide SAP : Document and Reporting Compliance
- Aide SAP : SAP Document and Reporting Compliance, cloud edition
- Aide SAP : Types d’ID de partie pour les destinataires Peppol
- Aide SAP : Maintenance des ID de participant Peppol génériques
- Aide SAP : Traitement des documents électroniques
