D I R D E B - Stuzza

Projektgruppe EDIFACT Datenformate 

D I R D E B 

für den InlandsZahlungsVerkehr 

Mai 2003 

In der vorliegenden Dokumentation wird die Verwendung des DIRDEB für die Erteilung von Lastschriften 

und Einzugsaufträgen im Inlands beschrieben. 

DIRDEB Datenbeschreibung STUZZA Version Mai 2003 1 / 33 

P:\A5_Datenträger\NACHRICHTEN\DIRDEB_FAT01G.doc

Inhaltsverzeichnis 

Wozu dient der DIRDEB im österreichischen InlandsZahlungsVerkehr ................................ 3 

Wie verhält sich der österreichische IZV-DIRDEB zum internationalen Standard................. 3 

Die Struktur des DIRDEB / Überblick..................................................................................... 4 

Zusammenfassungsregeln für Sammelaufträge ("batching criteria"):.................................... 5 

Weiterleitungsszenario und Schnittstelle zur NON-EDIFACT Welt ....................................... 5 

Erklärungen zur Dokumentation ............................................................................................ 6 

Branch Diagram..................................................................................................................... 7 

Seitenreferenz .................................................................................................................. 11 

C-Beleg............................................................................................................................. 33 



Wozu dient der DIRDEB im österreichischen InlandsZahlungsVerkehr 

Der DIRDEB dient als elektronischer Auftrag vom KUNDEN an die BANK, von anderen (Zahlungspflichtigen, 

Bezogenen) Beträge einzuziehen und dem Konto des Auftraggebers gutzuschreiben. Der Einzug kann im 

Rahmen des Abkommens und Vertrags für sogenannte Abbuchungsaufträge (Lastschriftsabkommen) oder im 

Rahmen des Einzugsermächtigungsverfahren (EE Abkommen) erfolgen. 

Mir dem hier beschriebenen DIRDEB für den IZV kann nur von Konten eingezogen werden, die bei einer 

inländischen Bank geführt werden. Der Einzugsbetrag kann nur in EUR angegeben werden. Andere Währungen 

werden nicht unterstützt. 

Ob das Konto, über welches der Einzugsauftrag disponiert wird, in EUR geführt wird oder nicht, ist für die 

Währungsangabe im Einzugsauftrag belanglos. Wenn die Konto-Denomination1 von der Denomination des 

Lastschriftsauftrags2 abweicht, wird der entsprechende Gegenwert am Konto gutgeschrieben3. Analoges gilt für 

die Denomination des Kontos auf der Seite des Zahlungspflichtigen. 

Wie verhält sich der österreichische IZV-DIRDEB zum internationalen Standard 

Der "inner-österreichische" DIRDEB ist kein Subset. Die gesamte Definition der Struktur, der Feldbelegung und 

der zulässigen Codes hält sich an den Rahmen, der durch die internationale Standardisierung auf Basis des 

Directory 96A. Da es zum Zeitpunkt der Erstellung dieser Dokumentation noch keinen internationalen Message 

Implementation Guide (MIG) gab, der alle österreichischen Verfahren abdeckt, konnten Codes und Qualifier 

zum Teil nur "entsprechend" belegt werden. Es ist daher möglich, dass es zu geringfügigen Abweichungen 

kommt, die aber mit einer entsprechenden Übergangsfrist an den internationalen Standard angepasst werden. 

Segmente und Felder, denen bei Lastschriftaufträgen im IZV keine sinnvolle Verwendung entspricht, werden als 

"not used" ausgewiesen. Die Bedeutung von "not used" ist exakt folgende: solche Angaben führen nicht zur 

Ablehnung des Auftrags, aber sie werden von der Banken-Applikation nicht berücksichtigt. Wenn also zum 

Beispiel im Einzugsauftrag eine Anweisung über Spesenteilung zwischen Auftraggeber und Bezogenem 

vorhanden ist (FCA Segment), so wird diese Anweisung ignoriert, da sie im IZV nicht möglich ist. 

Ebenso scheinen Codes für im IZV nicht zulässigen Abwicklungsvarianten in dieser Dokumentation nicht auf. So 

wird z.B. nirgends zwischen "pre-authorised" und "not-pre-authorised" unterschieden, da es die Variante des 

"not pre-authorised" Direct Debits im österreichischen IZV zur Zeit nicht gibt. 

Andererseits wurden, um die österreichischen "Direct Debit"- Dienstleistungen der Banken wie bisher in 

Anspruch nehmen zu können und um sie auf den DIRDEB abzubilden, zusätzliche Codes vorgesehen, die eine 

Erweiterung gegenüber dem internationalen Standard darstellen aber keine Einschränkung desselben. 

Das Szenario und die rechtlichen Grundlagen für "Direct Debits" sind von Land zu Land verschieden. Eine 

Anpassung ist nur schwierig, da Services, die sich entwickelt haben, schon zwecks der Service-Kontinuität auch 

in Zukunft bestehen bleiben müssen. 

1 In aller Regel werden die für Einzugsaufträge geführten Konten in EUR geführt, es kann jedoch vorkommen, dass 

zugunsten eines Kontos anderer Währung z.B. USD eingezogen wird. 

2 jemand, der in EUR fakturiert, zieht in EUR ein und muss sich nicht darum kümmern, ob der Zahlungspflichtige sein 

Konto EUR führt, oder z.B. in GBP. 

3 mit einem (textlichen) Hinweis am Kontoauszug, dass der Auftrag in der anderen Denomination war und welcher Betrag 

in dieser beauftragt wurde. 



Die Struktur des DIRDEB / Überblick 

Der DIRDEB besteht aus drei Ebenen (Leveln)4 : 

Level A: beschreibt die Nachricht als ganzes: wer sendet an wen, handelt es sich um das Original der 

Nachricht oder um eine zusätzliche Kopie, wer ist zu kontaktieren, falls mit der Nachricht Probleme 

bei der Bank auftreten, Kontrollsummen über die ganze Nachricht etc. 

Level B: enthält die Information zur Abrechnung eines Sammelauftrags: über welches Konto (des 

auftraggebenden Kunden) soll der Sammelauftrag abgerechnet werden, Durchführungsdatum für 

den Sammelauftrag, das allen Einzelaufträgen des Sammlers zugrundeliegende Geschäft, die Art 

der erforderlichen Banktransaktion etc. 

Der B-Level wird mit einem LIN Segment eingeleitet. Alle Segmente der Nachricht von einem LIN 

Segment bis zum nächsten LIN Segment5 ergeben in Summe die erforderlich Angaben zu einem 

Sammelauftrag . Im folgenden wird manchmal auch der Ausdruck "LIN-Abschnitt" dafür verwendet. 

Da ein DIRDEB mehrere LIN-Abschnitte haben kann, können mit einer DIRDEB-Nachricht mehrere 

Sammellastschriftsaufträge erteilt werden. Jeder Sammelauftrag resultiert in einer 

Gutschriftsbuchung am Konto des Auftraggebers. 

Darüber hinaus können im B-Level Angaben untergebracht werden, die für alle Einzelaufträge des 

Sammelauftrags gleich bleiben und daher nicht auf C-Level wiederholt werden müssen. 

Level C wird durch ein SEQ Segment eingeleitet. Alle Segmente zwischen einem SEQ und dem 

darauffolgenden SEQ6 detaillieren eine Einzellastschrift innerhalb des Sammelauftrags. Die 

enthaltene Information besagt im wesentlich von wem wieviel aus welchem Grund einzuziehen ist. 

Im Prinzip kann man mit einem DIRDEB nicht nur Sammelaufträge sondern auch Einzelaufträge senden. Dann 

steht im B-Level die Auftraggeber-Info und im nachfolgenden C Level (in diesem Fall der einzige SEQ Abschnitt 

innerhalb des LIN Abschnitts) die Info über und für den Zahlungspflichtigen. 

Normalerweise wird man jedoch mehrere Aufträge in einem Sammelauftrag zusammenziehen. Insofern 

entspricht jeder LIN-Abschnitt eines DIRDEB einem V2-Lastschriftbestand. 

So wie man (heute) nicht beliebige Aufträge in einem V2 Auftragsbestand zusammenfassen kann, gibt es auch 

Kriterien im DIRDEB, die ein Zusammenfassen von Aufträgen in einen LIN-Abschnitt ausschließen . Einige 

Kriterien sind bankintern verarbeitungsbedingt, andere folgen aus der Buchungslogik und nicht zuletzt resultieren 

einige auch daraus, daß man gewisse Angaben im DIRDEB nur auf B-Level vornehmen kann7. 

4 wie alle im österreichischen Banken-Szenario als Standard eingesetzten EDIFACT Nachrichten. Die Unterstützung 

anderer Nachrichten (z.B. PAYORD, PAYEXT etc. ) ist der individuellen Vereinbarung zwischen Kunde und 

kontoführendem Institut überlassen. 

5 im Falle des letzten Sammelauftrags innerhalb der Nachricht wird der entsprechende LIN-Abschnitt nicht wieder durch 

ein LIN-Segment begrenzt sondern durch das CNT Segment des Level A. 

6 der letzte Einzelauftrag (SEQ Abschnitt) innerhalb eines Sammelauftrags wird entweder durch das LIN-Segment des 

nächsten Sammelauftrags abgeschlossen oder durch das CNT im Level A, wenn es sich um den letzten Einzelauftrag 

im letzten Sammelauftrag der Nachricht handelt. 

7 z.B. ist die Angabe des der Zahlung zugrundeliegenden Geschäfts im derzeitigen (D96A) DIRDEB Aufbau nur im BUS 

Segment möglich und dieses gibt es auf dem C-Level nicht. Gibt man die Art des Grundgeschäfts (z.B. Versicherung) 

an, so folgt daraus, dass es für alle Einzelaufträge des LIN-Abschnitts gleich ist. 



Zusammenfassungsregeln für Sammelaufträge ("batching criteria"): 

1) Lastschriften, die in einem Auftragsbestand (=LIN-Abschnitt) zusammengefasst werden, müssen alle über 

dasselbe Konto und in gleicher Währung (bzw. Denomination) abgerechnet werden. Sie müssen dasselbe 

Durchführungsdatum8 aufweisen. 

2) Einzüge, die in ATS lauten, können nicht mit in EUR lautenden Einzügen gemischt werden. Diese Regel gilt 

für den "Übergangszeitraum" (Anfang 1999 bis Ende 2001) wenn im IZV sowohl Schilling als auch Euro eine 

gültige Denomination für Buchgeld ist. 

3) Weiter gilt, dass Aufträge, für die ein Grundgeschäftstyp angegeben wird, nicht mit Einzügen anderen 

Ursprungs gemischt werden können. Dafür wird dieser Grundgeschäftstyp als Information bis an den 

Zahlungspflichtigen weitergegeben. Wenn man Lastschriften mit verschiedenem Grundgeschäft in einem 

Sammelauftrag (LIN-Abschnitt) mischt, muss man die Angabe des Grundgeschäfts weglassen (d.h. Feld 

C521 im BUS Segment nicht belegen). 

Alle batching criteria ergeben sich auch zwangsläufig aus den Codier-Bestimmungen des DIRDEB in 

vorliegender Fassung. 

Weiterleitungsszenario und Schnittstelle zur NON-EDIFACT Welt 

Im österreichischen IZV werden EDIFACT Aufträge in voller Struktur und ohne Informationsverlust bis an das 

Institut des Begünstigten weitergeleitet. 

DIRDEB 

Auftraggeber 

In der obigen Darstellung sind DIRDEB, FINPAY, DEBMUL und MT9409 die jeweils übermittelten 

Nachrichtentypen. 

Wenn also eine Zahlung an einen Geschäftspartner erfolgt, der EDIFACT Anwender ist, so ist ein Informationsverlustfreies 

end-to-end Service möglich. 

Problematisch wird es allerdings, wenn der Begünstigte keine EDIFACT Nachrichten entgegennehmen kann. 

DIRDEB 

Auftraggeber 

Bank 1 

Bank 1 

FINPAY 

FINPAY 

Bank 2 

MT940 

und 

DEBMUL 

Begünstigter 

? 

Bank 2 Begünstigter 

Kein EDIFACT DT 

Das ist so bei (fast) allen Privatpersonen, bzw. bei der Mehrzahl kleinerer Unternehmen. In diesem Fall muss die 

Information irgendwie (meist auf einem Beleg) ausgedruckt werden und dazu müsste die strukturierte EDIFACT 

Information in Text umgesetzt werden. Da das meist weder möglich noch zweckmäßig ist, empfiehlt es sich, für 

solche Empfänger die Information wie bisher als Text in den Verwendungszweck zu verpacken (S.Gr. 16). 

8 sofern überhaupt eines angegeben wird. 

9 MT940 ist keine EDIFACT Nachricht, sondern die international standardisierte SWIFT Nachricht für den elektronischen 

Kontoauszug. 



Erklärungen zur Dokumentation 

Die syntaktische Unterscheidung zwischen M (="mandatory" = Element bzw. Segment muß in der Nachricht 

vorhanden sein) und C (="conditional" = Segment bzw. Element kann vorkommen) ist in der anwendungsorientierten 

Beschreibung nicht ausreichend scharf. Es wird daher die erweiterte Nomenklatur verwendet: 

R "required": das Element ist syntaktisch "C" aber im Zusammmenhang der beschriebenen Anwendung 

(IZV) erforderlich, z.B.: Kontonummer des Begünstigten muß bei einer Überweisung angegeben werden. 

D "dependent": ob das Element erforderlich ist oder nicht, hängt von der Konstellation ab, d.h. gewisse 

Werte in anderen Elementen erfordern auch die Befüllung dieses Elements oder schließen seine 

Befüllung aus. Beispiel Postleitzahl: nur bei PostBar erforderlich. 

Auch für den Fall, daß die Verwendung dieses Elements bilateral mit der kontoführenden Bank 

abgestimmt (vereinbart) werden muß verwenden wir D. 

A "advised": die Verwendung des Elements (in beschriebener Form) wird empfohlen. 

N "not used". Statt "N" in der Spalte "M/C" anzuschreiben, wird der Text "not used" manchmal in der Spalte 

"Belegung" angeschrieben. Ein eventueller Inhalt solcher Elemente wird in der Bankapplikation ignoriert, 

als wäre er nicht geschrieben. 

O "optional" (eine zusätzliche Information, die mitgeliefert werden kann, aber nicht muß). Gegenüber "A" 

also eine wertungsfreie Wahl (Nuance). 

Wenn ganze Segmente nicht verwendet werden, werden sie hier nicht in ihre Datenelemente aufgelöst 

dargestellt (zugunsten der Kompaktheit der Darstellung). 

Der Code "X" = "must not be used" wird soweit möglich vermieden, da dieser zu einer Ablehnung des Auftrags 

(eventuell der ganzen Nachricht) Anlaß geben würde, wenn ein solches Element in der Nachricht vorhanden ist 




Branch Diagram 



Branch-Diagram 

UNH LEVEL A 

M 1 

BGM DTM BUS SGr. 1 SGr. 2 SGr. 3 CNT SGr. 24 UNT 

M 1 M 1 D 1 D 2 O 5 O 3 R 5 N 5 M 1 

RFF FII NAD SGr. 4 AUT 

M 1 M 1 M 1 M 9999 N 1 

DTM CTA COM CTA COM LIN DTM 

R 1 N 1 N 5 O 1 O 5 M 1 N 1 

LEVEL B 

DTM RFF BUS FCA SGr. 5 SGr. 6 SGr. 7 SGr. 8 SGr. 9 SGr. 10 

O 1 R 2 D 1 N 1 R 1 M 1 D 3 D 1 N 10 D 1 

MOA FII NAD INP GIS PRC SGr. 11 

M 1 M 1 M 1 M 1 M 1 M 1 M 999999 

CTA COM CTA COM FTX DTM FTX SEQ 

N 1 N 5 O 1 O 5 N 1 N 2 M 1 M 1 

CUX DTM RFF MOA LOC NAD RCS FTX 

N 1 N 2 N 1 N 1 N 2 N 1 N 1 N 10 

LEVEL C 

MOA DTM RFF PAI FCA SGr. 12 SGr. 13 SGr. 14 SGr. 15 SGr. 16 

M 1 N 1 A 3 N 1 N 1 R 3 D 3 O 3 N 10 D 1 

FII NAD INP GIS PRC 

M 1 M 1 M 1 M 1 M 1 

CTA COM CTA COM FTX DTM FTX zur Kunden-Info 

N 1 N 5 N 1 N 5 N 1 N 2 D 5 

MOA LOC NAD RCS FTX 

N 1 N 2 N 1 N 1 N 10 



Branch-Diagram 

Kunden-Info 

SGr. 17 SGr. 23 

C 9999 C 1 

DOC GIS 

M 1 M 1 

MOA DTM RFF NAD SGr. 18 SGr. 19 SGr. 20 MOA 

C 5 C 5 C 5 C 2 C 5 C 100 C 1000 C 5 

Legende 

Segmentkennung bzw 

Segmentgruppe mit Nummer MOA 

CUX AJT DLI 

M 1 M 1 M 1 

DTM MOA RFF FTX MOA PIA DTM SGr. 21 SGr. 22 

C 1 M 1 C 1 C 5 M 5 C 5 C 5 C 5 C 10 

M 100 

Status max. Wiederholungsfaktor 

Grau unterlegte Segmente sind in der folgenden Beschreibung als "N"ot used gekennzeichnet 

CUX AJT 

M 1 M 1 

DTM MOA RFF FTX 

C 1 M 1 C 1 C 5 

Status: "M"andatory und "C"onditional Diese Qualifizierung ist vom UN-Directory vorgegeben und stellt sicher, daß die Nachricht richtig aufgelöst werden kann, also 

festzustellen, ob z.B. das DTM aus SGr. 4 oder bereits aus SGr. 8 stammt. 

"C" ist konsequent durch "R"equired, "O"ptional, "N"ot used, "D"ependent und "A"dviced ersetzt und qualifiziert die entsprechende Information aus der Sicht der 

Bankenapplikation, da es wenig sinnvoll ist z.B. ein Datumssegment aufzumachen und das Datum selbst - weil conditional - nicht einzusetzen. 

Wiederholungsfaktor: Die maximale Wiederholbarkeit des entsprechenden Segments bzw. Segmentgruppe an der jeweiligen Stelle (aus UN-Directory). Ob dies voll 

ausgeschöpft werden kann oder ob nicht nur eines, sondern mehrere Segmente erwartet werden, ist bei entsprechenden Segmenten in der Beschreibung 

vermerkt. 




Beschreibung der Segmente 

DIRDEB 



Seitenreferenz 

Level A 

UNH........................................................................12 

BGM .......................................................................12 

DTM........................................................................13 

BUS ........................................................................13 

Segmentgruppe 1...................................................13 

RFF ................................................................13 

DTM ...............................................................13 


FII...................................................................14 

CTA ................................................................14 

COM...............................................................14 


NAD................................................................15 

CTA ................................................................16 

COM...............................................................16 

CNT ........................................................................16 

Segmentgruppe 24.................................................17 

AUT........... Fehler! Textmarke nicht definiert. 

DTM .......... Fehler! Textmarke nicht definiert. 

UNT ........................................................................17 

Level B 


LIN..................................................................17 

DTM ...............................................................18 

RFF ................................................................18 

BUS................................................................19 

FCA................................................................20 

Segmentgr. 5..................................................20 

MOA.......................................................20 

CUX .......................................................20 

DTM.......................................................20 

RFF........................................................20 

Segmentgr. 6..................................................21 

FII ..........................................................21 

CTA........................................................21 

COM ......................................................21 

Segmentgr. 7..................................................22 

NAD .......................................................22 

CTA........................................................22 

COM ......................................................22 

Segmentgr. 8..................................................23 

INP.........................................................23 

FTX........................................................23 

DTM.......................................................23 

Segmentgr. 9..................................................23 

GIS.........................................................23 

MOA.......................................................23 

LOC .......................................................23 

NAD .......................................................23 

RCS .......................................................23 

FTX........................................................23 

Segmentgr. 10................................................24 

PRC .......................................................24 

FTX........................................................24 

(x) Die Segmentgruppen 17 bis 23 werden im separaten Dokument 

Strukturierte Kunden zu Kunden Information beschrieben. 

Level C 

Segmentgr. 11........................................................25 

SEQ................................................................25 

MOA ...............................................................25 

DTM ...............................................................25 

RFF ................................................................26 

PAI .................................................................26 

FCA................................................................26 

Segmentgr. 12 ...............................................27 

FII ..........................................................27 

CTA........................................................28 

COM ......................................................28 

Segmentgr. 13 ...............................................28 

NAD .......................................................28 

CTA........................................................29 

COM ......................................................29 

Segmentgr. 14 ...............................................29 

INP.........................................................29 

FTX........................................................30 

DTM.......................................................30 

Segmentgr. 15 ...............................................30 

GIS ........................................................30 

MOA.......................................................30 

LOC .......................................................30 

NAD .......................................................30 

RCS .......................................................30 

FTX........................................................30 

Segmentgr. 16 ...............................................31 

PRC .......................................................31 

FTX........................................................32 

Segmentgr. 17 .......................................(x) 

DOC ..............................................(x) 

MOA ..............................................(x) 

DTM...............................................(x) 

RFF ...............................................(x) 

NAD...............................................(x) 

Segmentgr. 18...............................(x) 

CUX ......................................(x) 

DTM ......................................(x) 

Segmentgr. 19...............................(x) 

AJT .......................................(x) 

MOA......................................(x) 

RFF.......................................(x) 

FTX .......................................(x) 

Segmentgr. 20...............................(x) 

DLI ........................................(x) 

MOA......................................(x) 

PIA ........................................(x) 

DTM ......................................(x) 

Segmentgr. 21 ......................(x) 

CUX..............................(x) 

DTM..............................(x) 

Segmentgr. 22 ......................(x) 

AJT...............................(x) 

MOA .............................(x) 

RFF ..............................(x) 

FTX...............................(x) 

Segmentgr. 23 .......................................(x) 

GIS ................................................(x) 

MOA ..............................................(x) 



Nr. Feldbeschreibung M/C Format Belegung, Verwendung, Bemerkungen Fußnote 

UNH-BGM-DTM-BUS-SG1-SG2-SG3-SG4-CNT-SG24-UNT 

UNH NACHRICHTEN-KOPFSEGMENT M 1 10 

0062 NACHRICHTEN-REFERENZNUMMER M an..14 Diese Referenznummer ist aus syntaktischen Gründen erforderlich. Sie hat weder buchhalterische, 

noch Nachforschungs-Bedeutung. Auf sie wird bei Rückmeldung von Syntax-Fehlern (CONTRL 

Nachricht) und ggf. bei nachfolgender Authentifizierung (AUTACK) Bezug genommen. Sie muss 

innerhalb eines Interchanges (siehe Einleitung) eindeutig sein. Meist wird sie von Konvertern 

automatisch vergeben. 

S009 NACHRICHTENKENNUNG M 

0065 Nachrichtentyp-Kennung M an..6 "DIRDEB" 

0052 Versionsnummer des Nachrichtentyps M an..3 "D" 

0054 Freigabenummer des Nachrichtentyps M an..3 "96A" 

0051 Verwaltende Organisation, codiert M an..2 "UN" 

0057 Anwendungscode der zuständigen 

R an..6 "FAT01G" für Finance AusTria VersionsnuMMer Generell 

Organisation 

0068 ALLGEMEINE ZUORDNUNGS-REFERENZ N an..35 

S010 STATUS DER ÜBERMITTLUNG N 

0070 Übermittlungsfolgenummer M n..2 

0073 Erste und letzte Übermittlung N a1 

Beispiel: UNH+M1+DIRDEB:D:96A:UN:FAT01G' 


BGM BEGINN DER NACHRICHT M 1 

C002 DOKUMENTEN-/NACHRICHTENNAME R 

1001 Dokumenten-/Nachrichtenname, codiert R an..3 "214" = Direct Debit Order 

1131 Codeliste, Qualifier N an..3 

3055 Verantwortliche Stelle für Codepflege, codiert N an..3 

1000 Dokument/Nachrichtenname N an..35 

1004 DOKUMENTEN-/NACHRICHTENNUMMER R an..35 Referenznummer des Dokuments. Mittels Angabe dieser Referenz im RFF der SGr.1 kann eine 

spätere Nachricht (z.B. ein DIRDEB als Kopie dieser Nachricht) einen Bezug herstellen. Daher 

muß sie eindeutig über einen Zeitraum von einem Monat sein. Für die Nachforschung hat diese 

Nummer keine Bedeutung. 

1225 NACHRICHTENFUNKTION, CODIERT R an..3 "9" = Original, "7" = Duplikat ("31" = Kopie). ein Duplikat ist immer an den Receiver des Originals 

gerichtet, eine Kopie immer an einen Dritten. 

4343 ANTWORT TYP, CODIERT N an..3 

Beispiel: BGM+214+REFD3AL14+9' 

10 Bezüglich der "Verpackung" der Nachricht zur Übertragung in einen Interchange siehe Beschreibung in der Einleitung. 

PAYMUL IZV Datenbeschreibung STUZZA Version Mai 2003 12 / 33 




DTM DATUM/UHRZEIT/ZEITRAUM M 1 

C507 DATUM/UHRZEIT/ZEITRAUM M 

2005 Datum/Uhrzeit/Zeitraum, Qualifier M an..3 "137" = Erstellungszeit der Nachricht 

2380 Datum/Uhrzeit/Zeitraum R an..35 CCYYMMDDHHMM oder CCYYMMDD 

2379 Datum/Uhrzeit/Zeitraum, Formatqualifier R an..3 "203" bzw. "102" 

bevorzugt ist das Format "203", aus Gründen der internationalen Kompatibilität sind jedoch auch 

"102" zugelassen. 

Beispiel: DTM+137:200207221606:203' 


BUS ART DES GESCHÄFTSVORFALLES D 1 detaillierte Beschreibung siehe BUS SGr. 4 11 


Segmentgruppe 1 D 2 wird nur verwendet, wenn auf eine frühere Nachricht Bezug genommen wird 

(BGM.1225 ungleich "9") 

RFF-DTM 

RFF REFERENZANGABEN M 1 

C506 REFERENZ M 

1153 Referenz, Qualifier M an..3 "ACW" = Referenznummer aus vorhergehender Nachricht 

1154 Referenznummer R an..35 Referenznummer aus Feld 1004 des BGM der früheren Nachricht 

1156 Zeilennummer N an..6 

4000 Referenz Versionsnummer N an..35 

Beispiel: RFF+ACW:REFD3AL10' 

RFF-DTM 

DTM DATUM/UHRZEIT/ZEITRAUM R 1 Anzugeben, wenn auf eine frühere Nachricht Bezug genommen wird 


2005 Datum/Uhrzeit/Zeitraum, Qualifier M an..3 "171" = Referenzdatum /Uhrzeit 

2380 Datum/Uhrzeit/Zeitraum R an..35 CCYYMMDDHHMM oder CCYYMMDD 

2379 Datum/Uhrzeit/Zeitraum, Formatqualifier R an..3 "203" bzw. "102" 

bevorzugt ist das Format "203", aus Gründen der internationalen Kompatibilität sind jedoch auch 

"102" zugelassen. 

Beispiel: DTM+171:200304101221:203' 

11 Alle Angaben, die man in diesem BUS Segment auf Level A machen kann, können im BUS Segment auf Level B gemacht werden. Daher empfiehlt es sich, das BUS Segment im 

Level A wegzulassen, es sei denn, die im Level A gemachte Angabe trifft für alle Aufträge des gesamten DIRDEB zu. 





Segmentgruppe 2 O 5 Dient der Angabe der BLZ des empfangenden Instituts bzw. in speziellen Fällen auch einer 

Kundennummer bzw. Identifikation (FII C078:3194) 

DIESE GRUPPE WIRD NUR EINMAL AKZEPTIERT 

FII-CTA-COM 

FII KREDITINSTITUT M 1 

3035 BETEILIGTER, QUALIFIER M an..3 "MR" message receiver (normalerweise das beauftragte Bank-Institut) 

C078 KONTOANGABEN O Nur gegen Vereinbarung mit dem empfangenden Institut in definierten Fällen 

3194 Kontonummer R an..35 Identifikationsnummer entsprechend Vereinbarung 12 

3192 Kontoinhaber N an..35 

3192 Kontoinhaber N an..35 

6345 Währung, codiert N an..3 

C088 KREDITINSTITUT-IDENTIFIKATION R 

3433 Internationaler Bankcode N an..11 



3434 Nationaler Bankcode R an..17 BLZ des Empfängers der Nachricht 

1131 Codeliste, Qualifier O an..3 "25" = Bank identification nur angebbar, wenn 3434 befüllt 

3055 Verantwortliche Stelle für Codepflege, codiert O an..3 "137" =Austrian bankers association nur angebbar, wenn 3434 befüllt 

3432 Name des Kreditinstitutes N an..70 

3436 Ortsangabe einer Zweigstelle N an..70 

3207 LAND, CODIERT R an..3 "AT" - ISO 3166 zwei Zeichen Ländercode; 

Beispiel: FII+MR++:::12000+AT' 

FII+MR+PS7006+:::60000:25:137+AT' 

FII-CTA-COM 

CTA KONTAKTSTELLE N 1 Der Kunde kann sich nicht zur Durchführung seiner Aufträge auf eine spezielle Stelle in der Bank beziehen 

FII-CTA-COM 

COM KOMMUNIKATIONSART N 5 Der Kunde kann sich nicht zur Durchführung seiner Aufträge auf eine spezielle Stelle in der Bank beziehen 

12 Die Angabe dient hier ausschließlich zur Identifikation des Auftraggebers. Die Konten, denen die Auftragssummen gutgeschrieben werden, stehen im FII mit Qualifier OR in 

Segmentgruppe 6. 





Segmentgruppe 3 O 3 Diese Segmentgruppe kann verwendet werden, wenn die kontoführende Stelle eine zusätzliche 

Kennung des Absenders vorschreibt oder um eine Kontaktstelle für Rückfragen zu definieren. 

DIE SEGMENTGRUPPE WIRD NUR EINMAL AKZEPTIERT 

NAD-CTA-COM 

NAD NAME UND ANSCHRIFT M 1 

3035 BETEILIGTER, QUALIFIER M an..3 "MS" = message sender 

C082 IDENTIFIKATION DES BETEILIGTEN O 13 

3039 Identifikation des Beteiligten M an..35 siehe Fußnote 13 

1131 Codeliste, Qualifier O an..3 siehe Fußnote 13 

3055 Verantwortliche Stelle für Codepflege, codiert O an..3 siehe Fußnote 13 

C058 NAME UND ANSCHRIFT N Wenn eine Angabe gemacht wird, dann in C080 und folgende 

3124 Zeile für Name und Anschrift M an..35 

3124 Zeile für Name und Anschrift N an..35 




C080 NAME DES BETEILIGTEN O Name des Senders der Nachricht; ggf. weitere Angaben in C059 und folgende 

3036 Name des Beteiligten M an..35 

3036 Name des Beteiligten O an..35 




3045 Name des Beteiligten Format, codiert N an..3 

C059 STRASSE O Selbsterklärend 

3042 Straße und Hausnummer/ Postfach M an..35 

3042 Straße und Hausnummer/ Postfach O an..35 



3164 ORT O an..35 selbsterklärend; gemeinsam mit 3251 maximal 35 Stellen 

3229 REGION/BUNDESLAND, IDENTIFIKATION N an..9 

3251 POSTLEITZAHL O an..9 Selbsterklärend 

3207 LAND, CODIERT O an..3 ISO 3166 zwei Zeichen Ländercode 

Beispiel: NAD+MS' 

NAD+MS+++Medizinisch Diagnostisches Laborato:des Österr. Apothekerverbandes+Michelbeuerng. 1+Wien++1090+AT' 

13 Ein internationaler Firmencode ist zur Zeit in Ausarbeitung bei der ISO. 




NAD-CTA-COM 

CTA KONTAKTSTELLE O 1 

3139 KONTAKT FUNKTION, CODIERT R an..3 "MS" Kontaktstelle des 'Message Sender' als einzig zulässiger Wert 

C056 KONTAKTSTELLE / KONTAKTPERSON R 

3413 Kontaktstellen / Kontaktperson Identifikation O an..17 Abteilungs(Kurz)bezeichnung wo die Kontaktperson erreichbar ist 

3412 Kontaktstellen / Kontaktperson R an..35 Name der Kontaktperson 

Beispiel: CTA+MS+:Mag. Ursula Klemperer' 

CTA+MS+Leistungsverrechn:Mag. Ursula Klemperer' 

NAD-CTA-COM 

COM KOMMUNIKATIONSART O 5 Sollte verwendet werden, wenn CTA kodiert ist, sonst nicht 

C076 KOMMUNIKATIONSART M 

3148 Kommunikationsnummer M an..512 Kontakt"nummer" der Kontaktstelle / Kontaktperson. Die Länge wird applikatorisch auf 128 

beschränkt 

3155 Kommunikationsart Qualifier M an..3 "TE" Telefon, "EM" e-Mail, "FX" Fax 14 

Beispiel: COM+(01)408 48 85:FX' 

COM+?+43-1-408 31 31:TE' 

COM+gustav.eisen@domaene.at:EM' 

A C H T U N G : An diese Stelle gehört der Level B. Die Beschreibung setzt jedoch mit dem Level A fort, damit diese Ebene im Ganzen abgeschlossen ist. 


CNT KONTROLLWERTE R 5 Dieses Segment muß dreimal verwendet werden ! 

C270 KONTROLLSUMMEN M 

6069 Kontrollsumme, Qualifier M an..3 "1" algebraische Summe aller SGr. 5 MOA Betragsfelder der Nachricht 

"2" Anzahl der LIN-Abschnitte (=Anzahl der Auftragsbestände) der Nachricht 

"39" Anzahl der SEQ-Abschnitte (=Anzahl der "Be"Auftragungen) in der Nachricht 

6066 Kontrollsummenwert M n..18 Summe entsprechend obigem Qualifier 

6411 Maßeinheit, Qualifier N an..3 

Beispiel: CNT+1:12036,54'CNT+2:8'CNT+39:18' 

14 Telex und X400 werden nicht empfohlen, aber akzeptiert 





Segmentgruppe 24 N 5 Die Segmentgruppe 24 wird nicht verwendet. Die Autorisierung und Authentifizierung erfolgt über 

die separate Nachricht AUTACK 

AUT-DTM 

AUT AUTORISIERUNGSERGEBNIS N 1 

AUT-DTM 

DTM DATUM/UHRZEIT/ZEITRAUM N 1 


UNT NACHRICHTEN-ENDE SEGMENT M 1 

0074 ANZAHL SEGMENTE in der NACHRICHT M n..10 Für IZV auf maximal 10 Stellen erweitert ! 

0062 NACHRICHTEN-REFERENZNUMMER M an..14 derselbe Wert wie im UNH 0062 der Nachricht 

Beispiel: UNT+253+M1' 

Hier beginnt der Level B. 


Segmentgruppe 4 M 9999 Das LIN-Segment leitet einen Auftragsbestand ein. Einem Auftragsbestand entspricht eine 

Sammelbelastung am Konto, welches in SGr 6 FII angegeben wird. 

LIN-DTM-RFF-BUS-FCA-SG5-SG6-SG7-SG8-SG9-SG10-SG11 

LIN POSITIONSDATEN M 1 

1082 POSITIONSNUMMER R n..6 fortlaufende Nummer, beginnend mit 1 innerhalb der Nachricht. 

1229 ACTION REQUEST / NOTIFICATION, CODED N an..3 

C212 ITEM NUMBER IDENTIFICATION N 

7140 Item number N an..35 

7143 Item number Type, codiert N an..3 



C829 SUB-LINE INFORMATION N 

5495 Sub-line indicator, codiert N an..3 

1082 Line item N n..6 

1222 CONFIGURATION LEVEL N n..2 

7083 CONFIGURATION, CODIERT N an..3 

Beispiel: LIN+1' 





DTM DATUM/UHRZEIT/ZEITRAUM O 1 Nur im Fall der Angabe eines in der Zukunft liegenden Durchführungsdatums 


2005 Datum/Uhrzeit/Zeitraum, Qualifier M an..3 "203" gewünschtes Durchführungsdatum 

2380 Datum/Uhrzeit/Zeitraum R an..35 CCYYMMDD 

2379 Datum/Uhrzeit/Zeitraum, Formatqualifier R an..3 "102" 

Beispiel: DTM+203:20020730:102' 


RFF REFERENZANGABEN R 2 Zur Angabe einer Bestandskontrollnummer; scheint in der Gutschriftsanzeige bzw. am 

Kontoauszug des Auftraggebers auf 

WIRD NUR EINMAL AKZEPTIERT ! 

C506 REFERENZ M 

1153 Referenz, Qualifier M an..3 "AKJ" Auftragsnummer des Einzugsbestands 

1154 Referenznummer R an..35 vom Kunden vergebene, innerhalb eines Jahres eindeutige Referenz für diesen Sammelauftrag. 

(wegen der Einschränkung des MT940 z.Zt. auf 16 Stellen begrenzt). 

Die Referenznummer darf, mit Ausnahme des Bindestrichs, KEINE Sonderzeichen enthalten ! 



Beispiel: RFF+AKJ:LAB02071900353' 





BUS ART DES GESCHÄFTSVORFALLES D 1 Die bevorzugte Verwendung dieses Segments ist an dieser Stelle (Level B), kann jedoch auch auf 

Level A erfolgen. Es muß jedoch einmal verwendet werden. Jede Angabe im BUS Segment 

bedingt, daß diese Angabe für alle folgenden Einzelaufträge gilt. Die möglichen Eintragungen im 

BUS Segment stellen somit Zusammenfassungskriterien für Aufträge (in Sammelaufträge) dar. 

Einzelaufträge, die verschiedene Einträge in diesem BUS Segment benötigen, können nicht in 

einem Auftragsbestand (LIN-Abschnitt) gemischt werden. 

C521 ART DES GESCHÄFTSVORFALLS O 

4027 Art des Geschäftsvorfalls, Qualifier M an..3 "1" der nachfolgende Code beschreibt den der Zahlung zugrundeliegenden Geschäftsvorfall 

(aus Sicht des Auftraggebers) 

4025 Art des Geschäftsvorfalls, codiert M an..3 CODE entsprechend UN-Tabelle (siehe Fußnote) 15 



4022 Beschreibung der Geschäftsart N an..70 

3279 GEOGRAPHISCHER BEREICH, CODIERT R an..3 "DO"=domestic, der Begünstigte ist in Österreich und ist hier resident 

4487 ART DER FINANZTRANSAKTION, CODIERT D an..3 Die folgenden Transaktionscodes sind verwendbar: 

"14" Einzug gemäß Einzugsermächtigungsverfahren (temporärer Code war "82") 

"13" Lastschrift auf Basis Abbuchungsauftrag (temporärer Code war "83") 

Alternativ zu SEQ:1159 – wird 4487 nicht kodiert, muss SEQ:1159 kodiert werden 

C551 BANK OPERATION (ZAHLUNGSFORM) R Die Angabe eines Bank Operation Code ist zwingend 

4383 Bank operation, codiert M an..3 "DDT" Direct Debit Transfer 



4463 INTRA-COMPANY PAYMENT, CODIERT N an..3 

Beispiel: BUS++DO++DDT' 

BUS+1:LOR+DO++DDT' 

BUS++DO+13+DDT' 

BUS+1:LOR+DO+13+DDT' 

15 Dieser Code wird (unkontrolliert) bis zur Empfängerbank (und, wenn der Empfänger EDIFACT Daten entgegennimmt, bis zum Empfänger) durchgeschleust. Der Empfänger kann daraus 

schließen, in welchen Teilbereich seiner Buchhaltung er den Einzug zu buchen hat. Diese Angabe ist jedoch nicht zwingend. 





FCA FINANCIAL CHARGES ALLOCATION N 1 


Segmentgruppe 5 R 1 

MOA-CUX-DTM-RFF 

MOA GELDBETRAG M 1 Die Angabe dieses Gesamtauftragswerts wird abschließend im CNT Segment auf Level A zur 

algebraischen Summe hinzuaddiert. 

C516 GELDBETRAG M 

5025 Geldbetragsart, Qualifier M an..3 "9" einzuziehender Gesamtbetrag, der dem Konto des Auftraggebers in weiterer Folge 

gutgeschrieben wird. 

5004 Geldbetrag R n..18 Summe aller Überweisungsbeträge der Einzelaufträge dieses LIN-Abschnitts 

(bankseitig auf 12 Vorkommastellen begrenzt). Maximal 2 Nachkommastellen. 

6345 Währungscode R an..3 ISO 4217 drei Zeichen Währungscode – "EUR" als einzig zulässiger Wert 

6343 Währung, Qualifier N an..3 

4405 Status codiert N an..3 

Beispiel: MOA+9:12580,50:EUR' 


CUX CURRENCIES N 1 




RFF REFERENZANGABEN N 1 





Segmentgruppe 6 M 1 

FII-CTA-COM 


3035 BETEILIGTER, QUALIFIER M an..3 "OR" Kontoverbindung des Auftraggebers = Einziehers bei der beauftragten Bank 16 

C078 KONTOANGABEN R 

3194 Kontonummer R an..35 Kontonummer oder IBAN des Auftraggebers. Auf dieser erfolgt die Gutschrift für den 

Sammelauftrag. 

3192 Kontoinhaber R an..35 Zwingend mit Kontowortlaut zu befüllen. 17 

3192 Kontoinhaber O an..35 Fortsetzung Kontowortlaut 

6345 Währung, codiert R an..3 ISO 4217 drei Zeichen Währungscode des Auftraggeberkontos 

C088 KREDITINSTITUT-IDENTIFIKATION D Nicht zu verwenden bei IBAN in 3194, sonst zwingend 




3434 Nationaler Bankcode R an..17 BankLeitZahl des beauftragten Instituts (exakt 5 Stellen). 





3207 LAND, CODIERT D an..3 "AT" - ISO 3166 zwei Zeichen Ländercode; nicht zu verwenden bei IBAN in 3194, sonst zwingend 

Beispiel: FII+OR+AT356000000007451061:Med. Diag. Laboratorium::EUR' 

FII+OR+AT356000000007451061:MED. DIAG. LABORATORIUM:1090 Wien:EUR' 

FII+OR+7451061:Med. Diag. Laboratorium::EUR+:::60000:25:137+AT' 

FII+OR+7451061:Med. Diag. Laboratorium:1090 Wien:EUR+:::60000:25:137+AT' 

FII-CTA-COM 

CTA KONTAKTSTELLE N 1 . 

FII-CTA-COM 

COM KOMMUNIKATIONSART N 5 

16 Aus der hier angegebenen Kontoverbindung resultiert die Abrechnungswährung für den Auftraggeber. 

17 Die Verwendung des NAD mit Qual "OY" für die Auftraggeberbezeichnung ist nur dann erforderlich, wenn der Kontoinhaber nicht mit dem Auftraggeber übereinstimmt (Einzug im Namen 

eines Anderen, z.B. "Huber Corp." als Kontoinhaber zieht ein für "Huber Information Services" als Auftraggeber). 





Segmentgruppe 7 D 3 Die Daten dieser Segmentgruppe werden unverändert an den Bezogenen weitergegeben, sofern 

dieser EDIFACT entgegennehmen kann. Andernfalls kann nur die Weitergabe von 2 Zeilen 

à 35 Zeichen garantiert werden. Wenn die Bezogenenbank die Daten des Auftrags für den 

Bezogenen ausdrucken muß, wird sie diese Felder in zwei Zeilen à 35 Stellen zusammenziehen 

und bei Überschreiten der möglichen Gesamtlänge (=70) entsprechend kürzen (bzw. 

abschneiden). 

Die Verwendung des NAD mit Qualifier "OY" (Auftraggebername) ist nur dann möglich 

wenn der Inhaber des Auftraggeberkontos nicht identisch ist mit dem Auftraggeber 

oder der Auftraggeber eine zusätzliche, kodifizierte Identifikation seiner selbst im Feld 

3039 an den Bezogenen weitergeben möchte und der LIN Abschnitt nur Abbuchungen 

von diesem Bezogenen enthält. 

WIRD NUR EINMAL AKZEPTIERT ! 


NAD-CTA-COM 


3035 BETEILIGTER, QUALIFIER M an..3 "OY" für Auftraggeber 

C082 IDENTIFIKATION DES BETEILIGTEN O 

3039 Identifikation des Beteiligten M an..35 Code (unter dem der Auftraggeber dem Bezogenen bekannt ist, z.B. eigene Kundennummer beim 

Abnehmer). Überschreibt beim Druckservice die zusätzliche Auftraggeberzeile. 



C058 NAME UND ANSCHRIFT N Auftraggeberangaben erfolgen immer strukturiert ! 

5 x 3124 Zeile für Name und Anschrift M an..35 

C080 NAME DES BETEILIGTEN D Zwingend wenn Auftraggeber ungleich Kontoinhaber; sonst nicht zu verwenden 

5 x 3036 Name des Beteiligten M an..35 


C059 STRASSE O Optional wenn Auftraggeber ungleich Kontoinhaber; sonst nicht zu verwenden 

4 x 3042 Straße und Hausnummer/Postfach M an..35 

3164 ORT O an..35 Optional wenn Auftraggeber ungleich Kontoinhaber; sonst nicht zu verwenden; gemeinsam mit 

3251 maximal 35 Stellen 


3251 POSTLEITZAHL O an..9 Optional wenn Auftraggeber ungleich Kontoinhaber; sonst nicht zu verwenden 

3207 LAND, CODIERT O an..3 ISO 3166 zwei Zeichen Ländercode 

Beispiel: NAD+OY+++Medizinisch Diagnostisches Laborato:des Östterr. Apothekerverbandes+Michelbeuerng. 1+Wien++1090+AT' 

NAD-CTA-COM 

CTA KONTAKTSTELLE O 1 

NAD-CTA-COM 

COM KOMMUNIKATIONSART O 5 





Segmentgruppe 8 D 1 detaillierte Beschreibung siehe SGr. 14. Wenn die Weisung auf Level B aufscheint, gilt sie für alle 

Einzelaufträge des Auftragsbestands (LIN-Abschnitt). Die Verwendung der SGr. 8 ist gegenseitig 

ausschließend mit der Verwendung der SGr 14. Ein Überschreiben der Weisung im Level B durch 

eine andere im Level C codierte Weisung ist nicht möglich ! 

INP-FTX-DTM 

INP BESONDERE WEISUNG M 1 

INP-FTX-DTM 

FTX FREIER TEXT N 1 

INP-FTX-DTM 



Segmentgruppe 9 N 10 

GIS-MOA-LOC-NAD-RCS-TFX 

GIS GENERAL INDICATOR M 1 


MOA GELDBETRAG N 1 


LOC PLACE / LOCATION IDENTIFICATION N 2 


NAD NAME UND ANSCHRIFT N 1 


RCS REQUIREMENTS AND CONDITIONS N 1 







Segmentgruppe 10 D 1 Die SGr. 10 dient (so wie SGr. 16) zur Weitergabe von den Einzug betreffende Information vom 

Auftraggeber an den Bezogenen. SGr. 10 kann jedoch nur dann verwendet werden, wenn 

1) die Information in unstrukturierter Form weitergegeben wird und 

2) für alle nachfolgenden Einzelaufträge gleich ist - d.h. die gleichbleibende Information wird auf Level B 

herausgehoben. Typischer Fall = "Prämie MM/JJ" für alle Versicherten, deren Prämieneinzüge folgen. 

zu beachten : 

(*) wird die SGr. 10 (Level B) benützt, so darf in den zugehörigen Einzelumsätzen in S.Gr 16 kein FTX 

auftreten. 

PRC-FTX 

PRC PROZESSBEZEICHNUNG M 1 

C242 PROZESSART UND -BESCHREIBUNG M 

7187 Prozeßart, Identifikation M an..17 "11" Information in unstrukturierter Form -> FTX folgt 



2 x 7186 Prozeßart N an..35 

Beispiel: PRC+11' 

PRC-FTX 

FTX FREIER TEXT M 1 

4451 TEXTZUORDNUNG, QUALIFIER M an..3 "PMD" Verwendungszweck (Payment Details) 

4453 TEXTVERARBEITUNGSHINWEIS, CODIERT N an..3 

C107 TEXT-REFERENZ N 

4441 Freier Text, codiert M an..3 



C108 TEXT R 

5 x 4440 Freier Text M an..70 Verwendungszweck in Textform 18 

3453 SPRACHE, CODIERT N an..3 

Beispiel: FTX+PMD+++Prämie Leben 04/03 inkl. Anpassung 3,456%' 

18 Es wird dringend empfohlen auf die Längenbeschränkungen der Zeilen gemäß C-Beleg zu achten (also maximal 5 Zeilen mit maximal 57 Stellen). Andernfalls muß beim Ausdruck 

umformatiert werden und es kann nicht garantiert werden, daß die Information dabei vollständig bleibt. 





Segmentgruppe 11 M 9999 

IZV: 

999999 

Diese Segmentgruppe leitet die Angaben zum Einzelauftrag ein. Jedem SEQ-Abschnitt entspricht 

ein Auftrag innerhalb des Sammelauftrags (Auftragsbestands = LIN-Abschnitt) 

Für IZV Auftragsbestände gilt die Beschränkung des UN/EDIFACT Max-Wiederholungsfaktor von 

9999 nicht. Die meisten Banken akzeptieren auch größere Auftragsbestände. Der tatsächlich 

maximale Wiederholungsfaktor ist mit der kontoführenden Bank abzustimmen. 

SEQ-MOA-DTM-RFF-PAI-FCA-SG12-SG13-SG14-SG15-SG16 

SEQ EINZELHEITEN ZUR REIHENFOLGE M 1 

1245 STATUSKENNZEICHEN, CODIERT N an..3 

C286 INFORMATION ÜBER EINE FOLGE R 

1050 Folgenummer M an..6 fortlaufende Nummer, beginnend mit "1" innerhalb des Auftragsbestands 

1159 Folgenummer source, codiert D an..3 Transaktionscode als Alternative zum Code im BUS Segment 

"82" Einzug gemäß Einzugsermächtigungsverfahren 

"83" Lastschrift auf Basis Abbuchungsauftrag 

"66" mit PSK zu vereinbaren und nur an PSK zu liefern . 

Nicht zu verwenden wenn BUS:4487 kodiert ist, sonst zwingend 

1131 Codeliste, Qualifier D an..3 "EBA" Zwingend wenn 1159 kodiert ist, sonst nicht zu verwenden 

3055 Verantwortliche Stelle für Codepflege, codiert D an..3 "137" Zwingend wenn 1159 kodiert ist, sonst nicht zu verwenden 

Beispiel: SEQ++1' 

SEQ++1:83:EBA:137' 


MOA GELDBETRAG M 1 

C516 GELDBETRAG M 

5025 Geldbetragsart, Qualifier M an..3 "9" für Einzugsbetrag 

5004 Geldbetrag R n..18 Einzugsbetrag. (z.Zt. bankseitig auf 9 Vorkommastellen begrenzt). Maximal 2 Nachkommastellen. 

6345 Währungscode R an..3 ISO 4217 drei Zeichen Währungscode – "EUR" als einzig zulässiger Wert 

6343 Währung, Qualifier N an..3 

4405 Status codiert N an..3 

Beispiel: MOA+9:123,75:EUR' 


DTM DATUM/UHRZEIT/ZEITRAUM N 1 Angabe des Durchführungsdatums ist immer für den ganzen Auftragsbestand gültig und daher auf 

Level B anzugeben 





RFF REFERENZANGABEN A 3 Dieses Segment dient dazu, Referenzen zum aktuellen Auftrag für Sender und Empfänger bzw. Bank 

aufzunehmen. Ein Segment mit Qualifier CR dient der eigenen Zuordnung. Die Qualifier PQ und AEF sind 

Referenzen für den Bezogenen (Kunde od. Bank). Die Angabe einer Auftraggeberreferenz (CR) ist 

strengstens empfohlen ! Im Fall einer Rücklastschrift erlaubt sie die einfache und rasche Zuordnung zum 

ursprünglichen Einzugsauftrag. 

Jede dieser Referenzen (PQ, AEF, CR) darf maximal einmal vorkommen !. 

C506 REFERENZ M International ist dieses Segment mindestens mit "CR" mitzugeben ! 

1153 Referenz, Qualifier M an..3 "PQ" Referenz für den Zahlungspflichtigen. 

"AEF" für die Weitergabe einer Referenznummer an den Zahlungspflichtigen 

(der zugehörige Wert in Feld 1154 muß numerisch und genau 12 Stellen sein). 

"CR" Auftraggeber-Referenz 

1154 Referenznummer R an..35 entsprechende Nummer (Wert) entsprechend obigem Qualifier 



Beispiel: RFF+PQ:Lebensversicherung Polizze 34/45678'RFF+CR:APO2002056006' 

RFF+PQ:Gebäudeversicherung'RFF+AEF:000340045678'RFF+CR:APO2002056006' 


PAI PAYMENT INSTRUCTION N 1 


FCA FINANCIAL CHARGES ALLOCATION N 1 

19 Zum Unterschied von Gutschriftsaufträgen ist bei Einzügen der Initiator der Transaktion gleichzeitig auch der Erbringer der Leistung (Lieferant, etc). Das bedeutet, daß bei 

Lastschriften meist der Auftraggeber selbst den Grundgeschäftsfall referenziert hat und diese Referenz bei Geschäftsabschluß dem Geschäftspartner (=Bezogener) bekannt gegeben 

hat. Auf diese Referenz sollte sich der Einzieher unter "PQ" beziehen. Daher ist 

PQ ist eine alphanumerische Referenz für den Empfänger, die das dem (meist periodischen wiederkehrenden) Einzug zugrundeliegende Grundgeschäft bezeichnet: z.B. 

Policennummer, Anschlussnummer (Gas, Telefon) oder ähnliches. Diese Referenz sollte von Einzug zu Einzug gleich bleiben. 

AEF ist eine Referenz für den Bezogenen für die Weitergabe eines rein numerischen Begriffs, z.B. an Hausverwaltungen. 

CR hingegen ist eine Referenz, die der Auftraggeber selbst (nur) dieser Einzugstransaktion zugeordnet hat. Sie wird im Falle einer Rücklastschrift zurückgeleitet und dient dem 

Auftraggeber dann zur Identifikation der ursprünglichen Lastschrift. Auch wenn das Grundgeschäft für die Einzüge gleichbleibt, kann die (und wird wohl auch) "CR" Referenz von 

Mal zu Mal wechseln (z.B. ein Wert, der sowohl Policennummer, als auch Prämien Monat in eine (vielleicht nur für den Auftraggeber interpretierbare) Nummer zusammenschließt. 

Ist eine CR angegeben, so wird diese bei Rücklastschriften immer zurückgegeben. Die Rückgabe der Bezogenenreferenz (PQ und AEF) ist im Fall einer Rücklastschrift empfohlen, 

kann aber nicht garantiert werden. 

20 Werden PQ und AEF gemeinsam verwendet darf der PQ Wert nicht länger als 28 Stellen sein. Tritt PQ ohne AEF auf, so ist es maximal 35 Stellen lang. 


P:\A5_Datenträger\NACHRICHTEN\DIRDEB_FAT01G.doc 

19 

20



Segmentgruppe 12 R 3 Zwingend für die Angabe der Kontoverbindung des Zahlungspflichtigen. Mehrfachnennung ist nicht 

möglich. 

FII-CTA-COM 


3035 BETEILIGTER, QUALIFIER M an..3 "PH" Kontoverbindung des Zahlungspflichtigen 

C078 KONTOANGABEN R 

3194 Kontonummer M an..35 Kontonummer, maximal 11 stellig, numerisch, bzw. IBAN (siehe Fußnote). 21 

3192 Kontoinhaber R an..35 Kontowortlaut 22 

3192 Kontoinhaber O an..35 Kontowortlaut, optionale zweite Zeile 

6345 Währung, codiert N an..3 

C088 KREDITINSTITUT-IDENTIFIKATION D Nicht zu verwenden bei IBAN, sonst zwingend 




3434 Nationaler Bankcode R an..17 BLZ Empfänger Institut (exakt 5 Stellen) 





3207 LAND, CODIERT D an..3 "AT" - ISO 3166 zwei Zeichen Ländercode. Bei IBAN nicht verwendet, sonst erforderlich. 

Beispiel: FII+PH+AT326000000001922503:Apotheke zur Kaiserkrone' 

FII+PH+1922503:Apotheke zur Kaiserkrone:1010 Freyung 4+:::60000:25:137+AT' 

21 Die IBAN (international bank account no) ist eine international normierte Schreibweise (ISO 13616) der Kontoverbindung, die sowohl das Land (des kontoführenden Instituts) als auch 

sämtliche national notwendigen Informationen enthält in der Form "LLppNNNNNNNNNNNNNNNN" wobei LL der ISO LänderCode (ISO 3166), pp eine Prüfziffer (Länder- und 

Institutsübergreifend nach ISO 7604) und NNNNNNNNNNNNNNNN die Bankleitzahl und die Kontonummer enthält. Die österreichischen Kreditinstitute geben die IBAN seit Beginn 1999 

an ihre Kunden zur Verwendung als Kontoverbindung mit ihren ausländischen Geschäftspartnern aus. Im Zuge der Angleichungen der europäischen nationalen Zahlungssysteme kann 

der Auftraggeber die IBAN auch für den IZV verwenden werden, mit dem Vorteil, daß der Prüfvorgang unabhängig von der BLZ ist. Sie wird daher als Alternative zur getrennten Angabe 

von BLZ und Kontonummer zugelassen. Im IZV kann sich die IBAN allerdings nur auf eine inländische Kontoverbindung beziehen, d.h. sie muß genau 20 Stellen lang sein und mit AT 

beginnen. 

22 An dieser Stelle wird immer die Bezeichnung (Name und Anschrift) des Bezogenenkontos angegeben, eine alternative Angabe der Kontobezeichnung in SGr. 13 NAD ist nicht möglich. 




FII-CTA-COM 

CTA KONTAKTSTELLE N 1 

FII-CTA-COM 



Segmentgruppe 13 D 3 Nur möglich, wenn Zahlungspflichtiger nicht gleich Kontoinhaber (FII SGr. 12) oder der 

Kontoinhaber nicht resident ist. 

NAD-CTA-COM 


3035 BETEILIGTER, QUALIFIER M an..3 "PL" Zahlungspflichtiger 23 

C082 IDENTIFIKATION DES BETEILIGTEN N 

3039 Identifikation des Beteiligten M an..35 



C058 NAME UND ANSCHRIFT D Alternativ zu C080 falls Bezogener ungleich Kontoinhaber; der strukturierten Angabe ist der 

Vorzug zu geben. Die gleichzeitige Kodierung in sowohl strukturiert als auch unstrukturiert ist 

verboten ! 

5 x 3124 Zeile für Name und Anschrift M an..35 

C080 NAME DES BETEILIGTEN D Alternativ zu C058 

5 x 3036 Name des Beteiligten M an..35 Die bevorzugte Angabe ist die strukturierte Form (C080, C059, 3164, 3229, 3251) 


C059 STRASSE D Alternativ zu C058 

4 x 3042 Straße und Hausnummer/Postfach M an..35 

3164 ORT D an..35 Alternativ zu C058; gemeinsam mit 3251 maximal 35 Stellen 


3251 POSTLEITZAHL O an..9 optional 

3207 LAND, CODIERT O an..3 ISO 3166 zwei Zeichen Ländercode. (angeben wenn nicht AT z.B. Zahlungspflichtiger 

/Kontoinhaber ist nonresident , hat aber ein Konto in Österreich) 

Beispiel: NAD+PL+++Mag. Dr. Kommerzialrat:Eugen Apothezky-Nasselreuth+Naglergasse 12/6:Postfach 24+Zürich++8023+CH' 

23 Für die Angabe der bezogenen Seite ist PL der einzig mögliche Qualifier. Die Angabe von Name/Anschrift des Bezogenen falls ident mit dem Kontoinhaber erfolgt in Feld 3192 im FII 

Segment SGr. 12. In diesem Fall wird das NAD ausschließlich zur ev. Kennzeichnung eines nicht Residenten verwendet. Nur wenn der Kontoinhaber nicht ident mit dem Bezogenen des 

Einzugs ist, ist das NAD mit PL zur Angabe der Daten des Bezogenen zu verwenden. Generell ist die Angabe in strukturierter Form vorzuziehen, auch wenn die Längenbeschränkungen 

für den Ausdruck dadurch nicht geändert werden (2 Zeilen à 35). 




NAD-CTA-COM 

CTA KONTAKTSTELLE N 1 

NAD-CTA-COM 



Segmentgruppe 14 O 3 Im IZV kann die SGr. 14 (und SGr. 8 ) für spezielle Institutsservices verwendet. werden 

INP-FTX-DTM 

INP BESONDERE WEISUNG M 1 

C849 BETEILIGTE an der WEISUNG R 

3301 Beauftragter einer Weisung, Identifikator M an..17 "3" Bank des Begünstigten. 

3285 Empfänger der Aktion/Weisung, Identifikator N an..17 

C522 WEISUNG R 

4403 Weisung, Qualifier M an..3 "1" (action required) 

4401 Weisung, codiert R an..3 Nach Vereinbarung 

1131 Codeliste, Qualifier R an..3 Nach Vereinbarung 

3055 Verantwortliche Stelle für Codepflege, codiert R an..3 Nach Vereinbarung 

4400 Instruction D an..35 Nach Vereinbarung 

C850 STATUS OF INSTRUCTION N 

4405 Status, codiert M an..3 

3036 Party name N an..35 

1229 ACTION REQUEST/NOTIFICATION, CODED N an..3 




INP-FTX-DTM 


INP-FTX-DTM 




GIS-MOA-LOC-NAD-RCS-FTX 

GIS GENERAL INDICATOR M 1 


MOA GELDBETRAG N 1 


LOC PLACE / LOCATION IDENTIFICATION N 2 


NAD NAME UND ANSCHRIFT N 1 


RCS REQUIREMENTS AND CONDITIONS N 1 







Segmentgruppe 16 D 1 siehe SGr. 10 - wurde bereits dort ein Verwendungszweck angegeben, ist die Angabe einer 

Textinformation an dieser Stelle verboten. 

Die SGr. 16 und alle Segmentgruppen unter ihr (17 bis 23) dienen zur Weiterleitung des Verwendungszwecks an den Zahlungspflichtigen. Sie wird bei einem EDIFACT end-to-end Service 

unverändert weitergegeben. Wenn allerdings der Zahlungspflichtige keine EDIFACT Daten entgegennehmen kann (Belegausdruck) oder ein anderes System zur Weiterleitung des Auftrags 

notwendig ist so unterliegt der Transport des Verwendungszwecks gewissen Beschränkungen. 

Es gibt zwei Formen wie man den Verwendungszweck "verpacken" kann: 

1. die unstrukturierte Form die Angabe des Verwendungszwecks steht als freier Text in den FTX Segmenten der SGr 16 

2. die strukturierte Form der Verwendungszweck ist kodiert und befindet sich in der SGr. 17 bzw. darunter (SGr. 18 bis 23) 

Weiter ist es möglich, sowohl die unstrukturierte als auch die strukturierte Form zu verwenden. In diesem Fall müssen die Inhalte (im Sinne des Kontexts!) deckungsgleich sein. Muss eine 

Konvertierung des EDIFACT Formats vorgenommen werden (z.B. Ausdruck auf Beleg für den Zahlungspflichtigen) so wird der Text aus den FTX Segmenten verwendet. Bei Befüllung 

beider Formate kann also der Absender sicher sein, dass den Zahlungspflichtigen, je nachdem ob er EDIFACT entgegennimmt oder nicht, die Information korrekt erreicht. 

Für EDIFACT–fähige Empfänger sollte die Information immer in strukturierter Form angegeben werden, wobei in vielen Fällen die Angabe der entsprechenden Referenz (SGr. 11 RFF "PQ" 

und/oder RFF "AEF") ausreichen wird. 

Im Fall der Angaben in Form von Textzeilen ist folgendes zu beachten: 

(1) bei einem Ausdruck werden die FTX-Subfelder 4440 als getrennte Zeilen behandelt. 

(2) Leerzeilen bewirken beim Belegdruck keinen Zeilenumbruch, sondern sind ein Syntaxfehler. 

(3) die maximale Anzahl Druckzeilen für Lastschriftbelege beträgt in Österreich 14 Zeilen à 57 Zeichen plus 2 Zeilen à 41 Zeichen. Alles was darüber hinausragt muß 

abgeschnitten werden und erreicht nicht den Zahlungspflichtigen. 

PRC-FTX-SG17-SG23 

PRC PROZESSBEZEICHNUNG M 1 

C242 PROZESSART UND -BESCHREIBUNG M 

7187 Prozessart, Identifikation M an..17 "11" Information liegt in UNSTRUKTURIERTER Form vor -> FTX folgt 

"8" Information liegt in STRUKTURIERTER Form vor -> SGr.17 ff folgt 



2 x 7186 Prozessart N an..35 

Beispiel: PRC+11' 

"9" sowohl als auch (Inhalte entsprechen einander) -> FTX und SGr.17 ff folgen 

24 Die in UN/EDIFACT ebenfalls vorgesehene Codierung "10" darf nicht verwendet werden. Ihre Bedeutung ist "sowohl als auch" wobei die Inhalte einander nicht entsprechen (d.h. der 

Text ist eine Ergänzung zur strukturierten Angabe des Verwendungszwecks. Das hat für eine automatische Verarbeitung der EDIFACT-Zahlungseingänge beim Begünstigten keinen 

Sinn, denn dann muß er diese Eingänge ohnedies händisch bearbeiten. Bei nicht EDIFACT entgegennehmenden Begünstigten würde die Information im strukturierten Teil zur Gänze 

verloren gehen, da - wenn beides vorliegt - immer nur der Text ausgedruckt wird. 


P:\A5_Datenträger\NACHRICHTEN\DIRDEB_FAT01G.doc 

24



FTX FREIER TEXT D 5 Abhängig von der Kodierung des PRC Segments 

4451 TEXTZUORDNUNG, QUALIFIER M an..3 "PMD" Verwendungszweck (Payment Details) 

4453 TEXTVERARBEITUNGSHINWEIS, CODIERT N an..3 

C107 TEXT-REFERENZ N 

4441 Freier Text, codiert M an..3 



C108 TEXT R 

5 x 4440 Freier Text M an..70 Verwendungszweck in Textform 

3453 SPRACHE, CODIERT N an..3 

Beispiel: FTX+PMD+++500 G Calendula Officinalis:1500 G Matricaria Chamomilla:1200 G Taxacum Officinale:1800 G Allium Sativum' 


Segmentgruppe 17 D 9999 Abhängig von der Kodierung des PRC Segments 

bis einschließlich 



werden im separaten Dokument "Strukturierte Kunden zu Kunden Information" beschrieben. Sie enthalten Information über den geschäftlichen Hintergrund zur 

Zahlung und sind vom Auftraggeber an der Empfänger gerichtet. Im EDIFACT end-to-end Service werden sie von den mit der Durchführung des Zahlungsauftrag 

befaßten Banken ungeprüft und unverändert bis zum Empfänger durchgereicht 



C-Beleg 

Beim Empfänger Institut wird für Endkunden oft ein Beleg erstellt. Dieser Beleg ist auch die Ursache für die 

diversen Längenbegrenzungen. Die Segmentangaben beziehen sich auf die Anlieferung im DIRDEB und zeigen 

somit wo die Daten von dort am Beleg aufscheinen. 

0 1 2 3 4 5 0 

·123456789·123456789·123456789·123456789·123456789·1234567· 

0· ··························································· 

1 · Einzug 

Lastschrift · 

2 · durch 

· 

3 · · 

4 · knknknknknk SGr.12 FII:C078:3192 ......... oder blzbl· 

5 · SGr.13 NAD:C080:3036 . und folgende · 

6 ·FTX C108:4440 aus SGr.16 (oder 10) ...... max. 57 Zeichen· 




1· ·FTX C108:4440 aus SGr.16 (oder 10) ...... max. 57 Zeichen· 

1 ·SGr.16 FTX C108:4440 .................... max. 57 Zeichen· 









2· ·FTX C108:4440 aus SGr.16 max. 41 Zeichen · 

1 ·FTX C108:4440 aus SGr.16 max. 41 Zeichen EUR 

· 

2 ·SGr.11 RFF C506:1154 ... PQ und/oder AEF bbbbbbbbbbbbbb· 

3 · · 

4 · KNKNKNKNKNK SGr.6 FII:C078:3192 .......... oder · 

5 · SGr.7 NAD:C080:3036 .. und folgende · 

6 · Verwendungszweck Kontonummer Bankleitzahl Betrag 

· 

7 · · 

8 · · 

9 · · 

3· · · 

1 · · 

0· ··························································· 

knknknknknk Kontonummer bzw. entsprechender Teil der IBAN SGr. 12 FII:C078:3194 

blzbl Bankleitzahl bzw. entsprechender Teil der IBAN SGr. 12 FII:C078:3434 

bbbbbbbbbbbbbb Überwiesener Teilbetrag SGr. 11 MOA:C516:5004 

KNKNKNKNKNK Kontonummer bzw. entsprechender Teil der IBAN SGr. 6 FII:C078:3194 

Die Textzeilen werden in der Reihenfolge gedruckt, in der sie angeliefert werden. Hier sei nochmals darauf 

aufmerksam gemacht, dass es entweder das eine FTX der SGr. 10 oder die bis zu 5 FTX der SGr. 16 gibt, 

jedoch nie beide. Weiter enthält jedes FTX maximal 5 Zeilen. 

Zu sehen ist auch, das bei der Verwendung der NAD Segmente nur 2 Zeilen von dort zum Andruck kommen 

können. Die Kreditinstitute versuchen die dort gelieferten Daten sinnvoll zusammenzuziehen, wobei klarerweise 

die Qualität der Befüllung das Ergebnis beeinflusst. Weniger ist in diesem Sinne oft mehr. 

Ebenso wird deutlich, warum RFF+PQ und RFF+AEF zusammen nur 40 Zeichen lang sein können und 

RFF+PQ deshalb allein vorkommend 35 Zeichen (Syntax Grenze) haben darf, im Verbund mit RFF+AEF aber 

nur 28 (da dieses genau 12 Ziffern lang sein muss).

D I R D E B - Stuzza

Sie wollen auch ein ePaper? Erhöhen Sie die Reichweite Ihrer Titel.

Template löschen?

Als Template speichern?