La facture PDF que votre boutique envoie après chaque commande validée n’est plus un document recevable entre professionnels. Depuis le 1er septembre 2026, toute entreprise assujettie à la TVA en France doit être en mesure de recevoir ses factures au format électronique structuré. PrestaShop, lui, n’a pas bougé : son moteur de factures produit toujours un PDF plat, sans donnée structurée ni canal de transmission.
Un marchand PrestaShop se retrouve donc avec une brique manquante entre son back-office et l’administration fiscale. Le sujet dépasse d’ailleurs le catalogue produits, puisque connecter sa boutique, sa banque et son encaissement forme un seul et même chantier. Trois flux, trois obligations distinctes, un seul point d’arrivée réglementaire.
Concrètement, une boutique qui vend à la fois à des particuliers et à des professionnels porte deux régimes à la fois. Les commandes B2C basculent en e-reporting, les commandes B2B en e-invoicing. Aucun module de mise en page ne règle cette bascule tout seul, et l’écart se paie en amendes forfaitaires par facture.
Depuis le 1er septembre 2026, la réception de factures électroniques s’impose à toutes les entreprises assujetties à la TVA. L’émission suit au 1er septembre 2027 pour les PME, les TPE et les micro-entreprises. PrestaShop ne couvre nativement ni le format structuré, ni le raccordement à une plateforme agréée.
Le diagnostic vous sort trois plateformes classées selon votre volume de commandes.
Ce que PrestaShop fait nativement, et ce qui manque
PrestaShop génère une facture dès qu’une commande passe dans un statut payé. Le document sort en PDF, s’archive dans le back-office et part par e-mail au client. Ce comportement satisfait le Code de commerce depuis toujours. La réforme, elle, réclame deux briques absentes du cœur : la donnée structurée et le tuyau de transmission.
Le PDF du moteur de factures n’est pas une facture électronique
Au sens fiscal, une facture électronique porte ses données dans un fichier lisible par une machine. Trois formats socle sont admis : le Factur-X, qui embarque un XML dans un PDF/A-3, l’UBL et le CII, tous deux en XML pur. Le générateur de PrestaShop ne produit aucun de ces trois formats.
Le PDF sorti par le back-office reste une image de facture. Un logiciel qui le reçoit ne peut pas en extraire le montant de TVA sans reconnaissance de caractères. Par ailleurs, une demande de prise en charge du Factur-X dans les factures PDF est ouverte depuis plusieurs années sur le dépôt GitHub du projet. Elle n’a été suivie d’aucune implémentation dans le cœur, ni en 1.7, ni en 8, ni en 9.
Aucun raccordement à une plateforme agréée dans le cœur
Le second manque est le canal. Une facture entre entreprises françaises circule désormais par une plateforme agréée, qui l’adresse au destinataire identifié dans l’annuaire tenu par l’administration. PrestaShop n’embarque ni connecteur, ni compte, ni gestion de cet annuaire.
L’absence de raccordement se sanctionne à part. L’administration adresse une mise en demeure et laisse un délai de trois mois. Passé ce délai, l’amende atteint 500 €, puis 1 000 € par trimestre si la situation dure. Autrement dit, un marchand peut être en règle sur ses mentions obligatoires et hors clous sur le raccordement. Le back-office ne saura pas davantage lui dire si une facture est bien parvenue à son destinataire.
Un module de facturation PrestaShop et une plateforme agréée ne jouent pas le même rôle. Le module met en forme et signe le fichier. La plateforme le transporte, l’adresse et transmet les données à l’administration. Un module seul ne rend aucune boutique conforme.
E-reporting et e-invoicing : une boutique porte les deux
Un site marchand mélange deux clientèles dans la même base de commandes. Cette cohabitation crée deux obligations parallèles, avec des données, des rythmes et des sanctions différents. La réforme ne demande pas de choisir entre les deux régimes, elle demande de savoir trier chaque commande du bon côté. Ce tri se joue au moment du checkout, bien avant la génération de la facture.
Les ventes aux particuliers relèvent de l’e-reporting
Pour une commande passée par un particulier, aucune facture électronique n’a besoin de circuler. En revanche, la boutique doit transmettre des données agrégées à l’administration par sa plateforme agréée. Le paquet contient les totaux hors taxes et toutes taxes comprises, la TVA ventilée par taux, la période concernée et la nature des opérations.
Aucune donnée nominative de client n’entre dans cet envoi. La fréquence, elle, suit le régime de TVA : mensuelle au réel normal, trimestrielle au réel simplifié, plus espacée en franchise. Le défaut de transmission coûte 500 € par envoi manquant. Le plafond annuel s’établit à 15 000 €, au titre de l’article 1788 D du CGI. S’y ajoute l’e-reporting des données de paiement sur les prestations de services, un point que traite notre page Stripe et la facturation électronique.
Les ventes aux professionnels basculent en e-invoicing
Dès qu’un acheteur commande au nom d’une entreprise française assujettie, la transaction sort du B2C. La facture doit alors partir en format structuré, par une plateforme agréée, vers le compte du client. L’émission s’impose depuis le 1er septembre 2026 aux grandes entreprises et aux ETI, puis au 1er septembre 2027 aux PME, TPE et micro-entreprises.
Le point de friction est en amont, dans le tunnel de commande. PrestaShop prévoit un champ de numéro de TVA intracommunautaire dans le formulaire d’adresse, mais pas de champ SIREN. Or c’est le SIREN qui sert de clé d’adressage dans l’annuaire. Sans lui, la facture ne trouve pas son destinataire. L’amende atteint alors 50 € par facture non conforme. Le plafond annuel monte à 15 000 €, selon l’article 1737 III du CGI.
La détection du statut professionnel mérite donc un vrai paramétrage. Certaines boutiques ouvrent un groupe client dédié, d’autres conditionnent l’affichage du champ SIREN au choix d’une adresse de société. Dans les deux cas, la règle de bascule doit être écrite noir sur blanc, puis testée sur des commandes réelles. Une commande professionnelle traitée en B2C fausse à la fois la facture et l’agrégat d’e-reporting, avec un risque de double comptage à la clé.
Le SIREN devient une donnée de commande au même titre que l’adresse de livraison. Prévoyez sa collecte au checkout, sa validation en base et sa reprise sur les comptes clients déjà existants. Une reprise d’historique se compte en heures de développement, pas en clics.
Ce qu’un module ne réglera pas à votre place
La marketplace PrestaShop et les éditeurs indépendants proposent désormais plusieurs modules estampillés Factur-X. Ils comblent une partie du manque, sans le couvrir en entier. Un marchand qui achète une licence en pensant clore le sujet découvre le reste du chantier trois semaines plus tard.
Le module produit le fichier, pas la conformité
Le module Factur-X de Datafirefly couvre les versions 8 et 9. Celui d’EvolveTech se vend 199 € HT en licence unique, pour les branches 1.7, 8 et 9. D’autres connecteurs, comme ceux de Kerawen, ClicFacture ou SplashSync, poussent les commandes vers un outil de gestion tiers.
Tous génèrent un fichier structuré. Aucun ne remplace le contrat avec une plateforme agréée, qui se souscrit séparément et se facture à l’abonnement ou au flux. Le budget réel additionne donc licence du module, abonnement plateforme et paramétrage. Cette dépendance à un tiers se retrouve sur les autres CMS auto-hébergés. Voir notre page pour tout savoir sur WooCommerce et la facturation électronique.
Les angles morts : avoirs, multiboutique, thèmes surchargés
Le moteur de factures de PrestaShop est l’une des classes les plus surchargées du logiciel. Numérotation personnalisée, mentions ajoutées, gabarits PDF retouchés : chaque override augmente le risque qu’un module XML lise mal les données de commande. Un contrôle de cohérence entre le PDF et le XML s’impose donc avant toute bascule.
Trois autres cas passent souvent à la trappe. Les avoirs et remboursements suivent le même circuit que les factures et doivent partir en format structuré. Le mode multiboutique impose un rattachement clair de chaque boutique à son SIREN. Enfin, une boutique auto-hébergée assume elle-même ses mises à jour, au contraire d’un site bâti sur un éditeur hébergé. Wix et la facturation électronique illustre cet écart de responsabilité.
Brancher PrestaShop sur une plateforme agréée
Une fois le diagnostic posé, la question devient pratique : par où passent les commandes pour ressortir en factures conformes ? Trois architectures cohabitent sur le marché, avec des coûts et des niveaux d’automatisation différents. Le choix dépend surtout du volume de commandes et de la présence d’un expert-comptable.
Trois façons de faire remonter les commandes
La première consiste à installer un module Factur-X dans PrestaShop, puis à déposer les fichiers produits sur une plateforme agréée. La deuxième branche directement la boutique sur un outil de gestion qui est lui-même agréé, par connecteur ou par API. La troisième passe par une synchronisation bancaire et commerciale, où la plateforme reconstruit les ventes à partir des encaissements.
La deuxième option reste la plus sûre sur le plan réglementaire, puisque l’émission et l’e-reporting vivent au même endroit. Voici les profils que couvrent les principales plateformes utilisées derrière une boutique PrestaShop.
| Plateforme | Profil de boutique | Ce qu’elle couvre | Prix d’entrée | |
|---|---|---|---|---|
InIndyIndépendants |
Micro et petite boutique | Facturation et e-reporting | Gratuit | Voir l’offre |
TiTiimeBoutique suivie en cabinet |
TPE avec expert-comptable | Émission et réception | Gratuit | Voir l’offre |
AxAxonautGestion commerciale |
TPE et PME multicanal | Devis, factures, relances | Dès 34,99 € | Voir l’offre |
PePennylaneVolumes élevés |
PME structurée | Comptabilité et flux de vente | Dès 14 € | Voir l’offre |
Ce qu’il faut vérifier avant de signer
Premier réflexe, contrôler que la plateforme figure bien sur la liste officielle publiée par l’administration, avec son numéro d’immatriculation. Un éditeur qui annonce une candidature en cours ne vaut pas un opérateur immatriculé. Ensuite viennent les questions de tuyauterie : formats acceptés en réception, gestion des mises à jour de l’annuaire, restitution des accusés de réception.
Regardez enfin le modèle tarifaire. Une boutique qui émet 400 factures par mois n’a pas le même profil qu’un prestataire qui en émet quinze. Certaines offres facturent au flux transmis, d’autres à l’utilisateur. Vérifiez également que l’e-reporting B2C est inclus, car il est parfois vendu en option alors qu’il représente l’essentiel des volumes d’un site marchand.
Le chantier à mener sur la boutique
La mise en conformité d’une boutique PrestaShop se planifie comme une montée de version, pas comme l’installation d’un module de promotion. Elle touche le tunnel de commande, la base clients, le moteur de factures et un prestataire externe. Quatre zones, quatre risques de régression.
Compter en semaines de délai technique
Choix de la plateforme, ajout du champ SIREN, reprise des comptes clients, tests d’émission : un chantier standard occupe deux à six semaines. Ce délai grimpe si la boutique tourne encore sur PrestaShop 1.7, dont l’écosystème de modules se réduit. Les recettes se font hors production, sur une copie de la base.
Prévoyez aussi du temps côté administratif. L’ouverture d’un compte sur une plateforme agréée suppose une vérification d’identité de l’entreprise et un paramétrage des mandats de transmission. Par ailleurs, une boutique qui travaille avec un expert-comptable gagne à caler ce choix avec lui, puisque les flux transmis alimentent directement la production comptable. Décider seul, puis découvrir que le cabinet impose un autre outil, oblige à refaire le raccordement.
Ce qui se teste avant la bascule
Trois scénarios méritent un test réel. Une commande B2C classique, pour vérifier que la vente remonte bien dans l’agrégat d’e-reporting. Une commande B2B avec SIREN valide, pour contrôler l’adressage et le retour d’accusé. Un remboursement partiel, enfin, pour voir si l’avoir généré part au bon format.
Surveillez ensuite les rejets pendant le premier mois. Un XML refusé pour champ manquant ne déclenche aucune alerte dans PrestaShop, puisque le back-office ignore l’existence du flux. C’est le tableau de bord de la plateforme agréée qui fait foi, et lui seul indique si une facture est parvenue à destination.
- PrestaShop ne produit ni Factur-X, ni UBL, ni CII dans son cœur, quelle que soit la version.
- Un module de facturation ne remplace jamais le raccordement à une plateforme agréée.
- Les ventes aux particuliers relèvent de l’e-reporting, celles aux professionnels de l’e-invoicing.
- Le champ SIREN au checkout conditionne l’adressage des factures B2B.
- Avoirs, multiboutique et overrides de thème sont les trois angles morts les plus fréquents.
Volume de commandes, part de B2B, cabinet comptable : trois réponses suffisent à trancher.
Questions fréquentes
Faut-il migrer vers PrestaShop 9 pour être conforme ?
Aucun texte n’impose une version de logiciel. La contrainte vient des modules. Les solutions Factur-X du marché ciblent les branches 8 et 9, et le support de la 1.7 se raréfie. Une boutique restée en 1.7 trouvera donc moins de connecteurs maintenus, et paiera plus cher un développement spécifique. La migration se justifie par la disponibilité des outils, pas par la réglementation elle-même.
Les avoirs et remboursements passent-ils aussi par la plateforme ?
Oui, dès lors qu’ils corrigent une facture B2B soumise à l’obligation. Un avoir est une facture rectificative : il suit le même format structuré et le même circuit de transmission. Sur une boutique, cela signifie que le module doit gérer les remboursements partiels, les retours produits et les annulations après expédition. La plupart des connecteurs traitent bien la facture initiale et couvrent mal ces cas, ce qui se vérifie avant l’achat.
Comment traiter les ventes hors de France ?
L’obligation d’émettre une facture électronique concerne les transactions entre entreprises établies en France. Une vente à un client professionnel étranger sort de ce périmètre, mais entre dans l’e-reporting des transactions internationales. La boutique transmet alors les données de l’opération à l’administration, sans facture structurée adressée au client. Les ventes à distance à des particuliers de l’Union européenne suivent leur propre régime déclaratif de TVA.
Combien de temps faut-il conserver les factures de la boutique ?
Deux durées coexistent. Le droit fiscal impose six ans à compter de la dernière opération. Le Code de commerce, lui, retient dix ans pour les pièces comptables. En pratique, une boutique se cale sur dix ans. Notez que l’archivage des fichiers structurés relève de votre responsabilité, même si la plateforme en propose un. Vérifiez la durée incluse et les conditions de restitution en fin de contrat.
Qui est responsable si une facture n’est pas transmise ?
L’entreprise émettrice, dans tous les cas. L’administration s’adresse au marchand, pas à l’éditeur du module ni à la plateforme. Un contrat de prestation peut prévoir des engagements de service et un recours commercial, sans transférer la responsabilité fiscale. C’est pourquoi le suivi des rejets et des accusés doit rester une routine interne. Prévoyez un contrôle mensuel des écarts entre commandes facturées et flux transmis.