Guide exemple fichier norme 34 SEPA XML : structure, modèles et exemples

Bien qu’il puisse sembler être quelque chose du passé, le fichier Norme 34 (ou AEB 34) est encore très présent dans de nombreux systèmes de gestion qui l’utilisent encore pour générer des virements. Cependant, voici ce qui est important : pour que les banques puissent traiter les encaissements, il est obligatoire de convertir ce fichier au format SEPA XML. Bien comprendre ce changement est essentiel pour éviter que vos reçus soient retournés et pour que vos opérations financières ne s’arrêtent pas.

Le fichier Norme 34 et pourquoi il faut le convertir en SEPA XML

Pendant de nombreuses années, la Norme 34 (ou Cahier 34 de l’Association Espagnole de Banque) était la norme de référence en Espagne pour émettre des virements de prélèvements domiciliés. Il s’agit d’un fichier texte brut, avec une structure très rigide et de longueur fixe, conçu uniquement pour fonctionner au sein du système bancaire espagnol.

Tout cela a changé avec l’arrivée de la Zone Unique de Paiements en Euros (SEPA). L’objectif de SEPA était très clair : unifier les transactions en euros sous un même parapluie de règles et de normes techniques, ce qui facilitait grandement les opérations entre pays.

La migration obligatoire vers la norme SEPA XML

Le format qui est venu remplacer la Norme 34 pour les prélèvements directs est le SEPA XML, spécifiquement le schéma connu sous le nom de pain.008.001.02. Contrairement à son prédécesseur, le XML est un format beaucoup plus polyvalent et complet, car il est basé sur la norme internationale ISO 20022.

Ce changement n’est pas une suggestion, c’est une obligation. Les banques n’acceptent plus les fichiers dans l’ancien format AEB 34 pour traiter les encaissements. C’est pourquoi toute entreprise qui continue à générer des virements depuis un ERP ou un logiciel ancien doit, sans faute, les convertir au format XML avant de les envoyer à l’entité bancaire.

Passer à SEPA, bien qu’obligatoire, apporte plusieurs avantages importants :

• Conformité réglementaire : Vous vous assurez que vos virements suivent la réglementation européenne, ce qui évite les rejets automatiques de la part de la banque.
• Moins d’erreurs : Le format XML a des validations internes et des champs de données beaucoup plus spécifiques, comme l’identifiant du mandat, qui aident à réduire les erreurs manuelles typiques.
• Plus grande efficacité : En unifiant tout sous la norme SEPA, la gestion des encaissements est simplifiée, surtout si vous avez des clients dans d’autres pays de la zone euro.

Si vous voulez en savoir plus sur ce format hérité, nous vous recommandons de lire notre article sur ce qu’est un fichier Norme 34 et pourquoi sa conversion est si importante aujourd’hui.

L’anatomie d’un fichier de prélèvements SEPA XML (Norme 34)

Pour vraiment comprendre comment les informations d’un ancien fichier Norme 34 sont transformées, il n’y a rien de tel que de se plonger dans les entrailles d’un exemple de fichier SEPA XML. À première vue, le nombre d’étiquettes et la structure hiérarchique peuvent être un peu intimidants, mais en réalité tout suit une logique très claire et ordonnée.

Un fichier de prélèvements directs SEPA (techniquement connu sous le nom de pain.008.001.02) est organisé en trois grands blocs. Chacun a une mission concrète : de l’identification du virement dans son ensemble jusqu’au détail de chacun des encaissements individuels. Maîtriser cette structure est fondamental pour savoir si vos données ont été converties correctement et pour pouvoir résoudre tout problème.

Attention au détail : un fichier SEPA XML bien construit est votre meilleure assurance contre les retours. On estime que les erreurs dans la génération de virements coûtent aux PME entre 1 % et 2 % de la valeur totale, en additionnant les commissions bancaires et les frais de gestion.

Décomposons ces blocs pour que vous puissiez voir quelles informations ils contiennent et, surtout, pourquoi c’est si important.

Structure principale d’un fichier SEPA XML (pain.008.001.02)

Pour avoir une vue d’ensemble, ce tableau résume les blocs principaux que vous trouverez dans tout fichier de prélèvements directs. C’est une aide-mémoire parfaite pour identifier rapidement où se trouve chaque type d’information.

Bloc XML (Étiquette)	Description du contenu	Exemple de champ clé
GrpHdr (En-tête du Groupe)	Contient les données globales du virement. Agit comme la couverture du fichier, identifiant le lot complet de transactions.	MsgId (Identifiant du message)
PmtInf (Information de Paiement)	Regroupe un ensemble de prélèvements sous des conditions communes, comme la date d’encaissement ou le compte du créancier.	ReqdColltnDt (Date d’encaissement)
DrctDbtTxInf (Transaction Individuelle)	Détaille chaque encaissement individuel : le montant, le débiteur, son compte bancaire et la référence du mandat associé.	InstdAmt (Montant du prélèvement)

Comme vous pouvez le voir, la structure va du général au particulier, assurant que toutes les informations sont organisées de manière logique pour que les systèmes bancaires les traitent sans erreurs.

Le bloc d’en-tête du groupe (GrpHdr)

Pensez à ce bloc comme à la couverture de votre virement. C’est la première chose que lit le système de la banque et il contient les informations qui identifient tout le lot de transactions que vous envoyez.

Ici, vous trouverez des champs clés comme :

• Identifiant du Message (MsgId) : Un code unique que vous assignez vous-même au virement. Il est fondamental pour pouvoir le suivre et le différencier de tout autre. Imaginez que c’est le numéro de facture de tout votre lot d’encaissements.
• Date et Heure de Création (CreDtTm) : Le moment exact où le fichier a été généré, avec le format strict AAAA-MM-DDThh:mm:ss.
• Nombre de Transactions (NbOfTxs) : Le décompte total de prélèvements que contient le fichier. Un simple compteur.
• Somme de Contrôle (CtrlSum) : Le montant total qui résulte de l’addition de tous les prélèvements. La banque utilise cette donnée comme une double vérification pour s’assurer qu’aucune transaction n’a été perdue ou modifiée en cours de route.

Le bloc d’information de paiement (PmtInf)

Juste après l’en-tête, apparaît ce deuxième grand bloc. Sa fonction est de regrouper les transactions qui partagent les mêmes conditions de paiement. Par exemple, tous les reçus qui seront encaissés à la même date et depuis le même compte bancaire de votre entreprise iront dans le même bloc PmtInf.

Dans ce bloc, les données les plus importantes sont :

• Identifiant de l’Ordre de Paiement (PmtInfId) : Une autre référence unique, mais cette fois pour ce groupe spécifique de paiements.
• Méthode de Paiement (PmtMtd) : Pour les prélèvements directs, ce champ contiendra toujours la valeur DD (Direct Debit).
• Date d’Encaissement Requise (ReqdColltnDt) : La date à laquelle vous voulez que la banque passe les reçus à l’encaissement auprès de vos clients.
• Données du Créancier (Cdtr) : Ici vont votre nom ou raison sociale et votre identifiant de créancier SEPA.
• Compte du Créancier (CdtrAcct) : Votre numéro de compte au format IBAN.

Le bloc de transactions individuelles (DrctDbtTxInf)

Nous arrivons au cœur du fichier. Imbriqué dans chaque bloc PmtInf, vous trouverez autant de blocs DrctDbtTxInf que de reçus individuels que vous voulez encaisser. Chacun représente un unique prélèvement à un client concret.

C’est le niveau de détail maximum, où toute l’information de l’encaissement est spécifiée :

• Montant du Prélèvement (InstdAmt) : Le montant exact qui sera débité au client.
• Identifiant du Mandat (MndtId) : La référence unique du mandat SEPA que votre client a signé autorisant l’encaissement. C’est une donnée critique.
• Date de Signature du Mandat (DtOfSgntr) : La date à laquelle cette autorisation a été signée.
• Données du Débiteur (Dbtr) : Le nom et l’adresse du client à qui on fait le prélèvement.
• Compte du Débiteur (DbtrAcct) : L’IBAN du compte bancaire de votre client.
• Concept du Reçu (RmtInf) : Une description claire de l’encaissement, comme “Cotisation mensuelle salle de sport” ou “Facture AB-2024-05”.

Mapping des champs : de la Norme 34 au XML SEPA

Passer de la classique Norme 34 à la norme SEPA XML est, au fond, comme traduire une langue. Il s’agit de prendre les informations que vous aviez déjà et de les placer au bon endroit dans une nouvelle structure. Comprendre cette correspondance est fondamental pour que la migration se passe bien du premier coup, sans erreurs qui retardent vos encaissements.

Le principal défi est qu’il n’y a pas toujours une équivalence directe. Le format SEPA introduit de nouveaux champs qui n’existaient tout simplement pas dans la Norme 34, surtout ceux qui ont à voir avec la gestion du mandat de domiciliation. Par exemple, une donnée aussi importante que la date de signature du mandat est obligatoire en SEPA, mais n’était pas envisagée dans l’ancien format AEB 34.

Correspondance des champs Norme 34 vs. SEPA XML

Pour que vous ayez une idée claire de comment fonctionne cette “traduction”, j’ai préparé un tableau de référence. Ici, vous pouvez voir d’un coup d’œil où va chaque donnée de votre fichier original quand vous le convertissez en SEPA XML. C’est une aide-mémoire parfaite pour résoudre rapidement les doutes.

Champ en Norme 34 AEB	Étiquette XML correspondante en SEPA	Observations importantes
NIF de l’Ordinateur	<Id><OrgId><Othr><Id> dans Cdtr	Identifie l’entreprise qui émet l’encaissement.
Compte du Débiteur	<DbtrAcct><Id><IBAN>	Le format change de CCC à IBAN, qui est obligatoire en SEPA.
Montant du Reçu	<InstdAmt>	Doit être spécifié avec la devise, par exemple, <InstdAmt Ccy="EUR">.
Référence Domiciliation	<MndtId>	Devient l’identifiant unique du mandat SEPA.
Concept du Reçu	<RmtInf><Ustrd>	C’est le texte que le client verra sur son relevé bancaire.

Comme vous pouvez le voir, la logique est assez directe pour les champs de base. Le vrai changement vient avec les informations que SEPA ajoute pour donner plus de sécurité et de traçabilité aux opérations.

Nouveaux champs et considérations clés

Au-delà de l’équivalence directe, le format XML SEPA va vous demander des données supplémentaires. Ignorer ces nouveaux requis est la cause numéro un pour laquelle les banques rejettent les fichiers de virements. Faites attention, car ils sont obligatoires.

Les données les plus importantes que vous devrez ajouter et qui n’étaient pas dans la Norme 34 sont :

• Identifiant du Créancier SEPA : C’est un code unique qui vous identifie comme émetteur de prélèvements dans toute la zone SEPA. Si vous ne l’avez pas, votre banque doit vous le fournir.
• Date de Signature du Mandat (DtOfSgntr) : La date exacte où votre client a signé l’autorisation. Ce champ est absolument indispensable.
• Type de Séquence (SeqTp) : Sert à indiquer si l’encaissement est récurrent (RCUR), le premier d’une série (FRST), le dernier (FNAL) ou un paiement unique (OOFF).

Un mapping correct est la base pour que la conversion fonctionne. Des convertisseurs SEPA font tout ce travail pour vous. Ils interprètent votre fichier Excel, CSV ou Norme 34, placent chaque donnée dans son étiquette XML correspondante et ajoutent les nouveaux champs pour générer un fichier SEPA valide instantanément.

Modèles et fichiers d’exemple à télécharger

Pour que vous puissiez commencer à travailler et comprendre tout le processus de manière pratique, nous avons préparé un paquet de ressources prêtes à télécharger. Avec ces fichiers, vous verrez très clairement comment on passe des données originales au fichier final qui est présenté à la banque.

Voici un exemple de fichier norme 34 sepa xml à chacune de ses étapes. Il vous servira à comparer les différentes structures, faire des tests dans vos propres programmes ou, simplement, les utiliser comme point de départ pour générer vos propres virements.

Les fichiers que vous pouvez télécharger sont les suivants :

• Fichier original en Norme 34 : Un fichier texte brut (.txt) qui est un exemple typique de ce qu’un ERP ou un système de gestion plus ancien générerait.
• Modèle de données en Excel/CSV : Contient exactement la même information que le virement précédent, mais organisée dans une feuille de calcul, beaucoup plus confortable à manipuler et éditer.
• Fichier SEPA XML final : Le fichier .xml qui s’obtient après la conversion, déjà validé et avec le format correct pour qu’aucune banque ne le traite.

Ce diagramme résume très bien le flux de conversion, partant d’un fichier N34 pour arriver à son équivalent en SEPA XML.

Comme vous pouvez le voir, le graphique montre clairement à quel point le processus est simple si on utilise un outil de conversion approprié. Il s’agit, en fin de compte, de transformer un format qui est déjà devenu obsolète en la norme XML que les banques exigent. Si vous avez besoin de plus de détails, je vous recommande de jeter un œil aux formats de fichiers que vous pouvez télécharger pour convertir.

Erreurs communes et validations clés lors de la génération du XML

Créer un exemple de fichier Norme 34 SEPA XML sans erreurs du premier coup est l’idéal, mais la réalité est que les erreurs sont monnaie courante. Un petit oubli suffit pour que la banque rejette le virement complet, ce qui se traduit par des retards dans les encaissements et, bien sûr, des coûts administratifs que vous n’aviez pas prévus.

Ces problèmes naissent généralement de détails qui sont négligés, que ce soit dans les données d’origine ou dans la structure même du fichier. La bonne nouvelle est que la plupart sont des erreurs typiques, faciles à prévoir et, par conséquent, à éviter. C’est pourquoi il est crucial d’effectuer une série de validations avant de considérer le fichier comme bon et de l’envoyer.

Pensez à ces vérifications comme à une liste de contrôle qualité. Les réviser vous fera gagner du temps, de l’argent et la frustration d’avoir à corriger et renvoyer des virements.

Validations essentielles avant l’envoi

Avant de télécharger votre fichier XML sur la banque en ligne, ne jouez pas avec le feu. Assurez-vous que ces points critiques sont parfaits, car une erreur dans n’importe lequel d’entre eux est une raison de rejet presque certaine.

• Format de l’IBAN : Cela semble évident, mais c’est l’une des erreurs les plus fréquentes. Vérifiez que tous les IBAN sont corrects, y compris le code du pays (ES pour l’Espagne) et ses deux chiffres de contrôle. Un seul IBAN mal formaté et la transaction associée sera invalidée.
• Somme de contrôle (CtrlSum) : Mathématiques pures. Le montant total que vous indiquez dans l’en-tête du groupe (GrpHdr) doit être exactement la somme de tous les montants individuels des transactions (InstdAmt). Tout déséquilibre, même d’un centime, fera sonner les alarmes de la banque.
• Cohérence des dates : La date d’encaissement (ReqdColltnDt) doit toujours être une date future et réaliste. N’oubliez pas les délais de présentation que votre banque vous exige ; par exemple, pour les prélèvements CORE, il est habituel de devoir envoyer le virement avec au moins D-2 jours ouvrables d’avance.
• Identifiants uniques : Le MsgId (le DNI du message) et les PmtInfId (l’identifiant de chaque bloc de paiement) doivent être uniques pour chaque virement. Si vous réutilisez des identifiants d’envois précédents, vous risquez que le système l’interprète comme un doublon et le rejette d’emblée.

Un conseil pratique : La validation automatique est votre meilleure alliée dans ce processus. Au lieu de devenir fou en révisant des centaines de lignes de code à la main, des outils de validation analysent le fichier en quelques secondes. Ils détectent ces erreurs et bien d’autres avant qu’elles n’arrivent à la banque. Cela ne prévient pas seulement les retours, mais réduit aussi les coûts opérationnels que génère la gestion des incidents.

Avoir un bon validateur vous donne la tranquillité que votre fichier est techniquement solide, vous permettant de vous concentrer sur ce qui compte vraiment : la gestion de votre entreprise, pas la résolution de problèmes techniques.

Automatisez la conversion de fichiers avec une API

Générer des virements à la main est une tâche lente, répétitive et, soyons honnêtes, une source constante d’erreurs qui finit par coûter du temps et de l’argent. Si vous voulez vraiment optimiser la création d’un exemple de fichier Norme 34 SEPA XML ou n’importe quel autre virement, l’automatisation est la seule voie. Chez GenerateSEPA, nous vous facilitons la tâche avec deux solutions qui s’adaptent parfaitement à votre équipe, qu’elle soit administrative ou plus technique.

Pour le quotidien des départements de finances et d’administration, notre plateforme web est l’outil parfait. C’est aussi simple que de télécharger un fichier en Excel, CSV ou même dans l’ancien format Norme 34. En quelques secondes, vous avez votre fichier SEPA XML validé et prêt à envoyer à la banque. Tout le processus est très visuel et intuitif, sans avoir besoin de se battre avec la complexité technique du XML.

C’est la façon la plus directe et contrôlée de gérer les virements.

L’interface est propre et claire : vous sélectionnez votre fichier source et la conversion s’occupe du reste.

Intégration totale pour développeurs avec l’API JSON

Maintenant, si ce que vous cherchez est l’efficacité maximale, la clé est d’intégrer la génération de virements directement dans vos systèmes, qu’il s’agisse d’un ERP, d’un CRM ou d’un logiciel sur mesure. Et c’est là que notre API JSON entre en jeu et fait une grande différence. Nous offrons aux développeurs un endpoint solide et fiable pour automatiser tout le processus de conversion de A à Z.

Qu’est-ce que cela signifie en pratique ? Que les fichiers peuvent être générés et validés sans que personne n’ait à intervenir manuellement. Votre système envoie les données du virement à notre API et reçoit en retour le fichier SEPA XML, déjà corrigé et prêt à utiliser. Cette intégration ne fait pas qu’économiser une quantité énorme de temps, elle garantit aussi que tout soit cohérent, réduisant les erreurs pratiquement à zéro. Si vous voulez connaître les détails techniques, vous pouvez consulter notre guide sur comment utiliser notre API.

“L’automatisation via une API n’est pas seulement une amélioration de l’efficacité ; c’est un avantage stratégique. Elle permet aux entreprises d’augmenter leurs opérations d’encaissement sans augmenter proportionnellement leur charge administrative, libérant l’équipe pour qu’elle se concentre sur des tâches de plus grande valeur.”

Les chiffres ne mentent pas : le volume de transactions numériques ne cesse d’augmenter. Rien qu’au premier semestre 2025, les transferts SEPA en Espagne ont augmenté de 12,7 % pour atteindre 1,584 milliard d’opérations, tandis que les prélèvements directs ont totalisé 1,143 milliard. Ce volume massif met en évidence la nécessité d’outils d’automatisation comme le nôtre, qui convertit les formats hérités comme la Norme 34 au XML requis. Ainsi, on évite les erreurs qui, selon les estimations du secteur, peuvent coûter aux PME entre 1-2 % de la valeur totale du virement. Vous pouvez en lire plus sur cette croissance dans Europa Press.

Sécurité et flexibilité dans l’automatisation

Quand il s’agit de données bancaires, la sécurité n’est pas négociable. Nous le prenons très au sérieux et protégeons vos informations avec plusieurs couches de sécurité :

• Chiffrement des données : Toute la communication, tant avec l’API qu’avec la plateforme web, voyage complètement chiffrée.
• Suppression automatique : Les fichiers que vous téléchargez et les résultats que nous générons sont supprimés de façon permanente de nos serveurs en seulement 10 minutes. Nous ne gardons rien.
• Flexibilité des formats : Notre API est conçue pour être flexible et comprendre les particularités de différents fichiers sources, s’adaptant à ce dont chaque entreprise a besoin.

Cette combinaison de simplicité pour les utilisateurs métier et de puissance pour les développeurs est ce qui fait de notre outil une solution adaptée pour moderniser et sécuriser la gestion de vos virements.

Pour les remises de prélèvements, l’ancien format équivalent est décrit dans notre guide de la norme SEPA 19, et vous trouverez un exemple de fichier pain.008.001.02 annoté balise par balise.

Questions fréquentes sur les fichiers Norme 34 et SEPA XML

Pour compléter ce guide sur comment passer de la Norme 34 à la norme SEPA, j’ai voulu recueillir les doutes les plus communs que vous rencontrerez au quotidien. Pensez-y comme à une aide-mémoire avec des réponses rapides, claires et directes, pour que vous ne restiez pas bloqué.

Ici, vous allez trouver des solutions aux problèmes typiques : de comprendre ce qui différencie un format d’un autre, jusqu’à savoir comment réagir quand la banque vous renvoie un virement. C’est le complément idéal à avoir toujours à portée de main.

Quelle est la principale différence entre un fichier Norme 34 et un SEPA XML ?

La grande différence est dans sa structure et où ils fonctionnent. Le fichier Norme 34 est un format de texte brut, de toujours, avec une longueur fixe pour chaque ligne. Il a été conçu pour fonctionner uniquement en Espagne et, soyons honnêtes, c’est une technologie qui est déjà très dépassée.

En revanche, un fichier SEPA XML est une norme européenne basée sur la norme internationale ISO 20022. Sa structure utilise des étiquettes, comme une page web, ce qui lui donne une flexibilité énorme et permet d’inclure beaucoup plus d’informations. Aujourd’hui, le SEPA XML est le seul format que les banques acceptent pour traiter les prélèvements directs dans toute la Zone Unique de Paiements en Euros.

Qu’est-ce qu’exactement l’identifiant du mandat dans un fichier SEPA ?

L’identifiant du mandat, que dans le fichier XML vous verrez comme <MndtId>, n’est rien de plus qu’une référence unique pour l’autorisation d’encaissement que votre client vous a signée. C’est, pour ainsi dire, le DNI de cette permission.

Cette référence, vous la mettez vous-même en tant qu’entreprise et elle ne peut pas être répétée pour la même combinaison de client et contrat. C’est un champ vital que vous devez garder en lieu sûr avec la date de signature, car les deux données sont obligatoires dans chaque encaissement que vous lancez.

Pour vous servir de référence, dans l’ancienne Norme 34, cette donnée s’appelait “Référence de la domiciliation”. La clé maintenant est qu’avec SEPA, la gestion et le suivi de ces mandats sont beaucoup plus stricts.

Pourquoi ma banque a-t-elle rejeté un fichier SEPA XML ?

Que la banque vous renvoie un virement est une nuisance, mais la bonne nouvelle est que c’est presque toujours dû à des erreurs de format ou de données qui peuvent être évitées facilement. Les causes les plus habituelles d’un rejet sont :

• Erreurs dans l’IBAN : Un chiffre de contrôle mal calculé ou un format qui n’est pas valide et cette transaction est exclue instantanément.
• Les comptes ne correspondent pas : Si le montant total que vous mettez dans l’en-tête (CtrlSum) ne coïncide pas avec la somme de tous les prélèvements, la banque rejettera le fichier entier.
• Format de date incorrect : Toutes les dates doivent aller sans faute au format AAAA-MM-DD. Sans exceptions.
• Caractères “bizarres” : Utiliser le “ñ” ou n’importe quel autre symbole non standard peut causer des problèmes si le fichier n’est pas codé correctement en UTF-8.
• Données du mandat manquantes : Oublier l’identifiant du mandat ou sa date de signature est une erreur critique qui invalide l’encaissement.

Le plus intelligent est d’utiliser un validateur automatique ou un outil spécialisé avant d’envoyer quoi que ce soit à la banque. C’est la meilleure façon de détecter ces erreurs et de s’assurer que le virement passe du premier coup.

Quelle différence y a-t-il entre le schéma SEPA CORE et le B2B ?

Quand vous préparez un fichier de prélèvements, vous devez choisir entre deux schémas. La décision dépend de qui vous allez facturer.

• Schéma CORE : C’est le basique et celui qui est utilisé 99 % du temps. Il vous sert à facturer n’importe quel client, qu’il s’agisse d’un particulier, d’un indépendant ou d’une entreprise. L’important est qu’il offre un délai de retour jusqu’à 8 semaines sans donner d’explications, et jusqu’à 13 mois si l’encaissement n’était pas autorisé.
• Schéma B2B (Business-to-Business) : Comme son nom l’indique, il est pensé uniquement pour facturer d’autres entreprises ou indépendants. Sa grande différence est que le client renonce au droit de retour. Cela fait que les délais pour présenter les encaissements sont plus courts, mais en échange cela vous exige de maintenir un contrôle des mandats beaucoup plus rigoureux.

---

En avez-vous assez de vous battre avec la complexité des fichiers SEPA et les rejets de la banque ? Avec GenerateSEPA, vous pouvez transformer vos fichiers Excel, CSV ou Norme 34 en un XML validé et prêt à envoyer en quelques secondes. Automatisez vos virements et économisez du temps et des maux de tête. Essayez-le gratuitement pendant 7 jours et simplifiez vos encaissements dès aujourd’hui.

---

Questions fréquentes

Quelle est la principale différence entre un fichier Norme 34 et un XML SEPA ?

Le fichier Norme 34 (Cuaderno 34 de l'AEB) est un format texte à longueur fixe conçu uniquement pour le système bancaire espagnol. Le XML SEPA suit la norme ISO 20022, utilise des balises structurées et fonctionne dans toute la zone SEPA. Il impose aussi des champs que l'ancien format ne prévoyait pas. Les banques espagnoles n'acceptent plus les fichiers Norme 34 : seul le XML SEPA est valable aujourd'hui.

Qu'est-ce que l'identifiant de mandat et pourquoi est-il obligatoire ?

L'identifiant de mandat (balise MndtId), appelé RUM en France, est la référence unique de l'autorisation de prélèvement signée par le client. C'est le créancier qui l'attribue, et elle ne doit pas se répéter pour un même couple client-contrat. Si le débiteur conteste un prélèvement, sa banque s'appuie sur cette référence et sur la date de signature pour vérifier que l'autorisation existait.

Pourquoi la banque rejette-t-elle un XML SEPA dont les données semblent correctes ?

Les rejets viennent souvent de détails invisibles à l'œil nu : IBAN avec une clé de contrôle fausse ou des espaces cachés, total de contrôle (CtrlSum) qui ne correspond pas à la somme des opérations, date qui n'est pas au format AAAA-MM-JJ, identifiants de message réutilisés ou données de mandat manquantes. Passer le fichier dans un validateur avant l'envoi évite qu'une remise entière soit rejetée pour une erreur évitable.

Comment convertir un ancien fichier Norme 34 en XML SEPA ?

Le plus simple est d'exporter les données vers Excel ou CSV, ou d'importer directement le fichier AEB dans un convertisseur SEPA. L'outil ajoute les champs que l'ancien format ne contenait pas et valide les IBAN et les totaux avant de générer le XML. Vous n'avez pas besoin de modifier le XML à la main.

---

Articles liés