Depuis le 1er septembre 2026, la facture circule comme un message : un identifiant technique, des statuts horodatés, des données transmises à la DGFiP. Ce troisième flux ne parle ni la langue du CRM ni celle de la comptabilité. Voici comment le réconcilier, avec le modèle de données et les contrôles qui tiennent.
Trois chiffres pour le même mois. Le CRM annonce 412 000 € de gagné, la comptabilité 398 000 € de facturé, la plateforme agréée 405 000 € de transmis. Aucun n’est faux. Aucun ne répond à la question du dirigeant : combien avons-nous réellement vendu, et qu’est-ce qui n’a pas été encaissé ?
Jusqu’ici, deux systèmes se disputaient le chiffre d’affaires : le CRM pour l’intention, la comptabilité pour l’engagement. La réforme ajoute un troisième flux, avec ses propres identifiants, ses propres statuts et sa propre temporalité. Ceux qui le traitent comme un simple tuyau de transmission se retrouvent avec trois sources de vérité et aucun arbitrage.
1. Pourquoi la facture électronique crée-t-elle un troisième flux ?
2. Où les trois sources divergent-elles ?
3. Comment construire la table de réconciliation ?
4. Que pilote-t-on une fois les flux réconciliés ?
5. Par où commencer avant septembre 2027 ?
Pourquoi la facture électronique crée-t-elle un troisième flux ?
Parce qu’une facture électronique n’est plus un document mais un objet avec un cycle de vie. Elle porte un identifiant technique distinct de son numéro, elle change d’état, et chaque changement est daté et transmis.
Ce que la plateforme agréée transporte vraiment
La plateforme agréée, ex-PDP, est immatriculée par la DGFiP pour trois ans renouvelables. Son rôle ne s’arrête pas au transport : elle émet, transmet et réceptionne la facture, extrait les données fiscales vers l’administration, transmet les données de transactions qui ne font pas l’objet d’une facture et, nouveauté de la réforme, les données de paiement pour l’ensemble des opérations.
Autrement dit, elle voit passer plus que des montants : des clients, des dates d’échéance, des encaissements. C’est un flux de revenus à part entière, pas une boîte aux lettres. Le circuit de routage passe par l’annuaire, qui associe chaque entreprise à sa plateforme et à son adresse de facturation — plus de 120 000 entreprises y étaient référencées dès l’ouverture, et près de 80 plateformes raccordées.
Trois temporalités qui ne se recouvrent jamais
Le CRM raisonne en intention : une opportunité gagnée le 28 du mois, avec une date de signature et un montant prévisionnel. La facturation raisonne en engagement : un numéro séquentiel, une date d’émission, une échéance. La plateforme raisonne en événement : dépôt, rejet, refus, encaissement, avec un horodatage à la seconde.
Ces trois horloges ne s’alignent pas. Une affaire gagnée en fin de mois est facturée le mois suivant. Une facture émise le 30 est déposée le 2. Un encaissement partiel arrive six semaines plus tard. Si vous comparez les trois sources à la même date, vous trouvez mécaniquement un écart, et cet écart n’est pas une erreur : c’est du temps.
Le piège de l’identifiant technique
Une facture électronique possède un identifiant unique attribué par la plateforme, qui n’est ni le numéro de facture, ni la référence de commande, ni l’identifiant de l’opportunité dans le CRM. Les statuts de cycle de vie référencent cet identifiant technique. Si votre table de faits ne stocke que le numéro de facture, vous perdez le lien avec les statuts et vous ne saurez jamais qu’une facture a été refusée par le client.
C’est le premier point de rupture que je rencontre sur chaque projet : la facture existe en comptabilité, elle existe dans la plateforme, et rien ne permet de les rapprocher autrement qu’à la main.
Où les trois sources divergent-elles ?
Dans un nombre limité de cas, toujours les mêmes. Les identifier une fois évite de réconcilier à la main chaque fin de mois.
Les cinq écarts qui reviennent chaque mois
Le décalage de date, d’abord : signature, émission et dépôt tombent rarement le même jour. L’avoir ensuite, qui diminue le chiffre d’affaires comptable sans annuler l’opportunité dans le CRM. L’acompte, facturé avant la prestation et parfois comptabilisé deux fois. La remise, appliquée en ligne de facture mais absente du montant de l’affaire. Et la devise, quand le CRM stocke en euros et la facture dans la devise de vente.
Chacun de ces écarts a une correction simple, à condition d’être modélisé. Le plus coûteux est l’avoir : une facture rectificative crée une nouvelle pièce, avec son propre identifiant, et double le chiffre d’affaires si elle est additionnée au lieu d’être netted.
Abonnements : la facture n’est pas la vente
Sur un modèle récurrent, une vente signée en janvier produit douze factures. Le CRM compte un contrat, la facturation compte douze pièces, la plateforme compte douze transmissions. Réconcilier ligne à ligne est impossible ; il faut réconcilier par période, en comparant le revenu récurrent attendu au facturé, et en isolant les écarts (churn, remise, prorata, impayé).
Le bon objet de rapprochement n’est alors ni l’opportunité ni la facture, mais l’abonnement : un identifiant de contrat qui se propage dans chaque facture, en référence externe.
Avoirs et rectificatives : le CA qui double
Un avoir est une facture de signe négatif. Si votre modèle somme toutes les pièces sans distinguer les types de document, votre chiffre d’affaires gonfle du montant des avoirs. Le contrôle est trivial à écrire, encore faut-il l’écrire : toute pièce sans facture d’origine référencée est suspecte, et toute facture annulée doit basculer dans un statut explicite.
Comment construire la table de réconciliation ?
Trois clés, une table de correspondance, un modèle en étoile. Rien de plus, mais ces trois éléments doivent exister avant le premier import.
Trois clés, une table de correspondance
La clé technique de la plateforme, le numéro de facture légal, la référence commerciale (commande, contrat ou opportunité). La table de correspondance porte les trois, plus une colonne de confiance : rapprochement exact, rapprochement sur référence commerciale, rapprochement faible sur client et montant. Un rapprochement faible doit rester visible ; le mélanger aux rapprochements exacts produit des tableaux de bord faux.
-- Table de correspondance : la seule source de vérité entre les trois systèmes
CREATE TABLE map_invoice (
pdp_invoice_id TEXT PRIMARY KEY, -- identifiant technique de la plateforme
invoice_number TEXT NOT NULL, -- numéro légal, séquentiel
legal_entity TEXT NOT NULL, -- une séquence par entité juridique
crm_reference TEXT, -- commande, contrat ou opportunité
match_confidence TEXT NOT NULL CHECK (match_confidence IN ('exact','reference','weak')),
matched_at TIMESTAMP,
UNIQUE (legal_entity, invoice_number) -- un numéro ne peut appartenir qu'à une entité
);Le modèle minimal en étoile
Une table de faits par facture, une par ligne, une table d’événements pour les statuts. Les statuts arrivent dans le désordre : un webhook peut livrer « encaissée » avant « mise à disposition ». On stocke donc chaque événement, et on calcule l’état courant par une vue, jamais par un update en place.
CREATE TABLE fact_invoice (
pdp_invoice_id TEXT PRIMARY KEY,
invoice_number TEXT NOT NULL,
client_key BIGINT NOT NULL,
document_type TEXT NOT NULL CHECK (document_type IN ('invoice','credit_note','deposit')),
issued_at DATE NOT NULL,
due_date DATE,
currency CHAR(3) NOT NULL,
amount_ht NUMERIC(14,2) NOT NULL,
amount_vat NUMERIC(14,2) NOT NULL,
amount_ttc NUMERIC(14,2) NOT NULL,
related_invoice TEXT -- facture d'origine pour un avoir
);
CREATE TABLE fact_invoice_line (
pdp_invoice_id TEXT NOT NULL REFERENCES fact_invoice(pdp_invoice_id),
line_no INT NOT NULL,
product_code TEXT,
quantity NUMERIC(12,3),
unit_price_ht NUMERIC(12,4),
amount_ht NUMERIC(14,2),
vat_rate NUMERIC(5,2),
PRIMARY KEY (pdp_invoice_id, line_no)
);
-- Journal d'événements : on insère, on ne met jamais à jour
CREATE TABLE invoice_status_event (
pdp_invoice_id TEXT NOT NULL,
status_code TEXT NOT NULL, -- 200 déposée, 210 refusée, 212 encaissée…
occurred_at TIMESTAMP NOT NULL,
source TEXT NOT NULL, -- pdp, buyer, seller
received_at TIMESTAMP DEFAULT now(),
PRIMARY KEY (pdp_invoice_id, status_code, occurred_at) -- idempotence des webhooks
);
Les contrôles qui tournent chaque nuit
Trois requêtes suffisent pour couvrir l’essentiel, quel que soit l’outil d’orchestration. La première compare le facturé au gagné, par mois et par entité. La deuxième traque les factures sans statut, signe d’un webhook perdu. La troisième détecte les avoirs orphelins et les doublons.
-- 1. Écart mensuel entre CRM et facturation, par entité
WITH crm AS (
SELECT legal_entity,
date_trunc('month', closed_won_at) AS mois,
SUM(amount_ht) AS ca_crm
FROM stg_crm_opportunity
WHERE stage = 'won'
GROUP BY 1, 2
), billed AS (
SELECT legal_entity,
date_trunc('month', issued_at) AS mois,
SUM(CASE WHEN document_type = 'credit_note' THEN -amount_ht ELSE amount_ht END) AS ca_facture
FROM fact_invoice
GROUP BY 1, 2
)
SELECT COALESCE(c.mois, b.mois) AS mois,
COALESCE(c.legal_entity, b.legal_entity) AS entite,
COALESCE(c.ca_crm, 0) AS ca_crm,
COALESCE(b.ca_facture, 0) AS ca_facture,
COALESCE(b.ca_facture, 0) - COALESCE(c.ca_crm, 0) AS ecart
FROM crm c
FULL OUTER JOIN billed b USING (legal_entity, mois)
ORDER BY mois DESC, ABS(COALESCE(b.ca_facture,0) - COALESCE(c.ca_crm,0)) DESC;-- 2. Factures déposées sans aucun statut depuis 48 h
SELECT f.pdp_invoice_id, f.invoice_number, f.issued_at
FROM fact_invoice f
LEFT JOIN invoice_status_event s USING (pdp_invoice_id)
WHERE f.issued_at >= CURRENT_DATE - 30
GROUP BY 1, 2, 3
HAVING COUNT(s.status_code) = 0;
-- 3. Avoirs sans facture d'origine, ou rattachés à une facture inconnue
SELECT a.pdp_invoice_id, a.invoice_number, a.related_invoice
FROM fact_invoice a
LEFT JOIN fact_invoice o
ON o.invoice_number = a.related_invoice
AND o.legal_entity = a.legal_entity
WHERE a.document_type = 'credit_note'
AND o.invoice_number IS NULL;
Ces trois contrôles ne remplacent pas une piste d’audit, ils la rendent possible. Ajoutez-leur une alerte quand l’écart dépasse un seuil que vous fixez par entité, et vous passez d’une réconciliation mensuelle à une surveillance continue.
Que pilote-t-on une fois les flux réconciliés ?
Le chiffre d’affaires cesse d’être une estimation produite en fin de mois. Il devient une série quotidienne, avec un état d’encaissement connu.
Le CA à J+1 et le DSO réel
Une fois les statuts consolidés, le délai de paiement se calcule sur des encaissements observés et non sur des échéances théoriques. Vous savez quelle part de votre portefeuille est refusée, en litige ou simplement non encaissée, et depuis combien de jours. C’est la différence entre un DSO calculé et un DSO espéré.
La détection des revenus perdus
Trois familles de fuites apparaissent dès que les sources se parlent : l’affaire gagnée jamais facturée, l’abonnement non refacturé après un changement de formule, et l’avoir émis sans contrepartie. Sur une PME, ces trois cas représentent souvent plus que le coût du projet de réconciliation.
Le contrôle est simple : toute opportunité gagnée depuis plus de trente jours sans facture associée remonte dans une liste, avec son propriétaire commercial. Ceux qui ont mis ce rapport en place ne reviennent pas en arrière.
Le forecast, enfin adossé au réel
Un prévisionnel construit sur le pipeline reste une opinion. Adossé au facturé et au récurrent encaissé, il devient un scénario. Vous pouvez comparer, mois après mois, ce que le CRM promettait et ce que la plateforme a réellement transmis, et corriger le taux de conversion utilisé dans les prévisions.
Par où commencer avant septembre 2027 ?
Les PME ont jusqu’au 1er septembre 2027 pour émettre, mais la réception est déjà obligatoire depuis septembre 2026. La fenêtre utile pour construire la réconciliation se ferme avec la première facture émise en électronique.
Exiger les statuts par API, pas par export
Un export CSV quotidien ne permet ni l’idempotence, ni le rejeu, ni la détection d’un événement manqué. Demandez une API REST avec webhooks signés, un identifiant d’événement unique et une politique de rejeu. Sans cela, vous construirez une réconciliation sur des fichiers et vous passerez vos fins de mois à chercher des statuts.
Six clauses à faire figurer au contrat
L’identifiant technique de la facture, l’historique complet des statuts avec horodatage, la signature des webhooks et la clé de rejeu, la durée de conservation des événements, l’accès aux données de paiement, et les modalités de sortie avec récupération de l’historique. Une plateforme agréée qui refuse l’un de ces six points n’est pas un fournisseur de données, seulement un transporteur.
Un pilote en quatre semaines
Semaine 1 : cartographier les trois clés sur dix factures réelles. Semaine 2 : charger l’historique des statuts et vérifier l’idempotence. Semaine 3 : brancher les trois contrôles et fixer les seuils d’alerte. Semaine 4 : comparer le CA réconcilié au chiffre comptable et documenter chaque écart résiduel. Si l’écart n’est pas expliqué à la fin du pilote, le problème est dans le modèle, pas dans les données.
Votre chiffre d’affaires est-il réconcilié, ou seulement estimé ?
La réforme de la facturation électronique n’ajoute pas seulement une obligation fiscale. Elle met à votre disposition un flux de revenus horodaté, avec des statuts que vous n’aviez jamais eus. Encore faut-il le brancher. Trois clés, une table de correspondance, trois contrôles nocturnes : c’est le prix d’un chiffre d’affaires que vous pouvez défendre en comité de direction.
Franck Scandolera — data engineer. Je conçois les modèles de données et les pipelines qui réconcilient CRM, facturation et flux réglementaires, et je forme les équipes internes à les maintenir.
Questions fréquentes
-
Une plateforme agréée peut-elle servir de source de vérité pour le CA ?
Non. Elle atteste de la transmission et du cycle de vie d’une facture, pas de la réalité comptable ni de l’intention commerciale. Elle devient une source fiable pour les statuts et les encaissements, à condition d’être rapprochée des deux autres. -
Faut-il attendre septembre 2027 pour s’y mettre ?
Non. La réception est obligatoire depuis septembre 2026, donc vous recevez déjà des factures électroniques de vos fournisseurs grands comptes. Et l’émission en 2027 arrivera avec son lot de statuts : mieux vaut un modèle testé avant. -
Quel format choisir entre Factur-X, UBL et CII ?
Les trois sont acceptés. Factur-X a l’avantage d’être un PDF lisible avec un XML embarqué, ce qui facilite la transition. Le point critique n’est pas le format mais le profil : restez en EN 16931, les profils MINIMUM et BASIC WL ne portent pas assez de données structurées. -
Peut-on réconcilier sans toucher au CRM ?
Oui, à condition d’exiger que la référence commerciale soit portée dans la facture en référence externe. Sans cette discipline, le rapprochement retombe sur le nom du client et le montant, ce qui produit des faux positifs dès que deux affaires se ressemblent. -
Combien de temps prend un tel projet ?
Un pilote sérieux tient en quatre semaines pour un périmètre d’une entité et d’une centaine de factures par mois. L’industrialisation multi-entités prend ensuite deux à trois mois, essentiellement pour traiter les cas particuliers : avoirs, acomptes, abonnements.
Sources
- DGFiP, « Facturation électronique et plateformes agréées », impots.gouv.fr (consulté le 11 novembre 2026). impots.gouv.fr
- DGFiP, Guide pratique de démarrage au 1er septembre 2026. PDF
- Ministère de l’Économie, « Facturation électronique entre entreprises : coup d’envoi de la réforme », 1er septembre 2026. economie.gouv.fr
- DGFiP et AIFE, « Ouverture de l’annuaire de la facturation électronique », 18 septembre 2025. economie.gouv.fr
- Entreprendre Service Public, « Mentions obligatoires sur une facture », vérifié le 11 août 2026. service-public.gouv.fr
- FNFE-MPE, format Factur-X et profils EN 16931. fnfe-mpe.org
Dev d’applications métier · Data Engineer · Automatisation IA
Clients : Logis Hôtels, Yelloh Village, BazarChic, FFF, Texdecor…
- Apps & agents IA : Node.js, Python, API, RAG, OpenAI, Mistral, Claude
- Data & Analytics Engineering : GCP, BigQuery, Snowflake, PostgreSQL, ClickHouse, dbt, Airflow, Dataform, Looker, Power BI, Metabase
- Automatisation IA : n8n, Apps Script, scraping, API, LLM
- Tracking & perf Web : GA4, GTM server, Matomo, Piano, Tealium, CAPI, Core Web Vitals