BT-3Invoice type code
Texte officiel de la règle
[BR-DE-17] Only the following codes from the code list UNTDID 1001 shall be transmitted in the element "Invoice type code" (BT-3): 326 (Partial invoice), 380 (Commercial invoice), 384 (Corrected invoice), 389 (Self-billed invoice) and 381 (Credit note), 875 (Partial construction invoice), 876 (Partial final construction invoice), 877 (Final construction invoice).
Le texte normatif est en anglais ; il est cité tel quel.
Pourquoi cette erreur apparaît
XRechnung restreint la liste UNTDID 1001 : seuls 326 (facture partielle), 380 (facture commerciale), 384 (facture rectificative), 389 (autofacturation), 381 (avoir), 875, 876 et 877 (factures de travaux) devraient être utilisés dans BT-3. La règle compare cbc:InvoiceTypeCode / cbc:CreditNoteTypeCode (UBL) ou rsm:ExchangedDocument/ram:TypeCode (CII) à cette liste et émet un avertissement dans le cas contraire. Les cas fréquents sont 386 (facture d'acompte), 383 (note de débit) ou 82 (services mesurés), valides selon la norme EN 16931 mais non attendus par les administrations allemandes.
Comment corriger
Faites correspondre vos types de documents aux codes autorisés : facture ordinaire 380, facture partielle ou d'échéance 326, rectification 384, avoir 381 (sous forme de cn:CreditNote en UBL), autofacturation 389, factures de travaux partielle/partielle finale/finale 875/876/877. Une demande d'acompte est normalement émise en 380 ou 326 avec l'acompte mentionné dans le libellé de ligne ; la facture finale utilise ensuite BT-113 (montant déjà payé) pour les sommes déjà réglées. Il s'agit d'un avertissement, mais de nombreux destinataires le traitent comme une erreur.
Exemple (valide)
<cbc:InvoiceTypeCode>380</cbc:InvoiceTypeCode>Ce que le validateur vérifie
Élément vérifié (contexte):
UBL
/ubl:Invoice | /cn:CreditNoteTest (XPath):
normalize-space(cbc:InvoiceTypeCode) = $supportedInvAndCNTypeCodes or normalize-space(cbc:CreditNoteTypeCode) = $supportedInvAndCNTypeCodesCII
/rsm:CrossIndustryInvoiceTest (XPath):
normalize-space(rsm:ExchangedDocument/ram:TypeCode) = ('326', '380', '384', '389', '381', '875', '876', '877')Vérifier votre facture
Déposez votre XML ou PDF dans le validateur : chaque règle en échec renvoie vers sa page ici. Gratuit, sans compte, le fichier n'est pas conservé.
La même vérification par API:
curl -F file=@invoice.xml https://einvoicechecker.com/v1/validateRègles liées
BR-DE-26Facture rectificative (384) sans référence à la facture antérieureBR-DE-1Les instructions de paiement (BG-16) sont absentesBR-DE-2Le contact du vendeur (BG-6) est absentBR-DE-3La ville du vendeur (BT-37) est absenteBR-DE-4L'élément « Code postal du vendeur » doit être transmisBR-DE-5Le point de contact du vendeur (BT-41) est absentBR-DE-6Le téléphone du contact vendeur (BT-42) est absentBR-DE-7L'adresse e-mail du contact vendeur (BT-43) est absente
Questions fréquentes
Que signifie BR-DE-17 ?
BR-DE-17 est une règle xrechnung : Only the following codes from the code list UNTDID 1001 shall be transmitted in the element "Invoice type code" (BT-3): 326 (Partial invoice), 380 (Commercial invoice), 384 (Corrected invoice), 389 (Self-billed invoice) and 381 (Credit note), 875 (Partial construction invoice), 876 (Partial final construction invoice), 877 (Final construction invoice).
Ma facture sera-t-elle rejetée à cause de BR-DE-17 ?
Non. BR-DE-17 est un avertissement : la facture est acceptée mais le destinataire voit la remarque. Corrigez-la quand même, les avertissements deviennent souvent des erreurs dans les versions suivantes.
À quels formats s'applique BR-DE-17 ?
XRechnung en syntaxe UBL ou CII, y compris les PDF Factur-X / ZUGFeRD au profil XRECHNUNG. Obligatoire pour facturer les administrations publiques allemandes. Syntaxe : UBL et CII.
Source: XRechnung 3.0.2, schematron 2.6.0 (KoSIT, September 2026). Catalogue généré à partir des jeux de règles officiels le 2026-10-15.