L'IBAN de crédit n'est pas valide pour un virement SEPA
Quand `Payment means type code` (BT-81) vaut 58 (virement SEPA), `Payment account identifier` (BT-84) doit être un IBAN correct — forme et clé de contrôle.
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.
[BR-DE-19] "Payment account identifier" (BT-84) soll eine korrekte IBAN enthalten, wenn in "Payment means type code" (BT-81) mit dem Code 58 SEPA als Zahlungsmittel gefordert wird.
Cité de schematron-xrechnung 3.0.2, 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.
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.
Pourquoi cette erreur se produit
La règle recalcule la clé de contrôle, elle ne se contente pas de la forme. Elle attrape donc le chiffre inversé dans un IBAN saisi à la main, que rien d'autre ne détecte avant le rejet bancaire. Les espaces de présentation sont ignorés avant le contrôle : ce n'est jamais la mise en forme qui échoue.
Comment la corriger
Corrigez l'IBAN dans votre référentiel bancaire. Factlint ne l'écrit jamais, même fourni explicitement : l'IBAN est nommément un champ financier (règle 1), et une correction automatique de coordonnées de paiement est exactement l'écriture qu'un fraudeur chercherait à provoquer.
Sévérité rendue par le référentiel
Le pack XRechnung classe cette règle en `warning` — un IBAN douteux n'empêche pas le document d'être formellement conforme. Un avertissement en périmètre écarte malgré tout le verdict « conforme » : au mieux la facture sort en `needs_input`. Et la banque, elle, ne rendra pas d'avertissement.
Exemple de correction XML
<ram:TypeCode>58</ram:TypeCode> … <ram:IBANID>DE00123456789012345678</ram:IBANID>
<ram:IBANID>DE43123456789012345678</ram:IBANID>