Multi-entités : gérer la facturation électronique de plusieurs SIREN depuis un seul système
par Paul Mantez, Co-fondateur & Développeur
Un groupe d'événementiel parisien, deux sociétés sous le même toit, un seul CRM où naissent toutes les factures. Côté direction, la question arrive vite : « On gère ça comment, avec deux SIREN ? On monte deux outils ? » La réponse courte est non. Mais elle mérite qu'on déplie le pourquoi, parce que c'est là que beaucoup de groupes vont se compliquer la vie sans raison — ou, à l'inverse, croire qu'un seul SIREN suffit pour tout le monde.
On a livré ce cas exact : ce groupe facture ses deux sociétés depuis un seul CRM, branché sur une seule plateforme. Voici ce que la réforme attend de chaque société, et comment un système unique les sert toutes sans les confondre.
Chaque SIREN est seul devant la réforme
L'administration ne connaît pas votre organigramme. Elle connaît des entités légales, identifiées par un SIREN. La réforme 2026 raisonne à cette maille, pas à la maille du groupe : chaque société a ses propres obligations, son inscription à l'annuaire, ses statuts à elle.
Concrètement, une holding qui chapeaute trois filiales, ce sont quatre conformités distinctes — une par société, chacune avec sa propre inscription à l'annuaire et son propre périmètre à suivre. Et les échéances se lisent société par société : la réception devient obligatoire pour toutes au 1er septembre 2026 ; l'émission s'impose dès 2026 aux grandes entreprises et aux ETI, puis en 2027 aux PME et aux TPE. Si une filiale est une ETI et une autre une petite structure, elles n'entrent pas dans l'émission le même jour — alors même qu'elles partagent le même actionnaire et, parfois, le même comptable.
La conséquence est simple à formuler : une entité conforme ne couvre pas sa voisine. Si vous voulez le cadre réglementaire complet — les dates, les formats du socle, le rôle de chaque acteur —, on l'a posé dans le guide de la facturation électronique quand vos factures sortent d'un CRM ou d'un outil métier. Ici, on reste sur ce que le multi-entités change.
L'annuaire et le routage : SIREN ou SIRET
Au centre du dispositif, un annuaire central tenu par l'administration fait le routage : il sait, pour chaque identifiant, quelle plateforme dessert l'entreprise destinataire, et oriente la facture en conséquence. C'est ce répertoire qui permet à une facture émise par votre société de retrouver son destinataire sans que vous ayez à connaître la plateforme d'en face.
Le point que peu de groupes ont en tête : le destinataire choisit sa granularité de réception. Une entreprise peut décider de tout recevoir au niveau du SIREN, ou bien d'éclater la réception par SIRET, établissement par établissement — pour qu'une facture destinée à l'agence de Lyon n'atterrisse pas dans la boîte de Paris. Les deux sont légitimes.
Pour vous qui émettez, cette liberté du destinataire a une traduction directe : le bon identifiant sur la facture devient bloquant. Une facture adressée au mauvais niveau — SIREN là où le client attend un SIRET précis — est rejetée, ou se perd dans un périmètre que personne ne regarde. Ce n'est plus l'enveloppe mal libellée qu'un agent finit par redresser à la main ; c'est un routage automatique qui échoue silencieusement. La donnée d'identité de vos clients, dans un groupe qui facture à beaucoup d'entités elles-mêmes multi-établissements, mérite d'être tenue au carré avant le 1er septembre, pas après le premier rejet.
Chez votre Plateforme Agréée : une entité = un objet
La réforme impose de passer par une Plateforme Agréée (ex-PDP) — l'opérateur privé habilité à émettre, recevoir et transmettre les factures. La DGFiP en a immatriculé plus de 200. Et toutes, dans leur modèle de données, partagent une caractéristique qui décide de votre architecture multi-entités : l'entité légale y est un objet de premier rang.
Chez Sage Network, cet objet s'appelle un dataset : un dataset par SIREN, avec sa raison sociale et son type. Le nom change d'une plateforme à l'autre, mais le principe tient partout — on a creusé ce modèle d'identité dans notre retour d'expérience sur l'intégration d'une API de plateforme agréée. C'est autour de cet objet que s'organisent le routage, les mentions, les abonnements aux statuts.
D'où l'erreur d'architecture qu'on voit venir de loin : configurer l'entité comme une variable globale du connecteur. Un connecteur réglé une fois pour « la société », SIREN en dur quelque part dans la configuration. Ça marche le jour de la mise en production avec une seule entité. Le jour où le groupe ajoute une filiale, il faut redéployer, parfois remonter une seconde instance — et on se retrouve avec deux copies du même outil à maintenir en parallèle.
La bonne approche tient en une phrase : l'entité est un paramètre de chaque appel, pas une constante du système. La passerelle sait, pour chaque facture, quel dataset viser ; elle le décide au moment de l'émission, pas à l'installation. Le moteur est unique, l'entité circule comme une donnée.
Centraliser le système, pas les entités
Concrètement, sur le groupe parisien : deux entités légales, deux SIREN, un seul CRM et une seule passerelle. Pas deux outils, pas deux instances, pas deux équipes à coordonner.
Quand une facture part, la passerelle lit le SIREN de l'entité émettrice et la route vers le bon dataset. Une facture de la première société atterrit sur le dataset de la première société ; une facture de la seconde, sur le sien. Le moteur de génération du format conforme, le dialogue avec la plateforme, la gestion des rejets : tout est mutualisé. Ce qui diffère d'une entité à l'autre, c'est la valeur d'un paramètre, pas la nature du code.
Et le retour fonctionne dans le même esprit. Les statuts qui remontent de la plateforme — déposée, acceptée, rejetée, encaissée — reviennent étiquetés par entité. La comptabilité voit, pour chaque facture, à quelle société elle appartient et où elle en est, sans avoir à recouper deux systèmes. La séparation comptable et fiscale entre les deux sociétés est nette ; le tuyau, lui, est commun.
Le test de cette architecture, c'est le jour où le groupe ouvre une troisième société. Avec un connecteur à entité figée, c'est un chantier : nouvelle instance, redéploiement, re-tests. Avec un système où l'entité est un paramètre, c'est une inscription à l'annuaire et une ligne dans le registre interne — le dataset se crée, le routage le reconnaît, et la passerelle l'émet dès le lendemain. Une formalité, pas un projet.
Ce que vous pouvez unifier, c'est l'outillage. Un système qui porte plusieurs SIREN proprement vous évite d'empiler les intégrations et d'en payer la maintenance en double — sans jamais mélanger ce qui doit rester séparé.
Plusieurs SIREN et une facturation à centraliser ? C'est exactement le cas qu'on a déjà livré. On connecte vos entités à une Plateforme Agréée →