Bankabgleich automatisieren: offene Posten ohne Handarbeit

Montagmorgen, Kontoauszug offen: 4.311,20 € sind eingegangen. Absender: «Müller GmbH & Co. KG». Verwendungszweck: «RG 2026-0847, danke». Deine Buchhaltung beantwortet jetzt drei Fragen: Wer ist das in unserem System? Welche offene Rechnung meint die Zahlung? Und stimmt der Betrag — oder fehlt Skonto? Drei Fragen, ein Posten. Bei 300 Zahlungseingängen im Monat sind das 900 Entscheidungen von Hand.

Was das kostet, rechnen wir auf unserer Seite zur Prozessautomatisierung vor: Die dort zitierte Billentis-Studie setzt 15–40 € Prozesskosten pro manuell bearbeitetem Beleg an. Der Bankabgleich ist ein Teil genau dieser Kette: Zahlungseingang zuordnen, offenen Posten ausbuchen, Differenzen klären. Wer das täglich von Hand macht, bezahlt jeden Monat aufs Neue für dieselbe Fleißarbeit.

Unsere These: Bankabgleich ist eine Datenfrage, keine Fleißfrage. Deine Bank liefert die Umsätze längst als strukturierte Daten. Dein ERP kennt die offenen Posten. Was fehlt, ist die Strecke dazwischen: Umsätze automatisch beziehen, gegen offene Posten matchen, Ausnahmen gezielt zu einem Menschen routen. Genau diese Strecke gehen wir in diesem Artikel entlang — Schritt für Schritt, mit den echten Standards dahinter.

Der Schaden ist dabei größer als die reine Arbeitszeit: Liegt der Abgleich drei Tage zurück, gehen Mahnungen an Kunden raus, die längst bezahlt haben. Und dein Blick auf die Liquidität ist so alt wie der letzte manuell abgehakte Auszug. Beides sind Folgen desselben Problems: Der Abgleich hängt an einer Person statt an einem Prozess.

Vorab: Niemand muss morgens Umsätze aus dem Online-Banking exportieren und als CSV weiterreichen. Für den automatisierten Kontozugriff gibt es etablierte Standards — drei Wege sind für dich relevant. Welcher passt, hängt von Kontenzahl, Bank und Bestandssystem ab. Wir gehen alle drei durch, jeweils mit Quelle und Stand.

EBICS steht für «Electronic Banking Internet Communication Standard»: der internetbasierte Kommunikationsstandard der Deutschen Kreditwirtschaft für die Kommunikation zwischen Kreditinstituten und Firmenkunden. Aktuelle Spezifikation ist Version 3.0.2, gültig seit dem 30.12.2022; die Änderungsrechte an den Spezifikationsdokumenten liegen bei der EBICS-Gesellschaft EBICS SCRL (ebics.de, abgerufen 08.09.2026).

Für den Bankabgleich zählen zwei Eigenschaften. Erstens: EBICS ist multibankfähig — Firmenkunden erreichen mit einer Software jedes Kreditinstitut, das EBICS anbietet (ebics.de, abgerufen 08.09.2026). Zweitens: Kontoauszüge sind ein ausdrücklich genannter Anwendungsfall, neben Überweisungen, Lastschriften und Cash-Management. Hast du Firmenkonten bei mehreren Banken, holst du alle Auszüge über einen verschlüsselten Kanal ab: täglich, automatisch, ohne Login von Hand.

FinTS («Financial Transaction Services») ist die Weiterentwicklung von HBCI, das die Deutsche Kreditwirtschaft erstmals 1996 veröffentlicht hat. Der Standard definiert eine einheitliche, multibankfähige Schnittstelle zwischen Kunde und Bank fürs Online-Banking und wird nach Angaben des Herausgebers von mehr als 2.000 Kreditinstituten unterstützt (fints.org, abgerufen 08.09.2026).

In der Praxis heißt das: FinTS ist der Weg, den viele Buchhaltungsprogramme nutzen — derselbe Zugang wie dein Online-Banking, nur maschinell angesprochen. Für ein einzelnes Geschäftskonto bei einer Bank mit gutem FinTS-Zugang reicht das oft aus. Für tägliche Auszüge über mehrere Firmenkonten hinweg ist EBICS der Firmenkunden-Weg, den die Standards selbst dafür vorsehen.

Der dritte Weg läuft über regulierte Drittdienste: Die PSD2 räumt sogenannten Kontoinformationsdiensten Zugriff auf Online-Zahlungskonten ein — kontoführende Zahlungsdienstleister müssen diesen Zugang und die entsprechenden Informationen unentgeltlich zur Verfügung stellen (die-dk.de, abgerufen 08.09.2026). Seit dem 01.01.2025 gibt es mit giroAPI zudem ein einheitliches Scheme der DK auf Basis der Berlin Group, das Zahlungsverkehr und Kontoinformationen abdeckt (die-dk.de, Pressemitteilung vom 30.01.2025).

Wichtig zur Einordnung: Hier hängt ein regulierter Dienstleister zwischen dir und deiner Bank. Das kann den Einstieg beschleunigen, macht dich aber von dessen Konditionen und Verfügbarkeit abhängig. Wir sprechen bewusst keine Anbieter-Empfehlung aus: Welcher Weg passt, entscheidet sich an deinen Konten und deinem Bestandssystem, nicht am Prospekt.

Egal, über welchen Weg die Umsätze kommen: Entscheidend ist das Format, in dem sie ankommen. Jahrzehntelang war das MT940, ein zeilenbasiertes SWIFT-Textformat. Damit ist Schluss: Seit dem 23.11.2025 sind MT940 und MT942 kein DK-Standard mehr (ebics.de, Format-Lifecycle, abgerufen 08.09.2026).

An ihre Stelle tritt camt: camt.052 und camt.053 nach ISO 20022 sind laut Format-Lifecycle der DK seither der einzige DK-Standard für elektronische Kontoinformationen, definiert in Kapitel 7 der Anlage 3 des DFÜ-Abkommens (aktuell Version 3.9; ebics.de, abgerufen 08.09.2026). camt.053 ist dabei der strukturierte elektronische Kontoauszug: XML mit definiertem Schema statt Textzeilen.

Was das für dein Matching bedeutet: Jede Buchung liegt als eigenes XML-Element vor, mit Betrag, Verwendungszweck und Referenzen in benannten Feldern — dein Parser validiert gegen das Schema, statt Textzeilen zu raten. Für Sammelbuchungen stellt die DK ergänzend camt.054 bereit: die Einzelposten hinter einer Sammelbuchung, ebenfalls strukturiert.

Ein Blick nach vorn gehört dazu: Die Nachfolgeversion der Anlage 3 (Version 26.11) ist bereits veröffentlicht und gilt ab dem 15.11.2026 (ebics.de, Datenformate, abgerufen 08.09.2026). Für dich heißt das: Wer heute einen Bankabgleich baut, baut ihn auf camt — jeder neue MT940-Parser ist eine Investition in ein abgekündigtes Format.

Praktisch läuft es in unseren Projekten so: Du bestellst bei deiner Bank die camt.053-Bereitstellung für deinen EBICS- oder FinTS-Zugang, der Workflow holt die Datei automatisch ab und parst sie gegen das XML-Schema. Ab da rechnet keine Regex mehr auf Textzeilen herum: Jedes Feld hat einen Namen und einen Platz.

Jetzt liegt auf der einen Seite der camt.053-Auszug, auf der anderen die offene-Posten-Liste aus deinem ERP. Das Matching bauen wir als Kaskade: erst die sicheren Regeln, dann die unscharfen, zuletzt der Mensch. Wichtig ist die Reihenfolge — jede Stufe bucht nur, was sie zweifelsfrei erkennt, und reicht den Rest weiter.

Die erste Stufe ist simpel: Steht im Verwendungszweck oder Referenzfeld eine eindeutige Rechnungsnummer und stimmt der Betrag auf den Cent, wird der Posten automatisch ausgeglichen. Kein Ermessen, kein Risiko: Diese Regel darfst du ohne Bauchschmerzen vollautomatisch buchen lassen.

Und hier zahlt die E-Rechnung direkt ein: Eine E-Rechnung nach EN 16931 ist strukturiertes XML — Rechnungsnummer und Referenzen liegen maschinenlesbar vor, auf beiden Seiten der Gleichung. Je mehr deiner Rechnungen strukturiert laufen, desto größer wird die Stufe der exakten Treffer. Wie du den Rechnungseingang automatisierst, zeigt der Schwesterartikel; die Fristen stehen im Beitrag zur E-Rechnungs-Pflicht, die Formate erklärt XRechnung vs. ZUGFeRD.

Ehrlich bleibt der Rest: Ein Kunde überweist drei Rechnungen in einer Summe. Einer zieht 2 % Skonto, obwohl die Frist um zwei Tage gerissen ist. Im Verwendungszweck steht «RG 2026-0874» statt 0847. Solche Fälle löst keine einzelne Regel, sondern eine Kombination: Beträge gegen Teilsummen offener Posten prüfen, Skonto-Toleranzen definieren, Zahlendreher über Ähnlichkeitsvergleich abfangen, Absender-Konten gegen Debitoren-Stammdaten halten.

Bei Sammelbuchungen hilft der Standard selbst: camt.054 liefert die Einzelposten hinter der Sammelgutschrift, strukturiert statt als Ratespiel im Verwendungszweck. Und zur Erwartungshaltung: Seriöse Branchen-Quoten für automatisches Matching gibt es nicht. Unser Erfahrungswert aus Integrationsprojekten: Mit sauberen Stammdaten und Referenzen landet die klare Mehrheit der Umsätze in den automatischen Stufen — den Rest behandelt die nächste Ebene.

Zwei Fälle verdienen eigene Regeln: Teilzahlungen und Überzahlungen. Eine Teilzahlung gleicht den Posten nicht aus, sondern reduziert ihn — das muss dein Abgleich sauber abbilden, sonst stimmt die offene-Posten-Liste nie. Und jede unscharfe Regel bekommt bei uns eine Konfidenz-Schwelle: Unterhalb davon wird nicht gebucht, sondern vorgeschlagen. Der Mensch bestätigt mit einem Klick, statt selbst zu suchen.

Vollautomatik ist das falsche Versprechen: Der Wert eines automatisierten Bankabgleichs entsteht nicht dadurch, dass niemand mehr hinschaut — sondern dadurch, dass Menschen nur noch die Fälle sehen, die Ermessen brauchen. Das Werkzeug dafür ist eine Review-Queue: Jeder Umsatz, den die Kaskade nicht sicher zuordnet, landet als Aufgabe mit Kontext bei deiner Buchhaltung: Umsatz, beste Kandidaten-Posten, Abweichungsgrund.

Ein typisierter Fall, wie wir ihn bauen (kein konkreter Kunde): Ein Großhändler mit rund 300 Zahlungseingängen pro Monat. Ein n8n-Workflow auf seiner eigenen Infrastruktur holt werktäglich den camt.053-Auszug per EBICS ab, führt die Matching-Kaskade aus und schreibt ausgeglichene Posten per API ins ERP zurück. Die Ausnahmen (im eingeschwungenen Zustand eine Handvoll pro Tag, Erfahrungswert) kommen als Liste mit Zuordnungsvorschlägen in die Buchhaltung.

Die Queue ist außerdem dein Lernwerkzeug: Taucht dieselbe Ausnahme dreimal auf (ein Kunde, der grundsätzlich ohne Referenz überweist), wird daraus eine neue Regel mit fester Zuordnung. So sinkt der manuelle Anteil über die Monate weiter, und jede automatische Buchung bleibt über den Workflow-Verlauf nachvollziehbar: Wer will, kann jede Zuordnung bis zum Umsatz im Auszug zurückverfolgen.

Zum Betriebsmodell sind wir eindeutig: n8n steht unter der Sustainable Use License, deshalb setzen wir es auf deiner Infrastruktur auf und betreuen es dort — wir hosten nicht. Deine Kontodaten verlassen dein Haus nicht in Richtung eines Automatisierungs-SaaS. Warum uns das wichtig ist, steht im Artikel zur Workflow-Automatisierung auf EU-Infrastruktur.

Der Bankabgleich ist ein Integrationsprojekt mit klarem Zuschnitt: Kontozugang klären (EBICS, FinTS oder PSD2-Weg), camt.053 als Datenbasis setzen, Matching-Kaskade an deine Debitoren anpassen, Review-Queue und ERP-Rückschreibung bauen. Genau solche Strecken sind unser Kerngeschäft: Wir integrieren um deine Bestandssysteme herum, statt dir neue Buchhaltungs- oder Banking-Software zu verkaufen.

Unsere Erfahrungswerte für den Rahmen: Ein Prozess-Check kostet 1.500 bis 3.000 € und klärt, welche deiner Abgleich-Fälle sich mit welchem Aufwand automatisieren lassen. Ein Pilot liegt bei 3.500 bis 8.000 €, die Umsetzung startet ab 8.000 €, der laufende Betrieb ab 1.500 € pro Monat. Wie wir Automatisierungs-Kandidaten priorisieren und rechnen, steht auf unserer Seite zur Prozessautomatisierung.

Ein sinnvoller Startpunkt ist fast immer der Zahlungseingang: hohes Volumen, klare Regeln, messbarer Effekt ab dem ersten Monat. Von dort wächst die Strecke Richtung Zahlungsausgang und Mahnwesen weiter, in dem Tempo, das deine Buchhaltung mitgeht.

Wenn du wissen willst, wie viel Handarbeit in deinem offene-Posten-Prozess wirklich steckt: Buch dir 30 Minuten mit mir. Bring deine Kontenstruktur und dein ERP mit — dann sagen wir dir ehrlich, ob sich die Strecke für dich rechnet und welcher Weg ans Konto der richtige ist.