Financial S upp ly C hai n SEPA Impact de SEPA dans le reporting CODA2.3 pour la domiciliation européenne SEPA version mars 2014 www.ing.be/sepa
Ce guide de référence a pour but de vous aider à réconcilier vos transactions en CODA2.3 dans le processus de migration de la domiciliation belge (DOM80) vers la domiciliation européenne SEPA (SEPA direct debit). Une description complète du CODA est disponible sur le site web de Febelfin dans le document «CODA extrait de compte codifié version 2.3» via le lien : http://www.febelfin.be/fr/paiements/directives-et-protocoles-standards-bancaires
Quelles sont les conséquences d une migration de DOM80 vers SDD (SEPA) pour CODA2.3? Le processus d exécution des domiciliations européennes SEPA diffère du processus d exécution des domiciliations belges DOM80. Il est spécifiquement conçu pour permettre au créancier d effectuer une réconciliation complètement automatisée. Les informations relatives à la non-exécution d une transaction DOM80 dans le reporting du CODA renseignaient quatre motifs (raisons) de refus différents et il n était pas possible de donner de plus amples renseignements concernant la non-exécution de la transaction. Lorsqu une domiciliation européenne SEPA n a pas pu être exécutée, la banque du débiteur envoie une transaction «R» à la banque du créancier. Cette transaction «R» peut contenir cinq types de motifs spécifiques de nonexécution ( reject, return, refund, reversal et request for cancellation ) et donne au créancier de plus amples informations concernant les futures actions à entreprendre. La raison plus détaillée de la non-exécution de la transaction est également communiquée (en quatre positions). Les champs «type de transaction R» et «raison» ont été tous deux ajoutés au champ de la communication structurée 127 dans la version 2.3 du CODA. Impact de SEPA dans le reporting CODA2.3 pour la domiciliation européenne 1
Où trouve-t-on cette communication structurée? Les informations relatives à l exécution ou à la non-exécution des domiciliations concernent différents champs. Pour pouvoir rendre ces informations cohérentes, la version 2.3 du CODA utilise une communication structurée pour ce type d informations. Les communications peuvent être contenues dans l enregistrement «mouvement» (record 2). La zone «structure de communication» indique si la communication est libre (0) ou structurée (1). Dans le cas d une communication structurée, on a déterminé un ensemble de règles spécifiques pour créer un format fixe. Le format est différent pour chaque type de transaction. La communication structurée peut contenir un maximum de 146 caractères, répartis dans trois enregistrements «records» (indiqués en jaune). Lorsque le type de communication d une transaction est structuré, les positions 63-65 définissent le format de la communication. Pour DOM80, la communication structurée est celle qui se trouve dans le type 107, et pour les domiciliations européennes SEPA, il s agit du type 127. Les différents types de communication sont indiqués dans les exemples suivants. Domiciliation belge (DOM80) Vous trouverez dans l exemple ci-dessous les principaux champs repris dans le reporting CODA pour la DOM80. Les champs indiqués sont spécifiques au reporting des domiciliations. Le code de transaction indique quel type de transaction est rapporté, et comment il faut interpréter le reporting. Pour les domiciliations, il s agit du code 05. Le numéro suivant, 52, concerne un crédit sauf bonne fin. Lorsqu une domiciliation est initiée pour un compte créancier chez ING Belgique, le montant total du batch importé est crédité sur votre compte. Après l opération de crédit, ING débitera aussi le compte de toutes les domiciliations non-exécutées, sous la forme d un mouvement global. Il est toutefois possible d obtenir de plus amples informations concernant cette opération globale de débit. L exemple qui suit concerne une information détaillée au sujet des domiciliations impayées de ce batch (code transaction 0503000). La demande exacte et la raison de la non-exécution sont indiquées dans la communication structurée. La manière dont il convient d interpréter cette communication structurée figure dans le relevé ci-dessous, qui donne des explications concernant la communication structurée 107 pour les domiciliations DOM80. Légende: Code de transaction Type communication Code communication Communication Référence Impact de SEPA dans le reporting CODA2.3 pour la domiciliation européenne 2
107 Domiciliation belge (DOM80) Numéro de domiciliation 12N Date pivot 6N JJMMAA Zone de communication 30AN Payé ou motif du refus 1AN 0 : payé 1 : domiciliation révoquée ou inexistante 2 : refus - autre raison D : payeur pas d accord E : numéro de domiciliation associé à un autre numéro d identification du créancier Numéro du créancier 11N Impact de SEPA dans le reporting CODA2.3 pour la domiciliation européenne 3
Domiciliation européenne SEPA (SDD) Les principaux champs dans le reporting CODA pour les domiciliations européennes SEPA figurent dans l exemple ci-dessous. Quand une domiciliation est introduite avec un compte créancier chez ING Belgique, le montant total du batch importé est crédité sur votre compte. Après l opération de crédit, il y aura deux options possibles pour SDD : vous pouvez opter pour un débit des domiciliations impayées sur base des transactions, ou pour un débit du montant global. Dans ce dernier cas, des informations détaillées sont fournies dans la version 2.3 Français du CODA. L exemple qui suit concerne les informations relatives aux domiciliations impayées de ce lot (code transaction 0503000). La manière dont il convient d interpréter cette communication structurée figure dans le relevé ci-dessous, qui donne des explications concernant la communication structurée 127 pour les domiciliations européennes SEPA. 21000200013100363124265001235 1000000001000000031011605030000Impayés sur votre remise Domiciliations Européennes 03101119411 0 2200020001-1.000,00Débiteurs ING, au total 1 paiement(1001638625 BBRUBEBB 1 0 2300020001 s) 0 1 21000200013100363124265001235 1000000001000000031011605030001127011011121BE01ZZZ0123456789 07043 03101119401 0 2200020001 I08755 1001638625 BBRUBEBB OTHR1 0 2300020001BE12310103160192 EURINGBE 1MD020 1 31000200023100363124265001235 605030001I08755 0 1 31000200033100363124265001235 60503000000331MD02 0 1 31000200043100363124265001235 605030001001INGBE 1 0 3200020004SINT MICHIELS WARANDE 60 1040 BRUSSEL Belgium 0 0 Légende: Code de l'opération Type de communication Type de communication structurée Communication Référence du client Détail de la communication "127": 21000200013100363124265001235 1000000001000000031011605030001127011011121BE01ZZZ0123456789 07043 03101119401 0 2200020001 I08755 1001638625 BBRUBEBB OTHR1 0 2300020001BE12310103160192 EURINGBE 1MD020 1 Légende: Date de Settlement Type de Direct Debit Schéma Direct Debit Payé ou raison du paiement refusé Code créancier Mandat référence Communication Type de transaction R Raison Impact de SEPA dans le reporting CODA2.3 pour la domiciliation européenne 4
127 Domiciliation européenne (SEPA direct debit) Date de settlement 6N JJMMAA Type de domiciliation 1N 0 : non précisé 1 : récurrent 2 : unique (one-off) 3 : 1st (recurrent) 4 : last (recurrent) Schéma domiciliation 1N 0 : non précisé 1 : SEPA core 2 : SEPA B2B Payé (0) ou raison du paiement refusé (1-4) 1N 0 : payé 1 : problème technique 2 : refus : raison non précisée 3 : débiteur pas d accord 4 : problème avec compte débiteur Code d identification du créancier 35AN Référence du mandat 35AN Communication 62AN Type de transaction R 1N 0 : payé (paid) 1 : inexécutable (reject) 2 : impayé (return) 3 : remboursement (refund) 4 : rectification (reversal) 5 : annulation (cancellation) Raison 4AN Impact de SEPA dans le reporting CODA2.3 pour la domiciliation européenne 5
Le type de transaction «R» donne des informations concernant les actions futures à entreprendre. Quand une première transaction de domiciliation européenne SEPA de type «FRST» n est pas liquidée (soit parce qu elle est inexécutable «reject» soit parce qu elle est annulée «cancel»), elle est considérée comme n ayant jamais été envoyée. Le créancier doit à nouveau envoyer la domiciliation avec le type de séquence «FRST» avec les mêmes informations ou des informations rectifiées dans les mêmes délais (sur base de la même référence de mandat et avec le même numéro de compte du débiteur). En cas de retour d une première transaction de domiciliation (First), le créancier doit renvoyer un fichier de type récurrent«rcur», compte tenu du fait que le mandat a été accepté. La raison donne de plus amples informations concernant le motif de la non-exécution, mais il convient de l interpréter avec prudence. En vertu de la législation relative à la vie privée, les différentes banques ne sont pas autorisées à communiquer des informations spécifiques concernant la situation financière d un débiteur. L utilisation de plusieurs motifs n est donc pas autorisée. Vous trouverez ci-dessous une liste des codes «raison» que nous utilisons : Code Raison Raison dans le Rulebook A utiliser en cas de AC01 Account Identifier (IBAN) Incorrect Compte IBAN du débiteur erroné AC04 Account closed Compte du débiteur clôturé AC06 Account blocked Compte du débiteur bloqué (ex. succession/faillite) AC13 Invalid Debtor Account Type Type de compte non autorisé pour la domiciliation européenne SEPA AG01 AG02 Direct Debit forbidden on this account for regulatory reasons Bank Operation code specified in the message is not valid for receiver Transaction interdite sur ce compte pour raisons de réglementation Code d opération bancaire indiqué dans le message non valide AM05 Duplication collection Encaissement similaire a été effectué récemment BE05 Identifier of the Creditor Incorrect Identifiant du créancier incorrect FF01 File Format incomplete or invalid - Fichier XML non/incorrectement rempli contient une faute de syntaxe - L information du mandat dans l encaissement est manquante ou erronée - L information sur le changement est manquante MD01 No valid mandate - Il n existe pas de mandat. - Mandat B2B non encore confirmé par le débiteur - Remboursement en cas de transaction non autorisée (13 mois après la date du débit) MD02 Mandate data missing or incorrect Type de séquence erroné MD06 Disputed authorized transaction Remboursement sans condition d une transaction (CORE jusqu à 8 semaines après le débit) MD07 Debtor Deceased Débiteur décédé MS02 Refusal by the Debtor Refus du débiteur MS03 Reason not specified Raison non spécifiée PY01 Not routable Banque du débiteur n est pas joignable pour SDD RC01 Bank Identifier (BIC) Incorrect BIC erroné RR01 Regulatory Reason Non conforme à la réglementation RR02 Regulatory Reason Non conforme à la réglementation RR03 Regulatory Reason Non conforme à la réglementation SL01 Specific Service offered by the Debtor Bank - Compte bloqué pour SDD par le débiteur (liste noire/blanche) - Dépasse la limite que le débiteur a indiquée sur le mandat (montant ou périodicité) Impact de SEPA dans le reporting CODA2.3 pour la domiciliation européenne 6
Où trouve-t-on les références du client? Les références du client se trouvent dans les enregistrements de données 2.2 (positions 64 à 98). Pour DOM80, cette zone est scindée en 2 x 13 positions. La référence du lot (batch) se trouve dans les 13 premières positions et la référence individuelle dans les 13 dernières positions. Pour les transactions SEPA (virement européen ou domiciliation européenne), on utilise le champ «PaymentInformationIdentification» pour communiquer la référence (record 2.2 positions 64 à 98) quand une comptabilisation globale est demandée. Les domiciliations européennes SEPA sont toujours comptabilisées globalement (par défaut). Par contre, les virements européens SEPA sont traités en tenant compte du paramètre «batchbooking». En cas de virement européen SEPA unitaire (S-ECT), les transactions sont comptabilisées séparément. On utilisera le champ «EndToEndIdentification» pour communiquer la référence (record 2.2 positions 64 à 98). Le tableau ci-dessous reprend les différentes références qui peuvent être utilisées pour initier une transaction XML avec le numéro d index tel qu utilisé dans les directives de format pour l initiation. Index Élément de message Description 2.1 PaymentInformationIdentification Cette référence obligatoire est déterminée par vous afin d identifier sans ambiguïté le bloc d informations du paiement dans le message. Cette référence est présente dans votre reporting CODA dans le champ du montant global. 2.31 EndToEndIdentification Cette référence obligatoire est déterminée par vous afin d identifier sans ambiguïté la transaction. L identification est transmise, inchangée, à travers toute la chaîne. Cette valeur identifie pour vous, en tant que créancier, chaque transaction présentée à votre banque, de façon unique. Elle sera transmise durant tout le processus de traitement des transactions du début à la fin. Vous devez définir la structure interne de cette référence, qui se trouve dans votre reporting CODA, au niveau des détails. 2.48 MandateIdentification Référence du mandat de domiciliation européenne signé entre le débiteur et vous, le créancier. Impact de SEPA dans le reporting CODA2.3 pour la domiciliation européenne 7
ING Belgique SA Banque avenue Marnix 24, B-1000 Bruxelles RPM Bruxelles TVA : BE 0403.200.393 BIC : BBRUBEBB IBAN : BE45 3109 1560 2789. Éditeur responsable : Inge Ampe Cours Saint-Michel 60, B-1040 Bruxelles 705117F 03/14 Editing Team & Graphic Studio Marketing ING Belgium