Adressage et annuaire : router une facture électronique au bon destinataire (SIREN, SIRET, code routage, BT-49)
Une facture parfaitement conforme peut n'arriver nulle part. L'annuaire central décide où elle part : SIREN, SIRET, code routage, adresse électronique BT-49. Les règles d'adressage de la réforme, et les six erreurs qui font échouer une livraison.
Les projets de facturation électronique se concentrent sur le format : Factur-X ou UBL, quel profil, quelle version de norme. C'est nécessaire, mais insuffisant. Une facture peut passer tous les contrôles de validation et ne jamais atteindre son destinataire, simplement parce que son adresse est fausse, incomplète ou absente de l'annuaire central. En phase de bascule, l'adressage est la première cause de flux qui n'arrivent pas. Cet article explique comment fonctionne l'adressage français (SIREN, SIRET, code routage), où l'adresse se loge techniquement dans la facture (BT-49 et son schéma 0225), et comment transformer ce sujet en référentiel maintenu plutôt qu'en champ rempli au hasard.
L'annuaire central, la carte routière de la réforme
Depuis le recentrage du Portail Public de Facturation fin 2024, le PPF n'échange plus de factures. Il conserve en revanche une fonction critique : il tient l'annuaire central des destinataires, alimenté et mis à jour par les Plateformes Agréées.
Le mécanisme est simple à décrire, et c'est justement ce qui le rend traître. Quand vous émettez une facture, votre plateforme doit répondre à une question avant toute chose : chez qui ce destinataire reçoit-il ses factures, et à quelle adresse ? La réponse vient de l'annuaire. Si la fiche du destinataire est absente, périmée ou si l'adresse que vous avez portée dans la facture ne correspond à aucune entrée, il n'y a pas de livraison possible. Votre facture est techniquement irréprochable et opérationnellement perdue.
Une conséquence à intégrer tout de suite : l'adressage est une donnée partagée. Elle dépend de ce que votre client a déclaré, pas seulement de ce que votre ERP contient. Une fiche client correcte depuis dix ans (raison sociale, SIRET, adresse postale) ne garantit rien sur son adresse de réception électronique.
Les quatre mailles d'adressage
Les spécifications externes B2B (version 3.2 du 30 avril 2026, publiée sur impots.gouv.fr) décrivent quatre formes d'adresse électronique, de la plus large à la plus fine. Le choix n'est pas cosmétique : il détermine dans quelle boîte de réception, chez votre client, la facture atterrit.
| Maille | Forme | Exemple | Quand l'utiliser |
|---|---|---|---|
| Entité juridique | SIREN |
552100554 |
Client mono-site, ou centralisation totale de la réception |
| Établissement | SIREN_SIRET |
552100554_55210055400013 |
Groupes multi-sites, usines, agences avec comptabilité locale |
| Service exécutant | SIREN_SIRET_CODEROUTAGE |
552100554_55210055400013_SERV01 |
Secteur public et entités qui reprennent la logique de code service |
| Flux dédié | SIREN_SUFFIXE |
552100554_ACHATS |
Directions achats, centres de services partagés, catégories de dépenses |
Trois règles structurent ces formes, et elles surprennent souvent les équipes d'intégration :
- toute adresse commence par le SIREN, y compris quand elle descend au niveau établissement. Le SIRET seul, sur 14 chiffres, n'est pas une adresse valide : la forme attendue est
SIREN_SIRET; - le séparateur est le tiret bas, et l'adresse complète est plafonnée à 95 caractères ;
- suffixe et code routage n'acceptent ni accents, ni espaces, ni arobase. En pratique : lettres non accentuées, chiffres, point et tiret.
Notez la distinction de vocabulaire, souvent brouillée dans les échanges projet. Le code routage correspond au code service exécutant, hérité de la logique du secteur public. Le suffixe est le mécanisme libre du B2B privé, choisi par le destinataire pour séparer ses flux. L'un et l'autre partagent une propriété décisive : ils ne se devinent pas et ne s'inventent pas. Un service achats peut vous demander d'utiliser _ACHATS, mais tant que cette adresse n'a pas été publiée dans l'annuaire par sa plateforme, elle ne résout rien.
Retenez la règle de prudence : descendez à la maille la plus fine que votre client a réellement déclarée, pas à la plus fine qu'il vous a mentionnée dans un mail.
BT-49 : où l'adresse se loge dans la facture
Dans la norme sémantique EN 16931, l'adresse électronique de l'acheteur porte l'identifiant BT-49, accompagné de son attribut de schéma BT-49-1. Le pendant côté vendeur est le BT-34. L'attribut de schéma indique dans quel référentiel l'identifiant doit être lu, selon la liste de codes EAS (ISO/IEC 6523) :
0002: SIRENE, l'identifiant SIREN de l'entreprise ;0009: SIRET, l'identifiant d'établissement ;0225: l'adresse électronique française du cadre de facturation, qui porte les quatre mailles vues plus haut,SIREN,SIREN_SIRET,SIREN_SIRET_CODEROUTAGEetSIREN_SUFFIXE;EM: une adresse e-mail, utilisée dans certains contextes internationaux et hors périmètre du routage domestique.
Le code 0225 est celui qui porte la logique de routage française. C'est lui que vous verrez dans les flux domestiques dès que l'adresse descend sous la maille entité juridique.
En UBL 2.1
<cac:AccountingCustomerParty>
<cac:Party>
<cbc:EndpointID schemeID="0225">552100554_ACHATS</cbc:EndpointID>
<cac:PartyLegalEntity>
<cbc:CompanyID schemeID="0002">552100554</cbc:CompanyID>
</cac:PartyLegalEntity>
</cac:Party>
</cac:AccountingCustomerParty>
En CII et Factur-X
<ram:BuyerTradeParty>
<ram:Name>Client Démonstration</ram:Name>
<ram:SpecifiedLegalOrganization>
<ram:ID schemeID="0002">552100554</ram:ID>
</ram:SpecifiedLegalOrganization>
<ram:PostalTradeAddress>
<ram:CountryID>FR</ram:CountryID>
</ram:PostalTradeAddress>
<ram:URIUniversalCommunication>
<ram:URIID schemeID="0225">552100554_ACHATS</ram:URIID>
</ram:URIUniversalCommunication>
</ram:BuyerTradeParty>
Factur-X embarque ce même XML CII dans le PDF/A-3 : l'adresse de routage vit dans la couche structurée, pas dans la représentation visuelle. Un utilisateur qui relit le PDF ne verra donc jamais l'erreur d'adressage. Seul un contrôle sur le XML la révèle.
Pour les flux qui transitent par Peppol, notez que le profil BIS Billing rend l'adresse électronique obligatoire pour les deux parties, vendeur et acheteur. Une facture domestique tolérée sans BT-49 par une chaîne interne sera rejetée dès qu'elle empruntera ce réseau.
Ne pas confondre adresse et identifiants
Quatre champs voisins sont régulièrement mélangés dans les mappings, avec des conséquences très différentes :
- BT-49, adresse électronique de l'acheteur : sert au routage. C'est le sujet de cet article.
- BT-47, identifiant d'enregistrement légal : identifie juridiquement l'entité (SIREN, SIRET). Il ne route rien.
- BT-48, numéro de TVA de l'acheteur : sert aux contrôles fiscaux et à l'autoliquidation, pas au routage.
- BT-10, référence acheteur : champ de gestion, qui porte le numéro d'engagement ou une référence de commande. Il ne remplace pas le BT-49.
Le réflexe qui coûte cher : recopier le SIRET de l'acheteur dans le BT-49 en le déclarant sous le schéma 0225. La valeur paraît correcte à l'œil, mais une adresse 0225 commence toujours par le SIREN : la forme attendue au niveau établissement est SIREN_SIRET, pas le SIRET seul.
Les six erreurs qui font échouer une livraison
- Aucune adresse électronique portée dans la facture. Votre plateforme doit alors deviner, ou rejeter. Le comportement varie d'un opérateur à l'autre, ce qui rend le diagnostic pénible en multi-plateformes.
- Un suffixe inventé. Le service achats vous a dit « mettez ACHATS » sans que l'adresse soit publiée dans l'annuaire. L'adresse ne résout pas.
- Un SIRET fermé. L'établissement a déménagé ou a été absorbé, le SIRET n'est plus actif, la fiche annuaire ne le référence plus. Votre ERP, lui, l'a toujours.
- Une forme d'adresse invalide. SIRET seul déclaré en
0225au lieu deSIREN_SIRET, suffixe accentué ou contenant un espace, adresse dépassant 95 caractères, schéma0002porté sur une adresse à suffixe. La valeur semble plausible, l'annuaire ne la reconnaît pas. - Un changement de plateforme côté client. Votre client migre vers une autre Plateforme Agréée. Son adresse peut changer, votre référentiel ne le sait pas. C'est le scénario le plus fréquent après le démarrage, et il est totalement silencieux tant que rien ne surveille les statuts.
- Une granularité incohérente entre commande et facture. Vous facturez au niveau SIREN un client qui rapproche ses factures au niveau établissement. La facture arrive, mais dans une file qui n'a pas le bon de commande en face. Techniquement livrée, opérationnellement bloquée.
Les cinq premières produisent un rejet technique, à corriger et à retransmettre. La sixième produit un litige de rapprochement, et se termine souvent en refus motivé par l'acheteur. Ce sont deux mécaniques distinctes, comme le rappelle notre article sur le guide de démarrage de la DGFiP.
Faire de l'adressage un référentiel, pas un champ
Le piège consiste à traiter l'adressage comme une donnée statique remplie une fois lors de la reprise. C'est une donnée vivante, qui change quand votre client change de plateforme, réorganise ses services partagés ou ferme un établissement. Elle mérite donc les attributs d'un référentiel maintenu, à tenir par partenaire :
- la valeur d'adresse déclarée et son schéma (
0002,0009,0225), stockés comme deux colonnes distinctes ; - la Plateforme Agréée du destinataire, avec son statut d'immatriculation ;
- la granularité convenue : entité, établissement, service ;
- la source de l'information : fiche annuaire, onboarding contractuel, déclaration du client ;
- la date de dernière vérification, avec une politique de revérification pour les comptes à volume ;
- les correspondances internes : quel code client ERP, quel site, quel bon de commande.
À ce référentiel s'ajoutent deux automatismes qui font la différence en production. Un contrôle avant émission, qui refuse de sortir une facture dont l'adresse ne respecte pas la forme attendue ou dont le SIREN ne correspond pas à l'identifiant de l'acheteur. Et une supervision des statuts de cycle de vie, qui transforme un non-routage en alerte nominative plutôt qu'en découverte au moment de la relance de paiement, six semaines plus tard.
Tester avant septembre
L'adressage se teste, et il se teste tôt, parce que la correction dépend d'un tiers. Trois actions concrètes à mener maintenant :
- Extrayez votre top 50 clients en volume de factures et confrontez, pour chacun, l'adresse que vous détenez à celle que sa plateforme déclare. C'est un travail d'onboarding, pas un travail d'informaticien.
- Générez des factures de recette portant vos vraies formes d'adresse, et vérifiez le XML plutôt que le PDF. Notre générateur de facture électronique expose un champ BT-49 qui accepte les mailles commençant par le SIREN, du
SIRENseul auSIREN_SIRET_CODEROUTAGE: il contrôle que le SIREN saisi correspond bien à l'identifiant acheteur, puis émet le schéma0225dans les sorties UBL, CII et Factur-X. En quelques secondes, vous voyez exactement ce que votre partenaire recevra. - Faites une bascule progressive en commençant par les partenaires dont l'adresse est confirmée. Le guide de démarrage recommande explicitement cette logique : basculer les flux prêts plutôt que d'attendre que tout le périmètre soit stabilisé.
Ce que SwiftEDI Solutions apporte sur ce sujet
En tant qu'Opérateur de Dématérialisation, SwiftEDI Solutions traite l'adressage comme un actif de production :
- SmartPartner tient le référentiel d'adressage par partenaire : valeur, schéma, granularité, Plateforme Agréée, date de vérification, correspondances ERP.
- SmartMapping injecte la bonne forme d'adresse et le bon
schemeIDselon le format cible, sans que vos équipes aient à connaître les subtilités UBL et CII. - SmartGateway applique les contrôles avant remise à la Plateforme Agréée, ce qui bloque en amont les adresses malformées plutôt que d'attendre le rejet.
- SmartMonitor et SmartNotify surveillent les statuts et remontent les non-routages par partenaire, avec le dossier de preuve technique associé à chaque document.
Le tout reste connecté à la Plateforme Agréée de votre choix : changer de PA ne remet en cause ni vos mappings, ni votre référentiel d'adressage.
FAQ
Qu'est-ce que le BT-49 dans une facture électronique ?
Le BT-49 est le champ de la norme EN 16931 qui porte l'adresse électronique de l'acheteur, celle qui sert à router la facture vers la bonne plateforme et le bon service. Il est complété par un attribut de schéma (BT-49-1) qui indique comment lire l'identifiant : 0002 pour un SIREN, 0009 pour un SIRET, 0225 pour l'adresse électronique française de facturation. En UBL, il correspond à cbc:EndpointID ; en CII et Factur-X, à ram:URIUniversalCommunication/ram:URIID.
Quel est le format d'une adresse électronique de facturation en France ?
Les spécifications externes B2B (version 3.2 du 30 avril 2026) prévoient quatre formes, toutes commençant par le SIREN de l'entreprise et séparées par un tiret bas : SIREN pour l'entité juridique, SIREN_SIRET pour un établissement, SIREN_SIRET_CODEROUTAGE pour un service exécutant, et SIREN_SUFFIXE pour un flux dédié. L'adresse complète est plafonnée à 95 caractères et n'accepte ni accents, ni espaces, ni arobase. Un SIRET seul, sur 14 chiffres, n'est donc pas une adresse valide sous le schéma 0225.
Faut-il adresser une facture au SIREN, à l'établissement ou à un service ?
Cela dépend de ce que le destinataire a déclaré dans l'annuaire central. La maille SIREN adresse l'entité juridique entière, la maille SIREN_SIRET un établissement précis, et le suffixe ou le code routage un service interne (direction achats, centre de services partagés). Utilisez la maille la plus fine réellement publiée dans l'annuaire : un suffixe communiqué par mail mais non déclaré ne permet aucune livraison.
Que se passe-t-il si l'adresse électronique est absente ou fausse ?
La facture ne peut pas être routée. Selon la plateforme, elle est rejetée techniquement ou orientée vers une adresse par défaut qui n'est pas la bonne file de traitement. Dans les deux cas, il s'agit d'un rejet à corriger et à retransmettre, pas d'un refus de l'acheteur. Le risque réel est le délai : sans supervision des statuts, l'anomalie se découvre au moment de la relance de paiement.
Quelle différence entre un code routage et un suffixe ?
Le code routage reprend la logique du code service exécutant du secteur public : il s'ajoute après le SIRET, dans la forme SIREN_SIRET_CODEROUTAGE. Le suffixe est le mécanisme libre du B2B privé, choisi par le destinataire pour séparer ses flux, dans la forme SIREN_SUFFIXE. Les deux se déclarent dans l'annuaire par la plateforme du destinataire, et aucun des deux ne se devine. À ne pas confondre non plus avec le numéro d'engagement, qui reste une donnée de gestion portée par un autre champ de la facture.
Références
- impots.gouv.fr, spécifications externes B2B, version 3.2 du 30 avril 2026 (versions antérieures : 3.1 du 31 octobre 2025, 3.0 du 18 décembre 2024)
- economie.gouv.fr, qu'est-ce que l'annuaire de la facturation électronique
- aife.economie.gouv.fr, facturation électronique interentreprises
- fnfe-mpe.org, Factur-X : spécifications et profils
- docs.peppol.eu, Peppol BIS Billing 3.0, règles de validation EndpointID
- Normes AFNOR XP Z12-012, XP Z12-013 et XP Z12-014, et liste de codes EAS (ISO/IEC 6523)
Vos adresses de facturation sont-elles à jour ? SwiftEDI Solutions audite votre référentiel d'adressage, confronte vos 50 premiers partenaires à l'annuaire et cadre la bascule, connecté à la Plateforme Agréée de votre choix. Réservez une démo de 30 minutes : cartographie de flux gratuite et plan de bascule chiffré.