Solange der Kunde per Überweisung zahlt, ist die Abstimmung einfach: eine Zahlung, eine Rechnungsnummer im Betreff, die Buchhaltung bucht das in fünf Sekunden im ERP. Sobald Przelewy24, PayU oder Stripe dazukommen — passt plötzlich nichts mehr zusammen. Das ist nicht die Schuld des Systems; es ist ein anderes Datenmodell.
Wir sehen das bei Kunden regelmäßig. Das Unternehmen eröffnet einen Onlineshop oder ein B2B-Portal, schaltet drei beliebte Zahlungsanbieter frei, hat innerhalb einer Woche Bestellungen. Nach einem Monat kommt die Buchhaltung mit einer Frage: warum sind auf dem Bankkonto 48 Sammelzahlungen und im ERP 312 Bestellungen, und wie bringen wir das jetzt zusammen. Die Antwort steckt weder im ERP noch beim Anbieter — sie steckt darin, dass niemand die Zwischenebene entworfen hat, die beides verbindet.
Ein Online-Zahlungsanbieter ist kein weiteres Bankkonto. Es ist ein eigenständiges System mit eigener Logik, eigenen Gebühren und eigenem Auszahlungsrhythmus. Wenn du ihn wie „noch ein Konto zum Importieren in Optima" behandelst, hast du nach drei Monaten 40–60 Tausend PLN in einer Zeile „zu klären".
Warum es auseinanderfällt
Im klassischen Modell zahlt der Kunde 1.230,00 PLN auf dein Konto, schreibt im Betreff FV/2026/0421, die Buchhaltung importiert den MT940-Auszug in Comarch Optima und der Abgleich geschieht automatisch. Eins zu eins. Das Problem bei Zahlungsanbietern ist, dass dieses Modell gleichzeitig auf drei Ebenen bricht.
Ebene eins — Auszahlung netto, nicht brutto. Der Kunde zahlt 1.230,00 PLN per Karte über Stripe. Auf deinem Konto landen 1.190,65 PLN, weil Stripe 3,2% Gebühr einbehalten hat. Das ERP sieht, dass die Rechnung über 1.230,00 lief — und der Abgleich funktioniert nicht, weil die Beträge nicht übereinstimmen. Legst du eine Regel „Differenzen bis 5% ignorieren" an, verlierst du den Überblick beim ersten Chargeback, der ebenfalls als „Differenz bis 5%" hereinkommt.
Ebene zwei — Sammelauszahlung, nicht pro Transaktion. PayU und Przelewy24 zahlen im Standard-KMU-Tarif einmal am Tag oder alle zwei Tage gesammelt aus. Du bekommst 12.437,22 PLN überwiesen, die 54 Transaktionen aus zwei Tagen entsprechen, abzüglich Gebühren, abzüglich einer Rückerstattung und eines Chargebacks. Im Betreff steht „PayU-Abrechnung 2026-10-24". Null Rechnungsnummern. Zerlege das von Hand.
Ebene drei — Fremdwährungen und grenzüberschreitend. Stripe zahlt dir in EUR oder USD aus, wenn du internationale Karten akzeptierst. Das ERP ist in PLN. Die Umrechnung passiert bei der Bank zum Kurs im Moment der Auszahlung, nicht im Moment der Bestellung. Die Kursdifferenz ist eine eigene Zeile in der GuV — das ERP berechnet das nicht selbst, weil es nicht weiß, welcher Kurs „erwartet" war.
Jede dieser Ebenen lässt sich einzeln in einer Tabelle manuell handhaben. Drei gleichzeitig, bei 300 Bestellungen im Monat, nicht mehr. Da brauchst du eine Integration.
Die drei Bausteine, die zusammenpassen müssen
Eine gut gebaute Anbieter–ERP-Integration besteht aus drei getrennten Mechanismen — kein Skript, das „alles synchronisiert". Ein Mechanismus = eine Verantwortung.
- Webhook zum Zahlungsstatus. Der Anbieter ruft deinen Endpunkt in dem Moment, in dem eine Zahlung erfolgreich war, fehlschlug, erstattet wurde oder zu einem Chargeback geführt hat. Das ist das Signal „auf dieser konkreten Transaktion hat sich etwas geändert" — und es soll genau eine Bestellung im ERP aktualisieren, nicht eine ganze Sammelauszahlung. Der Webhook muss idempotent sein: der Anbieter kann dasselbe Event dreimal senden, wenn er kurzzeitig kein 200 bekommt. Dreimal heißt nicht dreimal buchen — heißt einmal buchen, dann Duplikate ignorieren.
- Täglicher Anbieter-Report. Przelewy24, PayU, Stripe und tpay bieten alle entweder eine API oder einen CSV mit einer detaillierten Abrechnung — eine Zeile pro Transaktion, mit Gebühr, Vorsteuer auf die Gebühr, Rückerstattung, Chargeback. Dieser Report ist deine Quelle der Wahrheit für die Buchung aller Anbieterkosten. Er ist flach und hässlich, aber vollständig.
- Abgleich: Bankauszug gegen Anbieter-Report, nicht gegen Bestellungen. Das ist der eigentliche Kniff. Das ERP soll nicht versuchen, 12.437,22 PLN mit 54 Bestellungen gleichzeitig abzugleichen. Es soll 12.437,22 PLN gegen den Anbieter-Report vom 2026-10-24 abgleichen — und der Anbieter-Report weiß separat schon, welche Bestellungen darin steckten, weil er sie per Webhook gesehen hat. Drei Stufen, drei getrennte Abstimmungen, jede mit einem Kriterium.
Wenn du diese drei Mechanismen getrennt baust, sprengt ein Chargeback von Przelewy24, der zwei Wochen nach der Transaktion kommt, nicht mehr den Monatsabschluss — weil du weißt, auf welche Transaktion er sich bezieht und wie du ihn im ERP spiegelst.
Ein konkretes Beispiel aus der Praxis
Bei einem unserer Kunden — einem 28-Personen-Onlineshop für Haus- und Gartenmöbel — waren die Zahlungsanbieter von Anfang an angebunden: Przelewy24 als Hauptanbieter, PayU für 0%-Raten, Stripe für internationale Kunden. Comarch Optima als ERP, WooCommerce als Shop, Shop–ERP-Integration per API. Monatliches Volumen 450–600 Bestellungen, Umsatz ca. 480 Tausend PLN brutto.
Vor dem Umbau sah die Abrechnung so aus: einmal pro Woche importierte die Buchhaltung den Kontoauszug in Optima, schaute sich die Sammelzahlungen der Anbieter an und ordnete sie manuell den Bestellungen zu, indem sie parallel die Panels von Przelewy24 und PayU durchsah. Gebühren wurden pauschal auf Basis einer monatlichen Belastungsnote verbucht, die die Anbieter einmal pro Monat schickten. Rückerstattungen und Chargebacks tauchten zufällig auf — mal als Minus auf einer Sammelzahlung, mal als eigene Rückbuchung. Die Zeile „zu klären" in der Übersicht hatte immer 15–25 Positionen, insgesamt 20–35 Tausend PLN pro Monat.
Das Problem verschärfte sich am Quartalsende, weil ungeklärte Positionen sich anstauten. Im März und Juni 2026 war zwei Tage vor Quartalsschluss eine „Anbieter-Inventur" nötig — der Finanzleiter verbrachte vier bis sechs Stunden mit der Buchhalterin, um nicht zugeordnete Transaktionen zusammenzubringen. Alle zwei Quartale landeten 20–30 Tausend PLN auf einem Konto für Kursdifferenzen und Gebühren, weil niemand sie mehr konkreten Bestellungen zuordnen konnte.
Der Umbau dauerte sechs Wochen und blieb im Budget von 32 Tausend PLN. Wir haben eine kleine Middleware aufgesetzt (eine kleine .NET-Anwendung auf ihrem Server), die Webhooks von allen drei Anbietern empfängt, den Zustand jeder Transaktion in einer Datenbank speichert, täglich die Abrechnungsberichte per API zieht und Optima drei getrennte Buchungsdokumente zuführt: eine Verkaufsrechnung (Bestellung), eine Belastungsnote für die Gebühr (Aufwand) und ein KASSEN-Dokument für die Sammelauszahlung, das 1:1 mit dem Kontoauszug abgeglichen wird. Rückerstattungen und Chargebacks werden als Korrekturen gespiegelt und an die Ursprungstransaktion gehängt.
Nach drei Monaten fiel die Zeile „zu klären" von 20–35 Tausend auf 0,5–1,5 Tausend PLN pro Monat — hauptsächlich durch EUR–PLN-Rundungen bei Stripe. Das Quartalsende verlangte keine „Anbieter-Inventur" mehr. Die Buchhalterin bekam ca. 6–8 Stunden pro Woche zurück, die vorher ins manuelle Zuordnen flossen. Der Finanzleiter wusste zum ersten Mal, was Online-Zahlungen wirklich kosten — es waren 3,8% vom Umsatz, also ca. 18 Tausend PLN pro Monat, überwiegend bei PayU 0%-Raten, deren Gebühr auf den Shop durchgereicht wird.
Drei Fallen, die wir am häufigsten sehen
Es gibt drei Muster, an denen Anbieter–ERP-Integrationen nach einem halben Jahr auseinanderbrechen. Jede davon ist leicht zu umgehen, wenn man sie vorher kennt.
- „Bestellung = Rechnung = Zahlung", ohne Gedächtnis an die Gebühr. Das Unternehmen bucht im ERP nur die Verkaufsrechnung und die Zahlung in Höhe des Nettobetrags nach Gebühr, denn „der Rest ist die Anbietergebühr". Das funktioniert — bis zur ersten Steuerprüfung, die fragt, warum die Vorsteuer auf diese 3,2% Gebühr nirgends auftaucht. Die Anbietergebühr ist ein eigener Aufwand, eine eigene Rechnung (der Anbieter muss sie dir ausstellen), eine eigene USt-Buchung. Das ERP muss beide Seiten sehen.
- Webhook ohne Idempotenz. Manchmal schickt der Anbieter dasselbe Event zweimal — weil die erste Antwort deines Endpunkts zu spät kam und das System sie als verloren einstuft. Prüft deine Middleware nicht, ob diese Transaktion schon verarbeitet wurde, bucht sie zwei Rechnungen für einen Verkauf. Idempotenz = du speicherst die Event-ID in der Datenbank, verarbeitest sie beim zweiten Mal nicht, antwortest mit 200.
- Tests auf „pending" statt auf einem abgeschlossenen Webhook. Manchmal zieht ein Entwickler alle Bestellungen mit Status „pending" aus dem Shop und schiebt sie ins ERP, weil er sie „sofort sichtbar" haben will. Dann bricht der Kunde die Zahlung ab, der Anbieter sendet keinen Webhook, und im ERP bleibt eine Rechnung, die niemand bezahlen wird. Regel: Rechnung im ERP erst nach einem
PAID-Webhook erzeugen, niemals vorher.
Jede dieser Fallen lässt sich mit ein paar Zeilen Middleware-Code lösen — vorausgesetzt, du antizipierst sie vor dem Start und nicht nach dem ersten Quartalsabschluss.
Was du in diesem Monat tun kannst
Wenn du über 100 Tausend PLN monatlich über Anbieter abwickelst und keine ERP-Integration hast, zahlst du vermutlich schon jetzt eine Unwissenheitssteuer in Form ungeklärter Positionen und nicht erfasster Gebührenkosten. Fang mit drei Schritten an, die ohne großes Projekt möglich sind.
- Nimm die letzten drei Monate — wie oft musste die Buchhaltung etwas „manuell zuordnen" und wie hoch ist aktuell der Wert der Zeile „zu klären". Wenn es mehr als 1% des Monatsumsatzes ist, rechnet sich die Integration innerhalb eines halben Jahres.
- Prüf im Anbieter-Panel, ob der Webhook überhaupt eingeschaltet ist — und wohin er zeigt. Bei der Hälfte der Kunden, zu denen wir kommen, zeigt der Webhook noch auf die alte Shop-Domain, weil nach einer Migration vor zwei Jahren niemand umgestellt hat.
- Lad aus dem Anbieter-Panel den Abrechnungsreport für einen Monat als CSV herunter. Schau dir die Felder an — Bruttobetrag, Gebühr, USt auf die Gebühr, Status, Bestell-ID. Das sind genau die Daten, die ins ERP gehören, und das ist die minimale Form der Integration.
Nach diesen drei Schritten weißt du, ob das Problem überhaupt existiert und wie groß es ist.
Wie geht es weiter
Online-Zahlungen sind an sich nicht schwer — sie sind schwer, weil sie ein anderes Datenmodell als das Bankwesen haben. Behandelst du den Anbieter wie „noch ein Konto zum Importieren", verlierst du Monat für Monat Zeit und Geld. Baust du eine Zwischenebene, die die Sprache des Anbieters in die Sprache des ERP übersetzt, hört es auf, weh zu tun.
Das ist kein großes Projekt. Für ein kleines Unternehmen zwei bis sechs Wochen Arbeit einer Person plus eine einfache Middleware. Für ein größeres mit mehreren Verkaufskanälen und mehreren Anbietern ein bis drei Monate. Der Rückfluss kommt üblicherweise innerhalb eines halben Jahres — vor allem durch zurückgewonnene Zeit der Buchhaltung und dadurch, dass du nicht länger ein Konto „Differenzen" mit Summen fütterst, die eigentlich Kosten einer konkreten Transaktion wären.
Wenn du möchtest, dass wir uns deine Konfiguration ansehen — Anbieter, Shop, ERP, aktuelle Abrechnungsweise — zeigen wir dir, wo die Löcher sind und in welcher Größenordnung. Das erste Gespräch ist kostenlos und dauert eine halbe Stunde.
Ein Zahlungsanbieter ist kein Kontoauszug. Er ist ein eigenständiges System mit eigener Logik — und wenn das ERP das nicht weiß, zahlt ihr Monat für Monat mit Unwissen, nicht mit Gebühren.