pain.001.001.09 Beispiel: die SEPA-XML-Datei Feld für Feld

Beispieldateien zum Download

Alle vier Dateien kommen unverändert aus dem SEPA-Generator von finisma. Drei sind gültig, eine scheitert absichtlich am häufigsten Fehler. Namen und Konten sind erfunden: Die IBANs haben eine korrekte Prüfziffer, tragen aber die Bankleitzahl 99999999, die keiner Bank gehört. Ausführen lässt sich damit nichts, zum Testen eines Imports oder eines eigenen Parsers reichen sie.

Geprüft mit beiden Stufen des Validators: den Geschäftsregeln von finisma und dem Bankschema der Deutschen Kreditwirtschaft (DK-XSD GBIC_5). Die gültigen Dateien tragen den 1. März 2027 als Ausführungstermin. Wer sie nach diesem Tag prüft, bekommt dieselbe Meldung wie bei der dritten Datei.

1. Drei Ebenen: GrpHdr, PmtInf, CdtTrfTxInf

Eine pain.001-Datei ist ein Auftrag an die eigene Bank. Der Empfänger bekommt sie nie zu sehen. Sie besteht aus drei Ebenen, die ineinanderliegen:

• GrpHdr, der Nachrichtenkopf, genau einmal je Datei: Kennung, Erstellzeit, Zahl der Zahlungen, Summe, Einreicher.
• PmtInf, der Zahlungsblock: wer zahlt, von welchem Konto, an welchem Tag. Eine Datei darf mehrere Blöcke haben.
• CdtTrfTxInf, die einzelne Überweisung: Empfänger, IBAN, Betrag, Verwendungszweck. Beliebig viele je Block.

Was für alle Zahlungen eines Blocks gilt, steht nur einmal im PmtInf. In einer Sammelüberweisung an 40 Lieferanten taucht das eigene Konto deshalb ein einziges Mal auf.

Namensraum, Dateiendung, Zeichensatz

Die Version steht im Namensraum des Document-Elements: urn:iso:std:iso:20022:tech:xsd:pain.001.001.09. Daran erkennen Bank, Banking-Software und Validator, womit sie es zu tun haben. Endet der Namensraum auf .03, ist es das alte Format. Was beim Wechsel zu beachten ist, steht im Artikel pain.001.001.03 auf pain.001.001.09 umstellen.

Die Datei endet auf .xml und ist reiner Text. Öffnen Sie sie mit einem Texteditor, nicht mit Excel oder Word, die beim Speichern gern etwas umbauen. Die Kodierung ist UTF-8, so steht es in der ersten Zeile. finisma schreibt ohne Byte Order Mark (BOM), die Datei beginnt direkt mit <?xml. Nach dem BOM wird oft gefragt. Wir haben dieselbe Datei mit vorangestelltem BOM gegen das Bankschema laufen lassen: Sie bleibt gültig, und unser Validator liest sie auch. Wie jedes einzelne Bankportal damit umgeht, wissen wir nicht. Ohne BOM stellt sich die Frage gar nicht erst.

Namen und Verwendungszweck dürfen nur Zeichen aus dem SEPA-Zeichensatz enthalten: Buchstaben ohne Akzente, Ziffern, das Leerzeichen und / - ? : ( ) . , ' +. Umlaute werden umgeschrieben, aus „Broschüren“ in der Sammelüberweisung wurde „Broschueren“. Ein kaufmännisches Und gehört nicht dazu.

GBIC_5: das Schema der deutschen Banken

pain.001.001.09 ist ein ISO-20022-Format. Welchen Teil davon deutsche Banken annehmen, legt die Deutsche Kreditwirtschaft in Anlage 3 des DFÜ-Abkommens fest, als eigenes, strengeres XSD. Die aktuelle Fassung heißt GBIC_5 und trägt im Kopfkommentar den Stand 1. April 2025. Neu gegenüber GBIC_4 sind vor allem die hybride Adresse und die Vorgabe Euro bei Beträgen. Wer eine „SEPA-Datei gemäß pain.001.001.09_GBIC_5“ liefern soll, muss genau dieses Schema einhalten. Ein Unterschied, der Eigenentwicklungen oft trifft: ISO erlaubt für Namen 140 Zeichen, GBIC_5 nur 70.

Die XSD liegt auf ebics.de unter Datenformate, Ergänzende Dokumente. Herunterladen muss sie nur, wer selbst Dateien erzeugt. Zum Prüfen genügt der pain.001-Validator, der in Stufe 2 genau dagegen prüft.

2. Die Beispieldatei, kommentiert

Das ist die Einzelüberweisung aus der Download-Tabelle. Die Kommentare stehen nur hier im Artikel, in der Datei selbst gibt es keine.

<?xml version="1.0" encoding="UTF-8"?>
<Document xmlns="urn:iso:std:iso:20022:tech:xsd:pain.001.001.09">
  <CstmrCdtTrfInitn>
    <GrpHdr>
      <!-- Kennung der Nachricht: Datum plus Prüfsumme über den Inhalt -->
      <MsgId>MSG-20270301-1MW6VBR</MsgId>
      <CreDtTm>2027-03-01T00:00:00</CreDtTm>
      <!-- Anzahl und Summe aller Zahlungen der Datei -->
      <NbOfTxs>1</NbOfTxs>
      <CtrlSum>480.00</CtrlSum>
      <InitgPty>
        <Nm>Musterfirma Beispiel GmbH</Nm>
      </InitgPty>
    </GrpHdr>
    <PmtInf>
      <PmtInfId>PMTINF-20270301-1-1MW6VBR</PmtInfId>
      <!-- TRF = Überweisung -->
      <PmtMtd>TRF</PmtMtd>
      <!-- Bitte um eine Sammelbuchung auf dem Kontoauszug -->
      <BtchBookg>true</BtchBookg>
      <NbOfTxs>1</NbOfTxs>
      <CtrlSum>480.00</CtrlSum>
      <PmtTpInf>
        <SvcLvl>
          <Cd>SEPA</Cd>
        </SvcLvl>
      </PmtTpInf>
      <!-- Ausführungstermin: der häufigste Fehler in echten Dateien -->
      <ReqdExctnDt>
        <Dt>2027-03-01</Dt>
      </ReqdExctnDt>
      <Dbtr>
        <Nm>Musterfirma Beispiel GmbH</Nm>
      </Dbtr>
      <DbtrAcct>
        <Id>
          <IBAN>DE39999999990012345678</IBAN>
        </Id>
      </DbtrAcct>
      <!-- Pflichtfeld; ohne BIC steht hier der Platzhalter NOTPROVIDED -->
      <DbtrAgt>
        <FinInstnId><Othr><Id>NOTPROVIDED</Id></Othr></FinInstnId>
      </DbtrAgt>
      <!-- Entgelte: im SEPA-Profil nur SLEV -->
      <ChrgBr>SLEV</ChrgBr>
      <CdtTrfTxInf>
        <PmtId>
          <!-- Referenz, die bis zum Empfänger durchläuft, max. 35 Zeichen -->
          <EndToEndId>RE-2027-0142</EndToEndId>
        </PmtId>
        <Amt>
          <!-- Punkt als Dezimaltrenner, genau zwei Nachkommastellen -->
          <InstdAmt Ccy="EUR">480.00</InstdAmt>
        </Amt>
        <Cdtr>
          <Nm>Werkstatt Nordlicht GmbH</Nm>
        </Cdtr>
        <CdtrAcct>
          <Id>
            <IBAN>DE48999999991000000001</IBAN>
          </Id>
        </CdtrAcct>
        <!-- Verwendungszweck, max. 140 Zeichen im SEPA-Zeichensatz -->
        <RmtInf>
          <Ustrd>Rechnung RE-2027-0142, Kd-Nr. 4711</Ustrd>
        </RmtInf>
      </CdtTrfTxInf>
    </PmtInf>
  </CstmrCdtTrfInitn>
</Document>

Die meisten Felder erklären sich über ihre Kommentare.

MsgId. finisma setzt die Kennung aus dem Ausführungstag und einer Prüfsumme über den Inhalt des Zahllaufs zusammen. Früher waren es nur das Datum und ein fester Zähler. Zwei verschiedene Zahlläufe am selben Tag bekamen dadurch dieselbe MsgId, und Banken lehnen doppelte MsgIds als Dublette ab. Aufgefallen ist das an zwei echten Bank-Exporten. Heute ergibt derselbe Lauf immer dieselbe Kennung und jeder andere Lauf eine andere. Wer dieselbe Datei aus Versehen zweimal hochlädt, soll bei der Bank als Dublette auffallen, statt doppelt zu zahlen.

Seltsam sieht CreDtTm aus, der Erstellzeitpunkt: 2027-03-01T00:00:00 ist Mitternacht des Ausführungstags. Erzeugt wurde die Datei natürlich früher. Wir verzichten bewusst auf die echte Uhrzeit, damit dieselben Zahlungen immer byteidentisch dieselbe Datei ergeben. Das Schema verlangt hier nur ein gültiges Datum mit Uhrzeit.

NbOfTxs und CtrlSum stehen zweimal, im Kopf für die ganze Datei und im PmtInf für den Block. Bei nur einem Block sind die Werte gleich. GBIC_5 verlangt die Kontrollsumme an beiden Stellen, ISO nicht. finisma rechnet sie in Cent. Mit Fließkommazahlen ergeben 0,10 € plus 30,30 € nämlich 30.400000000000002. Stimmt die Summe nicht mit den Zahlungen überein, meldet der Validator PAIN_SUM_MISMATCH.

DbtrAgt ohne BIC. Für SEPA-Überweisungen reicht die IBAN. Das Feld für die Bank des Auftraggebers ist trotzdem Pflicht, also steht darin der Platzhalter NOTPROVIDED. Ist ein BIC bekannt, steht er in <BICFI>. In pain.001.001.03 hieß das Feld noch schlicht BIC, und an dieser Stelle scheitern alte Parser gern.

Beim Betrag gilt: Punkt als Trenner, genau zwei Nachkommastellen, die Währung als Attribut. Im SEPA-Profil ist nur EUR erlaubt, alles andere meldet der Validator als PAY_CURRENCY_SCT.

3. Pflichtfelder als Tabelle

Die Spalte „Pflicht“ folgt dem DK-Schema GBIC_5 für SEPA-Überweisungen. Die letzte Spalte nennt den Code, mit dem der Validator ein Problem in diesem Feld meldet. Jeder Code führt zur Erklärung im Fehlerglossar.

Eine Zeile weicht vom Schema ab. Einen leeren Verwendungszweck lässt GBIC_5 zu, wir werten ihn trotzdem als Fehler. Der Empfänger bekommt sonst Geld, das er keiner Rechnung zuordnen kann, und ruft an.

Das Schema kennt noch viele weitere Felder, etwa einen abweichenden Auftraggeber (UltmtDbtr), einen strukturierten Verwendungszweck (Strd) oder einen Zweckcode (Purp). Für eine normale Überweisung braucht man keines davon.

4. Adressen: PstlAdr strukturiert und hybrid

In der Beispieldatei steht keine einzige Adresse, und das ist Absicht. Für eine SEPA-Überweisung reichen Name und IBAN, die SEPA-Datei von finisma lässt die Adresse deshalb weg. Die Unruhe um die „Adresspflicht“ betrifft Dateien, die trotzdem eine Adresse mitschicken, und Auslandszahlungen.

Steht unter Dbtr oder Cdtr ein <PstlAdr>, verlangt GBIC_5 darin zwei Felder: den Ort (TwnNm) und den zweistelligen Ländercode (Ctry). Straße, Hausnummer und Postleitzahl dürfen strukturiert stehen (StrtNm, BldgNb, PstCd) oder als Freitext in höchstens zwei Adresszeilen mit je 70 Zeichen (AdrLine). Die Mischform aus festen Feldern für Ort und Land und freien Zeilen für den Rest heißt hybride Adresse.

So schreibt finisma eine Empfängeradresse bei einer Auslandszahlung (AXZ-Profil, ebenfalls pain.001.001.09):

<Cdtr>
  <Nm>Atelier Bergblick AG</Nm>
  <PstlAdr>
    <TwnNm>Zuerich</TwnNm>
    <Ctry>CH</Ctry>
    <AdrLine>Seestrasse 12</AdrLine>
    <AdrLine>8002 Zuerich</AdrLine>
  </PstlAdr>
</Cdtr>

Eine Regel findet man nicht im XSD, sondern nur in den DK-Vorgaben: Die Straße darf nicht doppelt stehen, also nicht strukturiert in StrtNm und zusätzlich in einer Adresszeile. Unser Validator prüft das und meldet PAY_ADDRESS_LINES. Im AXZ-Profil sind Ort und Land immer Pflicht, fehlen sie, lautet die Meldung PAY_ADDRESS_INCOMPLETE. Wie Auslandszahlungen aus DTAZV-Dateien in dieses Format kommen, beschreibt der Artikel DTAZV in AXZ umwandeln.

5. Sammel-, Gehalts- und Echtzeitüberweisung

Sammelüberweisung: BtchBookg

Die Sammelüberweisung aus der Download-Tabelle hat drei CdtTrfTxInf-Blöcke in einem PmtInf, NbOfTxs ist 3, CtrlSum 1824.70. Das Feld BtchBookg entscheidet, wie das auf dem eigenen Kontoauszug aussieht: true bittet um eine Buchung über die Summe, false um eine Buchung je Zahlung. „Bittet“ ist wörtlich gemeint, das Schema selbst nennt das Feld eine Bitte und keine Anweisung.

finisma setzt immer true, auch bei einer einzigen Zahlung, wo es keinen Unterschied macht. Wer jede Zahlung einzeln auf dem Auszug sehen will, braucht false. Das Schema lässt beides zu, wir haben die Variante gegen GBIC_5 geprüft. Haben einzelne Zahlungen einen anderen Termin, etwa wegen einer Skontofrist, legt finisma je Termin einen eigenen PmtInf-Block an. Wann sich eine Sammelbuchung lohnt, steht im Artikel Sammelüberweisung aus Rechnungen erstellen.

Gehaltsüberweisung: CtgyPurp SALA

Nach einer „Beispieldatei SEPA pain.001.001.09 salary“ wird oft gesucht. Gehälter kennzeichnet der Zweckcode SALA im Feld CtgyPurp, das in PmtTpInf nach SvcLvl steht:

<PmtTpInf>
  <SvcLvl>
    <Cd>SEPA</Cd>
  </SvcLvl>
  <CtgyPurp>
    <Cd>SALA</Cd>
  </CtgyPurp>
</PmtTpInf>

Sonst unterscheidet sich eine Gehaltsdatei nicht von einer normalen Sammelüberweisung. Die Gehaltsüberweisung in der Download-Tabelle zeigt das an zwei Gehältern, sie ist gegen GBIC_5 geprüft. Gehaltsdatei in finisma Zahlungen erstellen.

Echtzeitüberweisung: LclInstrm INST

GBIC_5 deckt SEPA- und Echtzeitüberweisungen mit demselben Schema ab. Die Echtzeitüberweisung erkennt die Bank am Code INST im Feld LclInstrm:

<PmtTpInf>
  <SvcLvl>
    <Cd>SEPA</Cd>
  </SvcLvl>
  <LclInstrm>
    <Cd>INST</Cd>
  </LclInstrm>
</PmtTpInf>

Die Reihenfolge ist fest: erst SvcLvl, dann LclInstrm, dann CtgyPurp. Wir haben probeweise CtgyPurp vor LclInstrm gesetzt, das Schema lehnt die Datei dann ab. Im Glossar heißt dieses Fehlerbild XSD_ELEMENT. Ob Ihre Bank Echtzeitüberweisungen per Datei annimmt, klären Sie mit ihr.

6. Woran echte Dateien scheitern: 635 Prüfungen

Die Zahlen stammen aus der Nutzungsstatistik des pain.001-Validators vom 26. August bis 25. September 2026. Die Statistik enthält nur Fehlercodes und Größenklassen, keine Beträge, IBANs oder Namen aus den Dateien.

Von 635 Prüfungen betrafen 621 eine Datei im Format .09 und nur 14 eine im alten .03. Die meisten Dateien sind also schon im neuen Format und scheitern trotzdem. Stufe 1, die Geschäftsregeln, meldete 313 Dateien als fehlerhaft, 269 waren ohne Befund, 51 hatten eine Warnung.

Die häufigsten Fehler, in dieser Reihenfolge:

1. Ausführungstermin in der Vergangenheit (PAY_EXECUTION_DATE_PAST), mit großem Abstand. 97 Dateien hatten nur diesen einen Fehler, mit anderen zusammen waren es rund 150, knapp die Hälfte aller fehlerhaften Dateien.
2. Ungültige IBAN (PAY_IBAN_INVALID): die Prüfziffer stimmt nicht. Oft reicht dafür ein Zahlendreher.
3. Verwendungszweck zu lang (PAY_REMITTANCE_LENGTH): über 140 Zeichen, gezählt nach der Umwandlung in den SEPA-Zeichensatz. Weil aus jedem Umlaut zwei Buchstaben werden, rutscht ein Text mit 138 Zeichen leicht darüber.
4. Unvollständige Adresse (PAY_ADDRESS_INCOMPLETE): Ort oder Land fehlen bei einer Auslandszahlung.

Die 97 Dateien mit nur einem Datumsfehler sind die interessanteste Gruppe, weil an ihnen sonst nichts auszusetzen war. Wir vermuten, dass viele Besucher eine ältere Datei aus dem Archiv hochladen, um das Format zu testen. Beim Erzeugen war sie richtig, nur der Termin ist inzwischen vorbei. Einreichen sollte man so eine Datei trotzdem nicht: Manche Bankportale weisen sie ab, andere ziehen den Termin stillschweigend auf den nächsten Bankarbeitstag. Ein neuer Export mit aktuellem Datum ist die saubere Lösung.

Die Schema-Prüfung (Stufe 2) läuft nur, wenn man sie anklickt. Das geschah 466-mal, und 267 dieser Dateien waren gegen das Bankschema ungültig, mehr als die Hälfte. Beide Stufen prüfen verschiedene Dinge. Ein abgelaufener Termin ist schematisch einwandfrei, die dritte Beispieldatei besteht das XSD ohne Befund. Ein Element an der falschen Stelle dagegen fällt nur dem Schema auf. Typische Schemafehler erklärt das Fehlerglossar in einer eigenen Gruppe.

7. Eigene Datei prüfen

Laden Sie Ihre Datei in den Validator oder fügen Sie das XML ein. Er zeigt Version und Profil, prüft die Geschäftsregeln aus Abschnitt 3 und auf Klick gegen GBIC_5. Die Datei verlässt dabei für Stufe 1 nicht den Browser.

8. Häufige Fragen zu pain.001.001.09

Quellen und Einordnung

DK-TVS GBIC_5 für SEPA- und Echtzeitüberweisungen (Anlage 3 des DFÜ-Abkommens, Stand 01.04.2025, bezogen über ebics.de) und das AXZ-TVS GBIC_5 für Auslandszahlungen; die Beispieldateien und Ausschnitte stammen aus dem Zahlungsgenerator von finisma oder sind, wo im Text so gekennzeichnet, von Hand ergänzt und gegen das Schema geprüft. Die Fehlerzahlen stammen aus der anonymen Nutzungsstatistik des pain.001-Validators vom 26.08. bis 25.09.2026. Der Beitrag ersetzt nicht die Einreichungsbedingungen Ihrer Bank.