Alle Artikel

Schweizer Banking · Schweizer Banking, Datei für Datei, Teil 2

pain.001 Schweiz: die Zahlungsdatei für Lieferanten

Veröffentlicht 06.11.2026 · 11 Min. Lesezeit

Was ist pain.001?

pain.001 ist die ISO-20022-Meldung «Customer Credit Transfer Initiation»: die Datei, mit der eine Firma ihrer Bank eine oder viele Überweisungen in Auftrag gibt. Sie trägt das Belastungskonto, das gewünschte Ausführungsdatum und pro Zahlung Betrag, Empfänger, Konto und Referenz. Die Bank führt die Zahlungen aus, und sie erscheinen später auf deinem Kontoauszug, als camt.053.

In der Schweiz und in Liechtenstein regeln die Swiss Payment Standards von SIX, wie eine pain.001 aussehen muss. Ab dem 14.11.2026 gelten die Implementation Guidelines für pain.001, SPS 2026 Version 2.3. Dazu gehört ein eigenes XML-Schema, pain.001.001.09.ch.03.xsd. Verstösst eine Datei gegen das Schema, weisen die Banken sie zurück. Softwarehersteller sollen ihre Dateien deshalb vorher dagegen prüfen, so verlangen es die Richtlinien (Kapitel 3.6).

Für eine Zahlung im Inland (Zahlungsart D) gilt: Zahlungsmethode TRF, Währung CHF oder EUR, und mit einer Schweizer oder Liechtensteiner IBAN darf die Bank des Empfängers fehlen, weil sie sich aus der IBAN ergibt. EUR läuft in dieser Zahlungsart bis November 2027. Was TILL sonst für Schweizer Bücher tut, steht auf der Seite Schweiz.

Wie wird aus einer offenen Rechnung eine pain.001-Datei?

Eine offene Lieferantenrechnung wird in fünf Schritten zur pain.001-Datei. Hat die Bank gezahlt, schliesst eine Zeile im Kontoauszug die Rechnung wieder. Die Tabelle zeigt den ganzen Weg, mit den Befehlen, die TILL dafür hat. Jeder Befehl ist auch ein MCP-Werkzeug, das ein Agent aufrufen kann.

Schritt 5 ist der wichtigste: generate_pain001 antwortet immer mit transmitted: false. Hat das Belastungskonto einen EBICS-Kanal, steht als Grund upload_in_ebanking dabei, sonst no_channel. Der EBICS-Client von TILL holt nur Auszüge ab und unterschreibt nichts, das erklärt Teil 1 dieser Serie über EBICS. In der öffentlichen Beta ist das Modul für die Verbindung zur Bank noch nicht veröffentlicht: Du importierst den camt.053 aus dem E-Banking (Schritt 7). Ruft ein verbundener Agent einen der schreibenden Befehle auf (Schritte 2 bis 5, 7 und 8), wird daraus standardmässig ein Vorschlag, den ein Mensch freigibt.

Was steht in einer pain.001.001.09-Datei?

Eine pain.001.001.09-Datei hat drei Ebenen. Die A-Ebene (GrpHdr) beschreibt die ganze Datei, die B-Ebene (PmtInf) ein Belastungskonto mit einem Ausführungsdatum, die C-Ebene (CdtTrfTxInf) eine einzelne Zahlung. So sieht eine Datei mit zwei Zahlungen aus, wie TILL sie schreibt:

<?xml version="1.0" encoding="UTF-8"?>
<Document xmlns="urn:iso:std:iso:20022:tech:xsd:pain.001.001.09">
 <CstmrCdtTrfInitn>
  <!-- A-Ebene: die ganze Datei -->
  <GrpHdr>
   <!-- neu für jede Datei, die Bank prüft auf Duplikate -->
   <MsgId>M4h1x8q2c7v0n5b3k9r6t2w8y</MsgId>
   <CreDtTm>2026-11-06T08:15:00.000Z</CreDtTm>
   <NbOfTxs>2</NbOfTxs>
   <!-- 1250.00 + 320.50 -->
   <CtrlSum>1570.50</CtrlSum>
   <InitgPty><Nm>Muster Werkstatt GmbH</Nm></InitgPty>
  </GrpHdr>
  <!-- B-Ebene: ein Belastungskonto, ein Datum -->
  <PmtInf>
   <PmtInfId>P4h1x8q2c7v0n5b3k9r6t2w8y</PmtInfId>
   <PmtMtd>TRF</PmtMtd>
   <!-- eine Sammelbuchung für den ganzen Lauf -->
   <BtchBookg>true</BtchBookg>
   <NbOfTxs>2</NbOfTxs>
   <CtrlSum>1570.50</CtrlSum>
   <ReqdExctnDt><Dt>2026-11-10</Dt></ReqdExctnDt>
   <Dbtr><Nm>Muster Werkstatt GmbH</Nm></Dbtr>
   <DbtrAcct><Id><IBAN>CH7280005000088877766</IBAN></Id></DbtrAcct>
   <!-- Clearing-Nummer, aus der IBAN abgeleitet -->
   <DbtrAgt><FinInstnId><ClrSysMmbId>
    <ClrSysId><Cd>CHBCC</Cd></ClrSysId><MmbId>80005</MmbId>
   </ClrSysMmbId></FinInstnId></DbtrAgt>
   <ChrgBr>SLEV</ChrgBr>
   <!-- C-Ebene: eine Zahlung, eine Rechnung -->
   <CdtTrfTxInf>
    <PmtId>
     <InstrId>I7m2p9s4d1f6g3j8l5z0a2c4e</InstrId>
     <EndToEndId>E7m2p9s4d1f6g3j8l5z0a2c4e</EndToEndId>
    </PmtId>
    <Amt><InstdAmt Ccy="CHF">1250.00</InstdAmt></Amt>
    <Cdtr><Nm>Papeterie Muster AG</Nm></Cdtr>
    <!-- eine QR-IBAN, darum zwingend eine QR-Referenz -->
    <CdtrAcct><Id><IBAN>CH4431999123000889012</IBAN></Id></CdtrAcct>
    <RmtInf><Strd><CdtrRefInf>
     <Tp><CdOrPrtry><Prtry>QRR</Prtry></CdOrPrtry></Tp>
     <Ref>210000000003139471430009017</Ref>
    </CdtrRefInf></Strd></RmtInf>
   </CdtTrfTxInf>
   <CdtTrfTxInf>
    <PmtId>
     <InstrId>I2q8w5e1r7t3y9u4i0o6p2a8s</InstrId>
     <EndToEndId>E2q8w5e1r7t3y9u4i0o6p2a8s</EndToEndId>
    </PmtId>
    <Amt><InstdAmt Ccy="CHF">320.50</InstdAmt></Amt>
    <Cdtr><Nm>Holzbau Beispiel GmbH</Nm></Cdtr>
    <!-- eine normale IBAN mit einer SCOR-Referenz -->
    <CdtrAcct><Id><IBAN>CH4821966000009613388</IBAN></Id></CdtrAcct>
    <RmtInf><Strd><CdtrRefInf>
     <Tp><CdOrPrtry><Cd>SCOR</Cd></CdOrPrtry></Tp>
     <Ref>RF18539007547034</Ref>
    </CdtrRefInf></Strd></RmtInf>
   </CdtTrfTxInf>
  </PmtInf>
 </CstmrCdtTrfInitn>
</Document>

Die vier Referenzen MsgId, PmtInfId, InstrId und EndToEndId vergibt TILL einmal, wenn der Zahlungslauf angelegt wird, und speichert sie. Jede passt in 35 Zeichen und in den Zeichensatz, den SIX für Referenzen erlaubt. Darum ist eine neu erzeugte Datei Byte für Byte dieselbe. Lädst du sie aus Versehen ein zweites Mal hoch, trägt sie dieselbe MsgId, und deine Bank kann das Duplikat erkennen. Einen Lauf, der schon bezahlt ist, erzeugt TILL gar nicht mehr (already_paid).

Wie sieht eine strukturierte Adresse in pain.001 aus?

Eine strukturierte Adresse in pain.001 steht unter PstlAdr, mit Strasse, Hausnummer, Postleitzahl, Ort und Land in eigenen Elementen. Ab dem 14.11.2026 müssen laut SIX die Adressen aller an einer Zahlung beteiligten Parteien so aufgebaut sein und mindestens Ort und Land als getrennte Datenelemente enthalten. Für den Empfänger der ersten Zahlung oben sähe das so aus:

<Cdtr>
 <Nm>Papeterie Muster AG</Nm>
 <PstlAdr>
  <!-- empfohlen -->
  <StrtNm>Bahnhofstrasse</StrtNm>
  <BldgNb>12</BldgNb>
  <PstCd>8999</PstCd>
  <!-- immer, wenn eine Adresse dasteht -->
  <TwnNm>Seldwyla</TwnNm>
  <Ctry>CH</Ctry>
 </PstlAdr>
</Cdtr>

Neben der strukturierten gibt es die hybride Adresse: Ort und Land wie oben, dazu höchstens zwei Zeilen AdrLine mit je 70 Zeichen für das, was in kein Feld passt. Was schon in einem Feld steht, darf in diesen Zeilen nicht noch einmal auftauchen. Ob deine Bank die hybride Adresse annimmt, hängt von ihrem Angebot ab. Die ganz unstrukturierte Adresse, nur Zeilen ohne Ort und Land, ist im Rahmen der Swiss Payment Standards ab dem 14.11.2026 nicht mehr zulässig.

Aus den SIX-Unterlagen: Das neue Adressformat ist ab dem 14.11.2026 für alle Zahlungsaufträge Pflicht, und deine Software muss die Adresse des Empfängers haben und in der richtigen Form mitgeben. Unvollständige Adressen können zur Abweisung der Zahlung führen. Deine eigene Adresse als Auftraggeber ergänzt dagegen die Bank aus ihren Stammdaten, du musst sie nicht mitliefern. Als Element führen die Richtlinien die Empfängeradresse optional, verlangen aber Ort und Land, sobald eine Adresse dasteht.

Was ändert sich am 14. November 2026?

Am 14. November 2026 endet in der Schweiz die Parallelphase der ISO-20022-Versionen, und die strukturierte Adresse wird Pflicht. Im Sommer 2026 haben Swift und das EPC ihren eigenen Novembertermin für Adressen ausgesetzt, die Schweiz hält an ihrem fest. Stand 28.10.2026 sagen die Quellen:

Der Aufschub von Swift betrifft den Zahlungsverkehr über das Swift-Netz, nicht die Schweizer Regeln. Laut SIX bleiben die Richtlinien ab dem 14.11.2026 unverändert in Kraft. Der SIC-Release vom 13.11.2026 kommt mit angepasstem Umfang: SIC verzichtet auf die Prüfung der Adressen, damit Weiterleitungen ins und aus dem Swift-Netz nicht hängen bleiben. Darum können weiterhin Zahlungen mit unstrukturierten Adressen eintreffen. Für deine eigene Datei gilt der neue Aufbau trotzdem.

Wie kommt die Zahlung zurück in die Buchhaltung?

Die Zahlung kommt als Belastung auf dem Kontoauszug zurück, und diese Zeile schliesst die Rechnungen. TILL sucht für eine Belastung den passenden Lauf auf zwei Wegen: über die EndToEndId einer einzelnen Zahlung oder über die PmtInfId des ganzen Laufs, dann mit der Summe des Laufs. Welchen Weg deine Bank nimmt, hängt von BtchBookg und von ihrer Auszugseinstellung ab, TILL nimmt beide.

Stimmen Referenz und Betrag, schlägt die Bank-Inbox den Lauf mit «sicher» vor. Buchst du die Zeile, markiert TILL den Lauf als bezahlt: eine Zahlung pro Rechnung, Soll 2000 Kreditoren, Haben das Bankkonto, am Buchungsdatum der Zeile. Ist die Zeile weder die Summe des Laufs noch eine seiner Zahlungen, lehnt TILL mit amount_mismatch ab, statt zu raten.

Einen Lauf ohne Bankzeile als bezahlt markieren geht auch, mit mark_batch_paid und confirmation: true, weil diese Bestätigung eine Tatsache über die Bank behauptet. Ein zweites Mal geht es nicht: Ein bezahlter Lauf lehnt jede weitere Bestätigung ab.

Was kann die pain.001 von TILL nicht?

Die pain.001 von TILL ist für Zahlungen an Lieferanten gedacht, mehr nicht. Was sie heute nicht kann:

• Sie geht nicht selbst zur Bank. In der öffentlichen Beta lädt TILL nichts hoch, unterschreibt nichts und gibt nichts frei. Du lädst die Datei im E-Banking hoch und gibst sie dort frei. Eine Statusmeldung pain.002 der Bank liest TILL in der öffentlichen Beta nicht: Eine abgewiesene Datei siehst du bei deiner Bank.
• Sie trägt noch keine Adresse des Empfängers, nur Name und IBAN. SIX schreibt die strukturierte oder hybride Adresse ab November 2026 für alle Parteien vor und verlangt von der Software, dass sie die Adresse des Empfängers mitgibt; als Element führen die Richtlinien sie optional, unvollständige Adressen können abgewiesen werden. Frag deine Bank, ob sie eine Inlandzahlung ohne Empfängeradresse ab dem 14.11.2026 ausführt, bevor du dich darauf verlässt.
• Nur CHF und EUR, eine Währung pro Lauf. Gedacht für Empfänger mit Schweizer oder Liechtensteiner IBAN (Zahlungsart D). Eine ausländische IBAN lehnt TILL heute nicht ab, die Zahlung ist dann aber keine Inlandzahlung mehr und trägt keine Empfängerbank. Keine SEPA-Zahlungen, keine Fremdwährungen, keine Instant Payments, keine Löhne.
• Eine Rechnung an eine QR-IBAN ohne gültige QR-Referenz lehnt TILL ab (needs_qrr_reference), statt eine Referenz zu erfinden. Dasselbe gilt für einen Lieferanten ohne Namen oder ohne IBAN.
• Die volle Prüfung gegen pain.001.001.09.ch.03.xsd läuft in der Testsuite von TILL, nicht bei jedem Erzeugen. Beim Erzeugen prüft TILL die eigene Datei auf Summen, Anzahl, Referenzlängen, IBANs, Prüfziffern und die Regel QR-IBAN mit QR-Referenz.

TILL ist eine öffentliche Beta und quelloffen unter MIT. Wie ein Agent über MCP bucht, ohne doppelt zu zählen, zeigt MCP trifft Hauptbuch, und was ein Agent in TILL darf, steht auf der Seite Agenten.

Checkliste: Ist deine Zahlungsdatei bereit für den 14. November 2026?

Diese Fragen gelten für jede Software, die pain.001 schreibt. Geh sie vor dem 14.11.2026 mit einer echten Datei durch:

1. Steht im Namespace der Datei pain.001.001.09?
2. Hat jeder Empfänger einen Namen und, wenn eine Adresse dasteht, Ort (TwnNm) und Land (Ctry) in eigenen Feldern?
3. Hat deine Software die Adresse jedes Empfängers, und schreibt sie diese in die Datei?
4. Stehen Strasse, Hausnummer und Postleitzahl in ihren Feldern statt zusammen in einer Zeile (empfohlen)?
5. Ist die MsgId bei jeder Datei neu, auch über 90 Tage?
6. Ergibt CtrlSum die Summe der Beträge und NbOfTxs die Anzahl der Zahlungen?
7. Geht eine QR-IBAN nur mit einer QR-Referenz raus, und ist freier Text höchstens 140 Zeichen lang?
8. Hast du die Datei gegen pain.001.001.09.ch.03.xsd geprüft, bevor du sie hochlädst?
9. Hast du alte Vorlagen im E-Banking ersetzt und deine Daueraufträge nach der Anleitung deiner Bank geprüft?
10. Nimmt deine Bank die hybride Adresse an, und führt sie eine Inlandzahlung ohne Empfängeradresse aus?