Entre une commande signée et une facture encaissée, il y a tout ce qui fait la trésorerie d'une PME : un acompte, un échéancier, une retenue le temps d'un litige, une commande qu'il faut solder parce qu'elle ne sera jamais facturée.
Odoo facture la commande, ou les quantités livrées. Dix-huit modules communautaires couvrent tout ce qui se passe entre les deux.
Résumé
sale_invoice_plan définit sur la commande un plan de facturation : acompte optionnel, puis des échéances portant chacune une date et un pourcentage du total, à générer échéance par échéance. sale_invoice_plan_report imprime ce plan sur le devis — ce qui en fait un argument commercial et non un réglage interne. sale_advance_payment encaisse un acompte avant toute facture, le suit sur la commande et le rapproche automatiquement à la validation de la facture.
Trois modules retiennent la facturation : sale_invoice_blocking bloque avec un motif choisi dans une table dédiée, sale_order_invoicing_finished_task subordonne la facturation d'une prestation au fait que la tâche soit marquée facturable, et sale_invoice_product_not_alone interdit qu'un produit — des frais annexes, une option — soit facturé seul.
Deux modules forcent : sale_force_invoiced passe une commande en « facturée » sans l'avoir été, sale_force_invoiced_quantity fait de même ligne à ligne. Le reste rend visible ce qui manque — montant déjà facturé, montant à facturer, politique de facturation au niveau de la commande, facturation par bon de livraison choisi, conditions de paiement héritées de l'adresse de facturation ou de l'équipe commerciale.
L'essentiel
- Un échéancier sur la commande : acompte plus échéances datées en pourcentage, imprimable sur le devis.
- L'acompte encaissé avant la facture, suivi sur la commande et rapproché automatiquement ensuite.
- Le blocage de facturation avec motif — litige, accord en attente — sans toucher aux lignes ni annuler la commande.
- Le forçage du statut facturé, commande entière ou quantité par ligne : la reprise de données et le litige partiel ont enfin une sortie propre.
- La facturation par bon de livraison choisi, quand plusieurs livraisons partielles ne doivent pas être facturées ensemble.
- Montant facturé et montant à facturer affichés : deux champs qui existent dans Odoo 18 mais restent masqués.
- Un commercial qui encaisse sans droits comptables, via une feuille de paiement qui produit un relevé bancaire.
Ce que ces modules ajoutent à l'instance
| Module | Rôle | Version |
|---|---|---|
sale_invoice_plan | Plan de facturation : acompte et échéances | 18.0.1.0.0 |
sale_invoice_plan_report | Le plan imprimé sur le devis | 18.0.1.0.0 |
sale_advance_payment | Acompte encaissé avant facture | 18.0.1.0.3 |
sale_invoice_frequency | Fréquence de facturation par client | 18.0.1.1.0 |
sale_invoice_policy | Politique de facturation au niveau de la commande | 18.0.1.1.1 |
sale_invoice_blocking | Blocage motivé de la facturation | 18.0.1.0.0 |
sale_invoice_product_not_alone | Interdire de facturer un produit seul | 18.0.1.0.0 |
sale_order_invoicing_finished_task | Facturer seulement les tâches facturables | 18.0.1.0.1 |
sale_order_invoicing_picking_filter | Facturer les livraisons choisies | 18.0.1.0.0 |
sale_force_invoiced | Forcer le statut « facturée » | 18.0.1.0.1 |
sale_force_invoiced_quantity | Forcer une quantité facturée par ligne | 18.0.1.0.0 |
sale_invoice_split_payment | Ne pas regrouper des conditions de paiement différentes | 18.0.1.0.0 |
sale_order_amount_to_invoice | Montant à facturer au niveau de la commande | 18.0.1.0.0 |
sale_order_invoice_amount | Montant facturé et restant, affichés | 18.0.1.0.0 |
sale_payment_sheet | Feuille de paiement pour les commerciaux | 18.0.1.0.1 |
sale_order_payment_terms_from_invoice_address | Conditions de paiement de l'adresse de facturation | 18.0.1.0.0 |
sale_team_payment_term | Conditions de paiement par équipe commerciale | 18.0.1.0.0 |
sale_invoice_delivery_state | État de livraison sur la facture | 18.0.1.0.0 |
Quatre ajoutent un menu : le plan de facturation (Ventes ▸ Commandes ▸ Utiliser un plan de facturation), les fréquences (Ventes ▸ Configuration ▸ Fréquence de facturation), les motifs de blocage (Ventes ▸ Configuration ▸ Commandes clients ▸ Motifs de blocage de la facturation) et la feuille de paiement (Ventes ▸ Commandes ▸ Payments).
Échelonner : le plan de facturation
Vendre un projet de 60 000 € payable 30 % à la commande, 40 % à mi-parcours et 30 % à la livraison est la norme dans le bâtiment, l'industrie sur mesure et le conseil. Odoo ne sait pas l'écrire.
- Sur la commande, ouvrir Utiliser un plan de facturation.
- Définir un acompte optionnel, puis les échéances : chacune porte une date et un pourcentage du montant total.
- Générer les factures échéance par échéance, au fil de l'avancement.
- Avec
sale_invoice_plan_report, le plan apparaît automatiquement sur le PDF du devis.
Le module complémentaire d'impression vaut autant que le module principal. Un échéancier que le client lit sur son devis est un engagement partagé ; un échéancier qui ne vit que dans l'ERP est une intention interne — et le premier appel de fonds surprend tout le monde.
Deux modules voisins complètent la cadence de facturation : sale_invoice_frequency définit une fréquence — quotidienne, hebdomadaire, mensuelle — par client, propagée aux commandes, pour regrouper ce qui doit l'être ; sale_invoice_policy permet de choisir la politique de facturation — sur les quantités commandées ou livrées — au niveau de la commande entière, au lieu de subir celle définie produit par produit.
Pour la facturation récurrente proprement dite — abonnements, contrats reconduits —, c'est une autre famille de modules : voir contrats récurrents et abonnements.
Encaisser avant la facture, et sans les droits comptables
L'acompte
sale_advance_payment enregistre un acompte directement depuis la commande, avant toute facture. Le montant résiduel et le statut de paiement se suivent sur la commande, et l'acompte est rapproché automatiquement avec la facture à sa validation.
C'est la réponse au cas le plus banal du commerce : le client paie pour déclencher la production, et la facture ne viendra que des semaines plus tard. Sans module, cet encaissement vit dans un compte d'attente que personne ne solde.
La feuille de paiement
sale_payment_sheetpermet à un commercial, sans droits comptables complets, d'enregistrer les paiements clients reçus — notamment en espèces — dans un document dédié. Une fois validée, la feuille génère un relevé bancaire reprenant ces encaissements.
Le compromis est bien construit : le commercial saisit ce qu'il a encaissé, la comptabilité valide et intègre. Personne n'a reçu de droits qu'il ne devrait pas avoir, et l'argent cesse de voyager dans une enveloppe jusqu'au bureau comptable.
Deux modules règlent enfin l'origine des conditions de paiement : sale_order_payment_terms_from_invoice_address les prend sur l'adresse de facturation plutôt que sur le client — ce qui compte pour les groupes dont la filiale commande et le siège paie — et sale_team_payment_term donne une condition par défaut par équipe commerciale, utilisée quand le client n'en a pas.
Retenir une facturation, proprement
Ne pas facturer est parfois la bonne décision. Encore faut-il que la raison soit écrite et que la commande ne soit pas dénaturée pour autant.
| Module | Ce qu'il bloque | Comment |
|---|---|---|
sale_invoice_blocking | Toute facturation depuis la commande | Avec un motif choisi dans une table de configuration |
sale_order_invoicing_finished_task | La facturation d'une prestation | Tant que la tâche n'est pas marquée facturable |
sale_invoice_product_not_alone | Un produit facturé isolément | Une case sur la fiche produit |
Le premier est le plus utile et le plus simple : un litige en cours, un accord commercial en attente, et la facture ne part pas — sans modifier les lignes, sans annuler la commande, avec un motif que tout le monde peut lire.
Le deuxième concerne les sociétés de services : du temps pointé sur une tâche n'est pas forcément du temps facturable. Lier la facturation à un marquage explicite évite la facture envoyée avant validation interne, qui coûte toujours plus cher à rattraper qu'à retarder.
Le troisième traite un détail qui fâche les clients : des frais de port ou une option facturés seuls, sur une facture qui ne contient rien d'autre. La case sur la fiche produit l'interdit.
Ces blocages rejoignent la mécanique des règles d'exception décrite dans ventes : types, workflows et blocages.
Forcer, choisir, et voir ce qui reste
Solder ce qui ne sera jamais facturé
sale_force_invoicedforce le statut d'une commande à « facturée », même si tout n'a pas été facturé. C'est la sortie propre d'un litige commercial, d'une reprise de données ou d'une migration qui laisse des commandes éternellement « en retard de facturation ».sale_force_invoiced_quantitydescend au niveau de la ligne : il force une quantité précise à déduire du restant à facturer, pour un écart partiel.
Ces deux modules sont indispensables après une migration. Sans eux, les commandes anciennes restent pour toujours dans les listes « à facturer », et l'indicateur qui devait piloter la facturation devient illisible — donc ignoré.
Choisir ce qu'on facture
sale_order_invoicing_picking_filter permet de générer une facture en choisissant précisément quels bons de livraison facturer, au lieu de facturer toutes les quantités livrées. Le cas : plusieurs livraisons partielles, dont certaines seulement doivent être facturées maintenant.
Il dépend du module qui relie transfert et facture — ce lien dont nous avons signalé ailleurs qu'il reste vide sans module de remplissage.
sale_invoice_split_payment empêche quant à lui le regroupement, dans une même facture, de commandes ayant des conditions de paiement différentes. C'est une sécurité : une facture regroupée ne peut pas porter deux échéanciers.
Voir les montants
| Module | Ce qu'il affiche |
|---|---|
sale_order_amount_to_invoice | Le montant à facturer agrégé au niveau de la commande, exploitable en liste |
sale_order_invoice_amount | Le montant déjà facturé et le restant, dans le récapitulatif de la commande |
Le second mérite une note : ces deux champs existent dans Odoo 18 sous forme de champs calculés, mais restent masqués par défaut. Le module se contente de les afficher. C'est le meilleur rapport entre la taille d'un module et son utilité quotidienne.
Limites connues
- Le plan de facturation sans son module d'impression reste un réglage interne : installer les deux.
- Le forçage du statut facturé est irréversible dans les faits : la commande sort des listes de travail. À réserver à un rôle identifié.
sale_order_invoicing_picking_filterdépend du lien transfert-facture, qui doit lui-même être alimenté par le module de remplissage correspondant.- La feuille de paiement crée un relevé bancaire : le circuit doit être validé avec la comptabilité avant d'être ouvert aux commerciaux.
- Les conditions de paiement ont trois origines possibles — client, adresse de facturation, équipe : en choisir une et s'y tenir, sinon personne ne sait d'où vient l'échéance.
sale_invoice_delivery_stateest peu documenté dans le relevé : son apport se vérifie sur le dépôt avant engagement.
Identité technique
Les dix-huit modules viennent du dépôt OCA sale-workflow, branche 18.0, en licence AGPL-3 sauf sale_order_invoice_amount (LGPL-3). Plusieurs dépendent de account et de sale_stock ; sale_order_invoicing_finished_task dépend de sale_timesheet et ne concerne donc que les activités de service.
Les familles voisines du même dépôt : la présentation des lignes, les dates et reliquats et les remises et tarifs.
Questions fréquentes
Odoo gère-t-il un échéancier de facturation ?
Pas en standard. sale_invoice_plan ajoute sur la commande un plan composé d'un acompte optionnel et d'échéances portant chacune une date et un pourcentage du total ; les factures se génèrent échéance par échéance. Installez aussi sale_invoice_plan_report, qui imprime le plan sur le devis — sans quoi le client ne connaît pas l'échéancier qu'il est censé accepter.
Comment encaisser un acompte avant d'émettre la facture ?
Avec sale_advance_payment : l'acompte s'enregistre directement depuis la commande, le montant résiduel et le statut de paiement se suivent sur celle-ci, et le rapprochement avec la facture se fait automatiquement à sa validation. Sans module, cet encaissement finit dans un compte d'attente que personne ne solde.
Comment empêcher de facturer une commande en litige ?
sale_invoice_blocking bloque la création de factures depuis la commande avec un motif choisi dans une table dédiée — sans modifier les lignes ni annuler la commande. Le motif est lisible par tous, ce qui évite la question « pourquoi celle-là n'est pas facturée ? » à chaque revue.
Que faire des vieilles commandes jamais facturées après une migration ?
Les forcer. sale_force_invoiced passe la commande entière en « facturée » sans facture correspondante ; sale_force_invoiced_quantity permet de ne forcer qu'une quantité par ligne pour un écart partiel. Sans cela, ces commandes restent éternellement dans les listes « à facturer » et rendent l'indicateur inutilisable.
Un commercial peut-il enregistrer un encaissement ?
Avec sale_payment_sheet, oui, sans droits comptables complets : il saisit les paiements reçus — en espèces notamment — dans une feuille de paiement qui, une fois validée, génère un relevé bancaire. La comptabilité garde la main sur l'intégration, le commercial cesse de transporter des enveloppes.
Se faire accompagner
La facturation des ventes est l'endroit où se joue la trésorerie, et où les contournements coûtent le plus : un acompte dans un compte d'attente, un litige géré par une commande annulée puis recréée, des commandes migrées qui polluent les listes pour toujours.
Nous traitons donc trois questions avant d'installer : qui a le droit de bloquer une facturation, qui a le droit de forcer un statut, et d'où viennent les conditions de paiement. Le paramétrage suit, et il tient. Voir les prestations d'Atalios Consulting ou demander un rappel.
Pour aller plus loin
- Contrats récurrents et abonnements
- Remises, prix et tarifs
- Ventes : types de commande, workflows et blocages
En résumé
Un échéancier imprimé sur le devis, un acompte encaissé avant la facture, un blocage motivé pendant le litige, un forçage pour solder ce qui ne sera jamais facturé, et deux montants qu'Odoo calcule sans les montrer. Tout ce qui se passe entre la commande signée et l'argent encaissé. Parlons de votre cycle de facturation.
