Facturation électronique · Données destinataire
Publié le
Depuis le 1er septembre 2026, la capacité à recevoir une facture électronique ne dépend plus seulement de la présence d’une adresse postale ou d’un numéro de TVA dans une fiche client. Le logiciel émetteur doit aussi être capable d’identifier l’adresse électronique de facturation attendue par le destinataire.
L’annuaire de la facturation électronique constitue le référentiel utilisé pour déterminer où une facture doit être acheminée. Il associe les entreprises et leurs établissements à une plateforme agréée ainsi qu’à une ou plusieurs adresses de facturation.
Pour un logiciel métier, l’enjeu n’est donc pas seulement de consulter l’annuaire. Il faut aussi savoir interpréter la réponse, proposer la bonne adresse à l’utilisateur, conserver la sélection effectuée et vérifier que cette information est encore valable au moment de l’envoi.
Cette étape complète l’intégration générale de la facturation électronique dans un logiciel métier, sans se confondre avec la génération de la facture, sa validation ou le suivi de son cycle de vie.
À quoi sert l’annuaire de la facturation électronique ?
L’annuaire référence les structures publiques ainsi que les structures privées identifiées comme assujetties à la TVA en France dans le périmètre de la réforme.
Il permet notamment de vérifier :
- si une structure est présente dans le dispositif ;
- si une plateforme agréée de réception lui est rattachée ;
- quels établissements dépendent de l’entreprise ;
- quelles adresses de facturation sont disponibles ;
- si ces adresses sont actives.
Le service public permet une recherche par SIREN, SIRET ou dénomination. Cette consultation est utile pour une vérification ponctuelle, mais un logiciel métier ne doit pas construire son automatisation en reproduisant ou en aspirant l’interface publique protégée par un CAPTCHA.
Pour les traitements de production, l’interrogation et le routage doivent passer par les mécanismes mis à disposition par la plateforme agréée raccordée ou par la solution compatible utilisée par le logiciel.
Consulter l’annuaire officiel de la facturation électronique
SIREN et SIRET : deux niveaux à conserver séparément
Le SIREN identifie l’unité légale. Le SIRET identifie un établissement appartenant à cette unité légale.
Une entreprise peut donc posséder :
- un seul SIREN ;
- un SIRET pour son siège ;
- plusieurs SIRET pour ses établissements ;
- plusieurs adresses de facturation rattachées à ces différents niveaux.
Le logiciel ne doit pas utiliser le SIREN et le SIRET comme deux variantes interchangeables d’un même identifiant.
Dans la fiche client, il faut distinguer au minimum :
Unité légale
SIREN
Établissement destinataire
SIRET
Adresse postale
Adresse électronique de facturation
Le client juridique peut être correctement identifié au niveau du SIREN alors que la facture doit être adressée à un établissement précis.
À l’inverse, utiliser systématiquement le SIRET du siège social peut être incorrect lorsque le client souhaite recevoir certaines factures sur un établissement secondaire ou un service spécialisé.
Une adresse électronique de facturation n’est pas une adresse e-mail
L’expression peut prêter à confusion. L’adresse électronique de facturation n’est pas nécessairement une adresse de courrier électronique.
Dans l’annuaire, elle correspond à un identifiant d’adressage utilisé pour acheminer la facture vers la plateforme et le périmètre de réception attendus.
La documentation officielle de Chorus Pro présente quatre formes principales :
SIREN
SIREN_SIRET
SIREN_SIRET_CodeRoutage
SIREN_Suffixe
Ces formats décrivent plusieurs niveaux de précision.
Adresse au niveau SIREN
SIREN
La facture est adressée à l’unité légale.
Ce niveau peut convenir lorsqu’une entreprise centralise toutes ses factures sur une seule adresse de réception.
Adresse au niveau SIRET
SIREN_SIRET
La facture est adressée à un établissement précis.
Le logiciel doit alors conserver le SIRET choisi et vérifier qu’il appartient bien au SIREN du client.
Adresse avec code de routage
SIREN_SIRET_CodeRoutage
Le code de routage représente un service ou un sous-ensemble rattaché à un établissement.
Il peut, par exemple, permettre à l’entreprise destinataire d’organiser ses factures selon un service, une activité ou un circuit interne.
Le code ne doit pas être déduit ou créé par le fournisseur. Il est défini par l’entreprise destinataire par l’intermédiaire de sa plateforme agréée.
Adresse avec suffixe
SIREN_Suffixe
Le suffixe constitue un sous-ensemble défini au niveau de l’unité légale.
Il se distingue du code de routage, qui appartient au niveau SIRET.
Un logiciel métier doit donc conserver le type d’adresse et ne pas stocker uniquement une chaîne opaque sans savoir s’il s’agit d’un SIREN, d’un établissement, d’un suffixe ou d’un code de routage.
Suffixe et code de routage ne sont pas obligatoires
Toutes les entreprises n’utilisent pas un suffixe ou un code de routage.
Ces identifiants sont créés à leur initiative, par l’intermédiaire de leur plateforme agréée. Ils servent à affiner le routage lorsqu’une organisation souhaite disposer de plusieurs points de réception.
Le logiciel émetteur doit donc prendre en charge deux situations :
- une seule adresse active est proposée ;
- plusieurs adresses actives sont proposées et une sélection est nécessaire.
Il ne faut pas rendre le code de routage obligatoire dans toutes les fiches clients.
Il ne faut pas non plus conserver une ancienne valeur comme si elle constituait une propriété permanente de l’entreprise. Le destinataire peut modifier son organisation, changer de plateforme ou faire évoluer ses adresses.
Plateforme rattachée et adresse active : deux informations différentes
La présence d’une plateforme agréée rattachée ne signifie pas toujours qu’une adresse est immédiatement utilisable.
La documentation de l’annuaire distingue :
- le rattachement à une plateforme agréée ;
- l’existence d’une ligne de facturation ;
- le caractère actif de cette ligne.
Une entreprise peut avoir choisi sa plateforme et disposer d’une adresse dont la date de prise d’effet se situe dans le futur.
Dans ce cas :
Plateforme rattachée : oui
Adresse active : non
Le logiciel ne doit donc pas autoriser une transmission sur la seule base de la présence d’une plateforme.
Avant l’envoi, il doit vérifier qu’une adresse utilisable est effectivement active.
Quelles données conserver dans la fiche client ?
Le modèle de données doit séparer les informations juridiques, les informations de routage et les données de contrôle.
Le tableau suivant constitue une recommandation d’architecture. Tous ces champs ne sont pas des données réglementaires à transmettre.
| Catégorie | Données conseillées | Utilité |
|---|---|---|
| Identité légale | SIREN, raison sociale | Identifier l’unité légale |
| Établissement | SIRET, dénomination, adresse postale | Identifier le destinataire opérationnel |
| Adressage | Type d’adresse, suffixe ou code de routage | Comprendre la structure de l’adresse |
| Adresse sélectionnée | Valeur complète de l’adresse de facturation | Préparer la transmission |
| État | Adresse active ou inactive | Bloquer les adresses inutilisables |
| Plateforme | Référence ou nom de la plateforme lorsque disponible | Comprendre le circuit de réception |
| Fraîcheur | Date et source de la dernière vérification | Détecter une donnée ancienne |
| Traçabilité | Utilisateur, réponse reçue, décision effectuée | Justifier la sélection |
Des noms techniques internes peuvent par exemple être utilisés :
customer_siren
customer_siret
routing_scope
billing_address
billing_suffix
routing_code
billing_address_active
receiver_platform_reference
directory_checked_at
directory_source
selected_by
selected_at
Ces noms sont des exemples d’architecture interne. Ils ne constituent pas un format officiel imposé par l’administration.
Ne pas écraser l’adresse utilisée sur une facture déjà émise
La fiche client peut évoluer. Une adresse peut être désactivée, remplacée ou complétée par un nouveau code de routage.
Cette évolution ne doit pas modifier silencieusement l’historique des factures.
Au moment de la transmission, le logiciel doit conserver un instantané des informations utilisées :
- SIREN ;
- SIRET ;
- adresse électronique de facturation ;
- type d’adressage ;
- date de vérification ;
- identifiant de la réponse ou de la consultation ;
- plateforme concernée ;
- date de transmission.
La fiche client contient l’état actuel. La facture et son journal de transmission conservent l’état effectivement utilisé lors de l’envoi.
Cette séparation facilite le support et permet de comprendre pourquoi une facture ancienne a été acheminée vers une adresse qui n’est plus active aujourd’hui.
Quel parcours prévoir avant l’envoi ?
Un parcours fiable peut suivre les étapes suivantes.
- Vérifier que le SIREN du client est présent et correctement formaté.
- Vérifier le SIRET si la facture concerne un établissement particulier.
- Interroger l’annuaire par l’intermédiaire de la plateforme ou de la passerelle raccordée.
- Récupérer les adresses disponibles et leur état.
- Écarter les adresses inactives.
- Présenter les choix utiles lorsqu’il existe plusieurs adresses.
- Conserver l’adresse retenue et son niveau.
- Créer un instantané avec la facture.
- Revalider la donnée avant l’envoi lorsqu’elle est ancienne ou incertaine.
- Conserver la réponse et le résultat de la transmission.
Le logiciel ne doit pas choisir silencieusement la première adresse reçue si plusieurs lignes actives correspondent à des périmètres différents.
Une règle automatique peut être envisagée lorsque le destinataire a confirmé un choix stable, mais cette règle doit rester visible, modifiable et traçable.
Que faire lorsque plusieurs adresses sont actives ?
Plusieurs adresses actives indiquent généralement que le destinataire organise ses factures selon différents établissements, services ou périmètres.
L’interface peut alors afficher :
- le niveau de l’adresse ;
- l’établissement ;
- la désignation du suffixe ou du code ;
- son état ;
- la date de dernière vérification ;
- une adresse précédemment utilisée, sans la sélectionner aveuglément.
L’utilisateur doit pouvoir choisir avec suffisamment de contexte.
Un simple menu contenant plusieurs identifiants techniques sans explication augmente le risque d’erreur.
Le logiciel peut mémoriser une préférence par relation commerciale, contrat ou type de dossier, mais il doit permettre une nouvelle consultation lorsque la situation évolue.
Peut-on mettre les résultats en cache ?
Une mise en cache peut réduire les appels et améliorer les performances, mais la copie locale ne doit pas devenir une source définitive.
Il est préférable de conserver :
- le résultat de la consultation ;
- la date de récupération ;
- la source ;
- une durée de validité interne configurable ;
- le contexte de la demande ;
- la date de la prochaine vérification ;
- les changements détectés.
Ne pas coder une durée universelle en dur sans tenir compte :
- des fonctions proposées par la plateforme ;
- de la fréquence de facturation ;
- du risque métier ;
- de la date de la dernière vérification ;
- d’un changement signalé par le client.
Une nouvelle consultation doit pouvoir être imposée :
- avant une première transmission ;
- lorsque la donnée est trop ancienne ;
- après un rejet lié à l’adressage ;
- après une modification de la fiche client ;
- lorsque le client signale un changement de plateforme ou de service.
Que faire lorsqu’aucune adresse active n’est trouvée ?
Le logiciel ne doit pas inventer une adresse ou supprimer un niveau d’adressage pour tenter l’envoi.
Il doit plutôt :
- vérifier le SIREN et le SIRET ;
- vérifier que l’établissement sélectionné correspond bien au client ;
- renouveler la consultation ;
- signaler clairement l’absence d’adresse active ;
- permettre de contacter le destinataire ;
- conserver le résultat de la vérification ;
- éviter la transmission tant que le routage n’est pas fiabilisé.
Une absence d’adresse peut signifier que la plateforme n’est pas encore activée, que la ligne n’est pas encore entrée en vigueur ou que les identifiants utilisés ne correspondent pas à la structure recherchée.
Le message affiché doit rester factuel et ne pas attribuer automatiquement la responsabilité au client ou à la plateforme.
Consultation publique et intégration automatisée
Le service public est utile pour effectuer une vérification manuelle. Son interface demande notamment le passage d’un CAPTCHA.
Un connecteur de production ne doit pas automatiser cette interface par extraction HTML ou contournement du CAPTCHA.
L’intégration doit utiliser les services prévus par la plateforme agréée ou par la solution compatible raccordée.
Cette séparation permet :
- de respecter le circuit technique attendu ;
- de recevoir une réponse structurée ;
- de gérer les erreurs ;
- d’identifier la source ;
- de tracer la consultation ;
- d’éviter une dépendance fragile à une interface destinée aux utilisateurs.
L’architecture API de facturation électronique doit donc prévoir une fonction dédiée à la résolution de l’adressage, distincte de l’envoi de la facture.
Modéliser un service de résolution d’adressage
Dans une architecture modulaire, le logiciel métier peut appeler un service interne de résolution.
Ce service reçoit par exemple :
SIREN
SIRET éventuel
Contexte du dossier
Adresse précédemment utilisée
Il restitue :
Entité trouvée
Établissements disponibles
Plateforme rattachée
Adresses trouvées
Adresses actives
Type de chaque adresse
Date de vérification
Avertissements éventuels
Le logiciel métier reste responsable de l’expérience utilisateur et du rattachement au dossier. La passerelle gère la communication avec la plateforme et normalise la réponse.
Cette architecture évite de dupliquer les règles de consultation dans plusieurs applications.
Comment Codisys Invoice Connect peut-il intervenir ?
Codisys Invoice Connect fournit une couche commune entre les logiciels métier et la plateforme agréée raccordée.
Sous réserve d’activation et de recette de la consultation automatisée de l’annuaire, cette couche pourrait permettre de :
- centraliser la consultation de l’adressage ;
- normaliser les informations retournées ;
- rapprocher SIREN, SIRET et adresse électronique ;
- conserver la date et la source du contrôle ;
- fournir une réponse commune à plusieurs applications ;
- transmettre ensuite la facture avec les informations retenues ;
- restituer les statuts et erreurs au logiciel métier.
Codisys Invoice Connect est une solution compatible facturation électronique raccordée à Hubtimize e-Invoicing, plateforme agréée développée par EsaLink.
Codisys Invoice Connect n’est pas lui-même une plateforme agréée.
La consultation automatisée de l’annuaire via Codisys Invoice Connect n’est pas annoncée ici comme disponible en production. Son activation et son périmètre doivent être confirmés pour chaque projet de raccordement.
Après l’envoi : conserver la distinction avec le rejet
La vérification de l’annuaire réduit les erreurs d’adressage, mais elle ne garantit pas à elle seule l’acceptation définitive de la facture.
Après la transmission, la plateforme ou le destinataire peut retourner un statut nécessitant une action.
Le logiciel doit alors distinguer :
- l’adresse vérifiée avant l’envoi ;
- la réponse obtenue lors de la transmission ;
- le statut reçu ;
- le motif ;
- les données corrigées ;
- une éventuelle nouvelle tentative.
Le guide sur les rejets et refus de facture électronique traite cette phase postérieure à l’envoi.
Checklist avant de transmettre une facture
- Le SIREN correspond-il à l’unité légale du client ?
- Le SIRET correspond-il au bon établissement ?
- Le type d’adresse est-il identifié ?
- L’adresse provient-elle d’une source récente et traçable ?
- Une plateforme agréée est-elle rattachée ?
- L’adresse de facturation est-elle active ?
- Plusieurs adresses nécessitent-elles un choix ?
- Le suffixe ou le code de routage a-t-il été fourni par le destinataire ?
- L’adresse retenue a-t-elle été enregistrée avec la facture ?
- La date de contrôle est-elle conservée ?
- Une nouvelle vérification est-elle nécessaire avant l’envoi ?
- Le logiciel conservera-t-il le résultat de la transmission ?
Conclusion
L’annuaire de la facturation électronique ne doit pas être traité comme un simple carnet d’adresses.
Pour un logiciel métier, il devient une source de données dynamique qui relie l’identité juridique du client, ses établissements, sa plateforme de réception et ses adresses actives.
Une intégration fiable doit distinguer le SIREN, le SIRET, le suffixe et le code de routage. Elle doit aussi conserver la date du contrôle, l’adresse utilisée et la réponse obtenue, sans modifier l’historique lorsqu’une fiche client évolue.
La qualité du routage dépend donc autant de la conception du modèle de données que de la connexion technique avec la plateforme agréée.
Intégrer l’annuaire dans votre logiciel métier
Codisys peut vous aider à analyser vos fiches clients, structurer les identifiants d’adressage, concevoir le parcours de sélection et relier votre logiciel à Codisys Invoice Connect.