Shopware Zahlungsart nachträglich ändern: was geht, was nicht und was es kostet
Der Kunde hat Vorkasse gewählt und per PayPal gezahlt. Die Kartenzahlung ist abgebrochen, überwiesen wurde trotzdem. Die Ware wurde abgeholt und bar bezahlt. In allen drei Fällen steht in der Bestellung eine Zahlungsart, die mit dem tatsächlichen Geldeingang nichts zu tun hat — und im Backend lässt sich das Feld nicht anfassen. Dieser Artikel beantwortet der Reihe nach, was Shopware 6 zulässt, warum es gesperrt ist und was die üblichen Umwege in der Buchhaltung anrichten.
Die Korrektur samt passendem Buchungsstapel steckt im Ertragswerke Buchhaltungs-Plugin — es legt eine zusätzliche Zahlungstransaktion an, statt die Historie zu überschreiben.
Inhalt
- Kann man in Shopware 6 die Zahlungsart nachträglich ändern?
- Warum ist das Zahlungsart-Feld im Backend gesperrt?
- Ging das in Shopware 5 noch?
- Der Kunde hat anders bezahlt als angegeben — was jetzt?
- Warum lässt Shopware Bestellungen ohne abgeschlossene Zahlung zu?
- Was tun bei fehlgeschlagener oder abgebrochener Zahlung?
- Wie ändere ich die Zahlungsart bei einer Gastbestellung?
- Wofür ist „Zahlungsart nach Abschluss der Bestellung ändern"?
- Kann der Kunde die Zahlungsart selbst wechseln?
- Wie verhindere ich, dass Kunden nachträglich wechseln?
- Hilft ein Zahlungslink weiter?
- Muss ich stornieren und neu anlegen?
- Zahlungsstatus oder Zahlungsart — was ist der Unterschied?
- Was richtet eine falsche Zahlungsart in der Buchhaltung an?
- Wie sieht eine saubere Korrektur aus?
- Wie wirkt sich das auf den DATEV-Export aus?
- Gibt es ein Plugin dafür?
Kann man in Shopware 6 die Zahlungsart nachträglich ändern?
Im Standard nicht. Das Zahlungsart-Feld einer bestehenden Bestellung ist in der Administration gesperrt. Es gibt keine Einstellung, die es freischaltet, und keinen Rechtesatz, der es erlaubt. Wer die Zahlungsart einer aufgegebenen Bestellung korrigieren will, braucht eine Erweiterung oder muss auf einen Umweg ausweichen.
Warum ist das Zahlungsart-Feld im Backend gesperrt?
Weil an der Zahlungsart keine bloße Bezeichnung hängt, sondern eine Zahlungstransaktion mit eigenem Status, eigener Historie und gegebenenfalls einer Referenz beim Zahlungsdienstleister. Würde man nur das Feld überschreiben, behauptete die Bestellung rückwirkend eine Zahlung, die so nie stattgefunden hat. Die Sperre ist technisch also nachvollziehbar — sie lässt den Händler nur mit dem Problem allein.
Ging das in Shopware 5 noch?
Ja. In Shopware 5 ließ sich die Zahlungsart einer Bestellung im Backend umstellen. Mit dem Wechsel auf Shopware 6 ist diese Möglichkeit entfallen und bis heute nicht zurückgekommen. Wer von 5 auf 6 migriert ist, vermisst sie in der Regel innerhalb der ersten Wochen.
Der Kunde hat anders bezahlt als angegeben — was jetzt?
Das ist der häufigste Fall und der, um den es eigentlich geht. Nicht der Kunde will etwas ändern, sondern die Realität weicht von der Bestellung ab:
- Bestellt auf Vorkasse, gezahlt per PayPal, weil ihm die Überweisung zu langsam war.
- Bestellt per Kreditkarte, Zahlung abgebrochen, dann doch überwiesen.
- Bestellt online, im Laden abgeholt und dort bar bezahlt.
- Bestellt auf Rechnung, aber vor Versand vorab überwiesen.
In all diesen Fällen ist das Geld da. Nur steht es in der Bestellung unter der falschen Zahlungsart — und damit später auf dem falschen Konto.
Warum lässt Shopware Bestellungen ohne abgeschlossene Zahlung zu?
Weil die Bestellung und die Zahlung zwei getrennte Vorgänge sind. Shopware legt die Bestellung an, sobald der Kunde sie abschickt, und startet danach die Zahlung. Bricht sie ab, bleibt die Bestellung bestehen — mit offener Zahlungstransaktion. Das ist sinnvoll, weil man den Kunden sonst bei jedem Zahlungsabbruch verlieren würde. Es führt aber dazu, dass Bestellungen mit einer Zahlungsart im System stehen, über die nie gezahlt wurde.
Was tun bei fehlgeschlagener oder abgebrochener Zahlung?
Im Standard bleiben drei Wege, und jeder hat seinen Preis:
| Weg | Was er kostet |
|---|---|
| Zahlungslink schicken — über den Zahlungsdienstleister eine Zahlungsaufforderung versenden. | Das Geld kommt an, aber die Bestellung trägt danach die Zahlungsart des Dienstleisters statt der, über die tatsächlich abgerechnet werden sollte. |
| Stornieren und neu anlegen — Bestellung abbrechen, der Kunde bestellt erneut. | Bestellnummer, Datum und Historie ändern sich. Bei versandter Ware oder erteilter Rechnung keine Option. |
| Als Kunde einloggen — über eine Zusatzfunktion die Storefront-Sicht übernehmen. | Nur bei registrierten Kunden mit aktiviertem Wechsel, bei Gastbestellungen gar nicht — und es ist ein Eingriff im Namen des Kunden. |
Wie ändere ich die Zahlungsart bei einer Gastbestellung?
Im Standard überhaupt nicht. Alle kundenseitigen Wege setzen ein Kundenkonto voraus. Ein Gast hat keins, kann sich also nicht einloggen und die Zahlungsart wechseln — und du kannst es auch nicht für ihn tun. Gerade im Shop mit hohem Gastanteil ist das die härteste Variante des Problems.
Wofür ist „Zahlungsart nach Abschluss der Bestellung ändern"?
Diese Einstellung klingt nach der Lösung, ist aber ausschließlich kundenseitig. Sie erlaubt dem eingeloggten Kunden, im eigenen Konto zu wechseln. Sie gibt dir als Händler keinerlei Zugriff auf das Feld im Backend. Wer sie aktiviert und danach im Administrationsbereich nachsieht, findet dort unverändert ein gesperrtes Feld.
Kann der Kunde die Zahlungsart selbst wechseln?
Ja, wenn er ein Konto hat und die Einstellung aktiv ist. Im Kundenkonto unter den Bestellungen lässt sich die Zahlungsart dann noch ändern. Für den Händler löst das wenig: Es setzt voraus, dass der Kunde mitspielt, sich einloggt und den Weg findet — bei einem Anruf „ich zahle lieber per Überweisung" ist das der längere Weg.
Wie verhindere ich, dass Kunden nachträglich wechseln?
Diese Frage wird oft mit der obigen verwechselt, ist aber das Gegenteil. Wer unterbinden will, dass ein Kunde nach dem Kauf von Kreditkarte auf Rechnungskauf umsteigt, schaltet genau die eben genannte Einstellung ab. Damit ist die kundenseitige Änderung gesperrt — an der Backend-Sperre ändert das nichts. Beide Richtungen sind unabhängig voneinander, und die Suchergebnisse zu diesem Thema vermischen sie regelmäßig.
Hilft ein Zahlungslink weiter?
Für den Geldeingang ja, für die Buchhaltung nein. Der Kunde zahlt, das Geld ist da — aber die Bestellung führt nun den Zahlungsdienstleister als Zahlungsart. Wenn ursprünglich Vorkasse vereinbart war, weicht die Buchung ab dem Moment vom Beleg ab. Bei wenigen Bestellungen korrigiert man das von Hand, bei zweihundert im Monat nicht mehr.
Muss ich stornieren und neu anlegen?
Das ist der sauberste Weg im Standard und zugleich der teuerste. Die neue Bestellung bekommt eine neue Nummer und ein neues Datum. Wurde bereits eine Rechnung erstellt, muss sie storniert werden. Ist die Ware unterwegs, passt die Nummer auf dem Lieferschein nicht mehr. Für einen Einzelfall vertretbar, als Routine nicht.
Zahlungsstatus oder Zahlungsart — was ist der Unterschied?
Der Zahlungsstatus sagt, ob bezahlt wurde: offen, bezahlt, teilweise bezahlt, erstattet. Den kannst du im Backend jederzeit setzen. Die Zahlungsart sagt, womit bezahlt wurde — und die ist gesperrt. Viele Anleitungen im Netz beschreiben das Setzen des Status und wirken dadurch, als sei das Problem gelöst. Ist es nicht: Eine auf „bezahlt" gesetzte Vorkasse-Bestellung, bei der in Wahrheit PayPal geflossen ist, bleibt buchhalterisch falsch.
Was richtet eine falsche Zahlungsart in der Buchhaltung an?
Zahlungsarten werden unterschiedlich gebucht. Eine Überweisung landet auf dem Bankkonto. Ein Zahlungsdienstleister bekommt ein eigenes Verrechnungskonto, weil er gesammelt und abzüglich seiner Gebühren auszahlt. Welche Kontonummern das sind, hängt vom Kontenrahmen ab — SKR03 und SKR04 unterscheiden sich, dein Steuerberater gibt sie vor.
Stimmt die Zahlungsart nicht, laufen zwei Dinge auseinander:
- Der Umsatzerlös wird gegen das Konto gebucht, das an der Bestellung hängt.
- Das Geld geht auf dem Konto ein, über das tatsächlich gezahlt wurde.
Am Monatsende steht auf dem einen Konto ein Betrag, der nie geflossen ist, und auf dem anderen ein Eingang ohne Gegenbuchung. Dazu kommt: Sammelauszahlungen eines Dienstleisters lassen sich einzelnen Bestellungen nur zuordnen, wenn die Zahlungsart stimmt. Sonst bleibt eine Differenz, die niemand mehr auflöst — und eine Kanzlei, die Rückfragen stellt und sie abrechnet.
Wie sieht eine saubere Korrektur aus?
Nicht durch Überschreiben. Was passiert ist, war ein Wechsel, und der gehört dokumentiert. Richtig ist:
- Eine zusätzliche Zahlungstransaktion mit der neuen Zahlungsart anlegen.
- Die ursprüngliche als abgebrochen oder fehlgeschlagen stehen lassen.
- Die neue als die maßgebliche führen.
Damit bleibt nachvollziehbar, dass zuerst Vorkasse gewählt und später per PayPal gezahlt wurde. Für die Buchhaltung zählt die letzte, tatsächlich erfolgreiche Transaktion — und der Umsatz läuft gegen das Konto, auf dem das Geld wirklich eingegangen ist.
Wie wirkt sich das auf den DATEV-Export aus?
Unmittelbar. Ein Buchungsstapel ist nur so gut wie die Zahlungsart, aus der er sein Gegenkonto ableitet. Wer den Export automatisiert, ohne die Zahlungsart korrigieren zu können, automatisiert den Fehler — zuverlässig, jeden Monat. Deshalb gehören Korrektur und Export in dasselbe Werkzeug.
Gibt es ein Plugin dafür?
Ja. Das Ertragswerke Buchhaltungs-Plugin legt genau diese zusätzliche Transaktion an — auch bei Gastbestellungen, weil die Korrektur im Backend an der Bestellung stattfindet und kein Kundenkonto braucht. Im selben Plugin steckt der DATEV-Export, der den Buchungsstapel dann mit der richtigen Zahlungsart erzeugt.