Connecter PrestaShop à votre logiciel comptable : Xero, QuickBooks et plus encore

Dernière vérification en juin 2026. Règles OSS à jour selon le régime européen post-2021 ; chemins du back-office vérifiés avec PrestaShop 1.7, 8.x et 9.x. Confirmez toujours le traitement fiscal avec votre propre expert-comptable.

Voici la distinction qui détermine à quel point votre clôture mensuelle sera pénible : PrestaShop est le système qui encaisse l’argent, tandis que votre logiciel comptable est celui qui doit expliquer cet argent à l’administration fiscale. Ce ne sont pas les mêmes tâches. Votre boutique enregistre une commande avec un client, un transporteur, un mode de paiement et un panier de produits. Votre comptable a besoin d’une facture numérotée de façon séquentielle, d’un compte de produits, d’un code de taxe et d’un avoir pour chaque remboursement, dans un format qui se rapproche au centime près. Connecter les deux revient à traduire un modèle dans l’autre. Si la traduction est correcte, la comptabilité se clôt presque toute seule ; si elle est mauvaise, vous vous retrouvez à rapprocher la TVA à la main à 23 h le dernier jour du trimestre.

Ce guide porte précisément sur la connexion de PrestaShop à un logiciel comptable, Xero, QuickBooks et les autres, afin que les commandes deviennent des factures correctes, auditables, sans ressaisie. Il ne traite pas de la connexion de PrestaShop à un ERP complet pour les stocks et les achats (c’est un autre problème, avec une autre logique, voir connecter PrestaShop à votre ERP et, pour la question « quand en ai-je besoin ? », quand votre boutique dépasse le travail manuel). Ici, le périmètre est le grand livre : factures, taxes, remboursements, frais et les chiffres que votre expert-comptable valide.

Ce qui doit réellement passer de PrestaShop vers la comptabilité

Avant de choisir un outil, clarifiez les données que la connexion doit transporter. PrestaShop en génère déjà la majeure partie. Le rôle de l’intégration est d’associer chaque élément au bon endroit dans votre plan comptable, pas de le recréer. Les objets importants se trouvent dans des tables PrestaShop bien définies, et connaître leurs noms vous dit exactement ce qu’une intégration lit :

• La facture, pas la commande. Une commande PrestaShop (ps_orders) n’est pas encore un document comptable. La facture est un objet distinct (OrderInvoice / ps_order_invoice), généré lorsque la commande atteint un état de facturation, et elle porte son propre numéro. Votre comptabilité se base sur la facture. Synchronisez des commandes sans facture et vous créerez un chiffre d’affaires qui n’existe pas encore légalement.
• La taxe, ventilée par taux. PrestaShop stocke la taxe par ligne et par facture (ps_order_detail_tax, ps_order_invoice_tax). Une seule commande peut contenir deux ou trois taux de TVA différents, produits au taux normal, produits au taux réduit, livraison à taux zéro. L’intégration doit préserver cette ventilation, pas seulement un total unique.
• Les remboursements et annulations sous forme d’avoirs. Un remboursement dans PrestaShop est un avoir (OrderSlip / ps_order_slip), avec son propre numéro séquentiel. Dans votre logiciel comptable, il doit arriver comme un avoir rattaché à la facture d’origine, pas comme une vente négative, et jamais comme une suppression silencieuse.
• Le paiement par rapport à la facture. Ce que le client a payé (ps_order_payment) et ce que vous avez facturé sont deux événements distincts. Le marquage d’une facture comme « payée » dans la comptabilité doit être piloté par l’enregistrement du paiement, afin que la trésorerie et le chiffre d’affaires se rapprochent séparément.
• Les frais de passerelle et la livraison. Stripe et PayPal prélèvent une commission avant que l’argent arrive ; les revenus de livraison (ce que le client a payé) et les coûts de livraison (ce que vous avez payé au transporteur) sont deux lignes différentes. Rien de tout cela n’apparaît dans une synchronisation naïve de type « total commande → chiffre d’affaires ».

Et alors ? Si vous savez nommer ces cinq flux, vous pouvez évaluer n’importe quel connecteur en cinq minutes : il suffit de demander lesquels il gère et lesquels il laisse discrètement de côté.

La décision avant l’outil : qui attribue le numéro de facture ?

C’est le choix unique qui façonne toute intégration comptable, et la plupart des guides le passent sous silence. Dans presque toutes les juridictions, les factures de vente et les avoirs doivent être séquentiels et uniques, et, dans certains pays, la séquence doit être sans rupture, ou chaque rupture doit être explicable et auditable. La question est donc de savoir quel système fait foi pour cette séquence.

Si PrestaShop porte la numérotation, la séquence native est configurable mais rudimentaire, et un trou non expliqué (facture annulée ou manquante, modification manuelle de la base de données, migration échouée ou remise à zéro mal configurée) est exactement le type d’élément qu’un auditeur signale. Deux de nos modules existent précisément pour ce point de contrôle : Invoice Number et Order Number vous permettent de définir le préfixe, la valeur de départ et le format afin que vos documents PrestaShop suivent la séquence annuelle, sans rupture, attendue par votre expert-comptable, au lieu de subir les réglages par défaut du cœur. Le bénéfice est précis mais réel : le document que votre client télécharge et celui que votre comptable archive portent le même numéro, légalement valide. Le rapprochement devient une recherche, pas une enquête.

Xero

Xero est un choix fréquent pour les boutiques britanniques et européennes, et il le mérite : une API bien documentée, une gestion native du multi-devises et un traitement de la TVA qui tient la route à l’international. Pour PrestaShop, la connexion est presque toujours indirecte, un service de middleware ou un module dédié lit les commandes facturées et crée les factures Xero correspondantes, car Xero ne propose pas son propre plugin natif pour PrestaShop.

Les quatre points qui déterminent réellement si une connexion Xero est correcte :

• Le mapping du plan comptable. Vos catégories (ou produits) PrestaShop doivent être associées aux comptes de produits dans Xero. Une boutique qui vend des biens physiques et des téléchargements numériques voudra généralement les placer dans des comptes séparés, décidez du mapping avant la première synchronisation, car le refaire après des milliers de factures est pénible.
• Le mapping des taux de taxe. Une règle de taxe PrestaShop (Back-office → International → Taxes → Règles de taxes) n’est pas le même objet qu’un taux de taxe Xero. Vous associez explicitement chaque élément : « FR Standard 20% » dans PrestaShop au taux correspondant dans Xero, puis de même pour chaque pays où vous vendez. Oubliez-en un, et les ventes de ce pays seront enregistrées avec la mauvaise taxe, ou sans taxe du tout.
• Le statut de paiement. Une facture ne doit être marquée payée dans Xero que lorsque PrestaShop confirme le paiement. Pilotez cela depuis l’état payé de la commande, pas depuis la création de la facture, sinon votre position de trésorerie sera surestimée.
• Le multi-devises. Si vous vendez en GBP, EUR et USD, laissez Xero gérer les taux de change et comptabilisez les factures dans la devise de vente. Ne préconvertissez pas dans l’intégration, vous perdriez la piste d’audit du montant dans la devise d’origine.

L’erreur Xero la plus fréquente consiste à synchroniser trop de choses. Commencez uniquement par les commandes facturées et payées. Les commandes brouillon, les paniers abandonnés et les paiements en attente n’ont rien à faire dans votre comptabilité tant que l’argent n’a pas changé de mains.

QuickBooks Online

QuickBooks Online est courant chez les marchands américains et peut aussi être utilisé dans certaines configurations européennes, avec un écosystème de connecteurs mûr, la plupart des plateformes de middleware le prennent en charge immédiatement. Savoir s’il convient vraiment à une boutique européenne dépend de vos obligations locales en matière de fiscalité et de facturation électronique ; vérifiez-les avant de vous engager. La difficulté pour les vendeurs transfrontaliers est que QuickBooks modélise la sales tax (États-Unis, basée sur la destination, par État/comté) très différemment de la TVA (Union européenne). Si vous vendez dans les deux zones, l’intégration doit créer la bonne écriture de taxe selon la localisation du client, une commande américaine reçoit une ligne de sales tax, une commande européenne reçoit une ligne de TVA, et cette logique se trouve dans le connecteur, pas dans QuickBooks.

Les réglages pratiques qui font gagner du temps :

• Utilisez les classes ou les emplacements. Si vous exploitez plusieurs boutiques PrestaShop (par exemple une boutique distincte par pays), les classes QuickBooks permettent de garder le chiffre d’affaires de chaque boutique séparé dans le P&L sans créer un second fichier QuickBooks.
• Traitez par lots, pas en flux continu. La synchronisation en temps réel paraît séduisante ; un lot quotidien ou horaire est plus fiable et beaucoup plus facile à déboguer lorsqu’une facture échoue. Vous voulez trouver un problème dans un lot de 40, pas le traquer dans un flux en direct.
• Décidez du niveau de détail produit. Chaque produit PrestaShop devient-il un article QuickBooks, ou regroupez-vous le chiffre d’affaires par catégorie ? Le suivi par produit donne des rapports au niveau produit et une liste d’articles bien plus volumineuse à maintenir ; le suivi par catégorie garde QuickBooks léger. La plupart des boutiques préfèrent l’agrégation.
• Reflétez les avoirs PrestaShop en credit memos. Un avoir PrestaShop doit créer un credit memo QuickBooks rattaché à la facture d’origine, même montant, même traitement fiscal.

Les autres plateformes, et pourquoi votre pays décide

Xero et QuickBooks dominent les discussions en anglais, mais le bon outil est généralement celui que votre expert-comptable local et votre administration fiscale attendent. L’approche d’intégration évolue en conséquence :

• Sage, bien implanté au Royaume-Uni et en France, fréquent dans les entreprises plus importantes ; l’approche d’intégration dépend du produit Sage, avec des options allant des connecteurs API (Sage Business Cloud, Intacct) au middleware et aux exports planifiés.
• Datev. Le standard de fait en Allemagne, car la plupart des conseillers fiscaux allemands (Steuerberater) l’utilisent. Ils veulent rarement une API ; ils veulent un export compatible Datev qu’ils peuvent importer. Pour ces comptables, un pipeline CSV/export propre vaut mieux que n’importe quel connecteur temps réel.
• Fakturownia / inFakt / wFirma, plateformes polonaises de facturation et de fiscalité. Les règles polonaises de numérotation et de déclaration JPK sont strictes, ce qui rend la décision « qui possède le numéro de facture » ci-dessus particulièrement structurante ici.
• Fattura24 / Aruba, l’Italie impose la facturation électronique (fatturazione elettronica) via le système d’échange SDI. Ces plateformes gèrent la transmission SDI ; le rôle de votre intégration PrestaShop est de leur fournir une facture correctement structurée, pas de parler directement à SDI.
• FreshBooks / outils de type Debitoor, facturation plus simple pour micro-entreprises et indépendants, généralement alimentée par export plutôt que par intégration profonde.

Pour toute plateforme sans connecteur clé en main, l’intégration se résume presque toujours à un export structuré que le logiciel comptable (ou votre expert-comptable) importe selon un calendrier. Ce n’est pas une solution au rabais, pour un flux Datev ou Fattura24, c’est exactement ce que le système récepteur attend.

Ce que contient réellement un fichier d’export comptable

Si vous choisissez la voie de l’export (Datev, JPK, « envoyez-moi juste un CSV »), il est utile de connaître les colonnes attendues côté réception, car un en-tête propre représente déjà l’essentiel du travail. L’import de votre comptable ne veut pas la vue commande de votre boutique, il veut des lignes au niveau facture, avec la taxe ventilée par taux. Un en-tête CSV exploitable pour un export de factures de vente ressemble à ceci :

invoice_number,invoice_date,order_reference,customer_name,customer_vat_number,country,currency,net_amount,tax_rate,tax_amount,gross_amount,payment_method,document_type
INV-2026-000412,2026-06-18,XKBKTSXPM,"ACME GmbH",DE811234567,DE,EUR,200.00,0.00,0.00,200.00,bankwire,invoice
INV-2026-000412,2026-06-18,XKBKTSXPM,"ACME GmbH",DE811234567,DE,EUR,50.00,19.00,9.50,59.50,bankwire,invoice
CN-2026-000031,2026-06-20,XKBKTSXPM,"ACME GmbH",DE811234567,DE,EUR,-50.00,19.00,-9.50,-59.50,bankwire,credit_note

Deux points à noter : chaque taux de taxe obtient sa propre ligne (une facture multi-taux s’étend donc sur plusieurs lignes dont la somme correspond au total du document), et un remboursement apparaît comme un credit_note avec des montants négatifs rattachés à la order_reference d’origine, jamais comme une ligne de facture supprimée ou modifiée. Validez les noms exacts des colonnes et le format de date avec votre expert-comptable avant le premier lancement ; Datev et JPK ont chacun leur mise en page requise, mais la logique, une ligne par taux, les avoirs en négatif, reste constante.

Deux chemins vers la comptabilité : module natif ou middleware

Une fois que vous savez ce qui doit circuler et qui possède la numérotation, il existe deux façons réalistes de déplacer les données. Elles ne s’excluent pas mutuellement, beaucoup de boutiques utilisent un module pour les factures et un connecteur middleware pour une plateforme précise, mais il est utile de voir clairement le compromis.

Côté module, notre module Financial Revolution gère la génération, la numérotation et l’export des factures dans des formats exploitables par votre plateforme comptable. Lorsque le livrable attendu est un fichier propre selon un calendrier, le cas Datev ou JPK, Invoice CSV List Exporter extrait les données de facture et de taxe par taux que votre expert-comptable importe, tandis que Orders CSV List Exporter couvre la partie commandes brutes lorsque c’est ce que le système récepteur attend. Le résultat concret : vous pouvez mettre en place un flux comptable précis depuis le back-office, sans abonnement middleware récurrent et sans que les données de commande quittent votre serveur. Ce qui est souvent le facteur décisif pour un flux Datev ou JPK où le comptable veut simplement un fichier propre, à intervalles réguliers. (Et si ce calendrier doit tourner sans intervention, Cron Manager exécute et enregistre l’export récurrent afin qu’une exécution manquée soit visible, pas silencieuse.)

Le middleware justifie son abonnement lorsque vous voulez précisément une synchronisation en direct, sans intervention, vers Xero ou QuickBooks, et que vous accordez de la valeur aux relances, aux journaux et aux connecteurs prémappés intégrés. Si votre raison d’utiliser Zapier ou Make relève plutôt de l’automatisation générale de la boutique que du grand livre lui-même, c’est un autre sujet. Les mécanismes de construction de ces workflows sont couverts dans Zapier et Make pour PrestaShop et l’angle no-code dans automatiser les workflows sans écrire de code.

TVA transfrontalière : la partie qui transforme une tâche comptable en sujet juridique

Si vous vendez au-delà des frontières de l’UE, la TVA est l’endroit où une intégration comptable cesse d’être un simple confort et devient une question de conformité. PrestaShop capture les faits bruts ; votre comptabilité doit les déclarer correctement.

• OSS (One-Stop Shop). Depuis juillet 2021, une boutique de l’UE peut déclarer la TVA de tous les États membres via une déclaration OSS unique, mais seulement si vos enregistrements savent le taux de quel pays s’est appliqué à chaque vente. PrestaShop stocke déjà la destination et la règle de taxe appliquée par facture ; l’intégration doit transmettre cette dimension pays jusqu’à la comptabilité, sinon votre déclaration OSS devient une estimation.
• Autoliquidation B2B. Vendez à une entreprise disposant d’un numéro de TVA intracommunautaire valide et vous ne facturez pas la TVA, l’acheteur l’autoliquide. Cela signifie que votre intégration doit comptabiliser la vente comme une écriture d’autoliquidation, pas comme une vente à TVA zéro, ce qui n’est pas la même chose pour l’administration fiscale. La validation du numéro au moment de la commande est le prérequis ; notre module Automatic EU VAT Checker vérifie les numéros de TVA via VIES en temps réel afin que la commande soit correctement marquée avant même d’atteindre votre comptabilité.
• Exports hors UE. Les ventes hors Union européenne sont généralement à taux zéro, mais elles doivent tout de même apparaître dans la comptabilité comme des exportations, présentes, pas invisibles.

La règle pratique : corrigez la TVA transfrontalière avant de monter en volume. Un mauvais mapping fiscal est une petite contrariété à 30 commandes par mois, et une correction à cinq chiffres à 3 000.

Les pièges qui touchent toutes les intégrations comptables

Quel que soit l’outil choisi, les mêmes quelques bugs reviennent. Les anticiper dès le départ coûte moins cher que les découvrir en fin d’exercice :

• Factures dupliquées. Le grand classique. Une synchronisation qui tourne deux fois, ou qui réessaie après un timeout, peut comptabiliser deux fois la même facture. La solution est une clé d’idempotence, presque toujours l’ID de commande ou de facture PrestaShop, pour que le système comptable reconnaisse et ignore une répétition.
• Écarts d’arrondi. PrestaShop et votre logiciel comptable peuvent arrondir la taxe par ligne ou sur le total différemment. Un écart d’un centime sur une commande est du bruit ; sur des milliers de commandes, cela devient un rapprochement qui ne tombe jamais juste. Décidez une fois de la règle d’arrondi et faites s’accorder les deux systèmes (le mode d’arrondi et le type d’arrondi de PrestaShop se trouvent sous Paramètres de la boutique → Général).
• Incohérence de devise. Un client paie en GBP, votre comptabilité est en EUR. L’écriture doit contenir à la fois le montant dans la devise d’origine et le montant converti au bon taux, sinon votre reporting en devises étrangères est fictif.
• Frais de passerelle oubliés. Le pourcentage prélevé par un prestataire de paiement n’est pas une remise sur le chiffre d’affaires, c’est une charge. Enregistrez séparément la vente brute et les frais, sinon vos marges paraissent meilleures qu’elles ne le sont et votre solde bancaire ne se rapprochera pas.
• Remboursements qui disparaissent. Les remboursements sont l’endroit où un processus manuel casse le plus souvent. Si les avoirs PrestaShop ne se transforment pas automatiquement en avoirs comptables, votre chiffre d’affaires est systématiquement surestimé. Automatisez ce flux en premier, pas en dernier.

Un déploiement raisonnable selon la taille de la boutique

Vous n’avez pas besoin du pipeline le plus sophistiqué, vous avez besoin d’un flux exact, fiable, qui économise plus de temps qu’il n’en coûte à exploiter. Adaptez l’effort au volume :

• Moins de ~50 factures/mois : un export hebdomadaire (CSV / style Datev) que votre expert-comptable importe suffit réellement. Ne sur-ingéniez pas.
• ~50–500/mois : une synchronisation quotidienne automatisée ou un export planifié, avec les remboursements automatisés et une alerte d’échec pour découvrir une exécution cassée le jour même, pas à la clôture mensuelle.
• 500+/mois : une intégration quasi temps réel avec idempotence, journalisation et supervision, le volume où un doublon silencieux ou un avoir manqué devient assez coûteux pour justifier l’ingénierie.

Et quelle que soit la taille : parlez à votre expert-comptable avant de construire. Demandez quel plan comptable utiliser, quels codes de taxe il attend, quel format d’export il importe réellement et s’il veut que PrestaShop ou son propre système porte la numérotation des factures. Faites ensuite tourner le nouveau pipeline en parallèle de votre processus existant pendant un mois complet et rapprochez les deux avant de couper la solution manuelle de secours. L’objectif n’est pas une intégration brillante. C’est une fin de trimestre où les comptes sont déjà clôturés parce que chaque commande, remboursement et ligne de taxe s’est correctement traduit dès le départ.

Questions fréquentes

Le numéro de facture doit-il venir de PrestaShop ou de mon logiciel comptable ?

Choisissez un registre de référence et tenez-vous-y. Si vous émettez les factures destinées aux clients au moment de la commande et que la boutique est votre principal journal des ventes, PrestaShop doit porter la numérotation, mais vous devez alors contrôler strictement le préfixe, le format et la séquence pour qu’elle soit sans rupture et solide en cas d’audit (c’est le rôle de Invoice Number et Order Number). Si votre expert-comptable exige d’émettre tous les documents légaux depuis son système, laissez-le les numéroter et traitez l’ID de commande PrestaShop comme une métadonnée, puis supprimez le PDF client pour éviter que les deux documents se contredisent.

Comment les remboursements doivent-ils arriver dans mon logiciel comptable ?

Sous forme d’avoirs, jamais comme des factures supprimées ou modifiées. Un avoir PrestaShop (OrderSlip / ps_order_slip) correspond à un avoir (Xero) ou à un credit memo (QuickBooks) rattaché à la facture d’origine, même montant, même traitement fiscal, valeurs négatives. Automatisez ce flux en premier, car un processus de remboursement manuel est la cause la plus fréquente d’une comptabilité qui surestime le chiffre d’affaires.

Ai-je besoin d’un abonnement middleware payant, ou puis-je simplement exporter un fichier ?

Pour un expert-comptable orienté export, Datev en Allemagne, JPK en Pologne, ou toute personne qui dit « envoyez-moi juste un CSV ». Un export planifié est exactement ce qu’il attend, et un module comme Invoice CSV List Exporter le fait sans frais récurrents et sans que les données de commande quittent votre serveur. Le middleware (Synder, A2X) justifie son abonnement lorsque vous voulez précisément une synchronisation API en direct, sans intervention, vers Xero ou QuickBooks, avec relances et journalisation gérées pour vous.

Comment éviter de comptabiliser deux fois les factures lorsqu’une synchronisation réessaie ?

Utilisez une clé d’idempotence, presque toujours l’ID de commande ou de facture PrestaShop, afin que le système comptable reconnaisse et ignore une répétition. Sans elle, toute synchronisation lancée deux fois ou relancée après un timeout peut comptabiliser de nouveau la même facture, et vous ne le découvrez qu’au rapprochement. C’est une décision de conception d’une ligne qui évite le bug le plus courant des intégrations comptables.

Ma TVA transfrontalière semble incorrecte dans la comptabilité, où cela se dérègle-t-il ?

Presque toujours dans le mapping des taux de taxe ou dans l’absence de dimension pays. PrestaShop stocke la destination et la règle de taxe appliquée par facture, mais l’intégration doit transporter ce pays jusqu’à la comptabilité pour la déclaration OSS, comptabiliser les ventes B2B avec numéros de TVA intracommunautaires valides en autoliquidation (pas en TVA zéro), et traiter les ventes hors UE comme des exportations à taux zéro plutôt que de les laisser disparaître. Validez les numéros de TVA au moment de la commande (Automatic EU VAT Checker vérifie via VIES) afin que chaque commande soit correctement marquée avant d’atteindre le grand livre.

À lire aussi

• Quand votre boutique dépasse le travail manuel. Décider si l’intégration comptable est la première étape dont vous avez besoin
• Connecter PrestaShop à votre ERP, la moitié stocks et achats, avec une logique différente du grand livre
• Zapier et Make pour PrestaShop, lorsque l’automatisation plus large de la boutique, et non le grand livre, est votre raison d’intégrer