Start / Glossar

Payment & Digitalisierung für Gastronomie und Hotellerie

Begriffe aus der Praxis.

Fiskalisierung, Payment, Kassenwelt: Hier stehen die Begriffe, die in Projekten wirklich fallen – jeder vom Ursprung her erklärt. Denn Regeln versteht man besser, wenn man weiß, woher sie kommen: von den GoB über GDPdU und GoBD bis zu TSE und DSFinV-K.

20 Begriffe · Stand: Juli 2026 · wird gepflegt

Einordnung aus der Praxis – keine Rechts- oder Steuerberatung, keine Produktempfehlung. Verbindlich sind die Gesetzestexte, die BMF-Schreiben und die individuelle steuerliche Beratung. Diese Seite ist Wissensdarbietung, kein Beratungs- oder Dienstleistungsangebot.

Cluster /01

Fiskalisierung & Regulatorik

Die Herleitungskette: GoB → GDPdU → GoBD → KassenSichV → TSEDSFinV-K – eine Linie, keine Einzelthemen.

GoB – Grundsätze ordnungsmäßiger Buchführung

#

Herkunft: Handelsrecht, § 238 HGB – älter als jede Kasse

Der Anfang von allem: Bücher müssen vollständig, richtig, zeitgerecht, geordnet, nachvollziehbar und unveränderbar geführt werden. Diese Prinzipien stammen aus einer Welt aus Papier und Tinte – und sie haben den Sprung in die digitale Welt vollständig überlebt.

Alles, was heute an der Kasse reguliert ist – GoBD, TSE, DSFinV-K – ist keine neue Idee, sondern die Übersetzung genau dieser Grundsätze in Software und Signaturen.

In der PraxisWer die GoB verstanden hat, versteht, warum eine Kasse keinen Vorgang „vergessen" darf – und muss die Folgeregeln nicht mehr auswendig lernen, sondern kann sie herleiten.

GoBD

#

Herkunft: GoB → GDPdU → GoBD (BMF-Schreiben)

Die „Grundsätze zur ordnungsmäßigen Führung und Aufbewahrung von Büchern, Aufzeichnungen und Unterlagen in elektronischer Form sowie zum Datenzugriff" – das BMF-Schreiben, das die GoB in die digitale Welt übersetzt. Vorgänger war die GDPdU.

Kernpunkte: Unveränderbarkeit der Daten, Verfahrensdokumentation, geordnete Aufbewahrung und der Datenzugriff der Finanzverwaltung.

In der PraxisDie GoBD betreffen nicht nur die Kasse, sondern jedes System, das buchführungsrelevante Daten erzeugt – von der Warenwirtschaft über das PMS bis zum Rechnungstool.

KassenSichV – Kassensicherungsverordnung

#

Herkunft: § 146a AO, konkretisiert durch Verordnung

Die Verordnung, die aus dem Gesetzesparagrafen gelebte Technik macht: Sie schreibt für elektronische Aufzeichnungssysteme die zertifizierte technische Sicherheitseinrichtung (TSE), die Belegausgabe und die elektronische Meldung der Kassen an die Finanzverwaltung vor.

In der PraxisDie KassenSichV ist das Scharnier zwischen Steuerrecht und Kassentechnik – wer wissen will, warum seine Kasse etwas tun muss, findet die Antwort meist hier oder eine Ebene höher in der AO.

TSE – Technische Sicherheitseinrichtung

#

Herkunft: Unveränderbarkeits-Prinzip der GoB, technisch erzwungen

Ein zertifiziertes Sicherheitsmodul mit Speichermedium und einheitlicher digitaler Schnittstelle. Es signiert jeden Kassenvorgang mit fortlaufendem Zähler – nachträgliche Änderungen werden dadurch nicht verboten, sondern sichtbar. Es gibt Hardware-Varianten (etwa als USB- oder SD-Modul) und Cloud-TSEn.

In der PraxisDie TSE-Einführung war aus der Projekterfahrung heraus weit mehr Organisations- als Technikthema: Zertifikatslaufzeiten, Export-Zuständigkeiten und Personalprozesse entscheiden über den Alltag, nicht das Modul selbst – hergeleitet im Fiskal-Zeitstrahl der Kassenwelt.

DSFinV-K

#

Herkunft: Datenzugriffs-Gedanke der GoBD, vereinheitlicht

Die „Digitale Schnittstelle der Finanzverwaltung für Kassensysteme": ein einheitliches Exportformat, in dem jede Kasse ihre Daten für die Prüfung bereitstellen muss – damit ein Prüfer jedes System gleich lesen kann, egal welcher Hersteller dahintersteht.

In der PraxisDer DSFinV-K-Export muss auf Knopfdruck funktionieren – ob er es tut, zeigt sich verlässlich erst, wenn man ihn vor der Prüfung einmal selbst gezogen hat.

Belegausgabepflicht

#

Herkunft: Nachvollziehbarkeit des Einzelvorgangs (GoB), § 146a Abs. 2 AO

Wer mit elektronischer Kasse arbeitet, muss zu jedem Geschäftsvorfall einen Beleg anbieten – papierhaft oder elektronisch. Eine Pflicht des Gastes, den Beleg mitzunehmen, gibt es nicht.

Der Gedanke dahinter: Jeder einzelne Vorgang soll für Gast und Prüfung nachvollziehbar dokumentiert sein – der Bon ist das sichtbare Ende der Signaturkette.

In der PraxisDer elektronische Beleg (etwa per QR-Code) erfüllt die Pflicht genauso wie Papier – die Umsetzung ist eine Prozess- und Gästefrage, keine Rechtsfrage.

Kassennachschau

#

Herkunft: § 146b AO – Prüfung ohne Ankündigung

Anders als die klassische Außenprüfung kommt die Kassennachschau unangekündigt, während der Geschäftszeiten. Der Prüfer darf Kassendaten, TSE und Verfahrensdokumentation einsehen und Testkäufe machen.

In der PraxisHier zeigt sich, ob Export, Dokumentation und Personalwissen wirklich funktionieren – im laufenden Mittagsgeschäft, nicht im Terminkalender.

Tagesabschluss / Z-Bericht

#

Herkunft: Kassensturzfähigkeit & zeitgerechte Erfassung (GoB)

Der summierende, fortlaufend nummerierte Abschluss eines Geschäftstags: Umsätze, Zahlarten, Stornos – einmal festgeschrieben, nicht mehr veränderbar. Der Z-Bericht ist die tägliche Antwort auf die alte Frage: Stimmt die Kasse?

In der PraxisCloud-Systeme erledigen den Abschluss teils automatisch zur festen Uhrzeit – die Verantwortung für die tägliche, vollständige Aufzeichnung bleibt trotzdem im Betrieb.

Cluster /02

Payment

Das Vier-Parteien-System: Gast (Issuer) → Kartensystem → Betrieb (Acquirer) – und die Bausteine drumherum, vom Terminal über SoftPOS bis zum Wallet.

Acquirer

#

Herkunft: Vier-Parteien-System der Kartenzahlung

Die Händlerbank: Sie nimmt Kartenzahlungen für den Betrieb an, rechnet sie ab und schreibt den Umsatz gut. Der Acquirer ist der Vertragspartner des Betriebs für die Kartenakzeptanz und setzt die Regeln der Kartensysteme auf Händlerseite um.

In der PraxisWenn im Betrieb von „unserem Payment-Vertrag" die Rede ist, ist fast immer der Akzeptanzvertrag mit dem Acquirer gemeint.

Issuer

#

Herkunft: Vier-Parteien-System der Kartenzahlung

Die kartenausgebende Bank des Gastes: Sie hat die Karte herausgegeben, genehmigt oder lehnt jede Transaktion ab und trägt das Risiko gegenüber ihrem Kunden.

Issuer und Acquirer sind die zwei Bank-Enden derselben Zahlung – verbunden über das Kartensystem dazwischen.

In der PraxisEine abgelehnte Zahlung am Terminal ist meist eine Entscheidung des Issuers – nicht des Terminals, nicht des Acquirers und nicht der Kasse.

Kartensystem (Scheme)

#

Herkunft: das Regelwerk zwischen den Banken

Das Netzwerk und Regelwerk, das Issuer und Acquirer verbindet – in Deutschland etwa die girocard, dazu die internationalen Kartensysteme. Die Schemes legen Standards, Abläufe, Sicherheitsanforderungen und Entgeltrahmen fest, ohne selbst Karten auszugeben oder Händler zu betreuen.

In der PraxisWelche Systeme ein Betrieb akzeptiert, entscheidet über Gäste-Komfort und Kondition – die Logos am Eingang sind die sichtbare Kurzfassung dieser Entscheidung.

Interchange

#

Herkunft: Ausgleichsmechanik im Vier-Parteien-System

Das Entgelt, das der Acquirer je Transaktion an den Issuer zahlt. In der EU für Verbraucherkarten durch die Interchange-Verordnung (EU) 2015/751 gedeckelt: höchstens 0,2 % bei Debit-, höchstens 0,3 % bei Kreditkarten; Firmenkarten sind ausgenommen. Ein Baustein der Händlerkondition, nicht die ganze.

In der PraxisWie sich aus Interchange, Scheme-Entgelten und der Marge des Dienstleisters die Gesamtkondition zusammensetzt, ist auf der Payment-Seite im Abschnitt Konditionen hergeleitet.

PSP – Payment Service Provider

#

Herkunft: Arbeitsteilung im Payment – Technik trifft Bank

Der Dienstleister, der die technische Anbindung an Zahlarten bündelt: vom stationären Terminal über Online-Payment bis zur App – eine Anbindung, viele Zahlarten. Häufig bringt der PSP das Acquiring gleich mit, dann kommen Technik und Abrechnung aus einer Hand.

In der PraxisPayment lässt sich wie ein Baukasten denken: Aus Terminal, Online-Strecke und Zahlarten wird für jedes Geschäftsmodell eine eigene Kombination – der PSP ist der, der die Bausteine liefert und verbindet.

SoftPOS

#

Herkunft: das Terminal, in Software übersetzt

Kartenakzeptanz per App auf einem handelsüblichen Smartphone oder Tablet: Die NFC-Schnittstelle des Geräts wird zum Kartenleser, eigene Zertifizierungsstandards sichern die Zahlung ab. Zusätzliche Hardware entfällt.

In der PraxisInteressant überall dort, wo das feste Terminal nicht hinkommt: am Tisch, im Außenbereich, auf Events – oder als Rückfallebene, wenn das Hauptterminal ausfällt.

Wallet

#

Herkunft: die Karte, tokenisiert aufs Gerät gebracht

Die digitale Brieftasche auf Smartphone oder Uhr: Die Karte des Gastes wird nicht kopiert, sondern tokenisiert hinterlegt – am Terminal läuft eine ganz normale Kartenzahlung, nur mit einem Token statt der echten Kartennummer.

In der PraxisFür Kasse und Terminal ist das Wallet keine neue Zahlart, sondern ein neuer Weg zur Karte – die Abrechnung dahinter bleibt dieselbe.

Cluster /03

Kasse, Software & Betrieb

Vom Küchenbon zur Cloud: Kasse → Schnittstellen → PMS · KDS · QR-Order – die Systeme, die im Betrieb zusammenspielen müssen.

Kassensystem: lokal vs. Cloud

#

Herkunft: zwei Betriebsmodelle für dieselbe Aufgabe

Lokal heißt: Daten und Logik liegen im Haus, das System läuft auch ohne Internet vollständig. Cloud/SaaS heißt: zentrale Software, Updates und Multi-Standort-Betrieb aus einer Hand – dafür braucht es ein durchdachtes Konzept für den Offline-Fall.

Beide Welten können ordnungsgemäß betrieben werden; der Unterschied liegt im Betriebsmodell, nicht in der Rechtslage.

In der PraxisDie Frage ist selten „lokal oder Cloud?", sondern: Wie arbeitet der Betrieb, wie stabil ist die Anbindung, wer pflegt das System – daraus ergibt sich die Antwort.

Schnittstelle (API)

#

Herkunft: der Küchenbon war die erste Schnittstelle der Gastronomie

Die vereinbarte Sprache, in der zwei Systeme Daten austauschen – Kasse und Payment, Kasse und Warenwirtschaft, Kasse und Hotelsystem. Was früher der Bon zwischen Service und Küche war, ist heute die API zwischen Systemen: eine klare Nachricht, ein klares Format, ein klarer Empfänger.

In der PraxisOb eine Lösung im Alltag trägt, entscheidet sich selten in der Kasse selbst – meist an der Qualität und Pflege ihrer Schnittstellen.

PMS & PMS-Schnittstelle

#

Herkunft: das Gastkonto – so alt wie die Hotellerie selbst

Das Property Management System ist das führende System des Hotels: Reservierung, Zimmerverwaltung, Gastkonto. Die PMS-Schnittstelle verbindet Restaurant, Bar und Spa mit diesem Konto – der Umsatz vom Abendessen wandert als Room Charge aufs Zimmer und erscheint auf einer Rechnung beim Check-out.

In der PraxisDer Check-out ist der letzte Eindruck des Aufenthalts – ob er reibungslos läuft, hängt daran, wie sauber Kasse, Payment und PMS zusammenspielen.

KDS – Kitchen Display System

#

Herkunft: der Küchenbon, digital gedacht

Bestellungen laufen nicht mehr auf den Bondrucker, sondern auf Bildschirme in der Küche: mit Gangfolge, Zeiten, Prioritäten und Status. Service und Küche sehen denselben Stand – was fertig ist, was wartet, was drängt.

In der PraxisEin KDS ist so gut wie die Prozesse dahinter: Wer die Gangsteuerung im Team nicht lebt, digitalisiert nur das Chaos vom Papier auf den Bildschirm.

QR-Order

#

Herkunft: die Speisekarte, um Bestellung und Zahlung erweitert

Der Gast scannt einen QR-Code am Tisch, bestellt selbst – und bezahlt je nach Lösung gleich mit. Die Bestellung landet direkt in Kasse und Küche, ohne Umweg über den Block.

Die Kernfrage ist die Integration: Läuft QR-Order in Kasse, Warenwirtschaft und Tagesabschluss mit – oder entsteht eine Insellösung mit eigener Abrechnung daneben?

In der PraxisQR-Order ersetzt nicht den Service, sondern verschiebt ihn: weniger Aufnehmen, mehr Gastgeben – wenn Prozesse und Systeme mitziehen.

Ein Begriff fehlt?

Dieses Glossar wächst aus der Praxis – aus Projekten, Partnergesprächen und dem fachlichen Austausch, den ich u. a. beim DFKA pflege. Wenn ein Begriff fehlt oder eine Erklärung unscharf ist: kurze E-Mail genügt.

Begriff vorschlagen

Austausch statt Angebot: Diese Seite ist Wissensdarbietung, kein Beratungs- oder Dienstleistungsangebot.

Häufige Fragen zum Glossar.

Anspruch, Arbeitsweise und Grenzen dieser Begriffssammlung – kurz beantwortet.

Stand: Juli 2026

Was erklärt dieses Glossar?

Das Glossar erklärt 20 Begriffe aus Fiskalisierung, Payment und Kassenwelt, die in Projekten wirklich fallen – von GoB, GoBD, TSE und DSFinV-K über Acquirer, Interchange und PSP bis zu PMS-Schnittstelle und QR-Order (Stand: Juli 2026, wird gepflegt). Jeder Begriff wird vom Ursprung her erklärt, damit Regeln herleitbar statt auswendig lernbar werden.

Worin unterscheidet sich dieses Glossar von anderen Kassen-Lexika?

Dieses Glossar erklärt Begriffe aus der Praxis von über 500 Kassenprojekten und immer entlang der Herleitungskette – etwa GoB → GDPdU → GoBD → KassenSichV → TSE → DSFinV-K als eine Linie statt sechs Einzelthemen. Alle Einträge sind herstellerneutral: keine Produktempfehlungen, keine Rankings. Die Einträge werden gepflegt und tragen sichtbar den Stand Juli 2026, damit nachvollziehbar bleibt, worauf sich jede Definition bezieht.

Ersetzt das Glossar eine Rechts- oder Steuerberatung?

Nein – das Glossar ist Einordnung aus der Praxis, keine Rechts- oder Steuerberatung. Verbindlich sind die Gesetzestexte, die BMF-Schreiben und die individuelle steuerliche Beratung. Rechts- und Steuerfragen beantwortet die Seite deshalb nur nach aktuellem Stand und mit Verweis auf die jeweils zuständigen Stellen. Diese Seite ist Wissensdarbietung, kein Beratungs- oder Dienstleistungsangebot.

Lust auf fachlichen Austausch?

Diese Seite verkauft nichts und berät nicht – sie gibt Wissen weiter. Wer über die Inhalte diskutieren, sie ergänzen oder ihnen widersprechen möchte: Der fachliche Austausch ist ausdrücklich willkommen.

kontakt@robertzelgin.de

Austausch statt Angebot: Diese Seite ist Wissensdarbietung, kein Beratungs- oder Dienstleistungsangebot.