Zum Inhalt springen
XSIS

Enterprises & Integrations

Zahlungsdateien und Abstimmung zwischen ERP und Bank

ERP zur Bank: Zahlungsdateien hinaus, Auszüge zurück, abgestimmt

Zahlungen als ISO 20022 pain.001 über Host-to-Host-SFTP oder Bank-APIs gesendet, mit camt.053- und MT940-Auszügen, die dem Hauptbuch zugeordnet werden.

Blueprint

ERP zur Bank: Zahlungen hinaus, Kontoauszüge hereinFreigegebene Zahlungen verlassen das ERP als signierte ISO-20022-Dateien über einen host-to-host-Kanal. Statusberichte und Kontoauszüge kommen denselben Weg zurück und werden offenen Posten zugeordnet. Ablehnungen und nicht zugeordnete Zeilen gehen mit dem Grund an Ihr Team.ERPERPZahlungsläufe, offenePosten, HauptbuchXSISIntegrationsschichtMapping, Validierung,Signierung undZeitsteuerungGatewaySicherer Bankkanalhost-to-host SFTP,EBICS oder Bank-APIBankBankZahlungen und CashManagementDienstAbstimmungs-EngineZuordnungsregeln undToleranzenMenschenTreasury- undFinanzteamPrüft Ablehnungen undDifferenzen1REST/JSON · IDoc2ISO 20022 pain.001OpenPGP3SFTP H2H4pain.002 · camt.053MT9405SFTP H2H6camt.0537REST/JSON8pain.002 RJCT910

ERP zur Bank: Zahlungen hinaus, Kontoauszüge herein

Freigegebene Zahlungen verlassen das ERP als signierte ISO-20022-Dateien über einen host-to-host-Kanal. Statusberichte und Kontoauszüge kommen denselben Weg zurück und werden offenen Posten zugeordnet. Ablehnungen und nicht zugeordnete Zeilen gehen mit dem Grund an Ihr Team.

  • Primärer Ablauf
  • Asynchron
  • Fehlerpfad
Der Ablauf in 10 Schritten

Der Ablauf Schritt für Schritt

  1. Von ERP nach Integrationsschicht: Freigegebener Zahlungslauf, über REST/JSON · IDoc (primärer Ablauf).
  2. Von Integrationsschicht nach Sicherer Bankkanal: Signierte und verschlüsselte Zahlungsdatei, über ISO 20022 pain.001 · OpenPGP (primärer Ablauf).
  3. Von Sicherer Bankkanal nach Bank: An die Bank übermittelt, über SFTP H2H (primärer Ablauf).
  4. Von Bank nach Sicherer Bankkanal: Statusberichte und Kontoauszüge, über pain.002 · camt.053 · MT940 (asynchron).
  5. Von Sicherer Bankkanal nach Integrationsschicht: Abgeholt und validiert, über SFTP H2H (asynchron).
  6. Von Integrationsschicht nach Abstimmungs-Engine: Kontoauszugszeilen, über camt.053 (asynchron).
  7. Von Abstimmungs-Engine nach ERP: Zugeordnete Buchungen verbucht, über REST/JSON (primärer Ablauf).
  8. Von Integrationsschicht nach Treasury- und Finanzteam: Abgelehnte Zahlungen mit Grundcode, über pain.002 RJCT (Fehlerpfad).
  9. Von Abstimmungs-Engine nach Treasury- und Finanzteam: Nicht zugeordnete Zeilen: eine Abstimmungsdifferenz (Fehlerpfad).
  10. Von Treasury- und Finanzteam nach ERP: Korrigiert und erneut übermittelt (Fehlerpfad).

Überblick

Das ist der Fluss zwischen einem ERP und seinen Banken: freigegebene Zahlungen gehen hinaus, Statusberichte und Auszüge kommen zurück. Es ist die Verbindung, die die meisten Finanzteams noch von Hand über Bankportale und Tabellen betreiben, und die, bei der ein Fehler Geld kostet.

Das Referenzdesign setzt eine Integrationsschicht zwischen das ERP und jede Bank. Die Schicht bildet Zahlungen auf die Variante der Bank von ISO 20022 pain.001 ab, signiert und verschlüsselt sie und liefert sie über Host-to-Host-SFTP, EBICS oder die API der Bank. Statusberichte und Auszüge kehren denselben Weg zurück und werden offenen Posten im ERP zugeordnet.

Der Fehlerpfad ist so sorgfältig gestaltet wie der Normalfall. Eine abgelehnte Zahlung kommt mit dem Grundcode der Bank zurück. Eine Auszugszeile, die nicht passt, wird zu einer Abstimmungsdifferenz, die eine benannte Person klärt. Nichts geht verloren, nichts wird doppelt gebucht.

So funktioniert der Ablauf

  1. Zahlungslauf freigeben

    Ihr ERP erzeugt den Zahlungslauf, und Ihre Genehmiger geben ihn frei, wie heute. Die Integrationsschicht übernimmt nur freigegebene Läufe.

  2. Abbilden, signieren, verschlüsseln

    Die Schicht bildet jede Zahlung auf die pain.001-Variante der Bank ab, validiert sie und signiert und verschlüsselt die Datei, wie die Bank es verlangt.

  3. An die Bank liefern

    Die Datei geht über den vereinbarten Kanal, Host-to-Host-SFTP, EBICS oder die API der Bank, vor der Cut-off-Zeit der Bank hinaus.

  4. Status und Auszüge empfangen

    Die Bank sendet pain.002-Statusberichte für jede Datei und Zahlung zurück sowie camt.053- oder MT940-Auszüge am Tagesende.

  5. Einsammeln und prüfen

    Die Schicht sammelt jeden Bericht ein, prüft ihn gegen die Auszugssequenz auf Lücken und Duplikate und liest ihn in Zeilen ein.

  6. Zuordnen und buchen

    Auszugszeilen werden mit den von Ihnen freigegebenen Regeln offenen Posten zugeordnet, und zugeordnete Einträge werden ins ERP gebucht.

Wenn etwas fehlschlägt

  • Eine Zahlung wird abgelehnt

    Der pain.002-Bericht enthält den Grundcode der Bank. Die Zahlung wird im ERP als abgelehnt markiert und an Ihr Treasury-Team zur Korrektur und erneuten Einreichung geschickt.

  • Eine Auszugszeile passt nicht

    Die Zeile wird zu einer Abstimmungsdifferenz mit den wahrscheinlichsten Kandidaten und dem Grund des Fehlschlags. Ihr Team klärt sie, und die Regeln können daraus lernen.

  • Eine Datei fehlt oder ist verspätet

    Auszugssequenznummern und erwartete Lieferzeiten werden geprüft. Eine fehlende oder verspätete Datei löst eine Warnung aus, bevor jemand sich auf die Liquiditätslage verlässt.

  • Ein Schlüssel oder Zertifikat läuft bald ab

    Signaturschlüssel und Kanäle-Zertifikate werden mit ihrem Ablaufdatum verfolgt, und die Erneuerung beginnt früh genug, um den neuen Schlüssel mit der Bank zu vereinbaren.

Standards und Systeme

Banking-Standards und -Kanäle
  • ISO 20022
  • pain.001
  • pain.002
  • camt.052
  • camt.053
  • camt.054
  • MT940
  • MT942
  • SFTP (H2H)
  • EBICS
  • Swift
  • OpenPGP

Fragen und Antworten

Host-to-Host, EBICS oder Bank-APIs: Was sollten wir nutzen?

Meist entscheidet die Bank. Host-to-Host-SFTP ist der am weitesten verbreitete Kanal für Firmenzahlungsdateien. EBICS ist bei Banken in Deutschland, Frankreich und den Nachbarländern verbreitet. Bank-APIs eignen sich für Echtzeit-Salden und Instant Payments, wo die Bank sie anbietet. Viele Unternehmen nutzen mehr als einen, und die Integrationsschicht verbirgt den Unterschied vor dem ERP.

Sollten wir camt.053- oder MT940-Auszüge empfangen?

Wo die Bank beides anbietet, enthält camt.053 reichere, strukturierte Verwendungszweckdaten, was die automatische Zuordnung verlässlicher macht. MT940 ist noch weit verbreitet und funktioniert für viele Fälle gut. Wir können beides annehmen, in dasselbe interne Modell überführen und jede Bank von MT940 auf camt.053 umstellen, wenn es für Sie und die Bank passt.

Sehen wir unsere Liquiditätslage tagsüber?

Ja, wenn Ihre Banken untertägige Berichte liefern. Sie kommen als camt.052- oder MT942-Nachrichten oder über eine Salden-API. Wir sammeln sie im Rhythmus, den jede Bank unterstützt, und zeigen sie neben den Tagesendauszügen, sodass Ihr Treasury-Team erwartete und tatsächliche Positionen vor den Cut-off-Zeiten sieht.

Können wir nachvollziehen, wer eine Zahlung freigegeben und gesendet hat?

Ja. Die Freigabe bleibt mit ihren bestehenden Kontrollen in Ihrem ERP. Die Integrationsschicht protokolliert jede Datei, die sie erstellt, signiert, sendet und empfängt, mit Zeitstempeln, Kennungen und dem verwendeten technischen Konto. Dieses Protokoll verbindet jede Zahlung im Statusbericht der Bank zurück zum ERP-Beleg und seinen Genehmigern.

Wir haben mehrere Banken. Ist jede ein eigenes Projekt?

Nein. Die Integrationsschicht, das interne Zahlungsmodell und die Zuordnungsregeln werden einmal gebaut. Jede neue Bank bringt ihre eigene Formatvariante, ihren Kanal und ihre Onboarding-Schritte mit, was kleinere Arbeitspakete sind. Wir binden meist zuerst die Bank mit dem größten Volumen an und ergänzen die anderen der Reihe nach.

Wie wird die Verbindung vor dem Go-live getestet?

Jede Bank stellt eine Testumgebung oder einen Testprozess bereit. Wir vereinbaren mit der Bank Testfälle für jede Zahlungsart, Ablehnungen und Auszüge, führen sie aus und bewahren die Nachweise auf. Wenn die Bank abnimmt, gehen wir mit einem kleinen ersten Zahlungslauf live und vergleichen die Ergebnisse, bevor wir den Rest umstellen.

Beginnen Sie mit einem Gespräch, nicht mit einem Vertrag.

Sagen Sie uns, was Sie bauen, verbinden oder absichern möchten. Ein Architekt geht es mit Ihnen durch und empfiehlt dann, wo Sie beginnen sollten.

Wie es weitergeht

  1. Terminabstimmung

    Unser Team schreibt Ihnen, um einen Termin für das Gespräch zu vereinbaren.

  2. Beratungsvorgespräch

    Ein kostenlose 30-minütige Online-Vorberatung: Wir gehen Ihre Ziele, Systeme und Rahmenbedingungen durch.

  3. Readiness-Review

    In einer kostenlose 48-stündige Readiness-Review prüft ein Principal Architect Ihr Projekt gegen die 6-Punkte-Definition of Ready und empfiehlt den passenden Track.

  4. Wahl des Tracks

    Projekte mit klarem Leistungsumfang erhalten innerhalb von 3–5 Werktagen ein verbindliches Angebot. Projekte in der Konzeptphase starten im Blueprint Studio. Ein laufendes System, das ausfällt, nicht dokumentiert ist oder integriert werden muss, beginnt mit einer Diagnose von 1–2 Wochen. Blueprint Studio und Diagnose haben jeweils ein festes Honorar, das im Angebot genannt wird.