Die meisten polnischen KMU behandeln den Kontoauszug wie eine Postkarte aus den 90ern: Datei im Online-Banking herunterladen, im ERP auf „Importieren" klicken, dann ordnet die Buchhalterin die Zahlungen den Rechnungen von Hand zu. Dabei stellt seit 2019 jede größere polnische Bank eine API zur Verfügung, die das für dich erledigt — man muss sie nur anbinden.
Wir machen diese Integrationen regelmäßig, und das Muster wiederholt sich. Ein Unternehmen hat drei Konten bei zwei Banken, zwei Währungen, ein ERP (meistens Comarch Optima oder enova365) und eine Person in der Buchhaltung, die jeden Montagmorgen zwei Stunden mit dem Import und der Zuordnung von Kontoauszügen verbringt. Jede Woche, das ganze Jahr. Das sind hunderte Stunden Arbeit, die niemand machen würde, wenn er die Wahl hätte.
Bei einem unserer Kunden — einem 25-Personen-Großhandel für Autoteile — verlor die Buchhalterin 8 Stunden pro Woche mit dem manuellen Import von Kontoauszügen aus drei Banken (mBank, Santander, ING) in Comarch Optima und mit dem Abgleich mit Verkaufsrechnungen. Nach der API-Integration plus regelbasiertem Matching nach Verwendungszweck und Beträgen: 30 Minuten pro Woche, um Ausnahmen manuell zu prüfen. Den Rest erledigt das System selbst, nachts. Amortisation — knapp vier Monate.
Was manuelle Auszugsbearbeitung wirklich kostet
Es ist leicht, das Ausmaß zu unterschätzen. „Fünfzehn Minuten am Tag" klingt nach nichts. Rechne anders — auf ein Jahr.
Ein typischer Großhändler mit zwei PLN-Konten und einem Fremdwährungskonto verzeichnet 50–80 Transaktionen pro Tag. Die Buchhalterin öffnet das Banking, lädt MT940 oder CSV herunter, geht ins ERP, klickt „Importieren", wählt die Datei, wartet, prüft, was geladen wurde, ordnet Zahlungen den Rechnungen zu — meist nach Betrag und einem Fragment des Kundennamens. Manchmal muss sie das von Hand korrigieren, weil die Bank den Geschäftspartner in einem anderen Format geschrieben hat als die Stammdaten. Fünf bis zehn Stunden Arbeit pro Woche in einer guten Woche. In einer schlechten — doppelt so viel, weil herauszufinden ist, warum ein Kunde 4.873 PLN statt 4.873,15 PLN gezahlt hat.
Dazu kommen die Kosten der Verzögerung. Der Vertrieb sieht im ERP nicht, ob eine Rechnung bezahlt wurde, und ruft die Buchhaltung an. Kunden bekommen Mahnungen, obwohl sie am Freitagnachmittag gezahlt haben — weil der Auszug „am Montag verbucht wird". Kleinigkeiten, aber zusammen kosten sie Glaubwürdigkeit und Zeit.
Was eine polnische Bank heute kann — und was dein ERP
Das polnische Banking ist hier überraschend gut aufgestellt. Alle Banken, die Geschäftskunden bedienen — mBank, ING, Santander, Pekao, PKO BP, Millennium, Alior, BNP Paribas — bieten eine PSD2-konforme API (AIS), mit der man Salden und Auszüge programmatisch abrufen kann. Einige Banken bieten zusätzlich Buchhaltungs-APIs mit reicheren Daten (mBank CompanyNet API, ING Business API, Santander mojeID Business).
Auf der anderen Seite — dein ERP. Die Lage hängt vom System ab:
- Comarch Optima hat ein eingebautes Modul „Comarch ERP Optima Virtuelles Konto" und Comarch-Bank-Connect-Integrationen für ausgewählte Banken. Funktioniert, aber nicht jede Bank ist out of the box dabei.
- enova365 hat ein Modul „Bank-Desktop" und unterstützt elektronisches Banking nach Webservice-/Multicash-Standards.
- Subiekt GT/nexo liest MT940 und CSV, hat aber keine native API-Integration — es braucht einen Mittler.
- Microsoft Dynamics 365 BC / NAV — hat Bank-Konnektoren, für polnische Banken braucht es aber oft eine dedizierte Lösung.
In der Praxis: Selbst wenn dein ERP „keine Integration mit Bank X hat", lässt sich das meistens mit einer Middleware lösen — einem kleinen Dienst, der die API der Bank mit der API des ERP verbindet. Buchstäblich einige hundert Zeilen Code in .NET oder Python. Kein halbjähriges Projekt.
Zahlungsmatching — hier steckt die eigentliche Arbeit
Auszüge abzurufen ist 20 % des Problems. Der Rest ist die Zuordnung von Zahlung zu Rechnung. Klingt einfach: es gibt einen Betrag, einen Verwendungszweck, einen Geschäftspartner. In der Realität — kommt drauf an.
Typische Knackpunkte:
- Der Kunde bezahlt zwei Rechnungen mit einer Überweisung (Verwendungszweck „RG 123, 124").
- Der Kunde bezahlt einen reduzierten Betrag wegen einer Reklamation, die er nie über das System gemeldet hat.
- Im Verwendungszweck steht „Zahlung für Rechnung 12/06/2025" — ist das eine Nummer oder ein Datum?
- Die Zahlung kommt von einem Privatkonto (Ehepartner, externer Buchhalter), nicht vom Firmenkonto aus den Stammdaten.
- Der Kunde bezahlt eine Rechnung aus dem Vorjahr, nachdem seine Steuernummer geändert wurde.
In der Praxis stützt sich vernünftiges Matching auf abgestufte Regeln: zuerst die perfekte Übereinstimmung suchen (Rechnungsnummer im Verwendungszweck + Betrag passt), dann Fuzzy-Matching (Nummer da, Betrag weicht um weniger als 1 PLN ab — vermutlich Rundung), dann Zuordnung nur nach Nummer, dann manuelle Prüfung des Rests. Ein gut konfiguriertes System fängt 85–95 % der Zahlungen automatisch ab. Den Rest macht ein Mensch — und das ist gut so, denn das sind genau die Fälle, in denen man denken muss.
Rollout-Plan in 4 Schritten
So sieht so ein Projekt typischerweise bei einem 20–50-Personen-Kunden aus. Realistisch 6–8 Wochen von der Entscheidung bis zur Produktion.
- Woche 1–2: Audit und Entscheidungen. Liste der Bankkonten, Währungen, typischen Zahlungsszenarien, des ERP und seiner Version. Entscheidung: ERP-native Integration oder Middleware. Auswahl der Bank, mit der wir starten (am besten die mit dem größten Verkehr — du siehst den Nutzen am schnellsten).
- Woche 3–4: Bank-API-Zugang und Sandbox. Hier liegen die meisten Formalitäten — Banken verlangen Verträge, eIDAS-Zertifikate für PSD2, manchmal einen Filialbesuch. Lohnt sich, sofort parallel zur Entwicklung zu starten.
- Woche 5–6: Umsetzung und Tests. Verbindung der Bank-API mit dem ERP, Konfiguration der Matching-Regeln, Anbindung der Geschäftspartner-Stammdaten. Hier kommen die spannendsten Entdeckungen — z. B. dass 200 Kunden in den Stammdaten eine Steuernummer mit Leerzeichen haben und 80 gar keine.
- Woche 7–8: Parallelbetrieb und Übernahme. Zwei Wochen lang läuft der manuelle Import weiter, daneben die Integration. Täglich vergleichst du die Ergebnisse. Nach zwei Wochen, wenn alles stimmt, schaltest du den manuellen Import ab.
Häufigste Fehler
Drei Dinge, die meistens am meisten weh tun:
- Kein Monitoring der Integration. Wenn die Middleware nachts um 3 Uhr ausfällt, weiß niemand davon bis Montagmorgen. Ein einfaches Alerting (E-Mail/Slack) für Authentifizierungsfehler in der Bank und für ausbleibende Auszüge über 24 Stunden ist Pflicht.
- Schmutzige Stammdaten. Zurück zu unserem Lieblingsthema — ohne saubere Daten ist jede Integration nur ein lauteres Chaos. Es lohnt sich, vorher Steuernummern, Namen und Bankkontonummern in den Stammdaten aufzuräumen.
- Zu aggressives Auto-Matching. Die Versuchung, „alles automatisch zu verbuchen", ist groß. Verwechselt das System aber zwei Kunden mit ähnlichen Namen, kostet das Auseinanderdröseln mehr Zeit, als die Automatisierung gespart hat. Lieber die Zweifelsfälle der manuellen Prüfung überlassen.
Wie geht es weiter
Bank-ERP-Integration ist eines jener Projekte, bei denen sich der ROI leicht rechnen und zeigen lässt. Eine Stunde Buchhalterzeit kostet einige Dutzend Zloty, und du holst typischerweise 5–10 Stunden pro Woche zurück. Aufs Jahr gerechnet sind das mehrere zehntausend Zloty weniger Kosten und — wichtiger — eine Buchhalterin, die Zeit für die Dinge hat, die wirklich einen Menschen brauchen.
Wenn du dich fragst, ob ein solches Projekt in deinem ERP-und-Banken-Setup Sinn ergibt, findest du das am schnellsten in einem halbstündigen Gespräch heraus. Keine Slides, kein Pitch — die Fragen, die zu beantworten sind, sind absehbar.
Du brauchst kein Data Warehouse, um aufzuhören, Kontoauszüge aus dem Online-Banking ins ERP abzutippen. Du brauchst eine API und einige Dutzend Stunden Arbeit.