Business

Un fichier SEPA validé peut être rejeté, vérifiez la version XSD

13 septembre 2026 Adrien Leclercq-Valette 7 min de lecture

Un fichier SEPA passe un validateur en ligne, s’affiche comme « conforme », puis est rejeté par la banque au moment de l’import. Le problème apparaît souvent après une migration ERP ou un changement de logiciel comptable. La cause tient généralement au niveau de contrôle appliqué : tester un fichier XML ne vérifie pas toujours les mêmes éléments. Voici comment contrôler un fichier SEPA avant son envoi et repérer les erreurs qui bloquent réellement les virements SCT et les prélèvements SDD.

Table des matières

Ce que signifie réellement « tester » un fichier SEPA

Derrière l’expression « tester un fichier SEPA » se trouvent trois niveaux de contrôle. Les confondre explique une grande partie des rejets inattendus.

Le premier vérifie que le fichier est un XML bien formé : les balises sont correctement fermées, l’encodage reste cohérent et l’arborescence peut être lue. Le deuxième confronte le XML au schéma XSD SEPA, le gabarit officiel qui définit les champs obligatoires, leur ordre et leur format. Le troisième applique des règles métier propres à la banque destinataire : cohérence des montants, validité de l’IBAN ou du BIC, présence effective d’un mandat pour un prélèvement.

Un fichier peut donc être bien formé et valide selon le schéma XSD, puis être refusé par l’interface bancaire. Celle-ci peut imposer des contraintes d’import supplémentaires, notamment une version précise du schéma ou des contrôles sur les données déjà enregistrées dans la banque. C’est l’écart le plus souvent découvert après un premier test pourtant concluant.

Les blocs XML à connaître avant de chercher une erreur

Pour localiser un problème sans parcourir chaque ligne du fichier, il faut repérer les trois zones principales de sa structure. La racine de message encadre l’ensemble du document. Le Group Header contient les informations globales de l’envoi : MessageIdentification, CreationDateTime, NumberOfTransactions et ControlSum. Le Payment Information regroupe ensuite les opérations, qu’il s’agisse de virements ou de prélèvements, avec leurs identifiants et leurs dates d’exécution.

Champs spécifiques à un virement SEPA (SCT)

Dans un fichier de virement, chaque transaction contient un EndToEndId pour assurer son suivi, un InstructedAmount pour le montant et les coordonnées du créancier : nom, IBAN et RemittanceInformation pour la référence de paiement. Un fichier qui règle 35 fournisseurs en une seule transmission contient 35 blocs de transaction distincts sous un même Group Header. Le NumberOfTransactions et le ControlSum doivent alors correspondre exactement au nombre d’opérations et à leur total réel.

Champs spécifiques à un prélèvement SEPA (SDD)

Le prélèvement ajoute les données liées au mandat : MandateIdentification, DateOfSignature et SequenceType. Ce dernier accepte quatre valeurs : FRST pour un premier prélèvement, RCUR pour un prélèvement récurrent, OOFF pour une opération unique et FNAL pour la dernière échéance d’une série.

Un fichier qui gère 120 abonnements mensuels utilise généralement RCUR pour les mandats déjà actifs. Les nouveaux abonnés doivent passer par FRST lors de leur première échéance. L’ICS, l’identifiant créancier SEPA délivré par la Banque de France, doit aussi figurer dans le fichier et correspondre à celui déclaré auprès de la banque.

Outils en ligne pour vérifier un fichier avant transmission

Avant l’envoi à la banque, un validateur en ligne permet d’écarter rapidement les erreurs de structure. La procédure reste généralement simple : déposer le fichier XML, sélectionner le type de flux, SCT ou SDD, puis lancer le contrôle. L’outil affiche souvent l’arborescence du document et signale les champs absents ou mal formés. Cette lecture de l’arbre XML aide à retrouver la zone concernée sans chercher manuellement dans l’ensemble du fichier.

La taille du fichier peut toutefois limiter le test. La plupart des validateurs acceptent des fichiers allant jusqu’à environ 1 Mo, ce qui suffit pour quelques centaines de transactions, mais peut devenir insuffisant pour un export volumineux. L’outil testsepa.cedricom.fr propose notamment une visualisation de l’arbre XML. sepaxml.com fait aussi partie des outils associés au test des fichiers SEPA.

Ces services vérifient surtout les deux premiers niveaux : la bonne formation XML et la conformité au schéma XSD. Ils ne remplacent pas le contrôle réalisé par la banque. Pour renforcer le diagnostic, vous pouvez comparer les résultats de deux validateurs. Une différence entre les rapports signale une zone du schéma à vérifier, mais ne prouve pas à elle seule qu’un fichier sera accepté lors de l’import bancaire.

Pourquoi un fichier « validé » peut quand même être rejeté

Le schéma XSD contrôle la structure du fichier, mais il ne vérifie pas toujours si les données correspondent aux attentes du système bancaire destinataire. Une banque peut exiger une version précise du schéma, comme pain.001.001.03 pour les virements ou pain.008.001.02 pour les prélèvements. Son système d’information peut ne pas accepter une version plus récente de la norme ISO 20022, même si cette version passe une validation XSD.

La version XSD attendue doit donc être comparée à celle produite par le logiciel. Ce contrôle est particulièrement nécessaire après une migration ERP, un changement de logiciel comptable ou un changement de banque. Un fichier généré avec une version différente peut être techniquement valide, mais impossible à importer dans l’environnement utilisé par l’établissement.

Les autres causes de rejet concernent des données très concrètes : un IBAN contenant un espace superflu ou un caractère invisible copié depuis un tableur, un mandat non communiqué à la banque, une date de première échéance FRST antérieure à la date de signature du mandat, ou un ControlSum qui ne correspond plus au total des transactions.

La référence unique du mandat, ou RUM, ne doit pas être confondue avec le simple MandateIdentification technique du fichier. Pour un prélèvement, la banque doit pouvoir rattacher l’opération au mandat attendu. L’ICS doit également rester identique à celui enregistré auprès d’elle.

Le ControlSum mérite une vérification spécifique. Toute modification manuelle d’un montant dans le XML doit être répercutée dans le total du Group Header. De même, NumberOfTransactions doit correspondre au nombre réel de lignes. Si l’un de ces deux champs est incorrect, le fichier entier peut être rejeté, même si une seule transaction a été modifiée.

Fiabiliser le contrôle en amont, dans le logiciel qui génère le fichier

Tester chaque fichier après sa génération permet de repérer les erreurs, mais ne les empêche pas toujours. Un contrôle intégré au logiciel réduit le risque dès la préparation du flux. Les principaux logiciels de comptabilité et ERP du marché, comme Sage, Cegid, Yooz, Izysuite ou Deltrian, proposent des contrôles de cohérence avant l’export. Ils peuvent notamment vérifier la présence d’un IBAN valide, l’existence d’un mandat actif pour chaque prélèvement et la concordance entre le nombre de lignes et les totaux déclarés.

Les outils de suivi de trésorerie tels qu’AGICAP, Profiture ou Nibelis ajoutent une couche de contrôle lorsqu’ils consolident plusieurs fichiers avant leur transmission. Cette étape limite les erreurs liées aux manipulations manuelles, en particulier lorsqu’un montant ou une transaction est modifié juste avant l’envoi.

Pour établir une vérification régulière, contrôlez d’abord la version pain.001 ou pain.008 attendue par la banque. Vérifiez ensuite la structure XML et les champs obligatoires avec un validateur en ligne. Comparez le nombre d’opérations et le total du fichier avec les données du logiciel. Pour les prélèvements, contrôlez enfin l’ICS, la RUM, le statut du mandat et le SequenceType.

La transmission peut ensuite s’appuyer sur le protocole EBICS, largement utilisé en France sous sa déclinaison normée STET. Il sécurise l’échange entre l’entreprise et la banque et évite certaines manipulations intermédiaires, comme l’envoi par e-mail ou le dépôt manuel sur un portail web.

Associer un contrôle dans le logiciel, une validation XML avant l’envoi et une transmission par EBICS réduit les risques de rejet. Cette méthode permet de repérer la différence entre un fichier conforme au schéma, un fichier conforme aux données attendues et un fichier réellement importable par la banque.