Personnalisation des numéros de facture et de commande : pourquoi les numéros par défaut ne suffisent pas

Révisé en juin 2026. S’applique à PrestaShop 1.6, 1.7, 8 et 9. Les clés de configuration ci-dessous sont stables sur ces versions ; les libellés de menu changent légèrement selon les versions, donc vérifiez le chemin exact dans votre propre installation. Rien ici ne constitue un conseil juridique ou fiscal, votre comptable et les règles locales déterminent à quoi ressemble une séquence conforme dans votre pays.

Par défaut, PrestaShop attribue à chaque commande une référence comme "XKJHQWER" et démarre les factures au numéro 1. Pour un catalogue de test, cela passe inaperçu. Le jour où vous recevez de vraies commandes, cela devient un risque : un conseiller du service client qui ne peut pas relire clairement un numéro de commande au téléphone, un comptable qui ne sait pas quel document correspond à quoi, et un contrôleur fiscal qui veut comprendre pourquoi la facture #4521 est suivie de la #4598 sans rien entre les deux. Ce guide porte précisément sur les numéros, la référence de commande et la séquence des factures/avoirs, ce que PrestaShop vous permet de modifier depuis le back-office, là où il s’arrête, et comment obtenir un schéma de numérotation validé par votre comptable et réellement utilisable par votre équipe.

C’est volontairement un sujet ciblé. Le format du PDF de facture lui-même, les règles légales pays par pays sur ce qu’une facture doit contenir, et le passage à la facturation électronique structurée sont des sujets distincts, chacun avec ses propres réponses, indiquées en fin d’article. Ici, nous restons sur la numérotation.

Ce que PrestaShop fournit nativement, et ce qu’il ne fournit pas

Deux systèmes de numérotation différents fonctionnent côte à côte dans PrestaShop, et les marchands les confondent constamment.

La référence de commande est le code visible par le client, généré au moment où une commande est passée. PrestaShop la construit dans Order::generateReference() sous forme de chaîne alphanumérique aléatoire en majuscules (la forme bien connue "XKJHQWER"). Elle n’est pas séquentielle, n’est pas configurable depuis le back-office et ne porte aucune signification. C’est ce qui apparaît dans l’e-mail de confirmation, dans Commandes → Commandes, et ce qu’un client vous lit au téléphone.

Le numéro de facture est différent : il n’est attribué que lorsqu’une facture est réellement générée (lorsqu’une commande atteint un statut marqué comme facture disponible), et il constitue une séquence continue. Vous disposez d’un contrôle limité à son sujet dans Commandes → Factures (PrestaShop 1.7 et versions ultérieures : Vendre → Commandes → Factures) :

Cela couvre les bases, et pour une boutique mono-pays et mono-boutique, cela peut suffire. Les limites apparaissent dès que votre configuration devient ne serait-ce qu’un peu plus exigeante :

• La référence de commande reste aléatoire. Aucun réglage natif ne la modifie. Votre entrepôt et votre service client restent coincés à épeler "XKJHQWER" à voix haute.
• Aucun contrôle du remplissage par zéros. Les numéros de facture avancent 1, 2, 3 … 999 sans moyen d’imposer une largeur fixe comme 00001, ils ne se trient donc pas proprement et ne s’alignent pas correctement dans les exports.
• Les avoirs natifs ont leur propre numérotation et préfixe de base, mais une mise en forme personnalisée limitée. PrestaShop génère les avoirs comme un type de document séparé avec un compteur et un préfixe distincts, mais vous avez peu de contrôle sur leur format, leur réinitialisation ou leur série par rapport à un module dédié. Certaines juridictions exigent des avoirs dans une série clairement séparée et explicite.
• L’année est la seule période de réinitialisation. Si votre comptable utilise des séquences mensuelles, l’option native ne sait pas le faire.
• La différenciation par boutique reste grossière. En multiboutique, vous pouvez varier le préfixe par boutique, mais construire à la main un schéma propre et spécifique à chaque marché devient vite laborieux.

Et alors ? Pourquoi la numérotation compte vraiment

C’est la partie que les marchands sous-estiment jusqu’au moment où quelque chose casse. Trois bénéfices concrets :

Sécurité en cas d’audit. Les règles européennes exigent une numérotation de facture séquentielle et unique, fondée sur une ou plusieurs séries, et de nombreuses administrations fiscales s’attendent à ce que tout trou soit explicable et documenté. Un trou que vous ne pouvez pas expliquer est exactement le genre de détail qui transforme un contrôle de routine en vrai problème. Ce qui est considéré comme conforme varie selon les pays, et ce niveau de détail appartient aux guides juridiques, pas ici : consultez personnalisation des factures : modèles PDF et exigences légales pour savoir ce que chaque marché attend sur le document, et l’aperçu du droit du commerce électronique dans l’UE pour les obligations plus larges. Le point essentiel pour la numérotation est simple : une séquence prévisible et maîtrisée est ce qui rend possible l’absence de trous inexpliqués.

Service client plus rapide. Un client qui lit "ORD-2026-00142" à votre conseiller permet une recherche en une seule tentative. Le même client qui lit "XKJHQWER" confond le K avec un Q, oublie un caractère, et vous passez deux minutes à confirmer l’orthographe. Multipliez cela par chaque appel au service client.

Comptabilité importée proprement. Que votre comptable utilise Datev, Xero ou un logiciel local, il attend un format cohérent et des numéros à largeur fixe qui se trient correctement. Définir le bon format avant le premier export coûte beaucoup moins cher que de réconcilier une incohérence plus tard.

Concevoir un schéma de numérotation robuste

Avant de toucher à un réglage, décidez du schéma sur papier. Un bon schéma est lisible, auto-daté et à largeur fixe. Un modèle pratique :

• Un préfixe qui identifie le document et le marché, RE pour une Rechnung allemande, FA pour une facture française, INV pour une facture générique en anglais.
• L’année (et le mois, si votre comptable utilise des séries mensuelles), cela rend le document auto-daté, sans devoir le croiser avec autre chose pour savoir quand il a été émis.
• Un compteur complété par des zéros, 00001 et non 1, pour que tout s’aligne et se trie correctement.
• Une série séparée pour les avoirs, utilisez un compteur d’avoirs distinct, sauf si votre comptable ou vos règles locales approuvent une série partagée ; un avoir est un type de document à part entière, et une série distincte est généralement plus claire.

Vous obtenez ainsi des formats comme RE-2026-00001 ou FV/00001/06/2026. La règle qui compte davantage que la forme exacte : choisissez-la une fois et ne la changez pas en cours de période. Modifier le format au milieu d’un exercice fiscal crée les enregistrements confus et les "trous" apparents que les auditeurs n’aiment pas. Si vous devez changer, faites-le à la frontière d’une année et laissez une note écrite à votre comptable.

Obtenir un contrôle complet : la voie du module

Lorsque les réglages natifs atteignent leurs limites, et pour la référence de commande, ils les atteignent immédiatement, deux de nos modules prennent le relais, chacun sur l’un des deux systèmes de numérotation.

Notre module Order Number remplace la référence de commande aléatoire par une référence significative et séquentielle. Il fonctionne en surchargeant la classe cœur Order, de sorte que la nouvelle référence se propage partout où l’ancienne apparaissait, liste du back-office, compte client, e-mail de confirmation, sans modification du thème. Vous construisez le format à partir de jetons : {YYYY} pour l’année, {MM} pour le mois, {NNNNNN} pour un compteur complété par des zéros, et même {PAYMENT} pour intégrer le moyen de paiement. Qu’est-ce que cela vous apporte concrètement ? Une référence comme ORD-2026-000142, qu’un client peut relire sans erreur et que votre entrepôt peut scanner et rechercher instantanément, le plus gros point de friction quotidien dans le traitement des commandes disparaît.

Notre module Invoice Number fait la même chose côté documents, bien au-delà de l’option native préfixe-plus-année. Vous définissez un préfixe personnalisé, insérez le jeton {YYYY}, choisissez la largeur du compteur avec {NNNN} ou {NNNNNN}, basculez la réinitialisation entre annuelle et mensuelle, et, ce que le cœur ne fait pas proprement, utilisez une séquence séparée et formatée indépendamment pour les avoirs. Et alors ? Vous donnez à votre comptable exactement le format demandé, avec la largeur exacte qui s’importe sans correction manuelle, et des avoirs dans leur propre série clairement libellée. La posture de conformité (continue, maîtrisée, explicable) et le confort comptable viennent du même réglage.

Pour le contenu de l’avoir plutôt que son numéro, ventilations de taxes correctes, références à la facture d’origine et mise en forme de niveau comptable sur le document lui-même, c’est le rôle de Financial Revolution, qui améliore les avoirs générés par PrestaShop lors d’un remboursement. La numérotation et le contenu du document sont volontairement des sujets séparés ; utilisez l’outil qui correspond au problème que vous corrigez.

Multiboutique : un schéma par boutique

Si vous gérez plusieurs boutiques, marques différentes, pays différents, canaux différents, chacune doit conserver son propre compteur et son propre préfixe. Les mélanger crée des trous apparents lorsque vous regardez les comptes d’une seule boutique et empêche de savoir d’un coup d’œil quelle boutique a émis un document. Une organisation propre :

Chaque boutique incrémente et réinitialise indépendamment, et le marché est lisible grâce au seul préfixe. Les réglages de facture tiennent déjà compte du contexte dans un multiboutique PrestaShop ; c’est du côté de la référence de commande qu’un module justifie sa place, car la référence aléatoire native n’a aucune notion de boutique.

Migrer depuis les numéros par défaut sans créer de doublons

Basculer une boutique en production demande de la prudence, choisissez un mauvais numéro de départ et vous pouvez entrer en collision avec des documents déjà existants. La séquence sûre :

1. Choisissez une date de transition, privilégiez une limite d’exercice fiscal ou de trimestre ; si vous devez changer en cours de période, documentez le changement et gardez les anciennes et nouvelles séries clairement traçables.
2. Réglez le prochain compteur au-dessus de votre numéro existant le plus élevé, pour les factures, c’est PS_INVOICE_START_NUMBER (ou la valeur de départ du module) ; cela garantit l’absence de doublons.
3. Ne touchez pas aux anciens documents. Ne renumérotez jamais rétroactivement des factures émises, elles conservent leurs numéros d’origine pendant toute leur durée légale de conservation. Seuls les nouveaux documents prennent le nouveau format.
4. Testez la réinitialisation avant d’en dépendre. Si vous configurez une réinitialisation annuelle ou mensuelle, prouvez qu’elle bascule réellement sur une copie de préproduction plutôt que de découvrir le 1er janvier qu’elle ne l’a pas fait.
5. Notez-le pour votre comptable. Une note d’une ligne indiquant ce qui a changé et quand supprime toute question sur le "trou" au moment de la transition.

Si vous préférez vérifier ou définir ces valeurs directement, elles se trouvent toutes dans la table ps_configuration sous forme de lignes clé/valeur simples. Lisez-les avant de changer quoi que ce soit dans le back-office afin de connaître l’état actuel :

-- Inspect the native invoice-numbering settings
SELECT name, value
FROM ps_configuration
WHERE name IN (
  'PS_INVOICE_PREFIX',
  'PS_INVOICE_USE_YEAR',
  'PS_INVOICE_RESET',
  'PS_INVOICE_START_NUMBER',
  'PS_DELIVERY_PREFIX',
  'PS_DELIVERY_NUMBER'
);

Certaines de ces valeurs sont par langue (le préfixe en particulier), donc sur une boutique multilingue, la ligne peut se trouver dans ps_configuration_lang avec une clé id_lang à la place. L’endroit le plus sûr pour les définir reste le back-office, qui écrit la bonne ligne pour le bon contexte de boutique et de langue ; considérez le SQL ci-dessus comme un moyen de voir l’état actuel, et faites une sauvegarde avant toute écriture manuelle. Le prochain numéro de facture séquentiel lui-même n’est pas stocké dans une ligne de configuration unique, PrestaShop le déduit du plus grand number existant dans ps_order_invoice, combiné à la valeur de départ, ce qui explique précisément pourquoi régler le numéro de départ au-dessus de votre document existant le plus élevé (plutôt que de renuméroter quoi que ce soit) est la méthode qui évite les doublons.

Erreurs fréquentes

• Changer de format en cours d’année. La source classique de comptabilité confuse et de trous inexpliqués. Ne changez qu’à une limite de période.
• Une seule série pour les factures et les avoirs. Certaines juridictions ou certains comptables exigent ou préfèrent une série séparée. Vérifiez localement ; même lorsqu’une série partagée est autorisée, les mélanger complique la comptabilité. Gardez INV- et une série d’avoirs distincte.
• Laisser le compteur sans zéros de remplissage. Les numéros de largeur variable se trient mal dans les feuilles de calcul et les exports. Utilisez une largeur fixe dès le premier jour.
• Oublier que la référence de commande existe. Les marchands corrigent les numéros de facture et laissent les commandes avec la référence aléatoire, puis se demandent pourquoi les appels au service client restent lents. Ce sont deux systèmes séparés ; corrigez les deux.
• Ne pas numéroter les bons de livraison de façon cohérente. Ils portent moins d’exigences légales, mais une séquence erratique de bons de livraison coûte tout de même du temps à votre équipe entrepôt.

Là où la numérotation s’arrête et où commence le reste de la conformité

La numérotation n’est qu’une partie du travail nécessaire pour gérer correctement les documents et la fiscalité dans PrestaShop. Les éléments voisins, chacun avec son propre guide :

• Ce que le PDF de facture doit afficher et comment personnaliser son modèle, personnalisation des factures : modèles PDF et exigences légales.
• La facturation électronique structurée là où elle est obligatoire (SDI italien, réforme française et plus encore), facturation électronique en Europe : quels pays l’exigent.
• Bien gérer la TVA au-delà des frontières, TVA dans l’UE : OSS, IOSS et ce que votre boutique doit gérer et le guide pratique configuration des taxes dans PrestaShop.
• Comment les prix apparaissent avant le paiement, règles d’affichage des prix en Europe.
• La gestion des retours et remboursements de bout en bout, dont l’avoir est une étape, retours et remboursements : rendre le processus indolore.

Questions fréquentes

Puis-je rendre la référence de commande PrestaShop séquentielle sans module ?

Pas depuis le back-office. La référence de commande vient de Order::generateReference(), qui renvoie une chaîne aléatoire en majuscules, et aucun réglage natif ne la modifie. Les seules façons de la rendre séquentielle consistent à surcharger vous-même la classe Order ou à utiliser un module qui le fait. Le numéro de facture est configurable nativement, mais la référence de commande ne l’est pas.

Pourquoi ma numérotation de facture comporte-t-elle des trous ?

Presque toujours parce qu’une commande a généré une facture puis a été annulée ou remboursée, ou parce qu’un statut que vous ne pensiez pas facturant avait son indicateur "Facture" activé. Le numéro a été attribué et le document a ensuite été annulé, laissant un trou. Dans plusieurs pays de l’UE, un trou n’est acceptable que si vous pouvez l’expliquer ; la solution pratique relève donc du processus, pas de la suppression : conservez le document annulé, notez pourquoi, et ne renumérotez jamais pour "fermer" le trou. La tolérance ou non des trous dépend de votre juridiction, confirmez avec votre comptable.

Je migre une boutique existante, quel numéro de départ dois-je définir ?

Définissez-le à un au-dessus du numéro de facture le plus élevé que vous avez déjà émis. PrestaShop déduit le prochain numéro des documents existants plus la valeur de départ, donc un numéro de départ supérieur à votre maximum actuel garantit l’absence de collision. Ne baissez jamais le numéro de départ en dessous d’un document émis, et ne renumérotez jamais rétroactivement les anciennes factures, elles conservent leurs numéros d’origine pendant toute leur durée légale de conservation.

Les factures et les avoirs doivent-ils partager une même série de numéros ?

Généralement non. Un avoir est un type de document distinct, et beaucoup de comptables ainsi que certaines juridictions préfèrent ou exigent une série séparée et explicite. PrestaShop donne aux avoirs leur propre compteur de base ; si vous avez besoin d’une série d’avoirs formatée indépendamment avec sa propre réinitialisation, c’est là que le module Invoice Number va au-delà de l’option native. Vérifiez la règle locale avant de partager une série.

Changer le préfixe de facture renumérote-t-il mes anciennes factures ?

Non. Les préfixes et jetons d’année s’appliquent aux documents générés après la modification du réglage ; les factures déjà émises conservent le format avec lequel elles ont été créées, car PrestaShop stocke le numéro attribué sur chaque ligne ps_order_invoice. C’est aussi pourquoi vous devez changer de format uniquement à une limite de période, mélanger deux formats dans un même exercice fiscal produit des enregistrements que les auditeurs trouvent confus.

La numérotation des documents fait partie de ces réglages que personne ne remarque quand tout va bien, mais que tout le monde voit le jour où elle est incorrecte. Décidez du schéma une fois, préfixe lisible, auto-datation, largeur fixe, avoirs dans leur propre série, définissez-le depuis le back-office ou avec un module qui comble les limites natives, puis n’y touchez plus. Bien faite, elle fait discrètement son travail à chaque audit, appel au service client et clôture annuelle, aussi longtemps que la boutique fonctionne.