Gutscheine in Shop und Filiale: ein Saldo für alle Kanäle

Gutscheine sind ein Weihnachtsthema, und das Weihnachtsgeschäft hat für den Handel besonderes Gewicht. Der Einzelhandel erzielt 18,5 Prozent seines Jahresumsatzes in den letzten beiden Monaten des Jahres (HDE); für November und Dezember 2025 hatte der Verband 126,2 Milliarden Euro Umsatz prognostiziert (HDE). Bei den geplanten Geschenkkäufen lagen Geschenkgutscheine mit 29 Prozent der Befragten vorn, knapp vor Spielwaren (HDE-Konsumbarometer).

Gekauft und eingelöst wird dabei nicht zwingend im selben Kanal. 73 Prozent der Befragten ab 16 Jahren wollten 2025 Weihnachtsgeschenke online bestellen, jede und jeder Fünfte (20 Prozent) etwa zur Hälfte im Internet und zur Hälfte im Geschäft vor Ort (Bitkom). 15 Prozent wollten alle Geschenke im Geschäft besorgen (Bitkom). Ein Gutschein, den eine Person online kauft, kann damit leicht bei jemandem landen, der lieber in der Filiale einkauft, oder umgekehrt.

Solange Shop und Kasse getrennte Gutscheinlisten führen, entstehen wiederkehrende Fehlerbilder. Sie fallen selten beim Verkauf auf, sondern bei der Einlösung, wenn eine Kundin an der Kasse steht und der Code dort unbekannt ist, oder bei der Abstimmung im Januar, wenn die Summe der offenen Gutscheine nicht zum Konto in der Buchhaltung passt.

Die Grundlagen der Kassenanbindung, also gemeinsamer Bestand, Click and Collect und Retoure in der Filiale, beschreibt der Beitrag zur Anbindung des Kassensystems an den Shop. Hier geht es um ein Objekt, das dort nicht vorkommt: den Gutschein mit seinem Saldo.

Die zentrale Entscheidung lautet: Welches System hält den maßgeblichen Saldo? Alle anderen Systeme fragen dort an, reservieren dort und buchen dort. Sie dürfen den Saldo anzeigen, aber nicht aus einer eigenen Kopie heraus über eine Einlösung entscheiden. In der Praxis kommen vier Orte infrage, jeder mit eigenen Stärken.

Naheliegend ist oft das ERP oder ein eigener Dienst in der Middleware, weil dort ohnehin Aufträge, Zahlarten und der Export an die Buchhaltung zusammenlaufen. Entscheidend ist weniger der Ort als die Regel: genau ein Saldo, ein Bewegungsjournal und eine definierte Schnittstelle, über die Shop, Kasse und gegebenenfalls Partner zugreifen. Ein nächtlicher Abgleich zwischen zwei gleichberechtigten Gutscheinlisten löst das Problem nicht; er findet Doppeleinlösungen erst, wenn die Ware schon den Laden verlassen hat. Wie sich Konflikte zwischen Systemen grundsätzlich auflösen lassen, beschreibt der Beitrag zur bidirektionalen Synchronisation.

Die gefährlichste Lücke entsteht, wenn zwei Kanäle denselben Gutschein fast gleichzeitig einsetzen: Ein Kunde zeigt den Code an der Kasse, während jemand anderes ihn im Checkout eintippt. Lesen beide Systeme denselben Saldo, ziehen beide ihren Betrag ab und schreiben das Ergebnis zurück, ist mehr Wert eingelöst, als der Gutschein trug. Das verhindert kein nachträglicher Abgleich, sondern nur eine Einlösung in klaren Schritten.

Technisch entscheidet eine atomare Operation: Die Reservierung wird nur gebucht, wenn der freie Saldo zum Zeitpunkt der Buchung mindestens den angefragten Betrag deckt, etwa über eine bedingte Aktualisierung in der Datenbank oder eine Versionsnummer am Gutscheinkonto. Scheitert die Bedingung, erhält der Kanal eine eindeutige Ablehnung. Über HTTP eignet sich dafür der Status 409 Conflict, der einen Konflikt mit dem aktuellen Zustand der Ressource meldet (RFC 9110). Kasse und Shop zeigen dann den tatsächlichen Saldo an, statt die Einlösung stillschweigend zu wiederholen.

Dazu gehört ein Idempotenzschlüssel je Einlösungsversuch. Bricht die Verbindung nach dem Buchen ab und sendet die Kasse die Anfrage erneut, darf das führende System den Betrag kein zweites Mal abziehen, sondern liefert das Ergebnis der ersten Buchung zurück. Wie solche Schlüssel und Wiederholungen aufgebaut werden, zeigt der Beitrag zu Idempotenz und Retry-Strategien.

Storno und Retoure sind die Stellen, an denen Gutscheinsalden am häufigsten auseinanderlaufen. Wird ein Bon storniert, auf dem ein Gutschein eingelöst wurde, muss die Einlösung als Gegenbewegung zurück auf das Gutscheinkonto, mit Bezug auf den stornierten Bon. Dasselbe gilt für eine abgebrochene Online-Bestellung: Die Einlösung wird zurückgebucht, nicht gelöscht. Wird dagegen der Verkauf eines Gutscheins rückgängig gemacht, sperrt das führende System den Code, bevor das Geld zurückfließt.

Bei einer Retoure kommt eine fachliche Entscheidung hinzu: Geht die Erstattung zurück auf den Gutschein, als neuer Gutschein an den Kunden oder als Geld auf das ursprüngliche Zahlungsmittel? Eine mögliche Regel ist die Erstattung zuerst auf den Gutschein, eine andere die anteilige Aufteilung nach der Zahlungsweise des Einkaufs. Wurde eine Bestellung über 80 Euro zu 30 Euro mit Gutschein und zu 50 Euro per Karte bezahlt und eine Position zurückgegeben, muss die Regel festlegen, welcher Teil zuerst erstattet wird. Diese Regel gehört in die Middleware oder das ERP, nicht in das Gedächtnis des Kassenpersonals.

Wichtig ist der Belegbezug in beide Richtungen: Die Gutschrift auf den Gutschein trägt die Retourennummer, die Retoure im ERP trägt den Gutschein als Erstattungsweg. Den Prozess vom Rückgabeantrag bis zur Gutschrift beschreibt der Beitrag zum RMA-Prozess zwischen Shop und ERP. Beim Widerruf eines Online-Kaufs gelten eigene Vorgaben zum Erstattungsweg, die der Beitrag zum Widerrufsbutton im Shop behandelt.

Jede Bewegung auf dem Gutscheinkonto ist ein Vorgang, den die Buchhaltung sehen muss. Beim Verkauf entsteht in der Regel eine Verbindlichkeit gegenüber dem Inhaber; für Bilanzierer ist zu diesem Zeitpunkt noch kein Ertrag realisiert (DSFinV-K). Bei der Einlösung wird die Verbindlichkeit aufgelöst und der Umsatz der gekauften Ware gebucht, die Ausbuchung eines verjährten Restwerts führt in der Regel zu einem Ertrag. Welche Konten und Steuerschlüssel dafür gelten, legen Sie mit der Steuerkanzlei fest. Die Schnittstelle sorgt dafür, dass jede Bewegung mit der Gutscheinnummer als Belegbezug ankommt.

Die Wege dorthin sind verschieden. Der Shop liefert Einzelbelege je Bestellung, die Kasse einen Tagesabschluss mit Summen je Geschäftsvorfall, das führende System das vollständige Journal. Sinnvoll ist es, das Journal als maßgebliche Quelle für die Gutscheinbuchungen zu nehmen und Shop- und Kassendaten dagegen abzustimmen. Wie Rechnungen, Gutschriften und Zahlungen in den Buchungsstapel gelangen, zeigt der Beitrag zur DATEV-Anbindung im E-Commerce; die laufende Übergabe richten wir über die DATEV-Anbindung ein.

Das Journal muss länger halten als jeder einzelne Gutschein. Bücher und Aufzeichnungen sind zehn Jahre, Buchungsbelege acht Jahre aufzubewahren (§ 147 Abs. 3 AO). Ablage des Journals, Rechtevergabe und Abstimmungen gehören deshalb in die Verfahrensdokumentation, wie sie der Beitrag zur GoBD-Verfahrensdokumentation für Schnittstellen beschreibt. Für den Abgleich der Restzahlungen mit den Zahlungsdiensten gilt dasselbe wie für jede andere Zahlart, siehe den Beitrag zur Payment-Reconciliation.

Eine solche Anbindung lässt sich auf bestehende Systeme setzen. Kasse und Shop müssen nicht ersetzt werden, solange beide Prüfung und Reservierung über eine Schnittstelle zulassen. Wie wir Warenwirtschaft und Shop verbinden, beschreibt die Seite zur Warenwirtschaft-Anbindung; welche Schnittstellen wir darüber hinaus entwickeln, steht unter API-Entwicklung.