The Right Move

TRM dévoile le retour d’expérience de son implémentation Peppol pour PrestaShop 1.7 et 8.x. PrestaShop et Peppol haine ou amour ?

Christian Janfils

Chez TRM, nos clients e-commerçants nous ont demandé de réaliser une intégration entre PrestaShop et le réseau Peppol. Peppol signifie « Pan-European Public Procurement Online », oui Public Procurement parce qu’initialiement, Peppol a été utuilisé pour des transactions avec les autorités, parfois appelées B2G (Business to Government).

Les raisons justifiant ce besoin d’intégration sont simples. Ces clients n’ont pas encore d’intégration à un ERP compatible Peppol ou encore ces clients ont centralisé tout leur business sur PrestaShop, y compris la gestion de caisse(s) en point(s) de vente. PrestaShop est donc le cœur de leur gestion commerciale, en ligne et parfois en magasin. Il fallait donc impérativement que PrestaShop puisse envoyer les factures et notes de crédit au format Peppol, en direct sur le réseau/la plateforme Peppol.

Nous avons déployé la solution en début d’année 2026 conformément aux obligations d’application en Belgique. C’est le moment de faire un retour d’expériences sur ce déploiement. Assurément, pour nos amis français (déploiement en 2027) et néerlandais (avant 2030), ce sera intéressant de profiter de cette expérience.

Après une brève introduction sur ce qu’est Peppol, comment techniquement le réseau fonctionne et l’architecture du réseau ainsi que son standard, nous viendrons aux choses sérieuses avec le comportement de PrestaShop avec Peppol. Pour ceux qui connaissent déjà le réseau, vous pouvez ne pas consulter ces parties introductives.

Pour bien commencer : Peppol pour les nuls

  • Envoyer ses documents de facturation par voie électronique (au format Peppol) est une obligation légale qui dépend du pays de l’Union européenne et qui concerne les entreprises et associations qui sont assujetties à la TVA (dans le jargon habituel, celles qui déduisent ou récupèrent la TVA),
  • Toutes les entités juridiques assujetties doivent d’abord s’inscrire sur le réseau Peppol pour recevoir un identifiant unique (généralement basé sur leur numéro de TVA). Tout le monde peut vérifier si son client ou fournisseur est bien inscrit sur le lien suivant https://directory.peppol.eu/public
  • Dans une transaction, le vendeur B2B (= assujetti) envoie la facture à son client B2B (= assujetti) via un programme, typiquement de comptabilité ou de facturation, connecté à un réseau qui supporte Peppol. Les notes de crédit suivent le même processus que les factures,
  • Actuellement, les transactions entre B2B et B2C ne sont pas soumises aux obligations Peppol,
  • L’acheteur (client) reçoit directement dans sa comptabilité la facture au format électronique Peppol. Généralement, un fichier PDF (copie à l’identique de la facture initiale) est joint au message électronique. Les vendeurs sont autorisés à ne plus imprimer de facture ni l’envoyer par email puisque généralement les programmes de facturation/comptabilité respectifs s’échangent les données en direct. Donc, en fin de compte, c’est un vrai gain de temps pour tous.

Comment cela se passe techniquement ?

  • Peppol, c’est un réseau comparable à des systèmes de messagerie ou de réseaux téléphoniques : ils sont interconnectés et fonctionnent avec un protocole technique qui rend les différents outils compatibles,
  • Après s’être inscrits (typiquement via son comptable et son logiciel de comptabilité/facturation), l’entité juridique associée (entreprise assujettie ou association sans but lucratif assujettie) va pouvoir envoyer des factures et des notes de crédit (« documents » au format Peppol) de même qu’en recevoir
    • Il n’y a qu’un et un seul canal par entité pour recevoir les documents au format Peppol. C’est logique puisque tous les documents « entrants » sont centralisés dans une et une seule comptabilité. C’est donc logiquement le programme de comptabilité de chaque entité qui centralise l’entrée des documents. C’est par là aussi que l’entité s’est inscrite sur la plateforme et a reçu son identifiant unique Peppol,
    • Il y a autant de canaux de sortie pour émettre des factures de vente que l’entité le souhaite. Cela peut sembler étrange, mais c’est logique. Prenons typiquement le cas d’une PME qui a à la fois une gestion de points de vente via sa caisse et un e-commerce. Ces deux outils ne sont pas encore intégrés. Il est donc logique que tant la caisse que l’e-commerce puissent tous deux émettre des factures, chacun de son côté (généralement des facturiers différents, pour une numérotation séparée).
  • La clé de l’interopérabilité c’est l’usage d’un standard unique à travers tout le réseau (national et international). C’est aussi central pour le sujet de notre article : tous les usagers doivent respecter le même standard pour émettre des factures et des notes de crédit conformes, que tous puissent recevoir et intégrer automatiquement dans leurs outils comptables.

Architecture du réseau Peppol : version simplifiée

  • Au centre, on a le réseau Peppol, qui permet de véhiculer les documents (factures et notes de crédit),
  • A la périphérie du réseau, on a les « Points d’accès » (access points) dont le nombre est limité et qui sont certifiés par chacune des autorités (publiques) nationales. La certification est ouverte à tous mais elle est assez contraignante. Ainsi certains éditeurs de logiciels ERP ou comptable ont préféré se faire certifier plutôt que de passer par un Point d’accès tiers,
  • Chaque logiciel permettant d’envoyer ou de recevoir des documents Peppol doit faire appel à un Point d’accès (qu’il peut lui-même être également quand il est certifié comme tel) pour envoyer et recevoir les documents.

Donc typiquement, chez TRM quand nous envoyons une facture à un de nos clients, nous l’éditons dans notre logiciel de facturation (Falco). Falco contient lui-même un Point d’accès qui transmet alors la facture au point d’accès associé au destinataire de cette facture pour qu’il arrive ainsi dans sa comptabilité.

Des messages peuvent être envoyés en retour ; c’est paramétrable, notamment pour dire que le document est arrivé ou accepté. La facture de vente TRM est ensuite intégrée automatiquement comme un « produit » (comptes 700) à notre programme comptable « Horus » connecté à Falco (Falco et Horus sont édités par la même maison de software).

En principe, Peppol, c’est du temps réel. Donc au moment de l’émission de la facture, elle doit être envoyée sur le réseau Peppol (c’est la recommandation). Une fois la facture envoyée, elle est devenue non modifiable. Donc toute erreur doit être corrigée par l’édition d’une note de crédit partielle ou totale et, le cas échéant, le renvoi d’une nouvelle facture modifiée.

Vous l’aurez de suite compris, la mise en œuvre de Peppol dans une entreprise, modifie les procédures de gestion interne. La transition n’est pas simple. Nous avons entendu nombre de nos clients qui avaient payé deux fois une facture parce que reçue par deux canaux séparés … Il faut donc faire évoluer ses procédures pour rendre la gestion « étanche », tant en factures de ventes que pour les factures d’achats (en entrée, à recevoir).

Peppol : un standard au cœur de tout !

C’est essentiel de comprendre comment le standard Peppol a été rédigé. Donc comment une facture doit être exprimée au sens informatique du terme pour que n’importe quel destinataire puisse la recevoir et qu’elle soit intégrée immédiatement et sans encombre dans son programme de comptabilité. Ce standard c’est l’esperanto de la conception comptable d’une facture et d’une note de crédit. On parle ici d’un domaine sémantique qui définit précisément chacun des concepts présents dans une facture : émetteur, destinataire, horodatage, article(s) vendus, la TVA applicable, la ou les ligne(s) d’article(s), les éventuelles réductions, le calcul des totaux HTVA et TTC, etc.

Pour ceux qui le souhaitent, le standard est « Peppol Bis Billing 3.0 ». Il fait l’objet d’une norme européenne (EN 16931) avec un format UBL/XML pour l’échange des messages.

C’est le comptable qui a gagné dans cette affaire : les règles strictes de bonnes pratiques comptables ont été implémentées pour définir une document de vente. On ne peut donc pas faire ce que l’on veut. Et c’est logique !

Le réseau Peppol est intelligent

Si le logiciel qui génère la facture XML/UBL ne respecte pas le standard, la facture envoyée dans le réseau Peppol sera refusée et Peppol indiquera les raisons pour lesquelles elle est refusée. En d’autres termes, Peppol « comprend » grâce à une syntaxe détaillée tout ce qui lui est envoyé et recalcule les montants avant d’accepter le document. Le standard Peppol est donc garant de la conformité des documents qui lui sont envoyés !

Prenons des exemples précis et concrets d’e-commerce pour illustrer ce principe

Cas #1 Imaginons un e-commerçant qui offre un pourcentage de réduction sur le panier en fonction de la valeur totale du panier. Exemple : 10% pour un panier àpd 100€, 15% àpd de 150€, 20% àpd 200€ et 25% pour un panier àpd de 250€. En outre, les articles peuvent avoir un taux de TVA différents. La réduction calculée globalement est ce qu’on appelle une réduction de pied de facture (« allowance » dans le standard ou « ristourne » pour le comptable). Peppol n’autorise pas de réduction de pied de facture si les TVA ne sont pas ventilées correctement entre les articles avec des taux différents . Peppol exige que les, par exemple 25% pour un panier de 250€, puissent être appliqués sur chacune des lignes de la facture, selon le taux de TVA. Par ligne, il faut entendre celle d’un article spécifique, acheté une ou plusieurs fois. Il faut donc, pour générer la version XML/UBL de cette facture reventiler la réduction de 25% sur chaque ligne de la facture Peppol et ne pas simplement la déduire en bas de facture. Et pourtant vous savez que votre e-commerce a toujours fonctionné avec cette réduction de pied de facture et que vos clients sont habitués à voir le total de la réduction en bas de facture, peu importe les taux de TVA !

Comment faire alors ? Il faut réconcilier les deux mondes : la facture PDF habituelle que vous générez depuis votre e-commerce, disponible dans « Mon compte » avec la réduction de pied de facture et, ensuite, la facture au format Peppol qui va être envoyée via le réseau Peppol. Cette facture Peppol sera ainsi la facture PDF déconstruite et reconstruite informatiquement en respectant la ventilation de la réduction globale par ligne. Tous les montants seront identiques, ce qui fera que l’on parle bien de la même facture ou de la même opération comptable.

Cas #2, même chose, mais l’e-commerçant ne souhaite pas que les articles déjà en promotion entrent dans le calcul du total du panier pour savoir quel pourcentage de réduction s’applique (10%, 15%, 20% ou 25% du #1 ci-dessus). C’est donc la même chose, mais cela signifie qu’il faut cette fois ventiler la réduction de bas de facture sur certaines lignes d’articles (au prix plein) et pas sur d’autres (déjà discountés dans le prix facial) tout en tenant compte des taux de TVA spécifiques, le cas échéant.

N’est pas Peppol qui veut

Vous l’aurez vite compris, ce standard « esperanto de la facturation » implique des difficultés pour quasi tous les outils de facturation. Eh oui, il y a peu d’outils d’e-commerce ou de facturation qui utilisent nativement les mêmes bonnes pratiques comptables de calcul des factures. Nous l’avons vu ci-dessus avec les réductions de pied de facture. Ceux qui supportent, en Belgique, les transactions avec les autorités publiques (marchés publics) ont eu une longueur d’avance, puisque Peppol était déjà obligatoire avec ces pouvoirs adjudicateurs depuis plusieurs années.

Le coup de grâce : le calcul des centimes (arrondis)

Vient ensuite le toujours délicat problème des arrondis de centimes. Chaque logiciel travaille avec un certain nombre de chiffres derrière la virgule (les décimales). Souvent, il y en a six mais les logiciels n’en affichent que deux. Ils procèdent donc à des arrondis. Les logiciels peuvent parfois être paramétrés pour que la facturation procède aux arrondis par unité d’article ou par ligne d’articles (donc sur la somme des articles identiques dans la commande) ou encore au total de la facture (arrondi une seule fois pour toute la facture). Et selon le choix, tout change ! Comme Peppol travaille principalement au niveau de la ligne d’articles, c’est par défaut là qu’il faut arrondir.

En théorie cela résout tous les problèmes, sauf que dans certains cas, notamment quand une facture contient plusieurs taux de TVA, le logiciel de facturation calcule souvent la TVA sur la somme des articles soumis au même taux. Et dans ce cas, les arrondis calculés par le logiciel ne sont pas ceux que Peppol attend : il n’y a pas d’arrondi par ligne mais pour la somme des lignes des articles au même taux de TVA. « Bardaf, c’est l’embardée » et Peppol refuse la facture parce que les montants ne correspondent pas, pour un ou plusieurs centimes.

Le pire : ce sont les notes de crédit

La plupart des e-commerçants que notre agence chouchoute au quotidien ont toujours rédigé des notes de crédit qui répondaient de manière souple aux besoins et aux circonstances liées aux discussions clients de service après-vente. Ces cas ne vous seront pas inconnus :

  • Le remboursement du transport (ex. plainte sur le retard ou un colis endommagé par le transporteur),
  • Le remboursement d’un ou de plusieurs articles (ex. le client s’est trompé d’article et a demandé un échange),
  • Le retour de certains articles en vertu du droit de rétractation,
  • Le remboursement partiel d’un article (ex. article légèrement endommagé),
  • Etc

Au vu des contraintes techniques évoquées ci-dessus, établir une note de crédit conforme au standard Peppol n’est pas une sinécure. Morceaux choisis :

  • Rembourser partiellement un article va créer quasi systématiquement des erreurs d’arrondis, a fortiori si la facture contenait plusieurs taux de TVA,
  • Que fait-on quand le client qui avait bénéficié dans le cas #1 ou #2 ci-dessus de 25% de réduction (ristourne au sens comptable) pour un panier supérieur à 250€ n’entre plus dans les conditions après le remboursement d’un ou plusieurs articles ? A combien lui rembourse-t-on ses articles et comment ventiler la correction de la réduction de pied de facture sur les lignes d’articles restantes ?
  • Rembourser le transport, s’il n’est pas considéré comme un article par le logiciel e-commerce, c’est créer une réduction de pied de facture à répercuter sur toutes les lignes d’articles … quel bazar pour le client qui ne va rien y comprendre !

Autant de casse-têtes quand votre logiciel e-commerce vous a permis, auparavant, de faire quasi tout ce que vous souhaitiez, mais que désormais ces manœuvres ne sont plus conformes à Peppol.

Que faire ? Pour chacun de ces cas, à nouveau, il faut déconstruire la facture ou la note de crédit et la reconstruire conformément au standard Peppol en s’assurant que tous les montants sont conformes et, surtout, cohérents en termes d’arrondis. Généralement, il faut étendre le modèle de données de la commande et de la facture initiale et enregistrer les données manquantes en bases de données, d’autant que ces mêmes informations seront nécessaires, dans le futur, en cas de note de crédit.

On est donc sur une dualité de factures et de notes de crédit : celle qui est montrée au client dans Mon Compte et qu’il peut comprendre et celle qui est envoyée dans Peppol, toutes deux devant être cohérentes en termes de montants et d’arrondis.

Maintenant que vous avez perçu les défis du passage à Peppol, comment cela se passe-t-il avec PrestaShop ?

PrestaShop n’a pas échappé à la règle : le calcul interne de ses factures ne respecte pas certains aspects du standard Peppol, notamment, la combinaison des éléments suivants :

  • La gestion des arrondis,
  • Le calcul de la TVA sur des sommes d’articles,
  • Le calcul des notes de crédit,
  • Les réductions de pied de factures.

Chez TRM, pour que nos clients e-commerçants puissent envoyer leurs documents via Peppol, nous avons développé un module Peppol pour PrestaShop. A la fois, nous avons respecté au maximum PrestaShop et collé autant que possible aux fonctionnalités de gestion e-commerce que nos clients e-commerçants adorent chez PrestaShop. Le challenge a été de gérer l’ensemble des cas rencontrés pour que les documents Peppol reconstruits sur la base des données venant de PrestaShop respectent le format Peppol et soient cohérents (montants et arrondis) avec les documents venant de PrestaShop.

Nous n’avons pas pu faire d’omelette sans casser des œufs. Nous avons dû (i) reconstruire partiellement la fonction de facturation de PrestaShop (dans le jargon technique la surcharger) et (ii) construire une nouvelle fonction de gestion des notes de crédit (remboursements clients) qui remplace la fonction native de PrestaShop.

Tant pour les factures que les notes de crédit, PrestaShop ne gère pas correctement au sens Peppol le calcul de la TVA. Les arrondis n’étaient jamais corrects parce que la TVA est appliquée sur la somme des articles d’un même taux de TVA. Exemple ci-dessous avec une facture contenant trois articles à 21% de TVA et un à 6% :

Pour montrer que le document Peppol généré sur la base des inputs donne un montant différent de la facture native de PrestaShop, nous avons reconstruit complètement cette facture dans Excel. Il y a deux calculs, à savoir celui au format Peppol (tout par ligne d’article) et celui de PrestaShop natif. Résultat, nous avons toujours 1 centime de différence et Peppol refusait systématiquement l’envoi de cette facture sur le réseau pour cette erreur de montant total.

Avec PrestaShop (en jaune) et Peppol (en vert) :

Pour les notes de crédit PrestaShop, c’était une (petite) catastrophe dès qu’il y avait un peu de complexité dans le remboursement. Nous avons d’abord dû nous rendre compte que depuis des années, le calcul des notes de crédit est faux à deux égards :

  • le calcul des arrondis est inexact en cas de plusieurs taux de TVA. Certains de nos collègues ont même qualifié ces résultats de farfelus sur plusieurs forums. Le bug est documenté par PrestaShop sur Github.
  • Ensuite, lorsque des remises globales sont apportées à la facture initiale, la note de crédit est parfois supérieure à la valeur d’achat total de la facture initiale. Le client recevait plus en remboursement que ce qu’il avait réellement dépensé.

Ces deux problèmes sont, à ma connaissance, toujours bien présents. C’est probablement une des raisons pour lesquelles PrestaShop ne propose pas, sur sa plateforme hébergée, une solution native d’envoi de documents Peppol. C’est une plateforme tierce qui, comme chez TRM, doit adapter (déconstruire et reconstruire) les documents avant de générer la version Peppol.

L’implémentation Peppol de TRM pour PrestaShop 1.7 et 8

Notre implémentation Peppol a été fortement grevée par les bugs internes de PrestaShop évoqués préalablement (1.7 et 8, nous n’avons pas encore de Peppol sur PrestaShop 9 au moment d’écrire ce retour d’expérience). Nos développeurs ont dû réécrire une partie de la facturation mais aussi surtout les mécanismes de remboursement à la base de la génération des notes de crédit.

Un nouvel écran de remboursement partiel ou total.

  • Actuellement, le client peut rembourser un ou plusieurs articles
  • Actuellement, le client peut rembourser le transport
  • Actuellement, le client ne peut pas rembourser une partie du montant d’un article

L’e-commerçant doit, soit rembourser toute la commande, soit rembourser un ou plusieurs articles. Les montants sont recalculés pour générer la note de crédit PrestaShop et faire l’envoi de la version XML/UBL sur le réseau Peppol. Notre nouveau composant gère les réductions de pied de facture. Une nouvelle version est en cours de développement pour permettre de rembourser partiellement un article.

Exemple du nouveau composant dans l’écran de la commande client du backoffice PrestaShop :

Transparent pour l’e-commerçant

Notre module pour PrestaShop s’accroche aux endroits où la facture est générée dans PrestaShop. Il n’y a donc rien à paramétrer pour l’e-commerçant. Dès que la facture est créée par PrestaShop, la facture Peppol est générée et envoyée vers le Point d’accès que TRM a choisi comme partenaire. Même chose pour la ou les notes de crédit.

Actuellement, seuls les documents destinés à un client ayant mentionné un numéro de TVA dans ses adresses de facturation et de livraison démarrent le processus Peppol dans le module de TRM.

Le module commence par vérifier auprès du Point d’accès Peppol si l’acheteur est bien enregistré auprès de Peppol. S’il n’est pas enregistré, alors la facture Peppol n’est pas générée ni envoyée et le backoffice PrestaShop affiche une note dans la commande pour indiquer que ce client n’est pas (ou pas encore) inscrit sur la plateforme Peppol.

Ici, on distingue le cas de l’association qui a un numéro d’entreprise mais qui n’est pas assujettie à la TVA. Ce client tombe sous la mention « ne supporte pas le type de document ». le second cas concerne le client assujetti mais non encore inscrit sur la plateforme (oui, oui, dix mois après l’obligation légale en Belgique, nous en voyons encore passer chez certains de nos clients ).

Si le client de la commande est bien inscrit, la facture au format Peppol est générée et envoyée automatiquement sur la plateforme Peppol. L’envoi reçoit une date et une heure (hotodatage) et la facture XML/UBL est enregistrée dans l’écran de la commande du client.

Exemple de tableau synthétisant l’envoi de la facture Peppol dans l’écran de la commande client du backoffice PrestaShop :

Le module Peppol pour PrestaShop de TRM rend le fichier XML/UBL téléchargeable, individuellement ou en masse. Ce fichier peut servir pour la comptabilité de nos clients. Les factures de vente au format Peppol sont reconnues par les logiciels comptables et plus aucun encodage n’est nécessaire lorsque ces factures sont importées dans les comptes de Produit (classe 700). Les documents peuvent être poussés en masse ou individuellement, voire par API (Application Programming Interface ou interface qui permet à deux programmes de se parler), dans la comptabilité de l’e-commerçant. Finis les encodages des factures B2B !

Lorsqu’une facture Peppol est refusée par la Plateforme Peppol, le module TRM garde la trace de la raison (erreur technique) fournie par la Plateforme Peppol, ainsi que l’horodatage. Le module TRM-Peppol dispose également d’un panneau d’administration où il est possible de déclarer une ou plusieurs adresses email à qui ces non-conformités Peppol seront envoyées à la réception du feedback du réseau Peppol. Peppol documente les erreurs et cela permet de corriger le document de vente. Ci-dessous, un cas de modification d’une commande dans le backoffice non supportée par Peppol. Ces erreurs du client sont généralement traitées en base de données (Support TRM) et le document Peppol est ensuite regénéré dans le backoffice de la commande, puis réenvoyé (avec succès).

TRM a également ajouté une colonne à l’écran du backoffice PrestaShop listant les commandes, de manière à filtrer ces commandes en fonction du statut d’envoi du document Peppol associé :

Une facture non envoyée peut être envoyée à tout moment depuis la page de la commande dans le backoffice :

Le module supporte également l’envoi en masse de commandes qui n’auraient pas été envoyées, via la page listant toutes les commandes. Une fois les commandes filtrées et sélectionnées, c’est très simple de faire un envoi multiple :

Certains logiciels comptables en Belgique permettent un import automatique des factures de vente de l’e-commerçant via l’envoi des factures Peppol par email sur une adresse spécifique au programme comptable. Même si à l’époque des API, ceci reste un peu primitif, il n’en reste pas moins que cela fonctionne. TRM a étendu son module pour prendre en charge l’envoi d’un email avec le document XML/UBL en attaché au mail vers une adresse unique pour la comptabilité de l’e-commerçant. Voici l’écran de configuration du module TRM Peppol pour PrestaShop :

Dernières remarques : attention aux contraintes légales

Les autorités qui certifient les Points d’accès Peppol ne vérifient pas que les factures envoyées correspondent aux entités qui les émettent. C’est peut-être un point faible, mais c’est ainsi. Au moment où votre boutique e-commerce envoie une facture, elle le fait au nom de l’entité légale définie dans PrestaShop. Il y a donc un risque technique non nul de falsification de l’identité de l’émetteur ou de l’envoi de factures non désirées à certaines entités qui n’auraient pas fait d’achat sur la plateforme e-commerce.

En Belgique, les autorités n’ont pas mis de contrôle en place. Elles rendent contractuellement les Points d’accès responsables en cas d’erreur technique ou de fraude. Le Point d’accès avec lequel TRM travaille a donc reporté contractuellement sur TRM la responsabilité en cas de fraude ou d’abus. Le Point d’accès a ainsi exigé une procédure de type « Know Your Customer » (KYC), comme pour une banque, pour s’assurer que TRM n’est pas abusé par ses propres clients.

TRM a dès lors mis en place un engagement contractuel avec ses clients pour parer à toute éventualité. Il doit être signé préalablement au déploiement du module TRM-Peppol.

Comme TRM assure aussi l’accompagnement de ses clients e-commerçants dans la mise en place des solutions de paiement en ligne, c’est donc la politique de KYC de la plateforme de paiements en ligne (MultiSafepay en l’occurrence) qui est utilisée pour toutes les vérifications nécessaires. Puisque le client de TRM satisfait aux exigences (en continu) du KYC de MultiSafepay, TRM est assuré de connaitre son client. Les clauses complémentaires transfèrent alors la cascade de responsabilité vers l’e-commerçant, qui sait qu’il ne peut envoyer des factures à son concurrent ou au nom de son concurrent 😊.

Un écran d’onboarding dans le module TRM-Peppol, pour le backoffice de PrestaShop

Ainsi, dans le backoffice PrestaShop, le Module Peppol requiert une série d’informations de type KYC sur l’e-commerçant, qui servent à initier et autoriser l’envoi de factures à travers le Point d’accès :

De même, les taux de TVA utilisés sur la boutique e-commerce doivent être prédéfinis et correspondre aux taux que Peppol définit lui-même dans le standard européen. Ainsi, les taux de TVA définis dans les écrans de PestaShop doivent être associés à leur pendant Peppol.

Extrait de la configuration backoffice :

Les nouveautés dans la gestion de l’e-shop pour l’e-commerçant

L’e-commerçant doit encore plus veiller à la bonne identité de ses clients, notamment au bon encodage du numéro de TVA intracommunautaire. C’est plutôt simple dans le cas de clients B2B belges uniquement, mais cela se corse avec l’élargissement aux transactions B2B transfrontalières. C’est la raison pour laquelle la validation préalable du numéro de TVA intracom est encore plus essentielle. TRM a ainsi mis en place, au-delà de l’habituel VIES gratuit  (API de la Commission européenne) une seconde plateforme (payante cette fois) de vérification des numéros de TVA intracom, en mode de redondance pour viser 100% de disponibilité de la vérification en temps réel à chaque nouvelle transaction.

L’e-commerçant doit être vigilant aux résultats des envois Peppol et mettre en place périodiquement (une fois par mois à minima) une procédure pour vérifier :

  • Ses clients B2B non-inscrits alors qu’ils le devraient : leur rappeler les obligations légales,
  • Les documents Peppol non envoyés et les réenvoyer (parfois, en raison d’un Point d’accès indisponible ou d’une erreur technique quelconque),
  • Les documents Peppol qui ont été refusés, pour vérifier, avec son agence technique, la raison de l’erreur, pour ensuite la corriger,
  • Les exports automatiques des factures de vente pour les intégrer à sa compatibilité,
  • Etc