Anlage zur SEPA- Kundeninformation
Technische Spezifikationen und Formate
Aktualisierte Auflage Stand 02/2013
Inhalt1. Dateiformate und SEPA-Verfahren
der aktuelle Stand in Deutschland 5
2. Zusammenhang der Kunden- und Bankformate (ISO20022) 6
3. SEPA-Kundenformate 6
4. Ausblick neue DF-Version 2.7/ November 2013 7
5. Nachrichtentypen-Erkennung 9
6. Aufbau der Kundendatei (XML*) 11
7. SEPA Credit Transfer (SCT) 13
8. Beispiel einer Kunden-Datei 16
9. SEPA Direct Debit (SDD) 17
10. SEPA hufig genutzte Zahlungs- informationen im Format 21
10.1 Verwendungszweck/RemittanceInfo 21
10.2 Zahlungsgrund/Purpose Code 23
10.3 Produktkategorie/Category Purpose 24
10.4 Fnf Beteiligte in einer SEPA-Nachricht 24
10.5 Name, Adresse 25
10.6 IBAN 26
10.7 Glubiger-Identifikation/CI 27
10.8 Identifikations-Nummern (OrgID/PrivateID) 28
10.9 Ultimate/Reference Party/On Behalf 29
10.10 Mandatsnderung/ Mandate-Amendment 30
10.11 Lastschriftsequenz 33
10.12 Zeichensatz und Umlaute 35
10.13 Konkurrierende Felder XOR 36
10.14 Referenz-Nummern und deren Verwendung 37
11. Reporting (Bank-Kunde) 40
11.1 Reporting (Bank-Kunde) 40
11.2 Buchung von SEPA Dateien 40
11.3 Status/Fehler Nachricht pain.002 42
11.4 Rckgabegrnde 44
11.5 Payment Status Report/ pain. 002-SEPA Credit Transfer 46
11.6 Payment Status Report/ pain.002-SEPA Direct Debit 48
11.7 Elektronischer Kontoauszug MT940 50
12. Internationale SEPA Formate 52
4Fr die Umstellung auf SEPA mssen Datenfelder in ihren Systemen entsprechend angepasst werden. In der vorliegenden Broschre erhalten Sie wesentliche Details zu den technischen Spezifikationen und verschiedenen SEPA Formaten.
Bei den nachfolgenden Informationen handelt es sich um eine Empfehlung.
Grundlage hierfr ist das DF-Abkommen. Auf den nchsten Seiten dieser Broschre finden Sie eine Zusammenfassung der wichtigsten fachlichen Felder, die zur Umstellung auf SEPA erforderlich sind.
Weitere Details oder Angaben zu technischen Feldern entnehmen Sie dem nachfolgenden Link: Anlage 3 der Schnittstellenspezifikation fr die Datenfernbertragung zwischen Kunde und Kreditinstitut gem DF-Abkommen Version 2.6 vom 18.06.2012, gltig ab 17. November 2012www.ebics.de/index.php?id=77
Weitere Informationen zur finalen Beschreibung der Formate erhalten Sie bei folgenden Stellen:Die Deutsche Kreditwirtschaft (DK)Anlagen zum Kapitel 2, SEPA-Zahlungsverkehrder Version 2.6 der Anlage 3 Stand: Finale Version vom 18.06.2012XML-Schemata fr SEPAwww.ebics.de/
51. Datenformate und SEPA-Verfahren der aktuelle Stand in Deutschland
Datenformate
Die SEPA-Datenformate basieren auf dem ISO-Standard 20022/UNIFI (Universal Financial Industry Message Scheme: www.iso20022.org) fr XML. XML ist ein offener Standard Keine feste Vorgabe von Feldbelegungen Grer als die bekannten DTA-Formate (z. B. DTAUS und DTAZV) Implementation Guidelines (Interbankenverkehr) wurden vom European Payments Council (EPC)
im September 2006 verabschiedet und werden jhrlich weiterentwickelt ISO 20022 als XML basiertes Format bildet die Grundlage fr den modernen globalen Zahlungsverkehr und
bietet eine sehr groe Bandbreite und dadurch eine entsprechende Variabilitt an SEPA macht den Anfang einer durchgngigen ISO20022 Verarbeitung im Zahlungsverkehrsprozess
hinsichtlich aller SEPA Produkte. Im SEPA Umfeld basiert bereits die komplette Prozesskette bis hin zum Auszug auf XML-ISO20022
Fr die Kunde-Bank-Beziehung wurde das Pain-Format (Payment Initiation) festgelegt.
OriginatorID1234 1234.56 SPUEDE2UXXX Creditor Name DE21500500009876543210
62. Zusammenhang der Kunden- und Bankformate (ISO20022)
Kunden reichen bei Banken das pain-Format fr Zahlungsdateien ein. Im Interbankenverhltnis werden die Zahlungen dann zwischen den Banken mit dem pacs-Format ausgetauscht. Der Kunde erhlt dann ber die Buchungen als Kontoinformation das camt-Format optional zur Verfgung gestellt. Fehler/Rejects knnen optional an den Kunden auch im pain-Format als Datei von der Bank zur Verfgung gestellt werden.
3. SEPA-KundenformateFormat-Evolution
Was ndert sich bei den SEPA-Auftragsdaten?
Januar 2008 (DF Anlage 3 Version 2.2) Start SEPA-berweisung (Credit Transfer)
November 2008 (DF Anlage 3 Version 2.3) keine Format nderungen
November 2009 (DF Anlage 3 Version 2.4) Start SEPA-Basislastschrift (Direct Debit Core) & SEPA-Firmenlastschrift (Direct Debit B2B) Grouping Standard vereinheitlicht nur noch MIXED analog European Payments Council (EPC) Vorgaben Optional: Zahlungsgrnde standardisiert (ber 100 Purpose-Codes) z. B. Gehalt, Vermgenswirksame
Leistungen, ffentliche Kassen Optional: Zustzliche Namensfelder fr Dritt-Beteiligte: Ultimative Creditor/Debtor Optional: Definition der Formate fr XML Auszug (camt.052, camt.053, camt.054)
Kundeninformation
pain
pain = Payment initiation Zahlungsverkehrsinitiierung fr
berweisungen (pain.001) Lastschriften (pain.008)
pacs
pacs = Payment clearing & settlement Clearing fr
berweisungen (pacs.008) Lastschriften (pacs.003)
camt
camt = cash management Konto-Informationen
Avis (camt.052) Auszug (camt.053) DTI (camt.054)
pain pain = Payment Initiation Fehler-
Nachrichten Fehler-Meldung/Statusmessage
(pain.002)
pacs pacs = C&S Fehler-Nachrichten Fehler-Meldung/Statusmessage
Zahlungsauftrag Fehlerinformation
Bank
Kunde
Kunde
7November 2010 (DF Anlage 3 Version 2.5) Summenfelder (Betrag, Posten & Referenz) auf Sammlerebene (PaymentInfo) Restrukturierung der Reject pain.002-Nachricht auf Kundenbedrfnisse Strukturierte Rckmeldung im MT940/MT942/DTI von Retouren-Gebhren Rckgabegrund FOCR aufgrund SCT-Rckruf nach Buchung (Recall) Optional: Zahlungsgrund Spende (PurposeCode = CHAR) Optional: Prfzifferngerechte CreditorReferenz auf berweisungsbelegen
November 2011keine neuen Formate
November 2012 (DF Anlage 3 Version 2.6) keine Format nderungen Rckgabegrund AC13 wenn Zahlungspflichtiger ein Verbraucher ist und FF05 wenn Lastschrift mit verkrzter
Vorlauffrist COR1 nicht mglich ist
Hinweis: Jedes Jahr im November tritt meist ein neues Rulebook, das die Grundlage fr die fortschreitenden Anpassungen an die aktuellen Bedrfnisse bildet, in Kraft. Das EPC Rulebook 7.0 wird allerdings erst mit dem Migrationsdatum 1.2.2014 umgesetzt. Fr Sie bedeuten diese jhrlichen Rulebook-nderungen, dass Sie gegebe-nenfalls auch Anpassungen in den Formaten vornehmen mssen. Die Deutsche Kreditwirtschaft hat vereinbart, dass grundstzlich immer die aktuelle Formatversion und die Vorgngerversion angenommen werden sollen. Die HVB nimmt darberhinaus auch noch ltere Versionen an. Fr Nutzung neuer Funktionalitten mssen allerdings auch die entsprechenden Formaten verwendet werden.
4. Ausblick nderungen fr November 2013Zum 4. November 2013 ist geplant, eine neue DF-Anlage 3, Version 2.7 einzufhren (Verffentlichung im April 2013).
Welche nderungen werden derzeit diskutiert (Stand Januar 2013): Es wird eine neue XML-Version fr die Formate auch mit neuen Prfschemata (XSD) zur Abdeckung der
fachlichen nderungen (insb. wegen IBANonly, COR1 und URGP) notwendig:
Version 2.5 Version 2.7 SCT: pain.001.002.03 -> pain.001.003.03 SDD: pain.008.002.02 -> pain.008.003.02 Status: pain.002.002.03 -> pain.002.003.03
SEPA Basislastschrift mit verkrzter Vorlauffrist COR1 (D-1) Die COR1 Basislastschrift wird zum November 2013 deutschlandweit eingefhrt Fr den EBICS-Standard ist die Auftragsart CD1 bzw C1C (Container) zu verwenden Im Localinstrument-Code des pain.008.003.02 wird der Code COR1 verwendet Die HVB nimmt bereits vor der deutschlandweiten Einfhrung COR1 Basis-Lastschriften im pain.008.002.02
und pain.008.001.02 entgegen, wenn der Zahlungspflichtige bei der HVB ist
COR1
8 XML-Urgent Payment - Eiliger Zahlungsverkehrsauftrag per XML Die XML-EuroEilzahlung ist das Nachfolgeprodukt der bisherigen DTE und EUE-Zahlungen im XML-Format Diese Zahlungen werden mit gleichtgiger Valuta als Einzelzahlung an die Bank des Begnstigten via Target
bertragen Es ist keine Sammler-Zahlung aus dem Massenzahlungsverkehr sondern eine Individual-Zahlung und fllt
daher nicht unter die SEPA-Produkte Eilzahlungen (XML-Variante fr die bisherigen DTE-Zahlungen) knnen mit der Auftragsart CCU im
pain.001.003.03 und dem Service-Level URGP bertragen werden. Die HVB nimmt bereits vor der deutschlandweiten Einfhrung im pain.001.002.03 und pain.001.001.03 entsprechende Eilzahlungen entgegen. Hierzu sind besondere Feldbelegungen ntig, um alle relevanten Informationen an den Empfnger weiterzuleiten. Felder wie CategoryPurpose, Debtior-ID, UltimateDebtor, Creditor ID, und UltimateCreditor knnen nicht weitergeleitet werden, Felder wie PurposeCode und End2End-ID werden von der HVB in den Verwendungszweck gestellt Die Produktbroschre und weitere Detailbeschreibungen zur Feldbelegung erhalten Sie bei Ihrem Cash Management & eBanking Spezialisten
IBANonly bzw. optionaler BIC Die Angabe des BICs wird zum 1.2.2014 optional fr Zahlungen innerhalb Deutschlands. Da das
DF-Abkommen Anlage 3 schon fr den November 2013 angepasst wird und nicht nochmal mehr im Februar 2014, sind die nderungen bereits hier angepasst
Bei der SEPA-berweisung wrde das, dann optionale, Feld ganz weg gelassen Bei der SEPA-Lastschrift bleibt das Feld weiterhin ein Pflichtfeld, aber es kann dann, statt dem
optionalen Feld , der Wert NOTPROVIDED in das Feld eingestellt werden
Sonstige geplante nderungen Altformate werden ab 2/2014 abgeschafft (z.B. DTA-berweisung/DTA-Lastschrift) Ausnahme
Kartenzahlungen wie ELV sowie elektronische Schecks und DTE In Diskussion ist das optionale Zulassen von deutschen Umlauten , , , , , , und verschiedenen
Sonderzeichen Rckgabegrund-Liste wird erweitert (CNOR/DNOR, wenn die Bank ber das Clearing nicht erreichbar ist) Weitere PurposeCodes fr Gehalt (PAYR Payroll mit GVC 153) und Dauerauftragsgutschrift (RINP mit
GVC 152)
URGP
HYVEDEMMXXX
NOTPROVIDED
Neu ab Nov 2013 optionaler BIC fr nationale Zahlungen:
95. Nachrichtentypen-ErkennungWie erkennen Sie um welche Nachricht und welche Version es sich handelt? Aufbau einer XML Nachrichtenbezeichnung:
pain.001.002.03 Version
V3 ISO-Stand 2009 Variante
Die Deutsche Kreditwirtschaft Nachricht/Message-Definition
CustomerCreditTransferInitiation Geschftsfeld/Business-Aresa
Payment Initiation
pain.001.002.03Business-AreapainPAymentINnitiation
Message-Definition 001berweisungCustomerCreditTransferInitiation 008LastschriftDirectDebitInitiation 002CustomerPaymentStatusReport(Reject) 007CustomerPaymentReversal(Lastschriftsstorno) 009bis012Mandats-Initierung,-nderung,-Stornound-Akzeptanz
Variante 002ZKA/DKVersion 001IS020022/EPC
Version 03Version2010/2012 02Version2009 01Version2008
camtCAshMAnagement 052BanktoCustomerAccountReportZV-AvisMT942-Nachfolger 053BanktoCustomerStatementKontoauszugMT940-Nachfolger 054BanktoCustomerDebitCreditNotificationSammlerDTI-Nachfolger 055CustomerPaymentCancellationRequestKundenRckruf 086BankServiceBilling(ehem.TWIST-BSB)
in Planung in Planung
in Planung
10
ltere Versionen des DF-Abkommens werden von der HVB auch noch akzeptiert: DF-Abkommen 2.4 (2009): pain.001.002.02 DF-Abkommen 2.3 (2008): pain.001.001.02.grp, pain.001.001.02.con und pain.001.001.02
bzw. geliefert nach entsprechender Einlieferung: DF-Abkommen 2.4 (2009): pain.002.002.02 DF-Abkommen 2.3 (2008): pain.002.001.02
SEPA Auftragsarten Direct Debit
Namespace/Schema SDD Core 2.5 (2010)/2.6 (2012)
SDD B2B 2.5 (2010)/2.6 (2012)
EBICS-mixed urn:iso:std:iso:20022:tech:xsd: pain.008.002.02
CDDpain.008.002.02
CDBpain.008.002.02
EBICS-XML-Container urn:conxml:xsd:container.nnn.002.02(+urn:iso:std:iso:20022:tech:xsd: pain.008.002.02)
CDCpain.008.002.02
C2Cpain.008.002.02
EBICS-Reject urn:iso:std:iso:20022:tech:xsd: pain.002.002.03
CDZ (Zip-Container) oderCBC (XML-Container)pain.002.002.03
CDZ (zip) oderCBC (Container)pain.002.002.03
HBCI-Sammel HKDME HKBME
SEPA Auftragsarten Credit Transfer DK-Format
Namespace/Schema SCT 2.5 (2010) 2.6 (2012)EBICS-mixed urn:iso:std:iso:20022:tech:xsd:pain.001.002.03 CCT
pain.001.002.03
EBICS-mixed Sonderprozess ohne VEU-Details urn:iso:std:iso:20022:tech:xsd:pain.001.002.03 XCT pain.001.002.03
EBICS-XML-Container
urn:conxml:xsd:container.nnn.002.02(+urn:iso:std:iso:20022:tech:xsd:pain.001.002.03)
CCCpain.001.002.03
EBICS-Reject urn:iso:std:iso:20022:tech:xsd:pain.002.002.03 CRZ (Zip-Container) oder CRC (XML-Container)pain.002.002.03
HBCI-Sammel HKCCM, HKCME
HBCI-Einzel HKCCS, HKCSE
ltere Versionen des DF-Abkommens werden von der HVB auch noch akzeptiert: DF-Abkommen 2.4 (2009): pain.008.002.01
bzw. geliefert nach entsprechender Einlieferung: DF-Abkommen 2.4 (2009): pain.002.002.02
Die Reject-Nachrichten (pain.002) werden verwendet, wenn die Rcknachricht vor Settlement, also vor Buchung, erfolgt. Dazu gehren z. B. Rckgaben wegen Formatfehlern etc.Weitere Informationen erhalten Sie von Ihrem Cash Management & eBanking Spezialisten.
Beauftragung einer SEPA Credit Transfer - Kunden-FormatFolgende Auftragsarten sind ber die bertragungswege (EBICS/HBCI bzw. FinTS) mglich
Beauftragung einer SEPA Direct Debit - Kunden-FormatFolgende Auftragsarten sind ber die bertragungswege (EBICS/HBCI bzw. FinTS) mglich
11
6. Aufbau der Kundendatei (XML*) XML-Container nur fr deutschen DK Formate optional
Group Header Dieser Block muss vorhanden sein und existiert einmal Er enthlt Elemente wie Nachrichten-ID, Erstellungsdatum und -zeit
Payment Information (Dateiebene) Dieser Block muss mindestens einmal vorkommen und ist wiederholbar Er enthlt Elemente, die sich auf die Herkunftsseite der Transaktion beziehen, wie z. B. Auftraggeber
oder Zahlungsart-Informationen und einen oder mehrere Transaction Information-Blcke Ebene der logischen Datei fr die Auftraggeber-Buchung (als Sammler)
Transaction Information Dieser Block muss pro Payment Information mindestens einmal vorkommen und ist wiederholbar Er enthlt u. a. Elemente, die sich auf die Empfngerseite Zahlungsempfnger bei der berweisung bzw Zahler (Zahlungspflichtiger) bei der Lastschrift beziehen, Enthlt den Betrag und den Verwendungszweck.
* XML = Extensible Markup Language
Auftragsarten Container sowie Aufbau Datei mit GroupHeader, PaymentInfo und TransactionsInfo
DK XML-Container EBICS-Auftragsart CCC
PaymentInfoDebtor: Konto-3
TransactionInfoCreditor/EUR
pain.001.002.03GroupHeaderInitiatingParty Firma-1
pain.001.002.03GroupHeaderInitiatingParty Firma-1
PaymentInfoDebtor: Konto-1
TransactionInfoCreditor/EUR
PaymentInfoDebtor: Konto-2
TransactionInfoCreditor/EUR
EBICS-Auftragsart CCT (mixed)
EBICS-Auftragsart CCT (mixed)
PaymentInfoDebtor: Konto-3
pain.001.002.03GroupHeaderInitiatingParty Firma-1
pain.001.002.03GroupHeaderInitiatingParty Firma-1
PaymentInfoDebtor: Konto-1
TransactionInfoCreditor/EUR
PaymentInfoDebtor: Konto-2
TransactionInfoCreditor/EUR
TransactionInfoCreditor/EUR
12
* Das bisherige Inlandszahlungsverkehrsformat DTAUS ist sehr viel kleiner als das XML-Datenformat. Eine Transaktion ohne Header hat im DTAUS bis zu 622 Bytes whrend eine SEPA-Transaktion ber 2.100 Bytes beinhalten kann, hinzu kommen noch die Headerinformationen. Um noch verarbeitungsfhige Dateien zu erhalten (Filetransfer, Mapping, Validierung und Fehlerrecherche etc) empfiehlt es sich, die Gruppierung nicht zu gro zu machen. Empfehlung maximal 100.000 Transaktionen pro Datei (bis zu 210 MB)
Prfung auf Doppelverarbeitung von Dateien Damit Dateien nicht doppelt verarbeitet werden, prft die HVB logische Dateien (PaymentInf) nach folgenden Prinzipien: Je Auftraggeber IBAN Zeitraum: 15 Target-Tage Ermittelte Gesamtsumme in EUR Ermittelte Anzahl Posten Produkt (SCT, Basislastschrift, Firmenlastschrift) Summe der Prfziffer (Stelle 3-4) aller Empfnger- bzw Zahlungspflichtigen-IBAN
Die Einreichung von SEPA-Dateien erfolgt als Sammler, hierzu mssen Dateien gebildet werden
Je physische Datei (Sendung (z.B. XML-Container)/Groupheader) getrennt nach Produkt (SCT, SDD-Core, SDD-Cor1, SDD-B2B, CT-Urgent) , , und
da fr jedes Produkt eine eigene Sende-Auftragsart verwendet werden muss
Je logische Datei (PaymentInf) insbesondere auch getrennt nach Auftraggeber-IBAN Flligkeitstag bzw. Ausfhrungstag Lastschrift Sequenz (First, Recurrent, Final, OneOff) Unterscheidung zwischen SCT und SCT-Preferred (gleichtgiges Clearing) Sammel/Einzelbuchung der Einreichung Anzahl der Stze bzw. Datei-Grenbeschrnkung siehe unten
In einer logischen Datei knnen gemischt werden z.B. : verschiedene Empfnger bzw Zahlungspflichte bei Lastschriften verschiedene Betrge Verwendungszweck , Zahlungsgrnde , End-toEnd-Referenz verschiedene Mandatsinformationen bei Lastschriften
Gruppierung von Dateien und was kann gemischt angeliefert werden?
13
7. SEPA Credit Transfer (SCT)Grundlegende Merkmale Auftraggeberkonto und Empfngerkonto werden im SEPA-Raum gefhrt
(Kontoinhaber kann auch auerhalb ansssig sein) Transaktionswhrung ist immer EUR
Unterschiede gegenber Inlandsberweisung (wird abgelst zum 1.2.2014) Verwendung von IBAN/BIC Verwendungszweck begrenzt auf 140 Zeichen (DTA: 378 Zeichen) Zustzliche Zahlungsgrnde (PurposeCodes) sind optional mglich Verwendung von On-Behalf/Ultimates ist optional mglich Zustzliche Referenzierungsmglichkeiten Grenzberschreitend im SEPA Raum
Unterschiede gegenber EU-Standardberweisung (abgelst seit 1.4.2012) explizit auch nationale Nutzung kein AWV-Meldeteil im Datensatz vorhanden auch Zahlungen in die Schweiz und Monaco
14
Wichtige fachliche XML Felder fr SEPA Credit Transfer
Feldnamen Beschreibung pain.001.002.03
Befllung DF Abkommen 2.5/2.6
Nheres siehe Seite
GrpHdr GroupHeader Absenderdaten 1 x pro logische Datei 11, 12
MsgId (Message-Id)
Einreicher-Referenznummer pro Datei Pflichtfeld (eindeutig) Max. 35 Zeichen 35, 37-38
CreDtTm (CreationDateTime)
Datum/Zeit der Dateierstellung Pflichtfeld ISO-Date
NbOfTxs (NumberOfTransactions)
Anzahl aller Einzeltransaktionen Pflichtfeld Unbegrenzt
CtrlSum (ControlSum)
Kontrollsumme in Euro der Einreichung Empfohlen Unbegrenzt
InitgPty-Nm (InitiatingPartyName)
Name Einreicher (kann vom Namen des Auftraggebers abweichen
Pflichtfeld Max. 70 Zeichen 25
InitgPty-Nm-Id-OrgId/PrvtId (InitiatingPartyOrganisa-tion-Id/Private-ID)
Identification DK nicht empfohlen Diverse 28, 35-38
PmtInf PaymentInstruction - Information
Auftraggeberdaten beliebig oft mglich, empfohlen max. 100
11, 12
PmtInfId (PaymentInformation-ID)
Referenz der Einreichung Pflicht Max. 35 Zeichen 35, 37-38
PmtMtd (PaymentMethod)
Zahlungsinstrument: Credit Transfer Pflicht TRF
BtchBookg (BatchBooking)
Auftraggeberbuchung Sammler/Ein-zelsatz
Optional, in Stammdaten administriert
false Einzelbuchungtrue Sammelbuchung
40-41
NbOfTxs (NumberOfTransactions)
Anzahl aller Einzeltransaktionen Empfohlen Unbegrenzt
CtrlSum (ControlSum)
Kontrollsumme in Euro der logischen Datei
Empfohlen Unbegrenzt
InstrPrty (InstructedPriority)
Prioritt der Ausfhrung: high oder norm
Optional, in Stammdaten administriert
HIGH SCT PreferredNORM SCT Normal
36
SvcLvl-Cd (ServiceLevelCode)
Service Schema Pflicht SEPA 8, 36
CtgyPurp (CategoryPurpose)
Zahlungsart der Datei Optional, in Stammdaten administriert
Fr gleichtgige Gehalts-zahlung SALA
24, 36
ReqdExctnDt (RequestedExecution Date)
Gewnschter Ausfhrungstermin Pflichtfeld ISO-Date
Dbtr-Nm (DebtorName)
Name Auftraggeber. Ggf. von Bank mit Kontoinhaber berschrieben
Pflichtfeld Max. 70 Zeichen 25
Dbtr-PstlAdr-Ctry (DebtorCountry)
Land der Anschrift des Auftraggebers Optional Lndercode ISO3166, DE fr Deutschland
25
Dbtr-PstlAdr-AdrLine (DebtorAddress)
Anschrift Auftraggeber. Ggf. von Bank mit Kontoadresse berschrieben
Optional Max. 140 Zeichen 25
Dbtr-Id-OrgId/PrvtId (DebtorOrganisation-Id/Private-ID)
Identification DK nicht empfohlen Diverse 28, 35-38
DbtrAcct-IBAN (DebtorIBAN)
IBAN des Auftraggebers Pflichtfeld Max. 34 Zeichen 8, 26
DbtrAcct-Ccy (DebtorAccountCurrency)
Whrung des Auftraggeberkontos Optional Whrungscode
DbtrAgt-BIC (DebtorAgentBIC)
BIC/SWIFT Code des Auftraggebers Pflichtfeld 8 bzw. 11 Stellen 8
UltmtDbtr (UltimateDebtorName)
Vom Kontoinhaber abweichender Auftraggeber. Rein informatorischer Charakter
Optional Max. 70 Zeichen 6, 25, 29, 36
UltmtDbtr-Id-OrgId-Othr (UltimateDebtor-IBAN)
Ultimate Einreicherbelastungs-IBAN Optional, nur wenn Produkt Ultimate Auftraggeber
Max. 34 Zeichen 26, 29, 28, 35
ChrgBr (ChargeBearer)
Preis-Verrechnung immer shared Empfohlen SLEV 36
15
Feldnamen Beschreibung Befllung DF Abkommen 2.5/2.6
Nheres siehe Seite
CdtTrfTxInf CreditTransfer- Transaction-Information
Transaktions-Information beliebig oft mglich, empfohlen max. 100.000
11, 12
InstrId (Instruction-ID)
Technische Referenz zwischen Einreicher und Bank
Optional, wenn gefllt: eindeutig Max. 35 Zeichen 35, 37-38
EndToEndID (End2End-ID)
Referenz, wird bis Begnstigten durchgereicht
Pflichtfeld (eindeutig, sonst: NOTPROVIDED)
Max. 35 Zeichen 35, 37-39
InstrAmt (Instructed Amount)
Betrag und Whrungskennzeichen Pflichtfeld Nur Euro erlaubt
UltmtDbtr (UltimateDebtor)
Abweichender Auftraggeber Optional. Nicht wenn auf PmtInf-Ebene schon gefllt
Max. 70 Zeichen 6, 25, 29, 36
UltmtDbtr-Id-OrgId/PrvtId (UltimateDebtorOrgani-sation-Id/Private-ID)
Identification DK nicht empfohlen Diverse 28, 35-38
CdtrAgt-BIC (CreditorAgentBIC)
BIC/SWIFT-Code der Begnstigten Bank Pflichtfeld 8 bzw. 11 Stellen 8
Cdtr-Nm (CreditorName)
Name Begnstigter Pflichtfeld Max. 70 Zeichen 25
Cdtr-PstlAdr-Ctry (CreditorCountry)
Land der Anschrift des Begnstigten Optional Lndercode ISO3166, DE fr Deutschland
25
Cdtr-PstlAdr-AdrLine (CreditorAddress)
Anschrift Begnstigter Optional Max. 140 Zeichen 25
Cdtr-Id-OrgId/PrvtId (CreditorOrganisation-Id/Private-ID)
Identification DK nicht empfohlen Diverse 35-38
CdtrAcct-IBAN (CreditorIBAN)
IBAN des Begnstigten Pflichtfeld Max. 34 Zeichen 8, 26
UltmtCdtr (UltimateCreditorName)
Abweichender Endbegnstigter. Rein informatorischer Charakter
Optional Max. 70 Zeichen 6, 25, 29
UltmtCdtr-Id-OrgId/PrvtId (UltimateCreditorOrgani-sation-Id/Private-ID)
Identification DK nicht empfohlen Diverse 28, 35, 37-38
Purp (Purpose)
Art der Zahlung (Textschlssel). Im Kontoauszug MT940/942 werden nicht alle Codes dargestellt. Die Codes BONU, PENS, SALA werden im MT940 als GVC 153; BENE, GOVT, SSBE als GVC 156; CHAR als GVC 119 bzw. 169 und CBFF als GVC 154 dargestellt
Optional ISO20022 ExternalPurposeCode-Liste
6, 23, 50
Ustrd-RmtInf (UnstructuredRemit-tanceInfo)
Unstrukturierter Verwendungszweck Empfohlen Max. 140 Zeichen 21, 36
Strd-CdtrRefInf-CdtrRefTp-Cd (StructuredCreditor Reference-Code)
Strukturierter Verwendungszweck fr VL-Leistung oder CreditorReference
Nur wenn kein unstrukturierter Verwendungszweck
SCOR 21-22, 36
Strd-CdtrRefInf-CdtrRef (StructuredCreditor Reference)
Strukturierter Verwendungszweck Teil 2a) VL-Leistung: Bezugsjahr der
Vermgenswirksamen Leistung und Referenz
alternativb) CreditorReference:
Prfziffern gerechte CreditorReference
Nur wenn kein unstrukturierter Verwendungszwecka) in Verbindung mit Purp=CBFF:
Bezugsjahr der VL und Referenzb) RF+Prfziffer+Reference
(ISO11649)
Max. 35 Zeichen 21-22, 35, 37-38
Nicht angegeben sind rein technische Felder oder Felder, die in Deutschland mglich, aber von den Banken nicht empfohlen sind (z.B. OrgID, weitere strukturierte Verwendungszwecke). Details und Angabe aller Felder finden Sie im DF-Abkommen Spezifikation der Datenformate.
Fortsetzung
16
8. Beispiel einer Kunden-DateiGroupHeader Beschreibung DTAUS-Feld
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:iso:std:iso:20022:tech:xsd:pain.001.002.03 pain.001.002.03.xsd"> 20121118-105506 2012-11-18T10:55:06 1 MEIER PAYMENT MUENCHEN
XML Schema und XSD Location
GroupHeader MessageID eindeutige Referenz der Datei Creation Date/Time NumberOf-Transactions optional Gesamtsumme EUR ber alle logischen Dateien Name Initiating Party (z.B. DATEV)
(~DTA-A7)
(DTA-A6)
Paymentinformation logische Datei
PAYMENT-20110318-105506 TRF true 1 1234.56 HIGH SEPA SALA 2012-11-19 MEIER CORNELIA MUENCHEN DE67700202700064535072 HYVEDEMMXXX MEIER GEHALTSABTEILUNG SLEV
PaymentInfID eindeutige Referenz der log. Datei PaymentMethode: Transfer Batchbooking True/False - Sammler/Einzelbuchung Anzahl Posten Summe EUR Priority NORM/HIGH (SCT-Preferred)
ServiceLevel SEPA
Category-Purpose SALA Gleichtgig beim Empfnger auch bei nach Cut-Off
Ausfhrungstag
Auftraggeber Name (ggf mit Adresse)
Auftraggeber IBAN
Auftraggeber BIC
Ultimate Auftraggebername
SELV = Share
(~DTA-A10)
(DTA-E4)(DTA-E8)
(DTA-A11b)
(DTA-C15)
(~DTA-C11)
(~DTA-C10)
CreditTransferTransaction Einzeltransaktion
OriginatorID1234 1234.56 SPUEDE2UXXX Creditor Name DE21500500009876543210 PENS Unstructured Remittance Information
End2End-Id Referenz der Zahlung aus Sicht des Auftraggebers
Betrag in EUR
Creditor Empfnger BIC
Empfngername
Empfnger IBAN
Purpose Textschlssel der Zahlung siehe ISO20022 external Code list
Remittance-Info Verwendungszweck 140 Stellen
(DTA-C12)
(~DTA-C4)
(DTA-C14a + Erw)
(~DTA-C5)
(~DTA-C7a)
(~DTA-C16 + Erw)
17
9. SEPA Direct Debit (SDD)Grundlegende Merkmale SEPA Basislastschrift (SDD-Core) hnlich der Inlands-Einzugsermchtigungs-Lastschrift SEPA Firmenlastschrift (SDD-B2B) hnlich der Inlands-Abbuchungsauftrags-Lastschrift Mandat muss zum Abgleich auch bei der Debitorbank vorliegen
Unterschiede gegenber Inlandslastschrift (wird abgelst zum 1.2.2014) Angabe der Glubiger Identifikationsnummer (vergeben von der Bundesbank) Mitgabe von Mandatsinformationen (Mandate-ID und Mandatsunterschriftsdatum) Mitgabe von prozessrelevanten Angaben (Sequenz der Einreichung, Flligkeitstag
mit entsprechenden Vorlaufeinreichungstagen) Verwendung von IBAN/BIC Verwendungszweck begrenzt auf 140 Zeichen (DTA: 378 Zeichen) Zustzliche Zahlungsgrnde (PurposeCodes) sind optional mglich Verwendung von On-Behalf/Ultimates ist mglich Zustzliche Referenzierungsmglichkeiten grenzberschreitende Nutzung im SEPA-Raum
Wichtige fachliche XML Felder fr SEPA Direct DebitFeldnamen Beschreibung
pain.008.002.02Befllung DF Abkommen 2.5/2.6
Inhalt des papierhaften Mandates
Nheres siehe Seite
GrpHdr GroupHeader Absenderdaten 1 x pro logische Datei 11, 12
MsgId (Message-Id)
Einreicher-Referenznummer pro Datei
Pflichtfeld (eindeutig) Max. 35 Zeichen 35, 37-38
CreDtTm (CreationDateTime)
Datum/Zeit der Dateierstellung Pflichtfeld ISO-Date
NbOfTxs (NumberOfTransactions)
Anzahl aller Einzeltransaktionen Pflichtfeld Unbegrenzt
CtrlSum (ControlSum)
Kontrollsumme in Euro der Einreichung
Empfohlen Unbegrenzt
InitgPty-Nm (InitiatingPartyName)
Name Einreicher (kann abweichen von Auftraggebernamen)
Pflichtfeld Max. 70 Zeichen 25
InitgPty-Nm-Id-OrgId/PrvtId (InitiatingPartyOrgani-sation-Id/Private-ID)
Identification DK nicht empfohlen Diverse 28, 35-38
PmtInf PaymentInstruction-Information
Zahlungsempfnger-Daten beliebig oft mglich, empfohlen max. 100
11, 12
PmtInfId (PaymentInformation-ID)
Referenz der Einreichung Pflichtfeld Max. 35 Zeichen 35, 37-38
PmtMtd (PaymentMethod)
Zahlungsinstrument: Direct Debit Pflichtfeld DD
BtchBookg (BatchBooking)
Auftraggeberbuchung Sammler/Einzelsatz
Optional, wenn administ-riert in Stammdaten
true-Sammelbuchung false-Einzelsatz-buchung
40-41
NbOfTxs (NumberOfTransactions
Anzahl aller Einzeltransaktionen Empfohlen Unbegrenzt
18
Feldnamen Beschreibung pain.008.002.02
Befllung DF Abkommen 2.5/2.6
Inhalt des papierhaften Mandates
Nheres siehe Seite
CtrlSum (ControlSum)
Kontrollsumme in Euro der logischen Datei
Empfohlen Unbegrenzt
SvcLvl-Cd (ServiceLevelCode)
Service Schema Pflicht SEPA 36
LclInstrm-Cd (LocalInstrumentCode
Lastschriftsart: normale SEPA-Core-Basislastschrift oder SEPA-B2B-Firmenlastschrift
Pflichtfeld (innerhalb GrpHdr nicht mischbar)
CORE oder B2B * 7, 33, 36
SeqTp (SequenceType)
Sequenz: Erst-, Folge-, Einmal- oder letztmalige-Lastschrift
Pflichtfeld FRST, RCUR, OOFF oder FNAL
Pflicht (wiederkehrend oder einmalig)
31, 33-34
CtgyPurp (CategoryPurpose)
Zahlungsart der Datei Optional Nicht zur Weitergabe an Endkunden
24, 36
ReqdColltnDt (RequestedCollection-Date)
Flligkeitsdatum der Lastschrift (Datum der Belastung auf Kto. des Bezogenen)
Pflichtfeld ISO-Date 33
Cdtr-Nm (CreditorName)
Name Zahlungsempfnger. Ggf. von Bank mit Kontoinhaber berschrieben
Pflichtfeld Max. 70 Zeichen Pflicht 25
Cdtr-PstlAdr-Ctry (CreditorCountry)
Land der Anschrift des Zahlungs-empfngers
Optional Lndercode ISO3166, DE fr Deutschland
Pflicht 25
Cdtr-PstlAdr-AdrLine (CreditorAddress)
Anschrift Zahlungsempfnger. Ggf. von Bank mit Kontoadresse berschrieben
Optional Max. 140 Zeichen Pflicht 25
CdtrAcct-IBAN (CreditorIBAN)
IBAN des Zahlungsempfngers Pflichtfeld Max. 34 Zeichen 8, 24
CdtrAcct-Ccy (CreditorAccount Currency)
Kontowhrung: muss EUR sein Optional EUR
CdtrAgt-BIC (CreditorBIC)
BIC/SWIFT Code des Zahlungs-empfngers
Pflichtfeld 8 bzw. 11 Stellen 8
UltmtCdtr (UltimateCreditor)
Vom Kontoinhaber abweichender Zahlungsempfnger. Rein informa-torischer Charakter
Optional Max. 70 Zeichen 6, 25, 29, 36
UltmtCdtr-Id--OrgId-Othr (UltimateCreditorIBAN)
Ultimate Einreicher-Gutschrifts-IBAN
Optional, nur wenn Produkt Ultimate Auftraggeber
Max. 34 Zeichen 26, 28-29
UltmtCdtr-Id-OrgId/PrvtId (UltimateCreditorOrga-nisation-Id/Private-ID)
Identification DK nicht empfohlen Diverse 28, 35-38
ChrgBr (ChargeBearer)
Preis-Verrechnung immer shared Pflichtfeld Ab DF-Abkommen 2.6 gendert auf Empfohlen
SLEV 36
CdtrSchmeId-Id-PrvtId-OthrId-Id (CreditorIdentification)
CreditorIdentification. Eindeutiges Identifikationsmerkmal des Zahlungsempfngers (per legal entity)
Pflichtfeld, entweder auf PmtInf-Ebene oder auf Transaction-Ebene immer gleich
Max. 35 Zeichen Pflicht 27, 36-38
Fortsetzung
* fr 2013 ist hier auch der LocalInstrumentCode COR1 vorgesehen fr die Lastschrift mit verkrzter Vorlaufzeit D-1
19
Feldnamen Beschreibung Befllung DF Abkommen 2.5/2.6
Inhalt des papierhaften Mandates
Nheres siehe Seite
Drct DbtTrfTxInf
Direct Debit Transac-tion-Information
Transaktions-Information beliebig oft mglich, empfohlen max. 100.000
11, 12
InstrId (Instruction-ID)
Technische Referenz zwischen Einreicher und Bank
Optional, wenn gefllt: eindeutig
Max. 35 Zeichen 35, 37-38
EndToEndID (End2End-ID)
Referenz, wird bis Zahlungs- pflichtigen durchgereicht
Pflichtfeld (eindeutig, sonst: NOTPROVIDED)
Max. 35 Zeichen 35, 37-39
InstrAmt (Instructed Amount)
Betrag und Whrungskennzeichen Pflichtfeld Nur Euro erlaubt
Mndtld (MandateID)
Eindeutige Mandatsreferenz Pflichtfeld Max. 35 Zeichen 35, 37-39
DtOfSgntr (DateOfSignature)
Datum, zu dem das Mandat unterschrieben wurde
Pflichtfeld ISO-Date Pflicht, im Papier-mandat auch Ort der Unterschrift und Unterschrift
AmdmntInd (AmendmentIndicator)
Kennzeichen, ob das Mandat verndert wurde
Pflichtfeld Vernderung = TrueStandard = False
30-32
OrgnlMndtId (OriginalMandateID)
Eindeutige Referenz des ursprngli-chen Mandats, falls sich die Mandatsreferenz (MndtId) gendert hat
Nur bei Mandats- vernderung (AmdmntInd = True)
Max. 35 Zeichen 30-32, 35, 37-39
OrgnlCdtrSchmeId-Nm (OriginalCreditorName)
Ursprnglicher Creditor Name, falls sich der Zahlungsempfnger gendert hat
Nur bei Mandats- vernderung (AmdmntInd = True)
Max. 70 Zeichen 25, 30-32
OrgnlCdtrSchmeId-Id-PrvtId-OthrId-Id (OriginalCreditorIdenti-fication)
Ursprngliche CreditorIdentifica-tion, falls sich die Creditor- Identification (CdtrSchmeIdI) gendert hat
Nur bei Mandats- vernderung (AmdmntInd = True)
Max. 35 Zeichen 27, 30-32, 35, 37-38
OrgnlDbtrAcct-IBAN (OriginalDebtorIBAN)
Ursprnglicher IBAN des Zahlungs-pflichtigen, falls sich der IBAN gendert hat
Nur bei Mandats- vernderung (AmdmntInd = True)
Max. 34 Zeichen 26, 30-32
OrgnlDbtrAgt-Id (OrignalDebtorAgentID)
Ursprngliche Debtorbank hat sich gendert. Neueinreichung mit Sequenz FRST ntig
Nur bei Mandats- vernderung (AmdmntInd = True)
Kennzeichen SMNDA 30-32, 34
ElctmcSgntr (ElectronicSignature)
Elektronisches Mandat eMandate - elektronische Signatur
Optional. Nicht fr papierhafte Mandate
Max. 1.025 Zeichen; erst Max. eMandate relevant
CdtrSchmeId-Id-PrvtId-OthrId-Id (CreditorIdentification)
CreditorIdentification. Eindeutiges Identifikationsmerkmal des Zahlungsempfngers (per legal entity)
Pflichtfeld, entweder auf PmtInf-Ebene oder auf Transaction-Ebene immer gleich.
Max. 35 Zeichen 27, 36-38
UltmtCdtr (UltimateCreditorName)
Name abweichender Zahlungsempfnger
Optional. Nicht wenn auf PmtInf-Ebene schon gefllt
Max. 70 Zeichen 6, 25, 29, 36
UltmtCdtr-Id-OrgId/PrvtId (UltimateCreditorOrga-nisation-Id/Private-ID)
Identification DK nicht empfohlen Diverse 28, 35-38
DbtrAgt-BIC (DebtorAgentBIC)
BIC/SWIFT-Code der zahlungspflichtigen Bank
Pflichtfeld 8 bzw. 11 Stellen 8
Dbtr-Nm (DebtorName)
Name Zahlungspflichtiger Pflichtfeld Max. 70 Zeichen 25
Dbtr-PstlAdr-Ctry (DebtorCountry)
Land der Anschrift des Zahlungspflichtigen
Optional Lndercode ISO3166, DE fr Deutschland
Pflicht 25
Dbtr-PstlAdr-AdrLine (DebtorAddress)
Anschrift Zahlungspflichtiger Optional Max. 140 Zeichen Pflicht 25
Fortsetzung
20
Feldnamen Beschreibung Befllung DF Abkommen 2.5/2.6
Inhalt des papierhaften Mandates
Nheres siehe Seite
Dbtr-Id-OrgId/PrvtId (DebtorOrganisation-Id/Private-ID)
Identification DK nicht empfohlen Diverse 28, 35-38
DbtrAcct-IBAN (DebtorIBAN)
IBAN des Zahlungspflichtigen Pflichtfeld Max. 34 Zeichen Pflicht 8, 26
UltmtDbtr (UltimateDebtor)
Name abweichender Zahlungs- pflichtiger. Rein informatorischer Charakter
Optional Max. 70 Zeichen Optional 6, 25, 29
UltmtDbtr-Id-OrgId/PrvdtId (UltimateDebtorOrga-nisation-Id/Private-ID)
Identification DK nicht empfohlen Diverse 28, 35-38
Purp (Purpose)
Art der Zahlung (Textschlussel). Im Kontoauszug MT940/942 werden nicht alle Codes dargestellt.
Optional ISO20022 ExternalPurposeCode-Liste
6, 23, 50
Ustrd-RmtInf (Unstructured RemittanceInfo)
Unstrukturierter Verwendungs-zweck
Empfohlen Max. 140 Zeichen Optional (Vertragsnummer und Beschreibung)
21, 36
Strd-CdtrRefInf-CdtrRefTp-Cd (StructuredCreditor Reference-Code)
Strukturierter Verwendungszweck DK nicht empfohlen SCOR 21, 36
Strd-CdtrRefInf-Cdtr Ref(StructuredCreditorReference)
Strukturierter Verwendungszweck Teil 2
DK nicht empfohlen Max. 35 Zeichen 21, 36
Fortsetzung
21
10. SEPA hufig genutzte Zahlungsinformationen im Format
10.1 Verwendungszweck
Verwendungszweck Der Verwendungszweck hat bei SEPA nur 140 Stellen. Im noch gltigen Inlandszahlungsverkehr sind dagegen
bis 14 x 27 Zeichen (= 378 Stellen) mglich. In Ergnzung zu dem Verwendungszweck kann bei SEPA allerdings noch ein strukturierter Purpose und
eine Detaillierung der beteiligten Parteien (Adresse und Identifikationsnummern) vorgenommen werden Es wird daher empfohlen den unstrukturierten Verwendungszweck zu verwenden
Strukturierter Verwendungszweck Der strukturierte Verwendungszweck kommt in 2 Fllen in FrageVermgenswirksame Leistungen (VL-Zahlungen) Wenn im strukturierten Verwendungszweck unter Informationen ber Vermgenswirksame
Leistungen eingestellt sind (wie z. B. Jahreszahl oder Vertragsnummer: XXJ/Vertragsnummer), muss der Purpose Code CBFF (Capital building fringe fortune) fr Vermgenswirksame Leistungen verwendet werden, um regelmiges Scannen des Verwendungszwecks zu vermeiden
Der Name des VL-Empfngers kann ggf. im Ultimate Creditor hinterlegt werden.
1234567890123456789012345678901234567890123456789012345678
9012345678901234567890123456789012345678901234567890123456789012345678901234567890
CBFF
SCOR XX3/123456789
22
SCOR RF98123456789012345678901
Strukturierte Creditor Referenz Belege mit Prfziffern gerechten Verwendungszwecken gibt es anlog den BZ-Belegen im Inlandszahlungs-
verkehr, auch in SEPA. Sie werden bei SEPA Creditor-Reference genannt nach ISO 11649, beginnend mit RF und dann gefolgt von 21 alphanumerischen Stellen. Berechnet wird die CreditorReference mit Modulus 97
In SEPA ist nur der strukturierte Verwendungszweck mit den Codewort SCOR zugelassen Wenn die Prfziffer nicht korrekt ist, wird die Referenz in den unstrukturierten Verwendungszweck berfhrt Im papierhaften und elektronischen Kontoauszug MT940 wird die Struktur grundstzlich nicht mitgegeben,
sondern einfach nur der Inhalt ohne Tags z.B. SCOR RF98123456789012345678901. Im neuen camt.05x wird die Struktur durchgeleitet
23
... PENS
10.2 Zahlungsgrund: Purpose Code
Die strukturierte Information ber den Zahlungsgrund pro Zahlung, z. B. Spende oder Gehalt wird ber den Purpose-Code in SEPA abgebildet
Der Purpose-Code geht grundstzlich an die Empfnger-Bank und deren End-Empfnger Er kann zu unterschiedlichen Geschftsvorfallcodes (GVC) im elektronischen Auszug fhren Die Zahlungsgrnde sind aufgefhrt in www.iso20022.org/external_code_list.page im Reiter 11-Purpose
Purpose- Code - Auszug
Erklrung Spezieller Geschfts-vorfall-Code fr elektro- nischen Auszug, bzw. Anmerkungen
ADVA Vorabzahlung
AGRT Landwirtschaft
AIRB Luftverkehr
ALMY Alimente und Unterhalt
BECH Kindergeld
BENE Arbeitslosengeld GVC Haben 156
BLDM Gebudepflege
BONU Bonuszahlung GVC Haben 153
BUSB Busverkehr
CASH Cash Mananagement
CBFF Vermgenswirksame Leistung
GVC Haben 154
CBTV Kabelfernsehen
CDBL Kreditkartenabrechnung
CFEE Stornogebhr
CHAR Spende GVC Soll 119, Haben 169
CLPR Autokredit
COMM Kommissionszahlung
COST Kosten Allgemein
CSLP Sozialversicherungsab-gaben
DCRD Debitkartenzahlung
DNTS Zahnarzt Service
ELEC Stromrechnung
ENRG Energie
ESTX Grundsteuer
GASB Gasrechnung
GDDS Warenkauf/Verkauf
GOVI Staatliche Versicherung
GOVT Zahlung an/von ffentli-chen Kassen
GVC Haben 156
GWLT Kriegsversehrtenzahlung
HLTC Gesundheits Service
HLTI Krankenversicherung
Purpose- Code - Auszug
Erklrung Spezieller Geschfts-vorfall-Code fr elektro- nischen Auszug, bzw. Anmerkungen
HSPC Krankenhausbehandlung
INPC Autoversicherung
INSM Ratenzahlung
INSU Versicherung
INTC Intra-Company bertrag
INTE Zinsen
INTX Einkommenssteuer
LBRI Berufsversicherung
LICF Lizenzkosten
LIFI Lebensversicherung
LOAN Kreditzahlung
MDCS Medizinische Dienste
NWCM Netzwerkkommunikation
PAYR Lohn/Gehaltszahlung GVC Haben 153 (ab DF-2.7)
PENS Pensions- und Renten-zahlung
GVC Haben 153
PHON Telefon
PPTI Haus/Grundstcksversi-cherung
RINP Dauerauftragsgutschrift GVC Haben 152 (Ab DF 2.7)
RLWY Bahnverkehr
SALA Lohn/Gehaltszahlung GVC Haben 153
SAVG Sparerzahlung
SCVE Dienstleistungen Allgemein
SSBE Sozialleistungen GVC Haben 156
STDY Bildung und Unterricht
SUPP Lieferantenzahlung
TAXS Steuerzahlung
TELI Laut Telefonauftrag
TRAD Handelsgeschft
VATX Mehrwertsteuer
WEBI Laut Auftrag im Internet
WTER Wasser
24
10.3 Produktkategorie: Category Purpose
Der Category Purpose ist eine Anweisung des Einreichers an die Einreicher-Bank Er gilt eine besondere Verarbeitung der Auftrge/der Datei z.B. mit einer Priorisierung oder Sonderkonditionen Gilt fr Datei oder je Zahlung Die Information geht nicht an die Empfnger-Bank Es ist eine bilaterale Vereinbarung ber Nutzung mit der Bank erforderlich Bei HVB wird dzt. nur SALA (gleichtgige Gehaltszahlungen) auf Dateiebene verwendet. Weitere
Informationen zum Produkt knnen Sie auch unserem Spezialflyer Credit Transfer Preferred entnehmen
... ... SALA ...
GroupHeader
PaymentInf Dateiebene
Transaktion
* Adresse nicht mglich bei Initiating Party
10.4 Fnf Beteiligte in einer SEPA-Nachricht
Beispiel SEPA-berweisung
Auftraggeber und Empfnger bzw. Zahlungspflichtiger erscheinen in den verschiedenen Ebenen eines SEPA Auftrages bzw. einer Dateieinreichung. ber die Felder Ultimate kann zustzlich ein abweichender Auftraggeber und Zahlungsempfnger bzw. - pflichtiger mitgegeben werden.
InitiatingParty (Einreicher)
Debitor (Auftraggeber)
Name (70 Stellen)
Creditor (Empfnger)
IBAN/BIC (Auftraggeber)
IBAN/BIC (Empfnger)
UltimateDebitor
UltimateCreditor
Adresse (2x 70 Stellen zzgl. Lndercode)*
Pflichtangabe
Optional
Organisationsnummer
Personenidentifikation
25
GroupHeader
PaymentInf Dateiebene
Transaktion
* Adresse nicht mglich bei Initiating Party** OrgID & PrivId nicht mglich bei Creditor
Beispiel SEPA-Lastschrift
InitiatingParty (Einreicher)
Creditor (Auftraggeber)
Name (70 Stellen)
Debitor (Zahlungspflichtiger)
Glubiger-ID (Creditor)
IBAN/BIC (Zahlungspflichtiger)
IBAN/BIC (Creditor)
UltimateCreditor
UltimateDebitor
Adresse (2x 70 Stellen zzgl. Lndercode)*
Pflichtangabe
Optional
Organisationsnummer**
Personenidentifikation**
10.5 Name, Adresse
In der SEPA Nachricht gibt es fnf mgliche Beteiligte (Debitor, Creditor, InitiatingParty, Ultimate Creditor und Ultimate Debtor)
Der jeweilige Name der Beteiligten wird immer mit bis zu 70 Stellen angegeben Optional knnen noch Adressen mitgegeben werden. Hierzu sind 2 mal 70 Stellen der
unstrukturierten Adresse zu verwenden zuzglich dem Lndercode Der Auftraggebername und die -Adresse (bei grenzberschreitenden Zahlungen) mssen aufgrund der Auftrag-
geberdatenverordnung korrekt mitgeliefert werden. Die HVB fllt diese automatisch mit den Kontostammdaten
ABC Handels GmbH
DE Dorfstrasse 14 Muenchen
26
10.6 IBAN
International Bank Account Number IBAN ist das eindeutige Identifikationskriterium fr Zahlungsempfnger und Zahlungspflichtige. Die IBAN lst die nationale Kontonummer im SEPA-Zahlungsraum fr SEPA-Auftrge komplett ab.
Der Aufbau ist definiert von ISO 13616-1:2007. Die IBAN beginnt mit zwei Buchstaben, dem Lnderkennzei-chen, gefolgt von der numerischen Prfziffer. Die zweistellige Prfziffer errechnet sich ber die gesamte IBAN nach ISO 7064 im Modulus 97-10. Anschlieend erfolgt eine Bank/Kontoidentifikation. Diese Bank/Kontoiden-tifkation ist je nach Land unterschiedlich strukturiert hat eine unterschiedliche Anzahl an Stellen. Somit kann die IBAN zwischen 15 und 31 Stellen lang sein und neben numerischen Werten auch ausserhalb des Lnder-codes alphanumerische Werte beinhalten.
In Deutschland bilden die ersten 8 Stellen nach der Prfziffer die numerische Bankleitzahl und die folgenden 10 Stellen die numerische Kontonummer, so dass der gesamte IBAN in Deutschland 22 stellig ist. Ob die Kontonummer korrekt ist, lsst sich fr viele Banken anhand der letzten Stelle der Kontonummer sagen. Viele Banken verwenden diese letzte Ziffer fr eine Kontrollziffer. Welcher bankenindividuelle Berechnungsmodulus hierfr notwendig ist, lsst sich im Bankleitzahlenverzeichnis bei der Bundesbank anhand der BLZ ermitteln.
Eine simple Ermittlung der Prfziffer anhand der BLZ und Kontonummer fhrt in Deutschland hufig zu Fehlleitungen von Zahlungen, da besonders zu beachten ist:
Einzelne Institute fllen das Kontonummernfeld im IBAN bei Kontonummern kleiner 10 Stellen nicht linksbndig mit Nullen auf sondern fllen die Nullen am Ende der Kontonummer
Besonders durch Fusionen und Zusammenlegungen von Bankfilialen benutzen Kunden hufig noch ihre alte Bankleitzahl weiter, obwohl sie bereits in ihrem IBAN eine neue Bankleitzahl erhalten haben
Deshalb sollte eine Konvertierung immer ber die kontofhrende Bank oder in Deutschland ber den BankVerlag stattfinden
DE40700202700012345678
27
IBAN Beispiele fr andere Lnder
sterreich (20 stellig): LLPPBBBBBKKKKKKKKKKKLL Lnderkennzeichen: AT BuchstabenPP Prfziffer 2 stellig numerisch BBB... sterreichische Bankleitzahl 5 stellig numerischKKK... Kontonummer 11 stellig numerisch
Schweiz (21 stellig): LLPPBBBBBKKKKKKKKKKKKLL Lnderkennzeichen: CH BuchstabenPP Prfziffer 2 stellig numerischBBB... Schweizer Bankleitzahl 5 stellig numerischKKK... Kontonummer 12 stellig numerisch
Italien (27 stellig): LLPPNBBBBBCCCCCKKKKKKKKKKKKLL Lnderkennzeichen: IT BuchstabenPP Prfziffer 2 stellig numerischN Control Internal Number (CIN) 1 stellig alphanumerischBBB... Associazione Bancaria Italiana (ABI) 5 stellig numerischCCC... Codice di Avviamento Bancario (CAB) 5 stellig numerischKKK... Kontonummer 12 stellig numerisch
10.7 Glubigeridentifikation (Creditoridentification/CI)
SEPA-Lastschrifteinreicher bentigen eine eindeutige Identifikationsnummer. Diese ist bei der Bundesbank pro Legal-Entity erhltlich www.glaeubiger-id.bundesbank.de Format: LLPPZZZ0NNNNNNNNNNLL LndercodePP Prfziffer berechnet nach ISO 13616 (analog IBAN-Prfziffer)ZZZ Glubiger Geschftsbereichskennung, beliebig zu vergeben, z.B. um berschneidungen
bei Mandatsreferenzen zu vermeiden. Im Standard mit Wert ZZZ belegen0NN 11-stellige eindeutige Glubigeridentifikation mit fhrender Null
Die Glubigeridentifikation sollte mglichst auf Payment-Informations-Ebene und nicht bei jeder Transaktion wiederholt angegeben werden
DE12ZZZ01234567890 SEPA
28
10.8 Identifikationsnummern (OrgID/PrivateID)
Optional kann zum Namen auch eine Identifikationsnummer mitgegeben werden. In Deutschland (DF- Anlage) wird empfohlen diese Felder nicht zu belegen, da auch eine Durchgngigkeit, z.B. im MT940 nicht gegeben ist. In manchen Lndern bzw. fr bestimmte Zahlungen, z.B. Steuerzahlungen, sind diese Angaben allerdings notwendig. Auch das internationale CGI-Format verlangt teilweise diese Identifikationsnummern. Neben der Identifikationsnummer knnen noch Daten, wie z.B. die ausstellende Behrde , mitgegeben werden. Es kann entweder eine Organisationsnummer oder eine Personennummer angegeben werden
Organisations Identifikation OrgID>, z.B. Firmennummer (COID), Kundennummer (CUST), Steuernummer (TXID), Arbeitgebernummer (EMPL), BIC/BEI, DUNS u.a. Siehe www.iso20022.org/external_code_list.page im Reiter 9-OrganisationIdentification
Personen Identifikation , z.B. Geburtsdatum/Ort, Sozialversicherungsnrummer (SOSE), Passnummer (CCPT), Steuernummer (TXID), Kundennummer (CUST), Fhrerscheinnummer (DRLC), Mitarbeiternummer (EMPL) u.a. Siehe www.iso20022.org/external_code_list.page im Reiter 10-PersonIdentifcation
Beispiel (entweder Geburtsdatum/ort ODER eine Nummer)
181/815/08155 TXID Finanzamt Muenchen IV
RA 123445123
CCPT Kreisverwaltungsreferat Muenchen
1980-11-07 Bayern Muenchen DE
29
10.9 Ultimate/Reference Party/On Behalf
Neben dem Auftraggeber knnen Namensfelder des abweichenden Auftraggebers Ultimate mitgeliefert werden. Auch fr den Empfnger gibt es die Mglichkeit, einen Ultimate Endbegnstigten bzw. einen Ultimate Zahlungspflichtigen im Datensatz mitzugeben
Der Abweichende Auftraggeber kann entweder auf Dateiebene (PaymentInf) oder auf Transaktionsebene mitgeschickt werden. Empfohlen wird hier die Verwendung auf Dateiebene
Wenn bei einer SEPA-Lastschrift ein Ultimate verwendet wird, muss dieser auch auf dem Mandat angegeben sein. Fr eine schuldbefreiende Zahlung bei Lastschriften ist auf der Zahlungsempfngerseite ein Konto fr fremde
Rechnung notwendig Die Ultimate-Felder haben rein informatorischen Charakter und werden als zustzlicher Verwendungszweck
interpretiert Nicht jede Bank bietet ber alle Kanle die Durchleitung dieser zustzlichen Informationen an den Empfnger
an. Besonders im Papier-Kontoauszug werden diese Informationen derzeit nur vereinzelt angedruckt. Eine zustzliche Angabe im Verwendungszweck ermglicht in jedem Fall eine Anzeige beim Endbegnstigten bzw. Zahlungspflichtigen
Im MT940 erfolgt die Weitergabe der Ultimate-Informationen im Feld 86/Subfeld ?20-?29 oder wenn kein Platz im Subfeld ?60-?63:
ABWA+[Abweichender berweisender (CT) bzw. Zahlungsempfnger (DD)] ABWE+[Abweichender Zahlungsempfnger (CT) bzw. Zahlungspflichtiger (DD)]
berweisung Beispiel Kindergeld
Lastschrift Beispiel Handyrechnung
Abweichendes Retourenkonto
Die Ultimate-Felder knnen auch dazu verwendet werden, um ein abweichendes Retourenkonto anzugeben. Hierbei wird das Einreicher- und Belastungskonto in die Feldgruppe UltimateDebtorId bei der berweisung bzw. UltimateCreditorId bei der Lastschrift eingestellt. Ein davon abweichendes Retourenkonto, auf dem etwaige Retouren gesammelt werden, wird dann in die normalen Debitor bzw. Creditor Felder eingestellt. Hierzu ist eine besondere Vereinbarung mit der HVB erforderlich. Nhere Infos zu dem Produkt Ultimate-Auftraggeber erhalten Sie bei Ihrem Cash Management & eBanking Spezialisten.
Firma AG
Kindergeld-Abteilung
Mutter Meier
Kind Meier
Mobilfunk AG
Mutter Meier
Kind Meier
30
On behalf Payments ber Payment FactoryWerden in einer Unternehmensgruppe ber eine Dachgesellschaft Zahlungen fr die verschiedenen Gesell-schaften durchgefhrt (Payment Factory) ist insbesondere bei den SEPA-Lastschriften, den Mandaten und der Glubiger-ID zu beachten, wer die Mandate mit welcher Glubiger-ID zu schlieen hat und ber welche Konten der Zahlungsverkehr ausgefhrt wird, damit auf der Auftraggeberseite und hinsichtlich einer schuldbefreienden Zahlungen alle Voraussetzungen getroffen sind.
Grundannahme: Liefergeschft und Rechnungsstellung erfolgt durch Lieferfirma Creditor ist Zahlungsabwicklungsfirma. Hierbei hat die kontofhrende Stelle zu beachten, dass die eingehenden
Gelder auf ein Konto fr fremde Rechnung laufen mssen (Treuhandkonto fr Lieferfirma). Eine Haftungs-erklrung durch Zahlungsabwicklungsfirma fr Rcklastschriften ist notwendig
Zahlungsabwicklungsfirma reicht die Lastschriften ein. Beim Einreicherkonto wird die Glubiger-Identifikations-nummer (CI) der Zahlungsabwicklungsfirma hinterlegt und bei Einreichungen geprft. Bei Gutschrift auf ein Zahlungsabwicklungsfirma-Konto muss also die CI von Zahlungsabwicklungsfirma hinterlegt werden. Ein Unternehmen kann nur mit einer CI Lastschriften einreichen, d.h. Zahlungsabwicklungsfirma kann nicht mit der CI von der Lieferfirma einreichen
Was ist auf dem Mandat anzugeben: Creditor ist Zahlungsabwicklungsfirma, CI von Zahlungsabwicklungsfirma als Creditor Reference Party wird Lieferfirma und als deren CI als Creditor Reference ID angegeben
Das Mandat mit Creditor Lieferfirma und CI Lieferfirma kann aufgrund der Koppelung der Kontonummer mit der CI nur fr die Gutschrift auf ein Lieferfirma Konto verwendet werden
Lastschrift
10.10 Mandatsnderung/Mandate-Amendment
Wenn sich nderungen am Mandat ergeben, muss nicht in jedem Fall ein neues Mandat eingeholt werden. Die Mandatsnderung wird in der nchstflligen SEPA-Lastschrift mitgeliefert
Folgende Felder sind hierfr im pain.008 vorgesehen: Creditor bedingte nderungen nderung der Mandatsnummer z.B. weil eine neue Mandatssystematik eingefhrt wird Mitgabe der neuen Mandatsnummer und der alten Mandatsnummer nderung des Creditor-Namen, z.B. aufgrund von Firmenfusionen. Hier wird zumeist auch eine neue
Glubiger-Identifikationsnummer ntig Mitgabe der neuen Glubiger-Identifikationsnummer und der alten Glubiger-
Identifikationsnummer sowie des neuen Creditor-Namens und des alten Creditor-Namens
Zahlungsabwicklungsfirma
Lieferfirma
Meier
31
nderungen beim Zahlungspflichtigen nderung der Debitoren-Kontoverbindung Mitgabe der neuen IBAN und alten IBAN Wechselt der Debitor seine Bank wird das Kennzeichen SMNDA (SameMandateNewDebtorAgent)
vergeben. Damit die neue Bank die korrekte Sequenz der Einreichung berprfen kann, muss diese Lastschrift dann als erstmalig FRST geschickt werden (mit den jeweilig notwendigen Vorlauftagen)
ndert sich der Debitorname, z.B. Heirat, muss kein neues Mandat eingeholt werden. Eine besondere Kennzeichnung in der Lastschrift ist hierbei nicht erforderlich
Kunde(Debitor)
B2B- Mandatsauftrag bzw. Debtor-Profilingmit genderten Mandatsdaten
schriftliche Mitteilung ber genderte IBAN/BIC Lieferant
(Creditor)Pre-Notification mit genderten Mandatsdaten
Debitor-Bank
MandatsnderungenDebitor-IBAN (alt/neu)Debitor-BIC Glubiger-ID (CI) (alt/neu)Creditorname (alt/neu)Mandats-ID (alt/neu)
Lastschrift mit angehngtenMandatsnderungen (alt/neu) Besonderheit: Bei BIC-nderung als FIRST D-5
Einreichung der nchsten* Lastschrift mit angehngtenMandatsnderungen
Archivierung derMandatsnderung
Prfung B2B-Lastschrift auf gltigen MandatsauftragPrfen auf Debtorprofiling (z.B. Sperren)
* falls eine Lastschrift mit Mandatsnderung rejected (pain.002) wird, muss der Folgeeinzug wieder mit Mandatsnderung erfolgen
1 2
4 8
7
3
6
5Einzug der Lastschrift mit angehngtenMandatsnde-rungen (alt/neu)
berblick des Prozesses bei Mandatsnderungen
Weiter zu beachten Wenn die Lastschrift mit den Mandatsnderungen vor Buchung zurckkommt (Information z.B. mit
(pain.002), muss der folgende Lastschrifteinzug wieder diese Mandatsnderungen enthalten In der Lastschrift mitgegebene Mandatsnderungen fhren bei der Zahlungspflichtigenbank nicht
automatisch zu nderung der Weisungen. So mssen vom Zahlungspflichtigen hinterlegte SEPA-Firmenlast-schriftsmandate durch den Zahlungspflichtigen ggf. aktiv gendert werden. Gleiches gilt auch fr hinterlegte Mandats-Sperrlisten (Negativ-Liste) bzw. explizit erlaubte Einzge (Positiv-Liste) von SEPA Basislastschriften. Diese mssen ggf. an die Mandatsnderung angepasst werden. Informieren Sie deshalb frhzeitig den Zahlungspflichtigen ber etwaige nderungen (z.B. ber eine hervorgehobene Prenotification) um unntige Retouren zu vermeiden
Archivieren Sie die Mandatsnderungen und die dazugehrigen Auftrge fr den lckenlosen Nachweis, um bei Mandatsanforderungen eine Lastschriftretoure wegen fehlender Autorisierung zu vermeiden
32
555544 2012-11-12 true 444444 Schrauben AG DE16HVB00000017432 SEPA DE84700202700654150818 SMNDA
Wann muss ein neues Mandat eingeholt werden? Wenn seit dem letzten Einzug 36 Monate vergangen sind Wenn eine Lastschriftrckgabe mit den Rckgabegrund NoMandate MD01 erfolgt Der letzte Einzug erfolgte mit Sequenz FNAL-Final oder OOFF-OneOff (und wurde nicht rejected) Der Debitor hat gegenber dem Creditor sein Mandat widerrufen
Kennzeichen neue Debtor-Bank
alte Debtor-IBAN
alte Glubiger-Identifikation
alter Creditor-Name
alte Mandatsnummer
Kennzeichen Mandatsnderung wird mitgeliefert
Aktuelle Mandatsnummer und Unterschriftsdatum
33
RCUR
Cutoff auf Basis der Sequenz FRST First RCUR recurrent FNAL Final OOFF OneOff
Basislastschrift (CORE)
Regel Vorlage Debtorbank, Flligkeitstag Duedate x
D 5 D 2 D 2 D 5
Cutoff HVB D 6, 12 Uhr D 3, 12 Uhr D 3, 12 Uhr D 6, 12 Uhr
Cutoff HVB Beispiel Fllig: Fr 31.1.2013
Mi 23.1.2013, 12 Uhr
Mo 28.1.2013, 12 Uhr
Mo 28.1.2013, 12 Uhr
Mi 23.1.2013, 12 Uhr
Basislastschrift mit verkrzter Vorlauffrist (COR1)
Regel Vorlage Debtorbank, Flligkeitstag Duedate x
D 1 D 1 D 1 D 1
Cutoff HVB D 2, 12 Uhr D 2, 12 Uhr D 2, 12 Uhr D 2, 12 Uhr
Cutoff HVB Beispiel Fllig: Fr 31.1.2013
Di 29.1.2013, 12 Uhr
Di 29.1.2013, 12 Uhr
Di 29.1.2013, 12 Uhr
Di 29.1.2013, 12 Uhr
Firmenlastschrift (B2B)
Regel Vorlage Debtorbank, Flligkeitstag Duedate x
D 1 D 1 D 1 D 1
Cutoff HVB D 2, 12 Uhr D 2, 12 Uhr D 2, 12 Uhr D 2, 12 Uhr
Cutoff HVB Beispiel Fllig: Fr 31.1.2013
Di 29.1.2013, 12 Uhr
Di 29.1.2013, 12 Uhr
Di 29.1.2013, 12 Uhr
Di 29.1.2013, 12 Uhr
10.11 Lastschriftsequenz
Es gibt zwei unterschiedliche SEPA-(Basis-/Firmen-) Lastschrift Mandate Fr WIEDERKEHRENDE Einzge Fr EINMALIGE Einzge Dieses wird auf dem Mandat angegeben. Auerdem ist fr die Sequenz entscheidend, ob ein Mandat bereits
verwendet wurde bzw. auch knftig weiter verwendet wird. Der Einzug der Lastschrift muss mit der korrekten Lastschriftsequenz erfolgen. Die Sequenz muss auf
logischer Dateiebene sortenrein geliefert werden. Von der Sequenz aus werden auch die korrekten Vorlauftage zum Flligkeitstag in Abhngigkeit des Lastschriftproduktes Core/Cor1/B2B bei der Einreichung berprft.
Arten der Lastschriftsequenzen Ersteinzug einer WIEDERKEHRENDEN Lastschrift FRST (First) Folgeeinzug einer WIEDERKEHRENDEN Lastschrift RCUR (Recurrent) Letzter Einzug einer WIEDERKEHRENDEN Lastschrift FNAL (Final) EINMALIGER Einzug OOFF (OneOff)
Bitte beachten Sie ggf. abweichend vereinbarte Cutoffzeiten. Die aktuell gltigen Cutoffzeiten der HVB finden Sie unter www.hvb.de Geschftsbedingungen/Konditionen
Grundlage fr die Berechnung: Fr die Vorlauftage (D 5/D 2/D 1) werden im Interbanken-Clearing Targettage verwendet, d.h. Montag
Freitag ohne die Targetfeiertage (1. Januar, Karfreitag, Ostermontag, 1. Mai, 25. & 26. Dezember) Fllt ein Flligkeitstag auf ein Wochenende oder einen Targetfeiertag, kann die Zahlungspflichtigenbank die
Debitorbelastung auf den nchstmglichen Bankarbeitstag verschieben Fr die Prenotificationregel (mind. 14 Tage) zhlen Kalendertage Fr die Lastschrift-Retoure (Return D+2 fr die B2B bzw. D+5 fr die Basislastschrift) zhlen Targettage Fr die Cutofftage zhlen Bankgeschftstage
bersicht ber die Cutoff-Termine pro Lastschriftprodukt auf Basis der Sequenz mit Beispiel
34
Aktueller Einzug Rckgabe des aktuellen Einzugs FolgeeinzugFRST First Keine Rckgabe RCUR Recurrent*
FRST First Vor Buchung (pain.002) FRST First
FRST First Nach Buchung RCUR Recurrent*
RCUR Recurrent Keine Rckgabe RCUR Recurrent*
RCUR Recurrent Vor Buchung (pain.002) RCUR Recurrent*
RCUR Recurrent Nach Buchung RCUR Recurrent*
FNAL Final Keine Rckgabe Kein Folgeeinzug
FNAL Final Vor Buchung (pain.002) FNAL - final
FNAL Final Nach Buchung Neues Mandat ntig
OOFF OneOff Keine Rckgabe Kein Folgeeinzug
OOFF OneOff Vor Buchung (pain.002) OOFF OneOff
OOFF OneOff Nach Buchung Neues Mandat ntig
Mandatsnderung neue Debtorbank SMNDA mit FRST First (Pflicht)
Keine Rckgabe RCUR Recurrent*
Mandatsnderung neue Debtorbank SMNDA mit FRST First (Pflicht)
Vor Buchung (pain.002) FRST First & Mandatsnderung SMNDA wiederholen
Mandatsnderung neue Debtorbank SMNDA mit FRST First (Pflicht)
Nach Buchung RCUR Recurrent* (Mandatsnderung nicht wiederholen)
Mandatsnderung gleiche Debtorbank mit RCUR Recurrent
Keine Rckgabe RCUR Recurrent* (Mandatsnderung nicht wiederholen)
Mandatsnderung gleiche Debtorbank mit RCUR Recurrent
Vor Buchung (pain.002) RCUR Recurrent* & Mandatsnderung wiederholen
Mandatsnderung gleiche Debtorbank mit RCUR Recurrent
Nach Buchung RCUR Recurrent* (Mandatsnderung nicht wiederholen)
* Ausnahme: der Folgeeinzug ist der letztmalige, dann mit FNAL-Final kennzeichnen
Besonderheiten fr die Lastschriftsequenz Kommt die Lastschrift vor Buchung zurck (reject/refusal/storno per pain.002) gilt die Lastschrift als nicht
angekommen und es muss die ursprngliche Sequenz fr den Folgeeinzug genommen werden. Es mssen dann auch die ursprnglichen Vorlauftage eingehalten werden
Kommt die Lastschrift nach Buchung zurck (return/refund) gilt die Lastschrift als angekommen. Es muss die nchste Sequenz fr den Folgeeinzug genommen werden, bzw. das Mandat gilt bei einer einmaligen bzw. finalen Lastschrift als abgelaufen
Erfolgt eine Mandatsnderung auf eine neue Zahlungspflichtigenbank SMNDA-SameMandateNewDebitor-Agent muss die Lastschriftsequenz als erstmalig FRST gekennzeichnet werden
Erfolgt eine Mandatsnderung auf die gleiche Zahlungspflichtigenbank (nur nderung der Creditordaten bzw. nur neue IBAN des Debitors bei gleicher Bank), muss die normale folgende Lastschriftsequenz verwendet werden
Mit welcher Lastschrift-Sequenz erfolgt der Folgeeinzug, wenn es eine Rckgabe einer Lastschrift gab und wann sind Mandatsnderungen zu wiederholen?
35
10.12 Zeichensatz und Umlaute
In SEPA kann ein umfangreicher Zeichensatz verwendet werden (UTF-8) mit vielen lnderspezifischen Umlauten. Das Deutsche Format (DK) lsst in der DF-Anlage derzeit nur einen eingeschrnkten Zeichensatz zu: Numerische Zeichen 0 bis 9 Buchstaben A bis Z und a bis z Sonderzeichen : ? , - ( + . )/und Leerzeichen Im EPC Format verarbeitet die HVB auch noch weitere Zeichen deutsche Umlaute Lnderumlaute
Sonderzeichen ! # $ % * ; = [ \ ] ^ { | } ~ Infos grundstzlich zum Zeichensatz:
www.europeanpaymentscouncil.eu/knowledge_bank_detail.cfm?documents_id=332 Im XML-Format sind folgende Sonderzeichen problematisch und sollten nicht verwendet werden:
& < > @ _ Banken, die die Sonderzeichen und Umlaute nicht verarbeiten knnen, ersetzen diese ggf. durch hnliche
Zeichen laut EPC-Empfehlung oder sonst durch Leerstelle oder Punkt. wird noch der alte elektronischen Kontoauszug MT940 verwendet (statt dem neuen camt.053) werden nur
folgende Zeichen weitergegeben: Numerische Zeichen 0 bis 9 Buchstaben A bis Z und a bis z Sonderzeichen : , - ( + . )/und Leerzeichen
Der definierte Zeichensatz ist mglich in allen Namens-, Adress- und Verwendungszweckfeldern.Besondere Felder und Zeichenrestriktionen Referenznummern
Message-ID , Private-ID und strukturierte Creditorreferenz Numerische Zeichen 0 bis 9 Buchstaben A bis Z und a bis z Sonderzeichen : ? , - ( + . )/aber ohne Leerzeichen Mandatsreferenz
hier gilt auch der eingeschrnkte Zeichensatz Numerische Zeichen 0 bis 9 Buchstaben A bis Z und a bis z (Kleinbuchstaben werden wie Grobuchstaben behandelt) Sonderzeichen : ? , - ( + . )/und Leerzeichen Empfehlung, da die Mandatsreferenz besonders wichtig ist, z.B. fr Mandatshinterlegung Keine Leerzeichen und nur eingeschrnkt Sonderzeichen verwenden Keine fhrenden Nullen verwenden Verwechslungsgefahr bei 0 und O BIC/IBAN Verwechslungsgefahr bei 0 und O Der 8 bis 11 stellige BIC hat immer Buchstaben (A bis Z) an den ersten 6 Stellen Der Lndercode des IBAN und der Glubiger-ID ist immer mit 2 Buchstaben zu belegen und die zweistellige
Prfziffer numerisch
36
10.13 Konkurrierende Felder XOR
Hufige Fehler bei der Feldbelegung sind Felder, die mehrfach auf verschiedenen Ebenen vorkommen oder an Bedingungen geknpft sind. Dieses wird durch das XML Prfschema (XSD) nur eingeschrnkt geprft. Einige Felder gibt es auf Dateiebene (Paymentinfo) und auch auf Transaktionsebene, z.B.
Bei einigen Feldern darf entweder das Eine oder das Andere verwendet werden. Beide Feldgruppen zu belegen, ist nicht mglich. Das XSD des DK prft dieses, aber das XSD fr EPC-Formate stellt hier keinen Fehler fest
Der Verwendungszweck kann entweder strukturiert ODER unstrukturiert angegeben werden. Beide knnen nicht gleichzeitig verwendet werden
Organisational-ID versus Private-ID . Hier ist nur eine der beiden Elementengruppen erlaubt Bei Nutzung von der Private-ID kann auch nur entweder eine Identifikationsnummer mit Issuer
und Identifikationsart und ODER ein Geburtstag mit Geburtsort verwendet werden
Paymentinfo-Ebene Transaktions-Ebene entweder oder/PflichtfeldCreditorIdentification(nur SDD)
Empfohlen Alternativ Pflicht bei SDD
CategoryPurpose Empfohlen (ntig fr HVB Produkt SEPA Gehaltszahlung)
Alternativ Optional
ChargeBearer Empfohlen Alternativ Pflicht SLEV
Ultimate-Debtor (SCT)Ultimate Creditor (SDD)
Variante 1 (ntig fr HVB Produkt SEPA Ultimate Auftraggeber)
Variante 2 Optional
ServiceLevel-Code Pflicht Nicht erlaubt auf Transaktionsebene bei DK Pflicht (SEPA, URGP)
InstructionPriority Optional Nicht erlaubt auf Transaktionsebene bei DK Optional
LocalInstrument-Code (nur SDD) Pflicht Nicht erlaubt auf Transaktionsebene bei DK Pflicht bei SDD (B2B, CORE, COR1)
37
10.14 SEPA-Referenznummern und deren Verwendung
Welche Referenznummern gibt es in SEPA und wo werden die vergeben?
SEPA-Feld Beschreibung Datei/Transaktions- Ebene
Verwendung Einreichung
MessageIdentification () Eindeutige technische Referenz der Datei des Datei-erstellers
GroupHeader SCT, SDD
DTI Dateinummer HVB-Sammlerreferenz
Original MessageIdentification ()
Ursprngliche Message ID bei Datei-Reject GroupHeader
PaymentInformationIdentification ()
Referenz der logischen Datei (Sammlerreferenz) Payment-Information SCT, SDD
Original PaymentInformationIdentification ()
Ursprngliche Referenz der logischen Datei bei Datei-Reject
Payment-Information -
Dateinummer HVB Eindeutige Dateinummer von HVB vergeben Payment-Information -
Transaktionsreferenz HVB Eindeutige HVB-Referenz der einzelnen Transaktion Transaktion SCT, SDD
CreditorIdentification (Creditor Identifier, )
Eindeutige GlubigerIdentification (von Bundesbank)
Payment-Information oder Transaktion
SDD
Original CreditorIdentification ()
Nur bei Mandatsnderung die ursprngliche CreditorIdentification
Transaktion SDD
InstructionIdentification () Technische Point-to-Point-Referenz Transaktions-referenz, wird nicht weitergegeben
Transaktion SCT, SDD
Original InstructionIdentification Ursprngliche Point-to-Point-Referenz bei Datei-Reject Transaktion -
End-to-End Identification () Fachliche Auftraggeberreferenz wird an Empfnger weitergeleitet
Transaktion SCT, SDD
Original End to End ID Ursprngliche Auftraggeberreferenz bei Datei-Reject Transaktion -
TransactionIdentification () Eindeutige Transaktionsnummer vom erstbeteiligten Institut vergeben
Transaktion -
Creditor Reference (CreditorReferenceInformation, )
Strukturierte Referenznummer im strukturierten Verwendungszweck
Transaktion SCT, SDD
MandateIdentification (Mandate Reference, )
Eindeutige Mandatsreferenz (bezogen auf GlubigerIdentification)
Transaktion SDD
Original MandateIdentification Nur bei Mandatsnderung die ursprngliche Mandats-referenz
Transaktion SDD
OrganisationIdentification () Identifikationsnummer einer Organisation (BIC, BEI, Steuernummer, Kundennummer, etc.; siehe ISO20022 External Code List)
Payment-Information oder Transaktion
*
PersonIdentification () Identifikationsnummer einer natrlichen Person (Geburtsdatum/Ort, Sozialversicherungsnummer, Pass-nummer, Steuernummer, Kundennummer, etc.; siehe ISO External Code List)
Payment-Information oder Transaktion
*
* in Deutschland Verwendung nicht empfohlen; Ergnzung zu InitiatingParty, Debtor, Creditor, UltimateDebtor, UltimateCreditor
38
SEPA-Feld Reporting pain.002 Reporting MT940/942 Reporting camt.052/camt.053MessageIdentification () pain.002 - -
DTI Dateinummer -
Original MessageIdentification ()
pain.002 - -
PaymentInformationIdentification ()
Wenn lnger als 16 Chars : :86: mit Identifier KREF+Wenn krzer: :61/7:
(only initiator entry)
Original PaymentInformationIdentification ()
pain.002 - -
Dateinummer HVB - :61/9: -
Transaktionsreferenz HVB - :61/8: bzw.
CreditorIdentification (Creditor Identifier, )
- :86: mit Identifier CRED+
Original CreditorIdentification ()
- - -
InstructionIdentification () - - -
Original InstructionIdentification pain.002 - -
End-to-End Identification () - :86: mit Identifier EREF+
Original End to End ID pain.002 - -
TransactionIdentification () - -
Creditor Reference (CreditorReferenceInformation, )
pain.002 Teil des strukturierten Verwendungszwecks (allerdings ohne Tags)
Teil des strukturierten Verwendungszwecks
MandateIdentification (Mandate Reference, )
pain.002 :86: mit Identifier MREF+
39
End-To-End Referenz Die bis zu 35 stellige End-To-End Referenz ist vom Einreicher zu vergeben. Sie wird an den Endempfnger
weitergeleitet und auch bei Retouren wieder an den Einreicher zurckgegeben Wenn diese nicht vom Einreicher mitgegeben wird, wird sie von der Bank mit NOTPROVIDED belegt Weitergabe im MT940: Feld 86/Subfeld ?20-?29: EREF+[Ende-zu-Ende Referenz] oder wenn kein Platz
im Subfeld ?60-?63
Mandatsnummer/Mandatsreferenz Die Mandatsnummer ist in Zusammenhang mit der Glubiger-Identifikationsnummer (CI) europaweit eindeutig Die bis zu 35 stellige Mandatsnummer ist vom Einreicher (Creditor) bei SEPA-Lastschriften eindeutig zu
vergeben Die Mandatsnummer dient dem Zahlungspflichtigen zur Abstimmung sowie fr etwaige Weisungen gegenber
der Debitorbank (z.B. zum Sperren oder betragsmigen Einschrnken der Lastschrift sowie zur Hinterlegung von Abbuchungsauthorisierungen im B2B-Mandat)
Sie wird an den Zahlungspflichtigen weitergeleitet im Prenotification (empfohlen) Pflichtfeld in der SEPA-Lastschrift Mandat zur Unterschrift (kann aber auch nachtrglich ergnzt werden) Elektronischen Kontoauszug MT940 (Feld 86/Subfeld ?20-?29: MREF+[Mandatsreferenz] ) oder wenn
kein Platz im Subfeld ?60-?63 Lastschriftretoure Wenn sich die Mandatsnummer ndert, kann die nderung ber die standardisierte Mandatsnderung
vorgenommen werden (siehe Kapitel Mandatsnderung) Fr die Vergabe der Mandatsnummer beachten Sie bitte auch das Kapitel Zeichensatz (siehe Seite 36)
12345678901234567890123456789012345
555544
40
11. Reporting bersicht11.1 Reporting (Bank-Kunde)
Welches Bank-Kunde Format ist fr welchen Zweck? In der folgenden Tabelle finden Sie eine bersicht der mglichen Varianten von elektronischen Kontoinformationen rund um Kontoauszge, Avise, Buchungssammler und Fehlerinformationen.
11.2 Buchung von SEPA Dateien
Buchung der Datei (Sammler-/Einzelsatzbuchung)Wie erfolgt die Einreicher-Dateibuchung auf dem Konto?Die Kontoeinstellung fr Dateieinreichungen mit mehr als einem Posten ist standardmig die Sammelbuchung. Auf Kundenwunsch knnen auch alle Zahlungen auf dem Konto einzeln gebucht werden, oder das Konto adminis-triert werden, dass Sie pro Datei individuell whlen knnen, welche Datei gesammelt wird (z.B. Gehaltsdateien) und welche Dateien als Einzelbuchung auf dem Kontoauszug erscheinen sollen. In der eingereichten SEPA- Datei knnen Sie individuell pro Datei einstellen ob die Buchung als Sammel- oder Einzelbuchung erfolgen soll (Kennzeichen BatchBooking):
Empfohlen fr Optionen Einschrnkung/ zu Beachten
Format Erstellungs Zeitpunkt
MT940 Elektronischer Kontoauszug Altsysteme
Nicht alle SEPA Felder werden durchgereicht
MT940 Tagesende Buchungstag
MT942 ZV-Avis Altsysteme
Nicht alle SEPA Felder werden durchgereicht
MT942 stndlich Buchungstag
DTI Elektronische Weiterverar-beitung von Eingngen und Retourenverarbeitung Altsysteme
Nicht alle SEPA Felder werden durchgereicht.Nicht fr Lastschriftretouren vor Buchung
DTAUS0DTAUS1
stndlich Buchungstag
camt.053 Elektronischer Kontoauszug Neu
camt.053.001.02 Tagesende Buchungstag
camt.052 Elektronisches ZV-Avis Neu
camt.052.001.02 stndlich Buchungstag
camt.054 Elektronische Weiterverar-beitung von Eingngen und Retourenverarbeitung Neu
Elektronische Informati-on ber die eingereichte SEPA Datei
ab Juni 2013 optional auch: Lastschriftretouren vor Buchung
Nicht fr Lastschriftretouren vor Buchung (bis Juni 2013)
camt.054.001.02 stndlich Buchungstag
camt.086 elektronisches Preis-reporting camt.086.001.01 Monatlich oder quartals-mig je nach Wunsch des Kunden
pain.002 SEPA-Fehlernachrichtenvor Buchung fr das SEPA-Mandats-Management
Optional seit Nov 2012: auch SEPA Fehlernachrich-ten nach Buchung
Keine Lastschrift-Retouren-gebhrenausweisung
DK:pain.002.002.03pain.002.002.02EPC:pain.002.001.03
Sofort bei Fehlerfest-stellung
true
41
BatchBooking = true (Sammelbuchung)
BatchBooking = false (Einzelsatzbuchung)
Damit dieses Feld BatchBooking in der Verarbeitung bercksichtigt wird, beauftragen sie dieses bitte im Vorwege bei Ihrem Cash Management & eBanking Spezialisten der Bank.
Einreicher Bruttoprinzip Die Einreicherbuchung erfolgt analog dem DTA im Inlandszahlungsverkehr im Bruttoprinzip, d.h. wenn einzelne
berweisungen rejected werden (z.B. zwei falsche BICs in einer Datei mit 10 Posten), erfolgt die Belastung auf dem Einreicherkonto mit der Gesamtsumme der Datei fr die 10 Posten. Die fehlerhaften zwei Stze werden dem Einreicherkonto zum Ausgleich wieder gutgeschrieben (dies kann nach Wunsch in einer Sammelsumme oder als Einzelsatz gebucht werden). Die Information ber die Detail-Fehler erfolgt sofort mittels Fehlerprotokoll und wenn gewnscht ber die elektronische Statusinformation pain.002. Die Buchung der Einreichung und der fehlerhaften Stze erfolgt immer zum Buchungstag dieses ist insbesondere relevant bei Lastschriftein-reichungen mit z.B. 6 Tagen Vorlauf. Die gebuchten fehlerhaften Stze werden Ihnen dann am Buchungstag per MT940 bzw. camt.053/camt.054 zur Verfgung gestellt
Einreicher - Nettoprinzip Das Nettoprinzip (die fehlerhaften Stze werden berhaupt nicht gebucht) erfolgt nur, wenn die gesamte Datei
abgelehnt wird. Auch hier erfolgt die Information ber die Detail-Fehler mittels Fehlerprotokoll und wenn gewnscht ber die elektronische Statusinformation pain.002
Wie erfolgt die Empfngerbuchung auf dem Konto?Eine groe Anzahl an Gut- oder Lastschriften knnen in SEPA auch gesammelt und auf dem Konto in einer Summe gebucht werden. Die Detailposten knnen Ihnen dann mittels einer elektronischen Datei zur Weiterverarbeitung zur Verfgung gestellt werden DTI: Hier werden die SEPA-Eingnge gesammelt und von XML in DTAUS-Format konvertiert und als DTI zur
Verfgung gestellt. Fr konkrete Konvertierungsregeln fragen Sie bitte Ihren Betreuer camt.054: um die umfangreichen Felder des SEPA-XML-Formates auch fr die Weiterverarbeitung nutzen zu knnen
42
Gleichartige Umstze (z.B. berweisungseingnge, Rcklastschriften) knnen beim Empfngerkonto gesammelt und in einem Betrag gebucht werden
bersichtlichkeit fr die Kontodispositionen wird erhht Sammlerdetails werden in einem separaten Prozess des Kunden effizient abgewickeltDie Einrichtung einer Sammelverbuchung von Gutschriftseingngen oder Belastungen knnen bei Ihrem zustndigen Cash Management & eBanking Spezialist der Bank beantragt werden.
11.3 Status/Fehler Nachricht pain.002
Mit einer Status/Fehlerdatei pain.002 erhalten Sie elektronisch in pain-Dateiformat eine genaue Rckmeldung zu den fehlerhaften Stzen und die Art der Fehler. Hiermit knnen Sie ein eindeutiges Matching zu Ihren originalen Einreichungen sicherstellen.
ISO 20022 Nachrichten enthalten alle relevanten Informationen von der Einreichung bis zur Rckmeldung Fehler-Report bereits vor Buchung (vergleichbar mit bestehendem Fehlerprotokoll) Besonderheit bei SEPA DD: Weiterleitung Auftrag an Zahlungspflichtiger-Bank bereits vor Flligkeit Prfung durch Zahlungspflichtiger-Bank vor Flligkeit (z.B. Konto aufgelst) Rckmeldung von Fehlern an Einreicher bereits vor Flligkeit bzw. vor Buchung Ergnzt Information im Kontoauszug (camt.053), da dieser erst nach Buchung vorliegt
Creditor Creditorbank Debtorbank Debtor
Beispiel SEPA-Lastschrift
pain.002 pacs Reject
Auftraggeber initiiert
Auftraggeber-Bank initiiert
Zahlungspflichtiger-Bank initiiert
Zahlungspflichtiger inittiiert
camt.053 (Kontoauszug)
camt.054 (Sammlerdetails)
Auftraggeber
Auftraggeber
Auftraggeber
Bank Empfnger
43
Unterscheidung der Rckgabe vor oder nach Buchung?Relevant ist hier immer der Interbankensettlement-Zeitpunkt. Rckgaben vor diesem Zeitpunkt werden dem Einreicher als Storno gebucht und Rckgaben danach als Retoure. Bei der Empfngerbank kann es sein, dass auch Rckgaben vor Buchung aus Transparenzgrnden dem Kunden gebucht und gleich wieder zurckgebucht werden. Die Unterscheidung auf der Einreicherseite ist insbesondere relevant, da ja fr Lastschrift-Folgeein-reichungen die richtige Sequenz gewhlt werden muss.Wie kann der Einreicher jetzt die richtige R-Nachricht identifizieren? Anhand der Rckgabegrnde lsst sich keine eindeutige Zuordnung treffen.
Option pain.002 auch fr Retouren nach Buchung dies kann sinnvoll sein, wenn fr das Mahnwesen zu den Lastschriftretouren nur ein einheitliches Format genutzt werden soll (der Standard wre pain.002 fr Rckgaben vor Buchung und camt.054 fr Retouren nach Buchung) wenn die Option pain.002 genutzt wird, ist folgendes zu beachten Die Unterscheidung der pain.002 Nachricht vor und nach Buchung lsst sich derzeit nur anhand der Referenz-
nummer bei der HVB durchfhren. Die pain.002-Vor-Buchung hat in der an 3. Stelle ein F, die pain.002-Nach-Buchung an der 3. Stelle ein I
Da im pain.002.002.03 die Felder fr Interbankpreise und Zinskompensationen nicht erlaubt sind, werden diese im pain.002.002.03 nicht explizit ausgewiesen. Der Bruttorckgabebetrag (inkl. Retourenpreise und Zinskompensationen) ist eingestellt in
Vor Buchung Nach BuchungBuchung Storno Retoure
pain.002 ja optional
Auftraggeber initiierte R-Nachrichten: Vor Buchung Rckruf (Revocation/Recall)
z.B. Besttigung der Revocation
Einreicher Bank initiierte R-Nachrichten: Vor Buchung Zahlungspflichtiger-Bank fr Lastschriften nicht SEPA-ready Pflichtfelder fehlen IBAN Check fehlerhaft
Zahlungspflichtiger-Bank initiierte R-Nachrichten bei Lastschriften: Vor Buchung Reject, z.B. Zahlungspflichtiger-Konto besteht nicht Zahlungspflichtiger-Konto gesperrt
Zahlungspflichtiger initiierte R-Nachrichten: Vor Buchung Mandatssperre durch Zahlungspflichtiger Komplette Lastschriftssperre Widerspruch bereits vor Buchung
44
11.4 Rckgabegrnde
Die HypoVereinsbank stellt Ihren Kunden die Rckgabegrnde in den Kontoauszgen sowohl papierhaft als auch elektronisch in den Datentrgerinformationen zur Verfgung.
Return-Reason ISO-Code
Name German Translation Returncode in MT940/DTI Textschlssel-Ergnzung
Returncode in pain.002
AC01 Incorrect Account Number IBAN fehlerhaft 901 AC01
AC04 Closed Account Number Konto aufgelst 902 AC04
AC06 Blocked AccountKonto gesperrt (auch bei unwiderruflicher Lastschriftsperre) 903 AC06
AC13 InvalidDebtorAccountTypeDer Zahlungspflichtige ist ein Verbraucher (relevant bei SEPA-Firmenlastschrift) 930 AC13
AG01 Transaction Forbidden Zahlungsart fr Konto unzulssig 904/914** AG01/MS03**
AG02 Invalid Bank Operation CodeTransaktionscode ungltig (auch falsche Lastschriftsequenz) 905 AG02
AM01 Zero Amount Betrag ist Null 911* AM01
AM02 Not Allowed Amount Betrag ist unzulssig 911*/914** AM02/MS03**
AM03 NotAllowedCurrency Whrung ist unzulssig 911*/914** AM03/MS03**
AM04 Insufficient Funds Rckgabe mangels Deckung 906/914** AM04/MS03**
AM05 Duplication Doppeleinreichung 907 AM05
AM06 TooLowAmount Betrag zu niedrig 911*/914** AM06/MS03**
AM07 BlockedAmount Betrag gesperrt 911*/914** AM07/MS03**
AM09 WrongAmount Betrag nicht korrekt 911*/914** AM09/MS03**
AM10 InvalidControlSum Summe Einzelbetrge ungleich Prfsumme 911* AM10
ARDTAlready returned transaction (Recall-Answer) Bereits zurckgegeben (Antwort auf SCT-Recall) 905* AG02
BE01 InconsistenWithEndCustomerKennung des Endkunden passt nicht zu der entsprechenden Kontonummer 911*/914** BE01/MS03**
BE04 Account address invalid Adressangaben unvollstndig 908/914** BE04/MS03**
BE05UnrecognisedInitiatingParty Identifier fo the Creditor incorrect
Absender unbekannt/ CI incorrect 911* BE05
BE06 UnknownEndCustomer Auftraggeber/Zahlungsempfnger unbekannt 911* BE06
BE07 MissingDebtorAddressAdresse des Zahlers (Zahlungspflichtigen) fehlt oder unvollstndig 914/914** BE07/MS03**
DT01 Invalid DateUngltiges Datum (z. B. falsches Abrechnungsdatum) 916* DT01
ED05 Settlement Failed Die Begleichung der Transaktion ist fehlgeschlagen 914 ED05
FF01 reject due to an invalid file format Dateiformat ungltig 911 FF01
45
Die genaue Feldbelegung stellt Ihnen auf Anfrage Ihr Cash Management & eBanking Spezialist gerne zur Verfgung.
* Meist keine Buchung deshalb kein MT940, sondern nur fr pain.002 interessant** Datenschutz Einschrnkung Abkommen ber SEPA-Inlandslastschrift; bei aktiven SDD-Retouren Datenschutz auf Debtorbank-
Seite innerhalb Deutschlands zu beachten, deshalb anonymisiert 914 bzw MS03
Return-Reason ISO-Code
Name German Translation Returncode in MT940/DTI Textschlssel-Ergnzung
Returncode in pain.002
FF05 DirectDebitTypeIncorrectFalsche Lastschriftart (COR1 trotz fehlender COR1-Vereinbarung verwendet) 931 FF05
FOCRpositive request for cancellation recall Rckgabe aufgrund eines Recalls (Rckrufes) 919 FOCR
LEGLLegal Decision (Recall-Answer)
Rechtliche Entscheidung (Antwort auf SCT-Recall) 917*/914** MS03
MD01 No Mandate
Kein gltiges Mandat (Rckgabe einer nicht autorisierten Lastschrift bis 13 Monate. Weiterverwendung des Mandates nicht erlaubt) 909 MD01
MD02Missing Mandatory Information Mandate
Die Daten zum Mandat fehlen oder sind nicht korrekt 910 MD02
MD03 Invalid File format Ungltiges Dateiformat 911 FF01
MD05 CollectionNotDue Kein flliger Einzug 916/914** DT01/MS03**
MD06 Refund Request By End Customer
Widerspruch durch den Zahler (Zahlungspflichtigen, Rckgabe bis zu 8 Wochen ohne Angaben von Grnden) 912 MD06
MD07 End Customer Deceased Kontoinhaber verstorben 913/914** MD07/MS03
MS02Not Specified Reason Customer Generated
Rckgabe durch den Zahler (Zahlungspflichtigen) vor Flligkeit (Refusal) 914 MS02
MS03Not Specified Reason Agent Generated Grund nicht spezifiziert 914 MS03
NARR Narrative Sonstige Grnde 914 MS03
NOASNo Answer from Customer (Antwort auf SCT-Recall)
Keine Anwort von Kunde (Antwort auf SCT-Recall) 911*/914** MS03
NOORNo Original Transaction Received
Original-SCT nicht erhalten (Antwort auf SCT-Recall) 911* RF01
PY01 Unknown BIC BIC unbekannt 915 RC01
RC01 Bank Identifier Incorrect BIC ungltig 915 RC01
RF01 NotUniqueTransactionReferenceTransaktionsreferenz innerhalb der Nachricht nicht eindeutig 907 RF01
RR01Not Specified Reason Customer Generated
Aufsichtsrechtliche Grnde, fehlendes Konto/ fehlende ID des Zahlers 917/914** RR01/MS03**
RR02 Missing Debtor Name or Address Aufsichtsrechtliche Grnde, fehlender Name/fehlende Adresse des Zahlers 917/914** RR02/MS03**
RR03 Missing Creditor Name or AddressAufsichtsrechtliche Grnde, fehlender Name/fehlende Adresse des Zahlungsempfngers 917/914** RR03/MS03**
RR04 Regulatory Reason Aufsichtsrechtliche Grnde 917/914** RR04/MS03**
SL01Specific Service offered by Debtor Bank
Spezifische Dienstleistung der Bank des Zahlers (auch aufgrund von Positiv-Negativlisten Wei-sung des Zahlungspflichtigen) 918 SL01
TM01 File received after Cut-off Time CutOff-Zeit berschritten 916 TM01
Fortsetzung
46
Wichtige fachliche XML Felder fr pain.002-SEPA Credit TransferFeldnamen Beschreibung
pain.002.002.03Befllung DF Abkommen 2.5/2.6
GrpHdr GroupHeader Absenderdaten 1 x pro logische Datei
MsgId Bankreferenznummer pro Datei Pflichtfeld max. 35 Zeichen
CreDtTm Datum/Zeit der Dateierstellung Pflichtfeld ISO-Date
DbtrAgt Kreditinstitut BIC Pflichtfeld nur SCT 8 bzw. 11 Stellen
OrgnlMsgId Ursprngliche Referenznummer der Kunden-einreichung
Originaldaten
OrgnlMsgNmId Ursprngliche XML-Dateityp Originaldaten pain.001
OrgnlNbOfTxs Ursprngliche Anzahl aller Einzel- transaktionen
Originaldaten
OrgnlCtrlSum Ursprngliche Kontrollsumme in Euro der Einreichung
Originaldaten
GrpSts Status auf Dateiebene Ein Status muss entweder auf Group, PmtInf oder Transaction Ebene angegeben sein
RJCT-Reject
StsRsnInf-Orgtr-Nm Initiator Rckgabe Kunde Nur zusammen mit GrpSts. Wenn Orgtr-BICOrBEI gefllt nicht erlaubt
Name (max. 70 Zeichen) = Kundeninitiert
StsRsnInf-Orgtr-Id-OrgId-BICOrBEI
Initiator Rckgabe Bank Nur zusammen mit GrpSts. Wenn Orgtr-Nm gefllt ist, nicht erlaubt