Quotidien finance innovation, innovation financière journal
Financial Year with Finyear
 
 
 
 


              

Déploiement de la facture dématérialisée : l'interopérabilité n'est pas qu'une affaire de format


Eric Wanscoor, Président de Qweeby - Mohamed Aymen Ben Abdallah, Directeur des opérations de Qweeby




Déploiement de la facture dématérialisée : l'interopérabilité n'est pas qu'une affaire de format
L'émetteur d'une facture électronique doit pouvoir la transmettre à son destinataire avec la facilité d'un courrier. Or l'émetteur n'est pas le seul décideur : le destinataire a des attentes en termes de mode d'acheminement, de format des données et de modalités réglementaires applicables. Favoriser la connaissance de ces attentes simplifiera les envois et facilitera le déploiement de la dématérialisation

Nous avons montré dans une précédente tribune que l'obstacle majeur au déploiement de la facture dématérialisée réside dans la trop faible interopérabilité de routage des flux électroniques. La transmission d'une facture électronique requérant généralement une démarche projet préalable à son envoi, ce qui est en contradiction avec la simplicité de l'acte d'achat en amont de l'acte de facturation.

L'usage de la dématérialisation des factures dans le B2B est de fait limité aux flux récurrents assez importants pour justifier un projet. La facture électronique ne tient donc pas la route face à la facture papier transmise par courrier car le courrier bénéficie de l'interopérabilité native du « bloc adresse » qui est explicite et opérationnel pour tous les utilisateurs : je mets ma facture papier dans l'enveloppe et cela suffit pour qu'elle arrive et soit recevable... Il est hélas hors de question de procéder ainsi pour une facture électronique. D'une part car le format électronique n'est pas recevable par défaut (l'accord du récepteur est requis) et d'autre part car la diversité des modalités d'envoi rendent cela impossible.

Il ressort que la facture dématérialisée a besoin d'une logique d'interopérabilité (routage et format) univoque qui permette à n'importe quel fournisseur d'émettre spontanément une facture électronique pour un de ses clients sans s'interroger longuement ou engager une démarche projet. Cette Interopérabilité apporte à l'émetteur la certitude que cette facture sera reçue et acceptée par le récepteur car conforme à ses exigences de format. Bref, il faut le couple Interopérabilité de Routage et Interopérabilité de Format. Les actions louables engagées pour la définition de formats de données ou de protocoles de transmission « standards » sont un premier pas nécessaire, mais insuffisant.

L'inévitable diversité inhérente à la facture dématérialisée

Chaque partie peut décider de son approche de la facture électronique. Et c'est tant mieux.

Cela correspond à plusieurs types de décisions. En premier lieu des décisions techniques : comment sera généré le flux sortant côté émetteur, ou traité le flux entrant côté récepteur ? Directement dans les outils existants ou via l'assistance d'un outil tiers ou d'une plateforme de dématérialisation fiscale des factures, par quels protocoles, quels dispositifs techniques d'interconnexion...

Viennent ensuite les décisions sur les modalités réglementaires applicables : les factures échangées sont-elles des PDF simples (article 289-VII 1° du Code Général des Impôts), des PDF signés (art. 289- VII 2°) ou des flux EDI (art. 289-VII 3°) ? Comme ces modalités ne sont pas transitives, c'est-à-dire par exemple qu'un envoi en 289-VII 1° ne peut être reçu en 289-VII 3°, le choix de l'émetteur concerne le récepteur et réciproquement...

Interviennent enfin les formats des données. La question ne se pose pas dans le cas du simple PDF non signé, en fait peu utilisé dans le B2B où personne ne veut d'un PDF image inexploitable et contraire à l'intérêt réel de la facture électronique qui est de disposer des données pour le traitement de la facture. Par contre la question se pose dans les autres schémas usuels en B2B où la plupart des échanges de PDF signés s'accompagnent d'un flux d'intégration soit en GS1 XML soit selon un format privé propre au client ou à son prestataire. Dans le cas de l'EDI, certains formats comme l'Edifcat d96a s'imposent ; cependant régulièrement ils intègrent des spécificités propres au récepteur. Et il n'est pas rare de croiser d'autres formats tels que l'Edifact d98a ou d03a. La dimension internationale et les évolutions du sujet poussent inéluctablement à la diversité des formats.

Les informations à connaître pour émettre une facture dématérialisée dans le B2B

Chaque partie doit maîtriser ses choix. Cependant, les rapports de force propres au B2B limitent souvent la marge de manœuvre de l'émetteur. Il doit se plier aux attentes de ses clients qui lui imposent leurs préférences réglementaires, par exemple 289-VII 3° là où l'émetteur se serait contenté d'un 289-VII 1°, leurs formats de données, par exemple GS1 XML là où l'émetteur aurait envoyé un simple PDF, et les points de livraison où les flux seront transmis par un protocole donné là où l'émetteur aurait envoyé un simple e-mail. Comme un émetteur a toujours plusieurs donneurs d'ordres dans sa clientèle, avec chacun ses attentes propres, émettre des factures électroniques conformes à toutes ces attentes constitue une gageure.

On perçoit qu'il est difficile, pour ne pas dire impossible, à un émetteur dans le B2B de dématérialiser ses factures sur la seule base des données de contact de son client. Et ceci même s'il sait que son client accepte la dématérialisation. En pratique il doit disposer de trois informations en préalable à l'émission d'une facture dématérialisée : le cadre réglementaire applicable, le format des données et les modalités d'acheminement. Ces informations ne pouvant pas être inclues dans le code SIRET ou l'identifiant TVA Intra, elles doivent être gérées soit dans une base de données référentielle soit via un Relevé d'Informations de Facturation, sorte de complément au RIB, fourni par le client à son fournisseur, en même temps que les données bancaires pour le paiement, en amont de la facturation.

Ainsi, l'émetteur d'une facture ou son opérateur, pourrait facilement connaître pour chacun des clients facturés, s'il accepte la facture électronique, sous quelle(s) modalité(s) réglementaire(s), selon quel(s) format(s) et via quel(s) point(s) de livraison. Il ne resterait plus alors que la phase pratique d'envoi, facilitée par des tests préalables entre les opérateurs concernés ou, tout simplement, assurée par le savoir-faire et l'expérience des opérateurs impliqués dans le processus d'échange.

Le rêve de l'opérateur : disposer de l'information de manière dynamique

La situation idéale serait d'interroger directement la base lors de la réalisation de la facturation, par le facturier ou par son opérateur, pour décider de manière dynamique si la facture part par le courrier ou en électronique (par la voie, selon le format et en respect des modalités applicables). Cette base pourrait également contenir des informations sur les variantes dans les formats attendus par les récepteurs pour permettre directement l'émission de la facture électronique selon la bonne structure de données tenant compte des éventuelles variations du format attendues par le destinataire.

Sur un plan technique c'est simple à réaliser. Une base de données mutualisée, alimentée et actualisée par les opérateurs ou les entreprises. Cette base est interrogée en web service à chaque fois que nécessaire par un émetteur de facture qui obtient directement les données à jour pour émettre une facture électronique conforme à l'attente du destinataire qu'il connaît simplement par son identifiant TVA intra, son code SIRET ou son GLN.

Les émetteurs pourraient même charger leur portefeuille client et identifier instantanément l'ampleur du déploiement qui leur est possible. Des services complémentaires faciliteraient les choses pour la gestion des accords de manière dynamique par exemple...

Avec un tel outil mutualisé, deviendrait alors simple d'émettre des factures électroniques pour toutes les transactions. Sous réserve de disposer d'un opérateur interconnecté à cette base et capable de gérer les interopérabilités concernées (routages et formats), ou de gérer soi-même, pour les plus audacieux, les interconnexions en direct.

Ce référentiel que nous appelons de nos vœux est un bien commun à l'échelle d'un pays ou d'une zone plus importante (l'Europe). Il doit donc être initié par une instance ou une organisation indépendante des opérateurs ou des entreprises, capable de se positionner sur une échelle géographique adaptée (GS1, Odette...). Rien n'existe pour le moment à notre connaissance sur le sujet et nous sommes impatients de voir une organisation de référence se saisir de ce sujet afin de faire avancer efficacement les choses.

Pour autant, tout ne sera pas réglé d'un coup car deux questions restent ouvertes. L'une concerne le modèle économique de cette interopérabilité de routage et l'autre les interconnexions entre opérateurs afin de faire vivre l'interopérabilité de routage. Nous reviendrons sur ces points dans une prochaine tribune.

Mardi 5 Novembre 2013
Notez




Nouveau commentaire :
Twitter

Your email address will not be published. Required fields are marked *
Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *



Recevez la newsletter quotidienne


évènements


Lettres métiers


Livres Blancs




Blockchain Daily News