Chaque projet d'intégration finit par la même réunion : la vente, la finance et la DSI veulent tous la facture « chez eux ». Voici, sans jargon, pourquoi la réponse est presque toujours l'ERP, quand elle ne l'est pas, et ce que cela change avec Odoo.
Trois métiers, une facture, trois « chez moi »
Avant de parler d'outils, écoutons la réunion. Chacun a de bonnes raisons — c'est bien le problème.
Tout le monde a raison. Le vrai problème est ailleurs : « facturer » n'est pas un verbe. C'en est cinq.
« Facturer », c'est en réalité cinq métiers
Pensez à un restaurant. Le serveur calcule l'addition, la caisse imprime le ticket numéroté, le comptable l'enregistre, quelqu'un encaisse, et à la fin du mois on sait ce qu'on a vraiment gagné. Le serveur peut calculer. Personne ne le laisse imprimer ses propres tickets à la main.
Calculer
Émettre
Comptabiliser
Encaisser
Rattacher le revenu
À retenir : le calcul peut vivre ailleurs. La comptabilité et l'encaissement finissent toujours dans le grand livre. L'émission, elle, engage juridiquement l'entreprise — c'est elle qu'il faut placer avec soin. Tout le débat « CRM ou ERP » ne porte en fait que sur cette case.
Le voyage d'une facture (vu par l'auditeur)
Un commissaire aux comptes n'audite pas un logiciel. Il audite une chaîne, avec un contrôle à chaque maillon. Faites défiler : la facture n° 0042 fait le trajet.
Chaque logiciel supplémentaire sur ce chemin ajoute une interface, donc un contrôle à documenter, donc une documentation à tenir à jour. Spoiler : elle ne l'est jamais. Le nombre de systèmes qui émettent des factures est le premier facteur de coût de votre audit.
2026-2027 : le PDF envoyé par mail prend sa retraite
Entre professionnels français, la facture doit désormais passer par une plateforme agréée (PA), dans un format structuré (Factur-X, UBL ou CII). Le PDF par mail devient un joli souvenir — et une non-conformité, sanctionnée jusqu'à 15 € par facture, plafonnée à 15 000 € par an.
Conséquence directe pour notre question : le système qui émet doit être une plateforme agréée, ou y être branché. Un système émetteur de plus, c'est un branchement de plus à payer, tester et maintenir. Et la PA renvoie des statuts (déposée, rejetée, refusée par le client) qui doivent remonter là où l'on suit l'encours — sinon la vente relance des clients pour une facture qu'ils ont refusée il y a trois semaines.
Les trois candidats au concours
Personne n'est nul. Chacun a simplement été conçu pour une des cinq fonctions — et une seule est réellement en jeu.
Le CRM
- Connaître le client, l'opportunité, le devis
- Calculer une remise, déclencher une commission
- Donner une vue à 360° au commercial
- Pas de grand livre, pas de clôture, pas de FEC
- Une seule date là où une facture en a quatre
- La taxe par facture, alors que la loi veut par ligne
- Un historique qu'un admin peut purger (10 ans de conservation, bonjour)
L'application dédiée
- Tarifer des millions d'événements (API, minutes, Go)
- Abonnements, prorata, changements en cours de mois
- Portail de paiement, relances automatiques
- Pas de comptabilité générale ni de TVA multi-pays
- Conformité PA à vérifier éditeur par éditeur
- Frais de paiement et remboursements rarement comptabilisés proprement
- Un troisième référentiel client et prix (un référentiel à trois maîtres n'a plus de maître)
L'ERP
- Numérotation par journal, verrouillage, avoirs
- TVA juste — y compris celle qui dépend des paiements
- Lettrage, relances, limites de crédit, FEC
- Séparation des tâches et transmission à la PA
- La tarification à l'usage à très grande échelle
- L'expérience « self-service » ultra-léchée
- Les gros runs mensuels, s'il est mal dimensionné
Si vous vendez des prestations, votre TVA est due au moment où le client paie, pas au moment où vous facturez. Le système qui voit les paiements doit donc calculer la TVA. Un CRM qui émet sans voir les paiements produit une déclaration de TVA fausse — avec le sourire.
L'arbre de décision en quatre questions
Dix-huit critères tiennent en un chemin simple. Répondez dans l'ordre.
Deux critères sont éliminatoires, quel que soit le score : un candidat qui n'est pas branché à une plateforme agréée, et un candidat qui ne sait pas gérer plusieurs dates (émission, livraison, comptable, TVA) ni interdire l'antidatage. Tout le reste se négocie par intégration.
Ce que la vente veut vraiment (et comment le lui donner sans lui donner les clés)
Quand on creuse, la demande de la vente passe de « la facture doit se faire dans le CRM » à « la facture doit être visible et déclenchable depuis le CRM, et porter nos références ». Trois besoins, trois réponses par intégration.
La vente veut une fenêtre sur la facture, pas le tampon. L'intégration donne la fenêtre.
Six erreurs vues sur le terrain
Toutes réelles, toutes évitables, toutes découvertes au pire moment (la clôture ou le contrôle).
Le CRM émet, l'ERP encaisse, les paiements ne remontent pas. La vente relance des clients qui ont payé.
Faire remonter les paiements — ou, mieux, émettre dans l'ERP.
Un outil numérote INV-2026-0001, l'autre FAC/2026/0001, pour la même société. Personne ne l'a écrit nulle part.
Documenter les séries, ou n'en avoir qu'une.
Le commercial « corrige » une facture déjà envoyée. La séquence est rompue, la TVA déclarée ne colle plus.
Verrouillage après validation. Une erreur se corrige par un avoir, jamais par une gomme.
Pour « rentrer dans le mois », une facture est datée du 30 alors que la numérotation est déjà au 3 du mois suivant.
Contrôle date / séquence par journal, dates de verrouillage posées à chaque clôture.
Un outil envoie un PDF par mail à un client professionnel français après la date d'obligation. Juridiquement, ce n'est plus une facture.
Brancher le système émetteur à une plateforme agréée. Ou émettre depuis un système qui en est une.
Pour « aller vite », les commerciaux peuvent créer, valider et annuler leurs factures et avoirs. L'auditeur appelle ça un défaut de contrôle interne majeur.
Une matrice de droits : qui crée, qui valide, qui émet un avoir. Revue chaque trimestre.
Et avec Odoo ?
Odoo a une particularité qui simplifie tout : c'est un CRM, un ERP et, depuis 2026, une plateforme agréée — dans une seule base de données. Le CRM d'Odoo ne facture pas : il alimente le devis, qui devient commande, qui devient facture dans la comptabilité. Le débat « CRM contre ERP » disparaît par construction.
Odoo est immatriculé plateforme agréée par la DGFiP depuis avril 2026, le module est en production depuis juin, sans surcoût et sans prestataire tiers. L'argument historique « notre outil de facturation est branché à une PA, pas l'ERP » tombe donc : dans Odoo, l'ERP est la PA.
Reste-t-il des cas où la facture sort d'Odoo ? Deux, honnêtement. La tarification à l'usage à grande échelle : l'outil externe calcule et pousse des lignes à facturer dans Odoo (motif E), Odoo émet, comptabilise, transmet et recouvre. Et l'application métier qui doit émettre elle-même (au comptoir, avec paiement carte immédiat) : elle déverse alors dans un journal Odoo dédié, réconcilié chaque jour (motif C).
Renseigner le SIREN de vos clients (sans lui, la facture électronique ne part pas), poser les positions fiscales, décider que le commercial n'a pas le droit de valider un avoir, et fermer les périodes à chaque clôture. L'outil est prêt ; la discipline, c'est vous.
À retenir en cinq phrases
- 1La facture est un acte juridique et fiscal avant d'être un document commercial.
- 2« Facturer » = calculer, émettre, comptabiliser, encaisser, rattacher le revenu. Seule l'émission fait débat.
- 3Par défaut, l'émission appartient à l'ERP. Depuis 2026, l'ERP doit aussi être — ou être branché à — une plateforme agréée.
- 4Ce que la vente réclame (voir, déclencher, ses références) s'obtient par intégration, pas en déplaçant la facture.
- 5Dans Odoo, la réponse est presque toujours « la facturation se fait dans Odoo ». Les exceptions calculent ailleurs ; elles ne comptabilisent jamais ailleurs.
Cet article ne constitue ni un avis juridique ni un avis comptable : confrontez-le à votre expert-comptable. Le calendrier et les sanctions cités sont ceux de la réforme française de la facturation électronique ; vérifiez leur version applicable sur Légifrance et le BOFiP.
Every integration project ends with the same meeting: Sales, Finance and IT all want the invoice to live "with them". Here is, jargon-free, why the answer is almost always the ERP, when it isn't, and what changes with Odoo.
Three teams, one invoice, three "it belongs to us"
Before talking tools, let's listen in on the meeting. Everyone has good reasons — that's precisely the problem.
Everyone is right. The real problem lies elsewhere: "invoicing" isn't one verb. It's five.
"Invoicing" is actually five jobs
Think of a restaurant. The waiter works out the bill, the till prints the numbered receipt, the bookkeeper records it, someone takes the money, and at month-end you know what you actually earned. The waiter can do the maths. Nobody lets him print his own receipts by hand.
Calculate
Issue
Book
Collect
Recognise revenue
Key point: calculation can live elsewhere. Booking and collection always end up in the general ledger. Issuing, however, legally binds the company — that's the one to place with care. The whole "CRM or ERP" debate is really about this single box.
An invoice's journey (as the auditor sees it)
A statutory auditor doesn't audit software. They audit a chain, with a control at every link. Scroll on: invoice no. 0042 makes the trip.
Every extra piece of software on this path adds an interface, hence a control to document, hence documentation to keep up to date. Spoiler: it never is. The number of systems issuing invoices is the first cost driver of your audit.
2026-2027: the emailed PDF retires
Between French businesses, invoices must now travel through an accredited platform (PA), in a structured format (Factur-X, UBL or CII). The emailed PDF becomes a fond memory — and a compliance breach, fined up to €15 per invoice, capped at €15,000 per year.
Direct consequence for our question: the system that issues must be an accredited platform, or be connected to one. One more issuing system means one more connection to pay for, test and maintain. And the PA sends back statuses (filed, rejected, refused by the customer) that must reach wherever receivables are tracked — otherwise Sales chases customers about an invoice they refused three weeks ago.
The three contestants
Nobody is bad at this. Each was simply designed for one of the five jobs — and only one is really at stake.
The CRM
- Knowing the customer, the opportunity, the quote
- Working out a discount, triggering a commission
- Giving the salesperson a 360° view
- No general ledger, no period close, no statutory audit file
- One date where an invoice has four
- Tax per invoice, where the law wants it per line
- A history any admin can purge (10 years of retention, hello)
The dedicated app
- Pricing millions of events (API calls, minutes, GB)
- Subscriptions, proration, mid-month changes
- Payment portal, automated dunning
- No general accounting, no multi-country VAT
- PA compliance to check vendor by vendor
- Payment fees and refunds rarely booked properly
- A third customer and price master (data with three masters has none)
The ERP
- Numbering per journal, locking, credit notes
- Correct VAT — including the kind that depends on payments
- Reconciliation, dunning, credit limits, audit file
- Segregation of duties and transmission to the PA
- Usage-based pricing at very large scale
- The ultra-polished self-service experience
- Big monthly billing runs, if undersized
If you sell services, in France your VAT is due when the customer pays, not when you invoice. So the system that sees payments must compute VAT. A CRM that issues without seeing payments produces a wrong VAT return — with a smile.
The decision tree in four questions
Eighteen criteria boil down to one simple path. Answer in order.
Two criteria are knock-outs, whatever the score: a contestant not connected to an accredited platform, and a contestant that cannot handle multiple dates (issue, delivery, accounting, VAT) or prevent backdating. Everything else is negotiated through integration.
What Sales really wants (and how to give it without handing over the keys)
Dig a little and the request from Sales shifts from "the invoice must be made in the CRM" to "the invoice must be visible and triggerable from the CRM, and carry our references". Three needs, three answers through integration.
Sales wants a window onto the invoice, not the rubber stamp. Integration provides the window.
Six mistakes seen in the field
All real, all avoidable, all discovered at the worst possible time (period close or a tax audit).
The CRM issues, the ERP collects, payments never flow back. Sales chases customers who have already paid.
Sync payments back — or, better, issue in the ERP.
One tool numbers INV-2026-0001, the other FAC/2026/0001, for the same legal entity. Nobody wrote it down anywhere.
Document the sequences, or have only one.
The salesperson "fixes" an invoice already sent. The sequence is broken and the VAT declared no longer matches.
Lock after validation. A mistake is fixed with a credit note, never an eraser.
To "make the month", an invoice is dated the 30th while the sequence is already on the 3rd of the next month.
Date / sequence check per journal, lock dates set at every close.
A tool emails a PDF to a French business customer after the deadline. Legally, it is no longer an invoice.
Connect the issuing system to an accredited platform. Or issue from a system that is one.
To "move fast", salespeople can create, validate and cancel their own invoices and credit notes. Auditors call that a major internal-control failure.
A rights matrix: who creates, who validates, who issues credit notes. Reviewed every quarter.
And with Odoo?
Odoo has one feature that simplifies everything: it is a CRM, an ERP and, since 2026, an accredited platform — in a single database. Odoo's CRM does not invoice: it feeds the quote, which becomes an order, which becomes an invoice in Accounting. The "CRM versus ERP" debate disappears by construction.
Odoo has been registered as an accredited platform by the French tax authority (DGFiP) since April 2026; the module has been in production since June, at no extra cost and with no third-party provider. The old argument "our billing tool is connected to a PA, the ERP isn't" therefore collapses: in Odoo, the ERP is the PA.
Are there still cases where invoicing leaves Odoo? Two, honestly. Usage-based pricing at large scale: the external tool calculates and pushes lines to invoice into Odoo (pattern E); Odoo issues, books, transmits and collects. And the industry-specific app that must issue itself (at the counter, with immediate card payment): it then feeds a dedicated Odoo journal, reconciled daily (pattern C).
Fill in your customers' company IDs (without them, the e-invoice doesn't leave), set fiscal positions, decide that salespeople may not validate credit notes, and lock periods at every close. The tool is ready; the discipline is yours.
Five sentences to remember
- 1An invoice is a legal and tax document before it is a commercial one.
- 2"Invoicing" = calculate, issue, book, collect, recognise revenue. Only issuing is up for debate.
- 3By default, issuing belongs to the ERP. Since 2026, the ERP must also be — or be connected to — an accredited platform.
- 4What Sales asks for (see, trigger, their references) is achieved through integration, not by moving the invoice.
- 5In Odoo, the answer is almost always "invoicing happens in Odoo". The exceptions calculate elsewhere; they never book elsewhere.
This article is neither legal nor accounting advice: check it with your chartered accountant. The timeline and penalties quoted are those of the French e-invoicing reform; verify the applicable version on Légifrance and the BOFiP.
Chaque projet d'intégration finit par la même réunion : la vente, la finance et la DSI veulent tous la facture « chez eux ». Voici, sans jargon, pourquoi la réponse est presque toujours l'ERP, quand elle ne l'est pas, et ce que cela change avec Odoo.
Trois métiers, une facture, trois « chez moi »
Avant de parler d'outils, écoutons la réunion. Chacun a de bonnes raisons — c'est bien le problème.
Tout le monde a raison. Le vrai problème est ailleurs : « facturer » n'est pas un verbe. C'en est cinq.
« Facturer », c'est en réalité cinq métiers
Pensez à un restaurant. Le serveur calcule l'addition, la caisse imprime le ticket numéroté, le comptable l'enregistre, quelqu'un encaisse, et à la fin du mois on sait ce qu'on a vraiment gagné. Le serveur peut calculer. Personne ne le laisse imprimer ses propres tickets à la main.
Calculer
Émettre
Comptabiliser
Encaisser
Rattacher le revenu
À retenir : le calcul peut vivre ailleurs. La comptabilité et l'encaissement finissent toujours dans le grand livre. L'émission, elle, engage juridiquement l'entreprise — c'est elle qu'il faut placer avec soin. Tout le débat « CRM ou ERP » ne porte en fait que sur cette case.
Le voyage d'une facture (vu par l'auditeur)
Un commissaire aux comptes n'audite pas un logiciel. Il audite une chaîne, avec un contrôle à chaque maillon. Faites défiler : la facture n° 0042 fait le trajet.
Chaque logiciel supplémentaire sur ce chemin ajoute une interface, donc un contrôle à documenter, donc une documentation à tenir à jour. Spoiler : elle ne l'est jamais. Le nombre de systèmes qui émettent des factures est le premier facteur de coût de votre audit.
2026-2027 : le PDF envoyé par mail prend sa retraite
Entre professionnels français, la facture doit désormais passer par une plateforme agréée (PA), dans un format structuré (Factur-X, UBL ou CII). Le PDF par mail devient un joli souvenir — et une non-conformité, sanctionnée jusqu'à 15 € par facture, plafonnée à 15 000 € par an.
Conséquence directe pour notre question : le système qui émet doit être une plateforme agréée, ou y être branché. Un système émetteur de plus, c'est un branchement de plus à payer, tester et maintenir. Et la PA renvoie des statuts (déposée, rejetée, refusée par le client) qui doivent remonter là où l'on suit l'encours — sinon la vente relance des clients pour une facture qu'ils ont refusée il y a trois semaines.
Les trois candidats au concours
Personne n'est nul. Chacun a simplement été conçu pour une des cinq fonctions — et une seule est réellement en jeu.
Le CRM
- Connaître le client, l'opportunité, le devis
- Calculer une remise, déclencher une commission
- Donner une vue à 360° au commercial
- Pas de grand livre, pas de clôture, pas de FEC
- Une seule date là où une facture en a quatre
- La taxe par facture, alors que la loi veut par ligne
- Un historique qu'un admin peut purger (10 ans de conservation, bonjour)
L'application dédiée
- Tarifer des millions d'événements (API, minutes, Go)
- Abonnements, prorata, changements en cours de mois
- Portail de paiement, relances automatiques
- Pas de comptabilité générale ni de TVA multi-pays
- Conformité PA à vérifier éditeur par éditeur
- Frais de paiement et remboursements rarement comptabilisés proprement
- Un troisième référentiel client et prix (un référentiel à trois maîtres n'a plus de maître)
L'ERP
- Numérotation par journal, verrouillage, avoirs
- TVA juste — y compris celle qui dépend des paiements
- Lettrage, relances, limites de crédit, FEC
- Séparation des tâches et transmission à la PA
- La tarification à l'usage à très grande échelle
- L'expérience « self-service » ultra-léchée
- Les gros runs mensuels, s'il est mal dimensionné
Si vous vendez des prestations, votre TVA est due au moment où le client paie, pas au moment où vous facturez. Le système qui voit les paiements doit donc calculer la TVA. Un CRM qui émet sans voir les paiements produit une déclaration de TVA fausse — avec le sourire.
L'arbre de décision en quatre questions
Dix-huit critères tiennent en un chemin simple. Répondez dans l'ordre.
Deux critères sont éliminatoires, quel que soit le score : un candidat qui n'est pas branché à une plateforme agréée, et un candidat qui ne sait pas gérer plusieurs dates (émission, livraison, comptable, TVA) ni interdire l'antidatage. Tout le reste se négocie par intégration.
Ce que la vente veut vraiment (et comment le lui donner sans lui donner les clés)
Quand on creuse, la demande de la vente passe de « la facture doit se faire dans le CRM » à « la facture doit être visible et déclenchable depuis le CRM, et porter nos références ». Trois besoins, trois réponses par intégration.
La vente veut une fenêtre sur la facture, pas le tampon. L'intégration donne la fenêtre.
Six erreurs vues sur le terrain
Toutes réelles, toutes évitables, toutes découvertes au pire moment (la clôture ou le contrôle).
Le CRM émet, l'ERP encaisse, les paiements ne remontent pas. La vente relance des clients qui ont payé.
Faire remonter les paiements — ou, mieux, émettre dans l'ERP.
Un outil numérote INV-2026-0001, l'autre FAC/2026/0001, pour la même société. Personne ne l'a écrit nulle part.
Documenter les séries, ou n'en avoir qu'une.
Le commercial « corrige » une facture déjà envoyée. La séquence est rompue, la TVA déclarée ne colle plus.
Verrouillage après validation. Une erreur se corrige par un avoir, jamais par une gomme.
Pour « rentrer dans le mois », une facture est datée du 30 alors que la numérotation est déjà au 3 du mois suivant.
Contrôle date / séquence par journal, dates de verrouillage posées à chaque clôture.
Un outil envoie un PDF par mail à un client professionnel français après la date d'obligation. Juridiquement, ce n'est plus une facture.
Brancher le système émetteur à une plateforme agréée. Ou émettre depuis un système qui en est une.
Pour « aller vite », les commerciaux peuvent créer, valider et annuler leurs factures et avoirs. L'auditeur appelle ça un défaut de contrôle interne majeur.
Une matrice de droits : qui crée, qui valide, qui émet un avoir. Revue chaque trimestre.
Et avec Odoo ?
Odoo a une particularité qui simplifie tout : c'est un CRM, un ERP et, depuis 2026, une plateforme agréée — dans une seule base de données. Le CRM d'Odoo ne facture pas : il alimente le devis, qui devient commande, qui devient facture dans la comptabilité. Le débat « CRM contre ERP » disparaît par construction.
Odoo est immatriculé plateforme agréée par la DGFiP depuis avril 2026, le module est en production depuis juin, sans surcoût et sans prestataire tiers. L'argument historique « notre outil de facturation est branché à une PA, pas l'ERP » tombe donc : dans Odoo, l'ERP est la PA.
Reste-t-il des cas où la facture sort d'Odoo ? Deux, honnêtement. La tarification à l'usage à grande échelle : l'outil externe calcule et pousse des lignes à facturer dans Odoo (motif E), Odoo émet, comptabilise, transmet et recouvre. Et l'application métier qui doit émettre elle-même (au comptoir, avec paiement carte immédiat) : elle déverse alors dans un journal Odoo dédié, réconcilié chaque jour (motif C).
Renseigner le SIREN de vos clients (sans lui, la facture électronique ne part pas), poser les positions fiscales, décider que le commercial n'a pas le droit de valider un avoir, et fermer les périodes à chaque clôture. L'outil est prêt ; la discipline, c'est vous.
À retenir en cinq phrases
- 1La facture est un acte juridique et fiscal avant d'être un document commercial.
- 2« Facturer » = calculer, émettre, comptabiliser, encaisser, rattacher le revenu. Seule l'émission fait débat.
- 3Par défaut, l'émission appartient à l'ERP. Depuis 2026, l'ERP doit aussi être — ou être branché à — une plateforme agréée.
- 4Ce que la vente réclame (voir, déclencher, ses références) s'obtient par intégration, pas en déplaçant la facture.
- 5Dans Odoo, la réponse est presque toujours « la facturation se fait dans Odoo ». Les exceptions calculent ailleurs ; elles ne comptabilisent jamais ailleurs.
Cet article ne constitue ni un avis juridique ni un avis comptable : confrontez-le à votre expert-comptable. Le calendrier et les sanctions cités sont ceux de la réforme française de la facturation électronique ; vérifiez leur version applicable sur Légifrance et le BOFiP.
Every integration project ends with the same meeting: Sales, Finance and IT all want the invoice to live "with them". Here is, jargon-free, why the answer is almost always the ERP, when it isn't, and what changes with Odoo.
Three teams, one invoice, three "it belongs to us"
Before talking tools, let's listen in on the meeting. Everyone has good reasons — that's precisely the problem.
Everyone is right. The real problem lies elsewhere: "invoicing" isn't one verb. It's five.
"Invoicing" is actually five jobs
Think of a restaurant. The waiter works out the bill, the till prints the numbered receipt, the bookkeeper records it, someone takes the money, and at month-end you know what you actually earned. The waiter can do the maths. Nobody lets him print his own receipts by hand.
Calculate
Issue
Book
Collect
Recognise revenue
Key point: calculation can live elsewhere. Booking and collection always end up in the general ledger. Issuing, however, legally binds the company — that's the one to place with care. The whole "CRM or ERP" debate is really about this single box.
An invoice's journey (as the auditor sees it)
A statutory auditor doesn't audit software. They audit a chain, with a control at every link. Scroll on: invoice no. 0042 makes the trip.
Every extra piece of software on this path adds an interface, hence a control to document, hence documentation to keep up to date. Spoiler: it never is. The number of systems issuing invoices is the first cost driver of your audit.
2026-2027: the emailed PDF retires
Between French businesses, invoices must now travel through an accredited platform (PA), in a structured format (Factur-X, UBL or CII). The emailed PDF becomes a fond memory — and a compliance breach, fined up to €15 per invoice, capped at €15,000 per year.
Direct consequence for our question: the system that issues must be an accredited platform, or be connected to one. One more issuing system means one more connection to pay for, test and maintain. And the PA sends back statuses (filed, rejected, refused by the customer) that must reach wherever receivables are tracked — otherwise Sales chases customers about an invoice they refused three weeks ago.
The three contestants
Nobody is bad at this. Each was simply designed for one of the five jobs — and only one is really at stake.
The CRM
- Knowing the customer, the opportunity, the quote
- Working out a discount, triggering a commission
- Giving the salesperson a 360° view
- No general ledger, no period close, no statutory audit file
- One date where an invoice has four
- Tax per invoice, where the law wants it per line
- A history any admin can purge (10 years of retention, hello)
The dedicated app
- Pricing millions of events (API calls, minutes, GB)
- Subscriptions, proration, mid-month changes
- Payment portal, automated dunning
- No general accounting, no multi-country VAT
- PA compliance to check vendor by vendor
- Payment fees and refunds rarely booked properly
- A third customer and price master (data with three masters has none)
The ERP
- Numbering per journal, locking, credit notes
- Correct VAT — including the kind that depends on payments
- Reconciliation, dunning, credit limits, audit file
- Segregation of duties and transmission to the PA
- Usage-based pricing at very large scale
- The ultra-polished self-service experience
- Big monthly billing runs, if undersized
If you sell services, in France your VAT is due when the customer pays, not when you invoice. So the system that sees payments must compute VAT. A CRM that issues without seeing payments produces a wrong VAT return — with a smile.
The decision tree in four questions
Eighteen criteria boil down to one simple path. Answer in order.
Two criteria are knock-outs, whatever the score: a contestant not connected to an accredited platform, and a contestant that cannot handle multiple dates (issue, delivery, accounting, VAT) or prevent backdating. Everything else is negotiated through integration.
What Sales really wants (and how to give it without handing over the keys)
Dig a little and the request from Sales shifts from "the invoice must be made in the CRM" to "the invoice must be visible and triggerable from the CRM, and carry our references". Three needs, three answers through integration.
Sales wants a window onto the invoice, not the rubber stamp. Integration provides the window.
Six mistakes seen in the field
All real, all avoidable, all discovered at the worst possible time (period close or a tax audit).
The CRM issues, the ERP collects, payments never flow back. Sales chases customers who have already paid.
Sync payments back — or, better, issue in the ERP.
One tool numbers INV-2026-0001, the other FAC/2026/0001, for the same legal entity. Nobody wrote it down anywhere.
Document the sequences, or have only one.
The salesperson "fixes" an invoice already sent. The sequence is broken and the VAT declared no longer matches.
Lock after validation. A mistake is fixed with a credit note, never an eraser.
To "make the month", an invoice is dated the 30th while the sequence is already on the 3rd of the next month.
Date / sequence check per journal, lock dates set at every close.
A tool emails a PDF to a French business customer after the deadline. Legally, it is no longer an invoice.
Connect the issuing system to an accredited platform. Or issue from a system that is one.
To "move fast", salespeople can create, validate and cancel their own invoices and credit notes. Auditors call that a major internal-control failure.
A rights matrix: who creates, who validates, who issues credit notes. Reviewed every quarter.
And with Odoo?
Odoo has one feature that simplifies everything: it is a CRM, an ERP and, since 2026, an accredited platform — in a single database. Odoo's CRM does not invoice: it feeds the quote, which becomes an order, which becomes an invoice in Accounting. The "CRM versus ERP" debate disappears by construction.
Odoo has been registered as an accredited platform by the French tax authority (DGFiP) since April 2026; the module has been in production since June, at no extra cost and with no third-party provider. The old argument "our billing tool is connected to a PA, the ERP isn't" therefore collapses: in Odoo, the ERP is the PA.
Are there still cases where invoicing leaves Odoo? Two, honestly. Usage-based pricing at large scale: the external tool calculates and pushes lines to invoice into Odoo (pattern E); Odoo issues, books, transmits and collects. And the industry-specific app that must issue itself (at the counter, with immediate card payment): it then feeds a dedicated Odoo journal, reconciled daily (pattern C).
Fill in your customers' company IDs (without them, the e-invoice doesn't leave), set fiscal positions, decide that salespeople may not validate credit notes, and lock periods at every close. The tool is ready; the discipline is yours.
Five sentences to remember
- 1An invoice is a legal and tax document before it is a commercial one.
- 2"Invoicing" = calculate, issue, book, collect, recognise revenue. Only issuing is up for debate.
- 3By default, issuing belongs to the ERP. Since 2026, the ERP must also be — or be connected to — an accredited platform.
- 4What Sales asks for (see, trigger, their references) is achieved through integration, not by moving the invoice.
- 5In Odoo, the answer is almost always "invoicing happens in Odoo". The exceptions calculate elsewhere; they never book elsewhere.
This article is neither legal nor accounting advice: check it with your chartered accountant. The timeline and penalties quoted are those of the French e-invoicing reform; verify the applicable version on Légifrance and the BOFiP.