L'adresse électronique du vendeur ne porte pas son SIREN sur une autofacture

Sur une transaction déclarée B2B dont le type de document est une autofacture (389, 501, 500, 471, 473, 261, 502), l'adresse électronique du vendeur (BT-34) doit commencer par son SIREN (BT-30) et porter le schéma 0225.

Seul l’émetteur détient cette valeur : Factlint la signale et ne la fabrique jamais. Testez votre facture pour savoir si elle est concernée.

Le message que votre validateur affiche

Recopié tel quel de l’artefact scellé : c’est la phrase exacte que le contrôle imprime quand cette règle échoue.

cii
BR-FR-22/BT-34 : Si le traitement est BAR/B2B et que le type de document (BT-3) est en autofacture (389, 501, 500, 471, 473, 261, 502), alors le BT-34 (EndpointID du vendeur) doit commencer par le SIREN (BT-30) et le BT-34-1 (schemeID) doit être égal à "0225". Valeurs actuelles : EndpointID=" ", schemeID=" ", SIREN=" ".

ubl
[BR-FR-22/BT-34] : Si le traitement est BAR/B2B et que le type de document (cbc:InvoiceTypeCode) est en autofacture (389, 501, 500, 471, 473, 261, 502), alors le BT-34 (cbc:EndpointID du vendeur) doit commencer par le SIREN (cbc:ID[@schemeID='0002']) et le schemeID doit être égal à "0225". Valeurs actuelles : EndpointID=" ", schemeID=" ", SIREN=" ".

Cité de schematron-fnfe 1.4.0.03, sous licence Apache-2.0.

Requêtes fréquentes autour de ce code

Ces formulations reprennent les recherches réelles d’un intégrateur : code, syntaxe, règle, champ métier et correction.

BR-FR-22 L'adresse électronique du vendeur ne porte pas son SIREN sur une autofactureBR-FR-22 Règles françaises BR-FR-CTCBR-FR-22 BT-34BR-FR-22/BT-34 : Si le traitement est BAR/B2B et que le type de document (BT-3) est en autofacture (389, 501, 500, 471, 473, 261, 502), alors le BT-34 (EndpointID du vendeur) doit commencer par le SIREN (BT-30) et le BT-34-1 (schemeID) doit être égal à "0225". Valeurs actuelles : EndpointID=" ", schemeID=" ", SIREN=" ".BR-FR-22 correction

Tester votre fichier avec cette erreur en tête

Déposez la facture concernée : le rapport dira si ce code apparaît, où il apparaît dans le document, et si Factlint peut seulement le signaler ou aussi le corriger.

Pour automatiser ce contrôle dans une chaîne ERP, appelez l’API de validation et reliez chaque code rendu à sa fiche publique.

Ouvrir le validateur Voir l’API

Pourquoi cette erreur se produit

En autofacturation, c'est l'acheteur qui émet et le vendeur qui reçoit : le destinataire à router est donc le vendeur, et c'est son adresse 0225 que l'annuaire doit reconnaître. La règle est le miroir de BR-FR-21, appliqué au flux inverse. La règle vient du pack Schematron FNFE, pas de la norme européenne : une facture parfaitement conforme à l'EN 16931 la déclenche dès qu'elle est jugée contre le socle français.

Comment la corriger

Renseignez dans BT-34 l'adresse de réception du vendeur telle que l'annuaire la publie, en schéma 0225. Factlint ne consulte pas l'annuaire et n'invente pas une adresse de routage.

Sévérité rendue par le référentiel

Bloquante depuis le 1er septembre 2026 : le socle courant, `fr-2026-09`, scelle l'artefact FNFE 1.4.0.03 en mode fatal, et c'est lui que le moteur épinglé applique par défaut. Une facture émise en août 2026 est jugée contre `fr-2026-08`, où la même règle sort en avertissement — ce qui écarte déjà le verdict « conforme ». L'API rend la sévérité du ruleset épinglé pour la facture jugée.

Exemple de correction XML

AVANT (invalide)

<ram:SellerTradeParty>…<ram:URIID schemeID="0088">3012345678901</ram:URIID>…</ram:SellerTradeParty>

APRÈS (conforme)

<ram:SellerTradeParty>…<ram:URIID schemeID="0225">123456789</ram:URIID>…</ram:SellerTradeParty>