Du premier devis à l’encaissement.

De quoi on parle

Le Quote-to-Cash — littéralement « du devis à l’encaissement » — désigne la chaîne complète d’une vente. Elle commence quand un commercial compose une offre, et elle finit quand le paiement est encaissé et comptabilisé.

Entre les deux, il y a plus d’étapes qu’on ne croit : choisir les bons produits, calculer le bon prix, émettre un devis, le transformer en commande, en faire un contrat, produire des factures au bon rythme, appliquer la bonne TVA, relancer, et finalement enregistrer l’écriture comptable.

Dans beaucoup d’entreprises, ces étapes vivent dans des outils différents — un CRM pour la vente, un tableur pour les prix, un logiciel de compta pour les factures — et c’est précisément là que le temps et l’argent se perdent.

Les symptômes que ça règle

On reconnaît généralement le problème avant de connaître son nom. Voici les formulations qui reviennent le plus souvent :

• « Chaque commercial a son tableur de prix. » Deux devis pour la même configuration sortent à deux prix différents, et personne ne sait lequel fait foi.
• « On refait la saisie trois fois. » Une fois dans le CRM, une fois dans le tableur de devis, une fois dans la compta. Chaque ressaisie est une occasion d’erreur.
• « On ne sait pas ce qui est facturé. » Les abonnements existent dans la tête des gens et dans des fichiers, pas dans un système qui produit les factures tout seul.
• « La facturation prend trois jours par mois. » Un travail manuel, répétitif, et qui part en retard dès que quelqu’un est absent.
• « On découvre les avenants trop tard. » Un client ajoute des licences en mars, la facturation s’en aperçoit en juin.

Aucun de ces symptômes n’est un problème d’outil isolé. Ce sont les signes d’une chaîne qui n’est pas reliée d’un bout à l’autre.

Le parcours d’une vente, étape par étape

Voici la chaîne complète. Chaque étape produit quelque chose dont la suivante a besoin — et c’est pour ça qu’une rupture au milieu coûte si cher.

Ce qu’un CRM fait, et ce qu’il ne fait pas

Un CRM (gestion de la relation client) sait très bien répondre à : qui est ce client, qui lui a parlé, où en est l’affaire, combien elle vaut.

Il ne sait pas, nativement : composer une offre avec des options compatibles entre elles, appliquer une grille tarifaire avec des paliers, produire un échéancier de facturation sur trois ans, calculer la TVA selon le pays de facturation, ou générer l’écriture comptable correspondante.

C’est exactement ce que Revenue Cloud ajoute par-dessus : la partie « ce qu’on vend, à quel prix, et comment on le facture ». Salesforce l’a renommé Revenue Management, et vous croiserez encore les deux noms.

Par où commencer

On n’est pas obligé de tout prendre d’un coup, et vouloir tout faire en une fois est la façon la plus fiable de ne rien livrer. Trois périmètres de départ, du plus léger au plus lourd :

1. Le devis seulement. Catalogue, configuration des offres, calcul du prix, édition du devis. On arrête avant la commande, et la facturation reste là où elle est. C’est le périmètre qui règle « chaque commercial a son tableur ».
2. Jusqu’à la commande et au contrat. On ajoute ce qui engage : la commande, le contrat, et ce que le client détient réellement. C’est ce qui permet de gérer proprement les avenants et les renouvellements.
3. Jusqu’à la facture et au paiement. On ajoute les échéanciers, les factures, la TVA et le lien avec la comptabilité. C’est le périmètre le plus lourd, et celui qui libère le plus de temps.

Le découpage n’est pas qu’une affaire de budget : chaque étage suppose que le précédent soit propre. Un catalogue mal modélisé ne produit pas de bonnes factures, quelle que soit la qualité du paramétrage de facturation.

Les questions à régler avant de commencer

Ce sont celles dont les réponses décident de l’architecture. Si elles ne sont pas tranchées au démarrage, elles le seront par défaut, et rarement bien.

• Qui est facturé, et est-ce toujours celui qui achète ? La réponse décide du modèle de facturation, et de la façon dont la TVA sera calculée.
• Qu’est-ce qui se vend à l’unité, et qu’est-ce qui se vend par paliers ? Un prix fixe et un prix qui dépend d’un volume ne se paramètrent pas de la même manière, et confondre les deux alourdit tout le catalogue.
• Le client peut-il modifier son contrat en cours de route ? Si oui, il faut savoir dès le départ ce qu’il détient à chaque instant — c’est une contrainte structurante, pas une option qu’on ajoute après.
• Où s’arrête Salesforce, et où commence la comptabilité ? La frontière doit être tracée sur un type d’enregistrement, pas sur un champ, et validée par la finance.
• Qui maintiendra le catalogue dans deux ans ? Un modèle que seule la personne qui l’a construit sait modifier est un modèle qui se figera.

Passer à la vue technique

Vous avez le fonctionnement métier. La suite — les objets, le paramétrage, les pièges — est dans le parcours Configurer, écrit pour les administrateurs et les architectes.

Ouvrir le parcours Configurer →