Payment-Reconciliation: Zahlungen mit dem ERP abgleichen

Im stationären Handel war der Abgleich einfach: Was in der Kasse lag, wurde verbucht. Im E-Commerce dagegen liegen zwischen Bestellung und Geldeingang mehrere Stationen. Der Kunde bezahlt heute, der Payment-Provider zieht das Geld morgen ein und überweist es übermorgen gesammelt auf das Geschäftskonto -- abzüglich Gebühren, eventuell verrechneter Rückbuchungen und mit einer eigenen Auszahlungsreferenz, die nichts mehr mit der ursprünglichen Bestellnummer zu tun hat.

Hinzu kommt die Vielfalt der Zahlungsarten. Der Rechnungskauf bleibt mit 25,8 Prozent Marktanteil eine der beliebtesten Zahlungsarten im deutschen Online-Handel (bevh, 2025), und im B2B wollen sogar 95 Prozent der Einkäufer auf Rechnung kaufen, während nur 45 Prozent der Händler diese Option anbieten (Mondu, 2025). Rechnungskauf bedeutet aber offene Posten, Teilzahlungen, Mahnstufen und späten Geldeingang -- ein Reconciliation-Szenario, das sich grundlegend von der sofortigen Kartenzahlung unterscheidet.

Der manuelle Abgleich frisst Zeit und ist fehleranfällig. In Projekten sehen wir regelmäßig, dass Buchhaltungsteams mehrere Stunden pro Woche allein mit dem Zuordnen von Sammelauszahlungen verbringen (Projekterfahrung). Jede falsch zugeordnete Zahlung erzeugt einen Differenzbetrag, der später mühsam recherchiert werden muss. Auch die indirekten Prozesskosten der Zahlungsabwicklung fallen ins Gewicht, weil Handling und Abgleich Zeit binden (ibi research, 2025). Genau hier setzt eine automatisierte Schnittstellenlösung an.

Ein belastbarer Abgleich beginnt mit der sauberen Erfassung von drei Datenquellen. Erstens die Payouts der Payment-Provider: Auszahlungsdateien oder API-Reports, die jede Transaktion mit Bruttobetrag, Gebühr, Nettobetrag, Auszahlungsdatum und einer Transaktions-ID auflisten. Zweitens die Bestellungen aus dem Shop-System, idealerweise per Webhook oder API inklusive Bestellnummer, Betrag, Zahlart und Status. Drittens die Rechnungen und offenen Posten aus dem ERP oder aus DATEV, die den buchhalterischen Soll-Zustand abbilden.

Die Kunst besteht darin, diese drei Welten über gemeinsame Schlüssel zu verbinden. In der Praxis sind das meist die Bestell- oder Rechnungsnummer als primärer Schlüssel, der Betrag als sekundäres Kriterium und das Datum als Toleranzfenster. Eine Middleware normalisiert die unterschiedlichen Datenformate, bevor der eigentliche Abgleich beginnt -- denn jeder Provider liefert seine Reports in einem eigenen Schema, mit eigenen Feldnamen und eigener Gebührenlogik.

Das Herzstück der Reconciliation ist die Matching-Engine. Sie arbeitet in mehreren Stufen, vom strengen zum toleranten Abgleich. Auf der ersten Stufe steht das exakte Matching: Referenznummer stimmt überein und der Betrag passt auf den Cent. Diese Fälle lassen sich vollautomatisch und ohne Risiko verbuchen. In gut gepflegten Setups deckt allein dieses Verfahren einen Großteil der Transaktionen ab.

Auf der zweiten Stufe folgt das Betrags-Matching mit Toleranz: Wenn die Referenz fehlt oder gekürzt ist, sucht die Engine nach offenen Posten mit passendem Betrag innerhalb eines Datumsfensters. Damit es nicht zu Fehlzuordnungen kommt, wird ein Treffer nur akzeptiert, wenn er eindeutig ist -- gibt es mehrere Kandidaten mit identischem Betrag, landet der Fall in der Klärliste. Die dritte Stufe ist das gruppierte Matching für Sammelauszahlungen, bei dem die Summe vieler Einzelposten gegen einen Auszahlungsbetrag geprüft wird.

Entscheidend ist die saubere Behandlung der Fälle, die sich nicht automatisch zuordnen lassen. Statt sie zu erzwingen, werden sie als unmatched markiert und in einer Klärliste bereitgestellt. So bleibt der automatische Anteil verlässlich, und der Buchhalter kümmert sich gezielt nur um die echten Ausnahmen. In der Praxis lassen sich Auto-Match-Quoten von deutlich über 90 Prozent erreichen (Projekterfahrung), wenn Referenzführung und Mapping stimmen.

Ein Payout ist selten gleich dem Bestellbetrag. Payment-Provider ziehen Transaktionsgebühren, oft ein prozentuales Disagio plus einen Fixbetrag pro Transaktion, sowie gegebenenfalls Wechselkurs- oder Auszahlungsgebühren ab. Wer nur den Netto-Auszahlungsbetrag gegen die Bruttoforderung hält, erzeugt bei jeder Transaktion eine Differenz -- und damit einen scheinbar offenen Restbetrag, der die Buchhaltung verstopft.

Die Reconciliation-Engine muss deshalb den Brutto-Netto-Split beherrschen: Die Forderung wird in voller Höhe ausgeglichen, die Gebühr wird separat auf ein Aufwandskonto gebucht. Das ist nicht nur eine technische, sondern auch eine steuerliche Anforderung -- die Vorsteuer aus Provider-Gebühren will korrekt erfasst werden. Eine durchdachte DATEV-Anbindung bildet diese Logik in der Kontenzuordnung ab.

Wichtig ist, dass die Gebührenlogik pro Provider konfigurierbar bleibt. Jeder Anbieter hat ein eigenes Modell aus prozentualen und fixen Bestandteilen. Die Engine sollte die tatsächlich abgezogene Gebühr aus dem Payout-Report übernehmen, statt sie zu kalkulieren -- so bleibt die Buchung deckungsgleich mit der realen Auszahlung, auch bei abweichenden Konditionen oder Sondersätzen.

Chargebacks sind der unangenehmste Teil der Reconciliation. Sie tauchen oft als negative Posten in einer späteren Auszahlung auf, ohne direkten Bezug zur ursprünglichen Bestellung. Die durchschnittliche Chargeback-Quote im Handel lag im dritten Quartal 2025 bei 0,26 Prozent und damit 53 Prozent über dem Wert vom Jahresanfang (Chargeflow, 2025); bei Card-not-present-Transaktionen liegt sie mit 0,6 bis 1 Prozent noch deutlich höher (Chargeflow, 2025).

Hinzu kommt das Problem der sogenannten Friendly Fraud: Schätzungen zufolge gehen rund 75 Prozent der Chargeback-Fälle auf Rückbuchungen durch eigentlich legitime Kunden zurück (Juniper Research, 2025). Für die Reconciliation bedeutet das: Jede Rückbuchung muss der ursprünglichen Transaktion zugeordnet, die zugehörige Forderung wieder geöffnet und die Gebühr für den Chargeback separat erfasst werden.

Alle Posten, die sich nicht eindeutig zuordnen lassen, gehören in eine Klärliste mit nachvollziehbarem Grund: kein Treffer, mehrdeutiger Treffer, Betragsdifferenz oder unbekannte Referenz. Diese Liste ist die Arbeitsoberfläche für das Buchhaltungsteam und gleichzeitig die Stelle, an der die Matching-Regeln nachgeschärft werden. Eine robuste Fehlerbehandlung sorgt dafür, dass kein Posten still verloren geht.

Das Ergebnis der Reconciliation ist nur dann wertvoll, wenn es sauber im Zielsystem ankommt. Hier trennen sich zwei Wege: Bei kleineren Setups läuft der Abgleich auf den offenen Posten in der Finanzbuchhaltung, etwa direkt in DATEV. Bei größeren Strukturen mit einem führenden ERP wie SAP oder Microsoft Dynamics führt das ERP die offenen Posten, und die Reconciliation bucht die Zahlungseingänge dorthin.

In beiden Fällen sollte die Buchung idempotent sein: Wird derselbe Payout-Report versehentlich zweimal eingelesen, darf keine Doppelbuchung entstehen. Das erreicht man über eindeutige Transaktions-IDs und einen Importstatus je Datensatz. Strategien für Idempotenz und Retries sind hier kein Luxus, sondern Pflicht -- gerade wenn Auszahlungsdateien automatisiert verarbeitet werden.

Jede Buchung sollte einen vollständigen Beleg- und Audit-Trail erzeugen: Welcher Payout, welche Transaktion, welcher offene Posten, welche Gebühr, welcher Zeitstempel. Das ist nicht nur für die GoBD-konforme Belegkette relevant, sondern auch für die spätere Fehlersuche. Bei Differenzen lässt sich so lückenlos nachvollziehen, welche Regel gegriffen hat und welcher Betrag wohin geflossen ist.

Eine Reconciliation-Lösung wird nicht von der Stange gebaut, sondern an die konkrete Zahlungs- und Buchhaltungslandschaft angepasst. Der Ablauf folgt typischerweise fünf Phasen, wobei die enge Abstimmung mit Buchhaltung und Steuerberater über den Erfolg entscheidet.

Aus der Projektpraxis kristallisieren sich wiederholt dieselben Fallstricke heraus. Wer sie kennt, kann sie von vornherein einplanen, statt sie später teuer nachzurüsten.