Start / Glossar

POS & Payment für Gastronomie, Hotellerie und Handel

Begriffe aus
der Praxis.

Fiskalisierung, Payment, Kassenwelt und KI: 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.

36 Begriffe · Stand: 02.09.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. Ab 2028 soll daraus nach dem Referentenentwurf eine elektronische Belegbereitstellungspflicht werden.

QR-Beleg

#

Herkunft: Referentenentwurf Kassenpflicht (BMF, 07.08.2026)

Der digitale Kassenbeleg als QR-Code auf dem Kassendisplay: Der Gast scannt ihn mit dem Handy, statt einen Papierbon gereicht zu bekommen. Der Referentenentwurf vom 07.08.2026 ersetzt die papierhafte Belegausgabepflicht zum 01.01.2028 durch eine elektronische Belegbereitstellungspflicht – der QR-Code ist einer der zulässigen Wege, neben E-Mail, NFC und Download; angeboten werden muss der Beleg weiterhin für jeden Geschäftsvorfall, Papier gibt es auf Wunsch. Status: Referentenentwurf, kein Gesetz.

In der PraxisFür Kassensysteme ist das mehr als ein Feature: Display, Software und Ablauf am Tresen müssen den QR-Beleg können – ein Auswahlkriterium beim nächsten Systemwechsel.

Belegbereitstellungspflicht

#

Herkunft: Referentenentwurf Kassenpflicht (BMF, 07.08.2026) – Nachfolger der Belegausgabepflicht

Die geplante Weiterentwicklung der Belegausgabepflicht: Statt den Bon auf Papier zu drucken, muss die Kasse ihn ab dem 01.01.2028 für jeden Geschäftsvorfall in einem standardisierten elektronischen Format bereitstellen – technikneutral per QR-Code auf dem Display, E-Mail, NFC oder Download. Papier gibt es weiterhin auf Wunsch. Der Referentenentwurf vom 07.08.2026 sieht die vollständige Ablösung zum 01.01.2028 vor; das Gesetzgebungsverfahren läuft, ein Gesetz existiert noch nicht.

In der PraxisFür die Systemauswahl ist das ab sofort ein Kriterium: Kann die Kasse Belege elektronisch bereitstellen – standardisiert, nicht nur als PDF-Mail? Wer 2026 ein System kauft, sollte diese Funktion mit ausschreiben statt 2027 nachzurüsten. Die Einordnung im Artikel →

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.

Aufbewahrungsfristen / BEG IV

#

Herkunft: Viertes Bürokratieentlastungsgesetz, seit 01.01.2025

Das Bürokratieentlastungsgesetz IV hat die Aufbewahrungsfrist für Buchungsbelege – dazu zählen Kassendaten, Tagesabschlüsse und Rechnungen – von 10 auf 8 Jahre verkürzt (§ 147 AO, § 257 HGB, § 14b UStG). Handelsbücher, Inventare und Jahresabschlüsse bleiben bei 10 Jahren; erfüllt ein Dokument beide Funktionen, gilt die längere Frist.

In der PraxisGegenbewegung beachten: Der Aktionsplan vom 16.07.2026 will für Buchungsbelege wieder 15 Jahre (geplant, kein Entwurf). Bis zur Klärung gilt: Fristen kennen, im Zweifel behalten – besonders DSFinV-K-Exporte und die Archive getauschter TSEs.

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.

Netzbetreiber

#

Herkunft: deutsche Kartenzahlungs-Infrastruktur

Der Dienstleister zwischen Terminal und Bankenwelt – historisch in zwei Rollen: Der technische Netzbetreiber routet die Transaktion vom Terminal zu den Autorisierungssystemen, der kaufmännische Netzbetreiber übernimmt Abrechnung und Service. Die Abwicklung der Zahlungen selbst (Acquiring) ist erlaubnispflichtig – die ZAG-Erlaubnis dafür erteilt die BaFin; rein technische Dienstleister sind davon ausgenommen.

In der PraxisTerminal, Netzbetrieb und Acquiring können bei einem Anbieter liegen – oder bei dreien. Wer kündigt oder wechselt, sollte wissen, welche Rolle in welchem Vertrag steckt.

Acquirer Service Fee

#

Herkunft: Preismodell der Kartenakzeptanz

Der Entgeltbestandteil des Acquirers für seine eigene Leistung: Abwicklung, Risiko, Auszahlung, Service. Zusammen mit der Interchange (an den Issuer) und der Scheme Fee (an das Kartensystem) ergibt sie die Händlerkondition einer Kartenzahlung – bei Interchange++-Modellen als eigene Zeile ausgewiesen, bei Pauschalpreisen einkalkuliert.

In der PraxisInterchange und Scheme Fee sind weitgehend gesetzt – die Service Fee ist der Teil der Kondition, über den man mit dem Acquirer tatsächlich spricht.

Surcharging

#

Herkunft: § 270a BGB, seit 2018

Ein Aufschlag auf den Preis, weil der Gast mit Karte zahlt. Für die gängigen Privatkundenkarten und SEPA-Verfahren ist Surcharging in Deutschland verboten; zulässig bleibt es unter anderem bei Firmenkarten, Drei-Parteien-Systemen wie American Express und Karten von außerhalb des EU-/EWR-Raums.

In der PraxisDas häufigste Missverständnis: „Kartenzahlung erst ab 10 €" ist kein Surcharging – aber ein eigenes Ärgernis. Wer Aufschläge erhebt, muss die Ausnahmen exakt kennen; sauberer ist, die Kosten in die Kalkulation zu nehmen statt auf den Bon.

ELV – Elektronisches Lastschriftverfahren

#

Herkunft: deutsches girocard-Umfeld

Kartenzahlung, abgewickelt als SEPA-Lastschrift statt über die girocard-Autorisierung: Das Terminal liest die Kartendaten, der Gast unterschreibt ein Lastschriftmandat. Günstig in der Abwicklung, aber ohne Zahlungsgarantie – die Lastschrift kann zurückgehen; das Risiko trägt der Betrieb oder ein ELV-Dienstleister mit eigenem Mahnwesen.

In der PraxisELV lebt vom Preisvorteil und stirbt am Risiko. In Verträgen lohnt der Blick, ob und wann der Anbieter auf ELV routet – und wer bei Rückläufern zahlt.

BNPL – Buy Now, Pay Later

#

Herkunft: Online-Handel

Bezahlen per Ratenzahlung oder aufgeschobener Zahlung über einen BNPL-Anbieter: Der Händler bekommt sein Geld sofort, der Anbieter übernimmt Ausfallrisiko und Forderung – gegen Gebühr. Im Gastgewerbe am Tresen bislang Nische, relevant im Online-Geschäft: Gutscheine, Arrangements, Tagungen, hochpreisige Buchungen.

In der PraxisDie Frage vor der Einführung ist dieselbe wie bei jeder Zahlart: Was kostet sie, welchen Umsatz bringt sie zusätzlich – und passt sie zum Konzept?

Wero

#

Herkunft: European Payments Initiative (EPI)

Das europäische Bezahlverfahren der European Payments Initiative: Konto-zu-Konto-Zahlungen in Echtzeit, gestartet als Handy-zu-Handy-Überweisung, ausgebaut Richtung E-Commerce und Handel. Getragen von großen europäischen Bankengruppen; in den Niederlanden löst Wero das dortige Verfahren iDEAL ab.

In der PraxisDer ernsthafteste europäische Anlauf zu mehr Unabhängigkeit von internationalen Kartensystemen. Für Betriebe noch kein To-do – aber ein Verfahren, das man auf dem Zettel hat.

Omnichannel

#

Herkunft: Handels- und Payment-Strategie

Alle Verkaufskanäle eines Betriebs – Tresen, Web, App, Plattform, Self-Ordering – laufen auf eine gemeinsame Daten- und Zahlungsbasis: ein Gast, ein Gutschein, eine Auswertung, egal wo gekauft wird. Das Gegenteil sind Insellösungen, die Umsätze und Kundendaten nebeneinander sammeln.

In der PraxisDer Prüfstein ist der Gutschein: online gekauft, an der Theke eingelöst, in der Auswertung sichtbar? Wenn ja, ist es Omnichannel – wenn nicht, sind es Inseln.

Trinkgeld-Funktion

#

Herkunft: Kartenterminal und Kassen-Setup

Die Terminal- oder Kassenfunktion, mit der der Gast bei Kartenzahlung Trinkgeld geben kann. Richtig eingerichtet, läuft das Trinkgeld getrennt vom Umsatz durch Kasse und Buchhaltung und kommt beim Team an; freiwilliges Trinkgeld an Angestellte bleibt steuerfrei.

In der PraxisDer unterschätzte Punkt ist der Ablauf: Wo das Terminal die Trinkgeld-Frage versteckt, sinkt das Trinkgeld. Technik, Buchung und Team-Absprache gehören zusammen aufgesetzt.

Cluster /03

Kasse, Software & Betrieb

Vom Küchenbon zur Cloud: Kasse → Schnittstellen → Warenwirtschaft · 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.

Warenwirtschaft (WaWi)

#

Herkunft: die zentralen Daten des Handels

Die Software, die Artikelstamm, Preise, Bestände, Bestellwesen und Lieferanten führt – im Sprachgebrauch „WaWi“, in größeren Häusern Teil eines ERP. Die Kasse bezieht Artikel und Preise von dort und meldet Verkäufe, Retouren und Zahlungen zurück; jeder Bon ist zugleich eine Bestandsbewegung. Viele POS-Systeme bringen heute selbst eine leistungsfähige Artikelverwaltung mit Lager und Bestellwesen mit – erst bei mehreren Standorten, Onlineshop oder großen Sortimenten übernimmt in der Regel ein eigenes Warenwirtschafts- oder ERP-System die Führung.

In der PraxisVerkauft wird das Feature, betrieben wird die Schnittstelle – und die wichtigste im Handel heißt Warenwirtschaft ⇄ Kasse. Die Handelsseite: Kasse, Warenwirtschaft & Filialnetz →

Einzweck- und Mehrzweck-Gutschein

#

Herkunft: § 3 Abs. 13–15 UStG (seit 01.01.2019) – zwei Gutscheinarten, zwei Kassenlogiken

Beim Einzweck-Gutschein stehen Leistungsort und Umsatzsteuersatz bei der Ausgabe fest; die Umsatzsteuer entsteht grundsätzlich schon bei Ausgabe oder Übertragung. Beim Mehrzweck-Gutschein ist mindestens eines davon offen – etwa weil Speisen und Getränke oder Verzehr im Haus und außer Haus unterschiedlich besteuert werden; die Umsatzsteuer entsteht grundsätzlich erst bei Einlösung. In Kassensystemen wird der Einzweck-Gutschein deshalb typischerweise bei Ausgabe mit der feststehenden steuerlichen Behandlung abgebildet, der Mehrzweck-Gutschein zunächst als Zahlungsmittel oder Guthaben geführt.

In der PraxisIn der Gastronomie ist der Mehrzweck-Gutschein der Normalfall. Welche Variante steuerlich vorliegt, klärt die Steuerberatung – die Kasse muss beide sauber buchen und im DSFinV-K-Export getrennt ausweisen können. Wertkarten, Gutscheine & Bonus auf der Handelsseite →

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.

RAG – Retrieval-Augmented Generation

#

Herkunft: KI-Architektur

Ein KI-Ansatz, bei dem das Sprachmodell nicht aus dem Gedächtnis antwortet, sondern zuerst in einer Wissensbasis nachschlägt – etwa im Produkthandbuch – und die Antwort aus den Fundstellen baut. Qualität und Verlässlichkeit hängen damit an der Dokumentation, nicht am Modell.

In der PraxisFür Software-Anbieter der Maßstab: Ist die Doku RAG-fähig gegliedert – Einzelartikel, eine Aussage pro Abschnitt, Versionsstand –, können Support-Assistenten daraus verlässlich antworten.

Corporate LLM

#

Herkunft: unternehmensinterner KI-Einsatz

Ein Sprachmodell-Setup unter Kontrolle des Unternehmens: Die KI arbeitet auf einer internen Wissensdatenbank, kann gezielt online zugreifen, bleibt aber unabhängig von internationalen KI-Plattformen – und Betriebsdaten fließen nicht ins Training fremder Modelle.

In der PraxisBeim Software-Einkauf die Datenschutz-Frage in einem Satz: Wo läuft die KI, und was passiert mit unseren Daten? Ein Anbieter mit Corporate-LLM-Ansatz kann sie beantworten.

Agentic Commerce

#

Herkunft: KI-Agenten im digitalen Vertrieb

Kaufvorgänge, die ein KI-Agent im Auftrag des Nutzers eigenständig erledigt: suchen, vergleichen, reservieren – perspektivisch auch bezahlen. Der erste Kontakt mit dem Betrieb ist dann keine Person, sondern eine Maschine, die nur findet und bucht, was sie lesen kann.

In der PraxisVorbereitung heißt Maschinenlesbarkeit: strukturierte Daten, saubere Schnittstellen, konsistente Fakten – dieselbe Hausaufgabe wie für KI-Suchantworten, nur mit Umsatz direkt dahinter.

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: 02.09.2026

Was ist eine TSE (Technische Sicherheitseinrichtung)?

Die TSE ist das zertifizierte Sicherheitsmodul, das seit 2020 jede elektronische Kasse in Deutschland braucht (§ 146a AO, KassenSichV). Sie signiert jeden Kassenvorgang fälschungssicher – als Hardware-Modul (USB/SD) oder als Cloud-TSE. Zertifikate laufen ab (je nach Bauart nach einigen Jahren) und müssen rechtzeitig getauscht oder verlängert werden – sonst arbeitet die Kasse nicht mehr gesetzeskonform.

Was bedeutet GoBD – einfach erklärt?

GoBD steht für die „Grundsätze zur ordnungsmäßigen Führung und Aufbewahrung von Büchern, Aufzeichnungen und Unterlagen in elektronischer Form sowie zum Datenzugriff". Übersetzt: Digitale Aufzeichnungen – auch Kassendaten – müssen vollständig, unveränderbar und nachvollziehbar sein. Für die Kasse heißt das konkret: Einzelaufzeichnung jedes Geschäftsvorfalls, keine nachträglichen Änderungen ohne Protokoll, geordnete und fristgerechte Aufbewahrung.

Registrierkasse oder Kassensystem – was ist der Unterschied?

Registrierkasse meint klassisch das einzelne Gerät mit Bonrolle; ein Kassensystem ist die vernetzte Lösung aus Software, Hardware, Schnittstellen und Payment – vom Tablet bis zur Mehrplatz-Installation mit Küchenmonitor. Steuerlich behandelt Deutschland beide gleich: Elektronisch heißt TSE-pflichtig. Die zum 01.01.2028 angekündigte Registrierkassenpflicht (Status: Ankündigung) würde erstmals die Nutzung elektronischer Kassen selbst vorschreiben.

Was ist der Unterschied zwischen Acquirer und Netzbetreiber?

Der Acquirer ist die Händlerbank: Er nimmt die Kartenzahlung an, verantwortet die Abwicklung und zahlt den Umsatz aus – dafür braucht er eine ZAG-Erlaubnis der BaFin. Der Netzbetreiber ist der Dienstleister zwischen Terminal und Bankenwelt: technisch (Routing der Transaktion) und/oder kaufmännisch (Abrechnung, Service). In der Praxis treten beide Rollen oft unter einer Marke auf – im Vertrag lohnt der Blick, wer welche Leistung tatsächlich erbringt.

Was ist Wero – und muss ich es schon anbieten?

Wero ist das Konto-zu-Konto-Bezahlverfahren der European Payments Initiative (EPI), getragen von großen europäischen Banken: Echtzeit-Zahlungen vom Handy, gestartet im privaten Bereich, ausgebaut Richtung Handel und E-Commerce; in den Niederlanden ersetzt es das Verfahren iDEAL. Für deutsche Gastro- und Hotelbetriebe besteht kein Handlungsdruck – die Akzeptanz kommt, wenn Terminals und Payment-Anbieter sie ausrollen. Beobachten reicht.

Was ist ein Corporate LLM – und warum ist das für Betriebe relevant?

Ein Corporate LLM ist ein Sprachmodell-Setup unter Kontrolle des Unternehmens: interne Wissensbasis, kontrollierter Online-Zugriff, keine Weitergabe von Betriebsdaten ins Training fremder Modelle. Relevant wird das beim Software-Einkauf: Wer Kassen-, PMS- oder Support-KI nutzt, gibt sonst womöglich Gäste- und Umsatzdaten an internationale Plattformen. Die Prüf-Frage an jeden Anbieter: Wo läuft die KI, und was passiert mit unseren Daten?

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.