La réforme française de la facturation électronique entre dans sa phase concrète pour les entreprises assujetties à la TVA. Pour beaucoup d'ETI, une question technique et organisationnelle émerge : comment faire dialoguer Salesforce — où vivent les devis, les contrats et les données de revenus — avec la Plateforme de Dématérialisation Partenaire (PDP) choisie ? Cet article aide à cadrer le sujet, sans promesse d'outil miracle, en distinguant ce qui relève du CRM, de l'ERP et de la PDP.

Ce que change la réforme, en résumé

La réforme instaure deux obligations distinctes : l'e-invoicing (échange de factures électroniques entre assujettis en France) et l'e-reporting (transmission à l'administration de données de transactions non couvertes par l'e-invoicing, notamment le B2C et l'international). Le calendrier officiel et les modalités sont publiés sur impots.gouv.fr et via la documentation de l'administration fiscale ; il est recommandé de vérifier les dates applicables à votre taille d'entreprise directement à la source, car elles ont déjà été ajustées.

Le point de bascule structurant : le Portail Public de Facturation (PPF) évolue vers un rôle d'annuaire et de concentrateur de données, tandis que la transmission des factures passe par des PDP immatriculées. Choisir sa PDP et organiser les flux devient donc un projet à part entière.

2
obligations distinctes : e-invoicing et e-reporting
4
statuts de cycle de vie de facture à gérer (émise, reçue, rejetée, encaissée...)
1
annuaire central pour le routage des factures

Où se situe Salesforce dans la chaîne ?

Salesforce n'est pas une plateforme de facturation fiscale, et il ne le devient pas avec la réforme. Sa place dépend de votre architecture existante. Trois configurations reviennent souvent chez les ETI :

  • Salesforce en amont : le CRM produit les devis (CPQ ou objets standards Opportunité/Devis), gère les contrats et les conditions commerciales. La donnée descend ensuite vers l'ERP, qui génère la facture.
  • Salesforce au cœur des revenus : avec Revenue Cloud (ex-CPQ & Billing), une partie de la logique de facturation et de reconnaissance du revenu vit dans Salesforce. Le lien avec la PDP devient alors plus direct.
  • Salesforce comme référentiel client : le CRM alimente les données tiers (SIREN, adresses, conditions de règlement) indispensables au routage et à la conformité des factures.

Dans tous les cas, la facture électronique légale sort d'un système capable de produire un format structuré conforme (Factur-X, UBL ou CII), puis transite par la PDP. Salesforce contribue aux données amont et à la visibilité aval, rarement à l'émission fiscale elle-même.

Ne confondez pas « facturer depuis Salesforce » et « émettre une facture électronique conforme ». Générer un PDF depuis le CRM ne suffit pas : le format doit être structuré et transiter par une PDP immatriculée. Vérifiez précisément quel système est responsable de l'émission fiscale avant tout développement.

Les flux à cartographier entre Salesforce et la PDP

Un projet de connexion réussi commence par une cartographie des flux, dans les deux sens. À minima, il faut arbitrer :

Flux sortants (vers la PDP)

  • Données de la facture ou de la commande facturable : lignes, montants HT/TVA, conditions de règlement.
  • Données tiers : SIREN/SIRET, coordonnées de facturation, mentions légales spécifiques au contrat.
  • Références de rattachement : numéro de commande, de contrat, de bon de livraison, pour la piste d'audit fiable.

Flux entrants (retours de la PDP)

  • Statuts de cycle de vie : facture déposée, reçue, acceptée, rejetée, encaissée. Ces statuts intéressent directement les équipes commerciales et le recouvrement.
  • Factures fournisseurs reçues, si vous souhaitez leur visibilité côté Salesforce (rapprochement contrats/achats).

La remontée des statuts dans Salesforce est souvent le vrai apport métier : un commercial ou un ADV voit, sur le compte client, si la facture est bloquée ou payée, sans changer d'outil.

Quelle architecture d'intégration privilégier ?

Le choix technique dépend du volume, de la fréquence et du système émetteur. Quelques repères :

  • Passer par l'ERP : si l'ERP émet déjà les factures, c'est souvent lui qui se connecte à la PDP. Salesforce lui transmet les données de commande. C'est l'option la plus fréquente et la moins risquée sur le plan fiscal.
  • Connecteur natif PDP–Salesforce : certaines PDP proposent des connecteurs ou des applications AppExchange. À évaluer sur la couverture réelle des formats et des statuts, pas seulement sur la démo.
  • Middleware / API : MuleSoft, une plateforme iPaaS tierce ou des API custom orchestrent les échanges. Pertinent si les systèmes sont nombreux et les règles complexes.

Le critère décisif n'est pas la technologie mais la responsabilité de conformité : qui garantit le format légal, l'archivage et la piste d'audit fiable ? Cette réponse doit être écrite noir sur blanc avant de coder.

Erreurs fréquentes à éviter

  • Sous-estimer la qualité des données tiers. Un SIREN erroné ou une adresse de facturation incomplète bloque le routage. La réforme rend la qualité du référentiel client critique — un chantier à lancer côté Salesforce dès maintenant.
  • Traiter le sujet comme un projet purement IT. L'ADV, le contrôle de gestion et la comptabilité doivent être associés au cadrage. Les statuts de facture changent leurs process quotidiens.
  • Développer avant d'avoir choisi la PDP. Les modalités d'intégration varient d'une plateforme à l'autre ; le choix de la PDP conditionne l'architecture.
  • Oublier l'e-reporting. Le B2C et les flux internationaux ne passent pas par l'e-invoicing mais génèrent des données à transmettre. Si Salesforce détient ces transactions, il faut en organiser l'extraction.

Comment cadrer le projet avec un intégrateur

Ce type de connexion touche à la fiscalité, au CRM et à l'ERP : peu d'acteurs maîtrisent les trois. Lors de la sélection d'un intégrateur, il est utile d'exiger :

  • une description écrite de qui porte la responsabilité de conformité (émission, format, archivage) ;
  • des références de projets combinant Salesforce et un flux de facturation, pas seulement du CRM classique ;
  • un plan de test des statuts entrants, y compris les cas de rejet ;
  • une trajectoire d'adaptation si le calendrier réglementaire évolue à nouveau.

INTEGREER aide à qualifier ce besoin à partir de données publiques (SIREN, effectifs, systèmes déclarés) et à formuler un cahier des charges précis avant de rencontrer des prestataires. L'objectif est de comparer des propositions sur des critères vérifiables, et non sur des arguments commerciaux.

En clair : la facturation électronique n'est pas d'abord un sujet Salesforce, mais elle rebat les cartes de vos flux CRM. Anticiper la cartographie, fiabiliser les données tiers et clarifier les responsabilités vous évitera de refaire l'intégration deux fois.

Un projet Salesforce à cadrer ?

Trouver le bon intégrateur Salesforce

Mise en relation gratuite · sans engagement · qualification par la donnée publique