Änderungen von Lieferantenbankkonten in Accounts Payable: Kontrollen vor der Freigabe

Die Änderung eines Lieferantenbankkontos ist eine Stammdatenänderung und keine einfache Korrektur einer einzelnen Rechnung. Ein Fehler kann eine ordnungsgemäß genehmigte Zahlung auf ein falsches Konto leiten. Das folgende Betriebsmodell ist mit System, Bankberechtigungen und Kundenverfahren abzustimmen.

1. Antrag und Stammdatenänderung trennen

Erfassen Sie den Antrag als eigenen Vorgang mit Lieferantenkennung, Gesellschaft, Land, Währung, Änderungsumfang und geplantem Wirksamkeitsdatum. Bewahren Sie Eingangskanal und Ausgangsdokument auf.

Übernehmen Sie ein Konto aus Rechnung oder Nachricht nicht direkt in den Stammsatz. Eine Abweichung muss geklärt werden, ersetzt aber nicht den vereinbarten Stammdatenprozess.

2. Identität und Quelle über einen unabhängigen Kanal prüfen

Bestätigen Sie die Änderung über einen bereits bekannten Kanal, der von der Nachricht mit dem neuen Konto unabhängig ist. Verwenden Sie einen genehmigten Kontakt aus Stammdaten oder Vertrag, nicht eine Nummer aus demselben Antrag.

Dokumentieren Sie, wer wann mit wem welche Daten bestätigt hat. Volle Kontonummern gehören nicht in allgemein zugängliche Notizen; Maskierung und rollenbasierter Zugriff richten sich nach der Kundenrichtlinie.

3. Alte und vorgeschlagene Werte vergleichen

Die Prüfung umfasst aktuellen und vorgeschlagenen Wert, Kontoinhaber, Land, Währung, Bank, IBAN oder lokale Kennung sowie die Gültigkeitsebene. Oracle unterscheidet Lieferant, Adresse und Standort; das beeinflusst das Freigaberouting.

Klären Sie auch Änderungen an Hauptkonto, Factoringkonto und Belegdokument. Prüfen Sie nicht nur die Nummer: Währung, Land oder Status können den Zahlungsweg verändern.

4. Konto erst nach Freigabe nutzbar machen

Microsoft beschreibt einen Workflow, in dem geschützte Felder bis zur Genehmigung vorgeschlagen bleiben und ein neues Konto vorher nicht nutzbar ist. Vereinbaren Sie Auslöser auch für Importe und Schnittstellen.

Die erfassende Person darf die eigene Änderung nicht allein genehmigen. Die Freigabe prüft Nachweis, unabhängige Bestätigung und Vorher-Nachher-Werte; eine Ablehnung braucht klaren Status und kontrollierte Korrektur.

5. Zahlung bei Unsicherheit sperren

Ist die Änderung offen, strittig oder ungeprüft, kennzeichnen Sie den Vorgang und verhindern die Nutzung der neuen Daten mit der vereinbarten Kontrolle. Eine manuelle Zahlung außerhalb des Workflows ist keine Lösung.

Vergleichen Sie vor dem nächsten Zahlungsvorschlag das Empfängerkonto mit genehmigten Stammdaten und den jüngsten Änderungen. Achten Sie besonders auf Änderungen kurz vor dem Fälligkeitsdatum, Dringlichkeit und Abweichungen zwischen Rechnung und Stammsatz.

6. Audit Trail sichern und erste Nutzung prüfen

SAP weist darauf hin, dass die Änderungshistorie Zeitpunkt, Benutzer, vorherigen Wert sowie hinzugefügte oder gelöschte Bankdaten zeigen kann. Bewahren Sie Antrag, Prüfung, Entscheidung, Systemhistorie und Aktivierungsdatum auf.

Prüfen Sie nach Freigabe die erste Zahlung auf das geänderte Konto: Lieferant, Betrag, Währung, Empfängerkonto und Ausgleichsnachweis. Die Erstnutzungsprüfung ersetzt keine Genehmigung, erkennt aber mögliche Konfigurations- oder Zuordnungsfehler.

Quellen und Geltungsbereich

• Microsoft Learn: Vendor bank account workflow
• Oracle: Internal Supplier Profile Bank Account Change
• Oracle: Use Procurement BU and Bank as Change Request Approval Attributes
• SAP Help: Displaying Changes to Supplier/Vendor Master Records

Die Dokumentation von Microsoft, Oracle und SAP wurde am 31. Oktober 2026 geprüft. Feldnamen und Workflow-Verhalten hängen von Produkt und Konfiguration ab. Bankdatenprüfung, Änderungsfreigabe und Zahlungsausführung erfordern Kundenverfahren und Berechtigungen.

Möchten Sie Dokumente und Ausnahmen in Accounts Payable strukturieren? Informieren Sie sich über die Unterstützung von Finanzprozessen und vereinbaren Sie Verantwortlichkeiten und Kontrollen des Kunden.