camt.053 Beispiel: der XML-Kontoauszug Feld für Feld

Beispieldatei zum Download

Ein Kontoauszug für einen Tag, ein Konto, drei Buchungen: eine SEPA-Gutschrift, eine SEPA-Lastschrift mit Mandat und Gläubiger-ID, ein Kontoführungsentgelt. Die Datei ist gültig gegen das ISO-Schema camt.053.001.08, die Salden gehen auf. Namen, Konten und die Gläubiger-ID sind erfunden, die IBANs haben korrekte Prüfziffern.

⬇ camt.053.001.08-beispiel.xml

Zum Ansehen ohne Editor: die Datei in den camt-Viewer ziehen. Er zeigt Kopf, Salden und Buchungen und rechnet den Saldo nach, ohne die Datei zu übertragen.

1. Drei Ebenen: GrpHdr, Stmt, Ntry

Eine camt.053-Datei ist die Antwort der Bank auf die Frage, was auf dem Konto passiert ist. Sie besteht aus drei Ebenen:

• GrpHdr, der Nachrichtenkopf, einmal pro Datei: Kennung der Lieferung, Erstellzeit, bei großen Lieferungen die Seitenzählung.
• Stmt, der eigentliche Auszug, einmal pro Konto und Zeitraum: Konto, Salden, Auszugsnummer, Zeitraum. Eine Datei kann mehrere Auszüge enthalten.
• Ntry, die einzelne Buchung, beliebig oft pro Auszug: Betrag, Richtung, Status, Datum, Buchungsart. Darunter in NtryDtls/TxDtls die Details zur Zahlung: Referenzen, Gegenpartei, Verwendungszweck.

Die Trennung zwischen Ntry und TxDtls ist der Punkt, an dem camt sich von einem einfachen Umsatz-Export unterscheidet. Eine Buchung kann mehrere Zahlungen bündeln, etwa eine Sammelüberweisung mit 30 Einzelzahlungen. Dann steht auf dem Auszug eine Buchung über die Summe, und die Einzelzahlungen folgen als 30 TxDtls oder in einer eigenen camt.054-Datei. Die drei Buchungen der Beispieldatei sind Einzelbuchungen mit höchstens einem TxDtls.

2. Kopf und Konto

Der Anfang der Datei, mit Kommentaren. Der Namensraum im Document-Element sagt, welche Nachricht und welche Version folgt. Werkzeuge, die die Datei prüfen, wählen daran ihr Schema.

<?xml version="1.0" encoding="UTF-8"?>
<!-- Namensraum = Nachricht und Version: camt.053, Version .08 -->
<Document xmlns="urn:iso:std:iso:20022:tech:xsd:camt.053.001.08">
  <BkToCstmrStmt>
    <GrpHdr>
      <!-- Kennung der Lieferung, von der Bank vergeben -->
      <MsgId>CAMT053-2026-10-01-0001</MsgId>
      <CreDtTm>2026-10-02T06:15:00+02:00</CreDtTm>
      <!-- Seite 1, letzte Seite: die Nachricht ist vollständig -->
      <MsgPgntn>
        <PgNb>1</PgNb>
        <LastPgInd>true</LastPgInd>
      </MsgPgntn>
    </GrpHdr>
    <Stmt>
      <Id>STMT-2026-10-01-A</Id>
      <!-- fortlaufende Auszugsnummer, elektronisch und rechtlich -->
      <ElctrncSeqNb>7</ElctrncSeqNb>
      <LglSeqNb>7</LglSeqNb>
      <CreDtTm>2026-10-02T06:15:00+02:00</CreDtTm>
      <!-- Zeitraum, den der Auszug abdeckt -->
      <FrToDt>
        <FrDtTm>2026-10-01T00:00:00+02:00</FrDtTm>
        <ToDtTm>2026-10-01T23:59:59+02:00</ToDtTm>
      </FrToDt>
      <Acct>
        <Id>
          <IBAN>DE02120300000000202051</IBAN>
        </Id>
        <Ccy>EUR</Ccy>
        <Ownr>
          <Nm>Musterfirma GmbH</Nm>
        </Ownr>
        <!-- kontoführende Bank; in .02 heißt das Element BIC -->
        <Svcr>
          <FinInstnId>
            <BICFI>TESTDE21XXX</BICFI>
            <Nm>Testbank Nord</Nm>
          </FinInstnId>
        </Svcr>
      </Acct>

LglSeqNb ist die Auszugsnummer, wie sie auf einem Papierauszug stünde. Fehlt zwischen zwei Lieferungen eine Nummer, fehlt ein Auszug. Der Zeitraum in FrToDt gilt für alle Buchungen darunter; eine Buchung mit einem Buchungsdatum außerhalb davon ist ein Hinweis auf eine Nachbuchung oder einen Fehler. Acct/Svcr nennt die kontoführende Bank, nicht die Gegenpartei.

3. Salden und die Rechnung dahinter

Ein Tagesauszug hat mindestens zwei Salden: den Anfangssaldo (OPBD, opening booked) und den Endsaldo (CLBD, closing booked). Manche Banken liefern statt OPBD den Endsaldo des Vortags als PRCD. Dazu kommen je nach Bank verfügbare Salden (CLAV, FWAV).

<Bal>
  <Tp><CdOrPrtry><Cd>OPBD</Cd></CdOrPrtry></Tp>
  <Amt Ccy="EUR">12500.00</Amt>
  <CdtDbtInd>CRDT</CdtDbtInd>
  <Dt><Dt>2026-09-30</Dt></Dt>
</Bal>
<Bal>
  <Tp><CdOrPrtry><Cd>CLBD</Cd></CdOrPrtry></Tp>
  <Amt Ccy="EUR">13587.60</Amt>
  <CdtDbtInd>CRDT</CdtDbtInd>
  <Dt><Dt>2026-10-01</Dt></Dt>
</Bal>

Der Betrag steht immer positiv, die Richtung in CdtDbtInd: CRDT für ein Guthaben, DBIT für einen Sollsaldo. Zwischen beiden Salden liegen die Buchungen, und die Rechnung muss aufgehen:

In die Rechnung gehören nur gebuchte Buchungen (Status BOOK). Vormerkungen (PDNG) stehen vor allem in untertägigen camt.052-Berichten und zählen nicht. Geht die Rechnung nicht auf, ist die Datei meist unvollständig: eine weitere Seite fehlt, oder eine Buchung wurde beim Wandeln verloren. Was dann zu tun ist, erklärt der Eintrag Salden passen nicht zu den Buchungen im camt-Fehlerglossar.

4. Eine Buchung, kommentiert

Die erste Buchung der Datei, die SEPA-Gutschrift, vollständig:

<Ntry>
  <Amt Ccy="EUR">1190.00</Amt>
  <!-- CRDT = Haben (Gutschrift), DBIT = Soll (Belastung) -->
  <CdtDbtInd>CRDT</CdtDbtInd>
  <!-- in .08 eine Auswahl Sts/Cd, in .02 der Code direkt in Sts -->
  <Sts>
    <Cd>BOOK</Cd>
  </Sts>
  <BookgDt><Dt>2026-10-01</Dt></BookgDt>
  <ValDt><Dt>2026-10-01</Dt></ValDt>
  <!-- Referenz der Bank für diese Buchung -->
  <AcctSvcrRef>2026100100001</AcctSvcrRef>
  <BkTxCd>
    <!-- ISO-Codierung: Zahlungsverkehr / empfangene Überweisung / SEPA -->
    <Domn>
      <Cd>PMNT</Cd>
      <Fmly><Cd>RCDT</Cd><SubFmlyCd>ESCT</SubFmlyCd></Fmly>
    </Domn>
    <!-- deutsche Codierung: SWIFT-Schlüssel plus Geschäftsvorfallcode -->
    <Prtry>
      <Cd>NTRF+166</Cd>
      <Issr>DK</Issr>
    </Prtry>
  </BkTxCd>
  <NtryDtls>
    <TxDtls>
      <Refs>
        <EndToEndId>RE-2026-0815</EndToEndId>
      </Refs>
      <AmtDtls>
        <TxAmt><Amt Ccy="EUR">1190.00</Amt></TxAmt>
      </AmtDtls>
      <!-- bei einer Gutschrift ist der Zahler (Dbtr) die Gegenpartei -->
      <RltdPties>
        <Dbtr>
          <!-- in .08 eine Ebene tiefer unter Pty -->
          <Pty><Nm>Adler Logistik GmbH</Nm></Pty>
        </Dbtr>
        <DbtrAcct><Id><IBAN>DE75512108001245126199</IBAN></Id></DbtrAcct>
      </RltdPties>
      <RltdAgts>
        <DbtrAgt><FinInstnId><BICFI>ADLRDE55XXX</BICFI></FinInstnId></DbtrAgt>
      </RltdAgts>
      <!-- Verwendungszweck, mehrere Ustrd-Zeilen zu je max. 140 Zeichen -->
      <RmtInf>
        <Ustrd>Rechnung RE-2026-0815</Ustrd>
        <Ustrd>Kundennummer 4711</Ustrd>
      </RmtInf>
    </TxDtls>
  </NtryDtls>
  <AddtlNtryInf>SEPA-Gutschrift</AddtlNtryInf>
</Ntry>

Wer die Gegenpartei ist, hängt an der Richtung. Bei einer Gutschrift (CRDT) ist es der Zahler, also RltdPties/Dbtr mit DbtrAcct und RltdAgts/DbtrAgt. Bei einer Belastung (DBIT) ist es der Empfänger unter Cdtr. Wer camt-Dateien selbst einliest, liest beide Seiten und wählt dann nach Richtung aus.

BookgDt ist der Tag der Buchung, ValDt der Tag, ab dem der Betrag zinswirksam ist. Bei Überweisungen liegen beide meist auf demselben Tag, bei Kartenabrechnungen und Zinsen können Wochen dazwischen liegen. EndToEndId ist die Referenz, die der Zahler bei der Überweisung mitgegeben hat; im Beispiel die Rechnungsnummer. Über sie findet eine Buchhaltung die offene Rechnung. AddtlNtryInf ist ein freier Buchungstext der Bank.

5. Buchungsart: BkTxCd und GVC

Jede Buchung trägt einen Bank Transaction Code, und zwar in zwei Codierungen nebeneinander. Die ISO-Codierung unter Domn hat drei Stufen: Domäne, Familie, Unterfamilie. PMNT / RCDT / ESCT heißt Zahlungsverkehr, empfangene Überweisung, SEPA. Die deutsche Codierung steht unter Prtry mit dem Issuer DK (in älteren Dateien ZKA): der Geschäftsvorfallcode (GVC), dreistellig, wie ihn deutsche Buchhaltungen seit MT940-Zeiten kennen.

Im Feld steht entweder nur der GVC oder der SWIFT-Buchungsschlüssel davor, getrennt durch ein Pluszeichen: NTRF+166. Im Gesamtbeispiel der Deutschen Kreditwirtschaft kommen beide Formen vor, teils mit weiteren Teilen wie einer Primanota. Die drei GVC der Beispieldatei mit ihrem Text aus Anhang 1 der Anlage 3 des DFÜ-Abkommens:

Anhang 1 ordnet jedem GVC eine ISO-Kombination zu und führt rund 170 Codes. Der camt-Viewer zeigt zu jedem GVC den Text aus dieser Liste; ein Code, der dort fehlt, wird als unbekannter GVC gemeldet.

6. Lastschrift: Mandat und Gläubiger-ID

Die zweite Buchung ist eine SEPA-Lastschrift über 89,90 €, DBIT, GVC 105. Gegenüber der Gutschrift kommen zwei Angaben dazu: die Mandatsreferenz in Refs/MndtId und die Gläubiger-Identifikation des Einziehenden unter Cdtr/Pty/Id.

<Refs>
  <EndToEndId>LS-2026-0930-1</EndToEndId>
  <MndtId>MANDAT-2024-0042</MndtId>
</Refs>
...
<RltdPties>
  <Cdtr>
    <Pty>
      <Nm>Energie Musterstadt AG</Nm>
      <Id>
        <PrvtId>
          <Othr>
            <Id>DE98ZZZ09999999999</Id>
            <SchmeNm><Prtry>SEPA</Prtry></SchmeNm>
          </Othr>
        </PrvtId>
      </Id>
    </Pty>
  </Cdtr>
  <CdtrAcct><Id><IBAN>DE12500105170648489890</IBAN></Id></CdtrAcct>
</RltdPties>

Mit Mandatsreferenz und Gläubiger-ID lässt sich eine Lastschrift eindeutig ihrem Vertrag zuordnen, auch wenn der Verwendungszweck nur „Abschlag Strom Oktober" lautet. Wer eine Lastschrift zurückgeben will, braucht genau diese beiden Werte. Kommt die Lastschrift zurück, erscheint eine weitere Buchung mit RtrInf/Rsn/Cd, etwa AC04 für ein aufgelöstes Konto oder MD06 für einen Widerspruch.

Die dritte Buchung, das Entgelt über 12,50 €, hat keine NtryDtls. Es gibt keine Gegenpartei und keine Referenz, nur den Betrag, GVC 808 und den Text in AddtlNtryInf.

7. camt.053.001.02 gegen .08

Seit 2010 liefern deutsche Banken camt.053 in der Version .02 aus dem ISO-Release 2009. Mit der Umstellung auf die ISO-Version 2019 kommt .08 dazu; über EBICS ist die Version ein Parameter der Bestellung. Inhaltlich tragen beide dasselbe. Wer einen Parser für .02 hat, muss für .08 an wenigen Stellen nachziehen:

Die ersten drei Zeilen sind die, an denen Konverter scheitern: Eine .08-Datei mit <Sts>BOOK</Sts> oder <BIC> ist schemawidrig, und ein .02-Parser findet in einer .08-Datei den Namen der Gegenpartei nicht, weil er eine Ebene tiefer unter Pty steht. Die Saldoart ist in .02 eine feste Liste; ein unbekannter Code fällt dort schon beim Schema durch, in .08 erst bei der fachlichen Prüfung.

Eigene, eingeschränkte camt-Schemas wie die DK-TVS für pain.001 veröffentlicht die Deutsche Kreditwirtschaft nicht. Sie stellt die ISO-Originale der Version 2019 bereit, dazu Belegungsregeln und Beispiele. Prüfgrundlage ist deshalb das ISO-Schema der jeweiligen Version.

8. SVWZ+ und EREF+ in gewandelten Dateien

Nicht jede camt-Datei ist nativ erzeugt. Banken und Programme, die ihre Auszüge aus MT940 wandeln, übernehmen das alte Feld 86 mit seinen Schlüsselwörtern in den Verwendungszweck. Dieselbe Lastschrift wie oben sieht dann so aus:

<RmtInf>
  <Ustrd>EREF+LS-2026-0930-1MREF+MANDAT-2024-0042CRED+DE98ZZZ09999999999SVWZ+Abschlag Strom Oktober</Ustrd>
</RmtInf>

SVWZ+ leitet den eigentlichen Verwendungszweck ein, EREF+ die Ende-zu-Ende-Referenz, MREF+ die Mandatsreferenz, CRED+ die Gläubiger-ID, dazu KREF+ (Kundenreferenz), ABWA+ und ABWE+ (abweichender Auftraggeber und Empfänger). Weil MT940 den Text in Zeilen zu 27 Zeichen schnitt, können die Teile über mehrere Ustrd-Zeilen laufen, und ein Wort kann mitten in der Zeile umbrechen. Wer solche Dateien auswertet, setzt die Zeilen ohne Trennzeichen zusammen und zerlegt dann an den Schlüsselwörtern.

Der camt-Viewer macht das automatisch und meldet die Herkunft als Hinweis Verwendungszweck mit DK-Schlüsselwörtern. In der Buchungsliste steht dann nur der SVWZ-Teil, die übrigen Felder in der Detailansicht.

9. Eigene Datei ansehen und prüfen

Den eigenen Kontoauszug in einem Editor zu lesen, geht, ist aber mühsam. Der camt-Viewer zeigt dieselbe Datei als Tabelle mit Salden, Buchungen, Gegenparteien und GVC-Texten, rechnet den Saldo nach und exportiert die Buchungen als CSV. Der camt-Validator stellt die Prüfung voran: Struktur, Plausibilität und auf Klick das ISO-Schema mit Zeile und Spalte für jeden Verstoß. Beides läuft im Browser; nur die Schema-Prüfung überträgt die Datei auf Ihren Klick kurzzeitig.

Und die Gegenrichtung: Die Zahlungsdatei, deren Ausführung später im Kontoauszug erscheint, erklärt der Artikel pain.001.001.09 Beispiel. Was hinter der Entgeltbuchung mit GVC 808 steht, zeigt die Gebührenabrechnung der Bank im Format camt.086; sie lässt sich im camt.086-Viewer lesen.

10. Häufige Fragen zu camt.053

Quellen und Einordnung

ISO-20022-Schemas camt.053.001.02 (Message Archive auf iso20022.org) und camt.053.001.08 (über ebics.de, Ergänzende Dokumente, Kapitel 7); Anhang 1 der Anlage 3 des DFÜ-Abkommens (Mapping GVC, Stand 09.04.2026); Gesamtbeispiel camt.053 der Deutschen Kreditwirtschaft vom 08.07.2025. Die Beispieldatei ist synthetisch und gegen das Schema camt.053.001.08 geprüft. Der Beitrag ersetzt nicht die Belegungsregeln Ihrer Bank.