Eine API macht noch kein offenes Kassensystem

Wenn größere Interessenten KORONA kennenlernen wollen, präsentieren meistens unsere Kollegen Christian und Martin. Sitzt auf der anderen Seite ein IT-Leiter, Softwarespezialist oder ein Systemarchitekt, holen sie mich gern dazu.

Die erste halbe Stunde sage ich wenig. Dann kommen die technischen Fragen. Und mit erstaunlicher Zuverlässigkeit diese hier:

„Haben Sie eine API?“

Ja. Haben wir.

Damit wäre alles erledigt. Haken in die Liste, nächste Zeile, alle zufrieden.

Ich bohre aber lieber nach:

„Eine API haben wir, aber damit wissen Sie noch gar nichts über unsere Lösung.“

Danach wird das Gespräch meist richtig interessant. Ob ein Kassensystem offen ist, hängt nämlich kaum davon ab, ob es eine API hat. Viel mehr davon, was Sie damit machen können und dürfen.

Mein Arbeitsbegriff ist ziemlich simpel. Ein offenes Kassensystem lässt Sie über dokumentierte Schnittstellen an Ihre wichtigen Daten und Prozesse. Sie und Ihre Partner dürfen damit arbeiten. Und wenn Sie gehen, nehmen Sie Ihre Daten vollständig mit. Alles andere ist ein Etikett.

Ob ein Kassensystem eine API hat, ist ungefähr so aufschlussreich wie die Frage, ob ein Auto einen Motor hat. Hat es. Jedes. Interessant wird es erst bei der Frage, ob Sie damit einen Anhänger ziehen können.

Was wollen Sie denn über die Schnittstelle machen? Artikel und Preise übertragen? Bestände in Echtzeit abfragen? Einem Loyalty-Programm nach jedem Kauf den vollständigen Beleg schicken? Eigene Oberflächen bauen? Partner neue Funktionen ergänzen lassen? Oder beim nächsten Systemwechsel alles mitnehmen?

Das sind sechs völlig verschiedene Anforderungen. Eine API kann alle sechs abdecken. Sie kann aber auch einmal pro Nacht eine Datei mit Artikelnummern auf einen schimmligen FTP-Server legen. Beides heißt Schnittstelle. Beides bekommt den Haken.

Dass so gefragt wird, liegt übrigens nicht an den Kunden. Das haben wir Anbieter uns selbst eingebrockt. Wir haben jahrelang Etiketten verkauft. Irgendwann hat der Markt gelernt, nach Etiketten zu fragen.

Cloud? Ja. Headless? Ja. API First? Ja. KI? Ja.

Manche Anforderungskataloge sind länger als die Bedienungsanleitung der Lösungen. Ich glaube, dass einige Zeilen darin seit Jahren von Ausschreibung zu Ausschreibung weitergereicht werden. Keiner weiß mehr genau, warum sie drinstehen.

Ich frage deshalb zurück: „Was wollen Sie über die API konkret abbilden?“

Manchmal kommt eine klare Antwort. Dann reden wir über echte Prozesse.

Manchmal auch nicht. Die API steht in der Liste, aber keiner weiß, wofür. Für später, heißt es dann.

Dieses „für später“ ist Gedöns und später oft der teuerste Posten im ganzen Projekt. Er steht nur in keinem Angebot.

Ein Loyalty-Anbieter soll z. B. nach jedem Kauf die Belegpositionen bekommen. Klingt nach einer kleinen Datenübertragung.

Dann kommen die Details. Ist der Beleg sofort da oder erst nach dem Tagesabschluss? Sind Rabatte, Gutscheine und Retouren drin? Gibt es eindeutige IDs für Kunde, Artikel und Transaktion? Wird das Loyalty-System aktiv benachrichtigt oder muss es alle paar Minuten nachfragen? Was passiert, wenn die Leitung zehn Minuten weg ist? Und wenn ein Beleg zweimal ankommt, bekommt die Kundin dann doppelt Punkte?

Spätestens hier redet niemand mehr darüber, ob es eine API gibt. Jetzt geht es darum, ob ein Geschäftsprozess hält. Samstag um 11 und zwanzig Leute in der Schlange.

Sie kennen die Folie. Meist links oder oben ERP, CRM, Warenwirtschaft. Rechts oder unten Kasse, Webshop und App. In der Mitte ein Kasten, auf dem API steht. Pfeile rein, Pfeile raus. Sieht offen aus. Sieht modern aus.

Ich habe solche Folien bei vielen Anbietern gesehen. Bei uns übrigens auch. Der Kasten in der Mitte kostet nichts, man malt ihn einfach dahin.

Was wirklich zählt, steht fast nie drauf. Wer darf die API nutzen? Nur der Hersteller oder auch Sie und Ihre Partner? Was lässt sich lesen, was schreiben? Gibt es ein Testsystem? Eine Dokumentation, die ein Entwickler ohne kostenpflichtigen Telefonjoker versteht? Nachvollziehbare Fehlercodes? Was kostet die Nutzung, gibt es Limits? Braucht jeder neue Anwendungsfall erst ein eigenes Projekt beim Hersteller?

Wenn ein Anbieter bei diesen Fragen schnell auf die nächste Folie klickt, haben Sie Ihre Antwort.

Ein Begriff, den ich in diesem Zusammenhang besonders mag, ist OpenAPI. Klingt schon so schön offen.

OpenAPI ist ein guter und weit verbreiteter Standard, um HTTP-APIs zu beschreiben. Entwickler sehen damit, welche Aufrufe es gibt und wie die Daten aussehen. Man kann Dokumentation, Tests und sogar Programmcode daraus erzeugen. Technisch eine feine Sache.

Mit Offenheit hat der Name aber erst mal gar nichts zu tun. Eine perfekt beschriebene Schnittstelle kann trotzdem komplett zu sein. Vielleicht darf nur der Hersteller ran. Vielleicht deckt sie zehn Prozent der Prozesse ab. Vielleicht ist sie so teuer, dass sie nur im Konzernprojekt jemand bezahlt.

OpenAPI beschreibt die Tür sehr ordentlich. Ob Sie einen Schlüssel bekommen und was dahinter liegt, steht nicht in der Spezifikation.

Meine Lieblingsfrage an jeden Anbieter, uns eingeschlossen: „Wie bekommen wir unsere Daten wieder raus?“

In einer ersten Präsentation wirkt die Frage fast unhöflich. Man lernt sich gerade kennen und redet schon über die Trennung.

Genau deshalb sollten Sie sie stellen, solange die Anbieter noch um Sie werben.

Wer von Offenheit spricht, muss erklären können, wie Artikel, Kunden, Bestände, Transaktionen und historische Belege vollständig exportiert werden. Dokumentiert und in einer Form, mit der ein anderes System etwas anfangen kann. Ein riesiger CSV-Export ist Gedöns und keine Antwort. Man kann auch den Aktenschrank aus dem Fenster kippen und behaupten, die Unterlagen seien jetzt frei zugänglich.

Achten Sie dabei auf die Reaktion. Ein Anbieter, der bei dieser Frage nervös wird, verrät Ihnen mehr über sein Geschäftsmodell als in der ganzen Präsentation.

Die liebe EU sieht das inzwischen ähnlich. Der Data Act gilt seit September 2025. Er enthält für bestimmte Datenverarbeitungsdienste Regeln, die den Anbieterwechsel erleichtern sollen, je nach Voraussetzungen auch offene Schnittstellen und den Export in einem gängigen, maschinenlesbaren Format. Macht das jedes Kassensystem automatisch offen? Nein. Den Blick in den eigenen Vertrag ersetzt es auch nicht. Die Richtung ist aber ziemlich eindeutig. Ihre Daten gehören Ihnen. Eigentlich hätte man dafür kein Gesetz gebraucht.

Jetzt wird es etwas empfindlich. Sorry.

Ich habe gesehen, dass einige Anbieter ihre über viele Jahre gewachsene Software mit ein paar Schnittstellen nachrüsten. Kurz darauf steht API First auf der Startseite.

Geändert hat sich dabei vor allem die Website.

API First heißt, dass die Schnittstellen von Anfang an das Fundament sind und kein späterer Anbau. Der Hersteller betreibt seine eigenen Anwendungen über dieselben Schnittstellen, die auch Sie und Ihre Partner bekommen. Das lässt sich leicht testen. Fragen Sie einfach, ob die eigene Kassenoberfläche des Anbieters über genau die API läuft, die Sie nutzen würden.

Wenn die eigene Oberfläche bequem durch den Haupteingang geht und externe Entwickler durchs Kellerfenster klettern müssen, dann ist das eben ein Kellerfenster mit gutem Marketing.

Bei Headless POS läuft dasselbe Spiel. Eine Kasse wird nicht headless, weil sie Daten an andere Systeme schicken kann. Headless heißt, Oberfläche und Geschäftslogik sind wirklich getrennt. Preise, Steuern, Aktionen und Belege laufen in einem gemeinsamen Kern. Darauf greift zu, was gerade gebraucht wird; die Kasse an der Theke, das Self-Service-Terminal, das Tablet im Gang, der Webshop oder eine App, die Ihr eigenes Team gebaut hat.

Die Oberfläche kann wechseln. Die Logik bleibt. Diese Entscheidung fällt ganz am Anfang der Architektur. Auf einer Marketingfolie lässt sie sich nicht nachholen.

Ich spreche regelmäßig mit CEOs oder CTOs anderer Anbieter, also unserer Wettbewerber. Oft ziemlich offen, man kennt sich ja schon ewig. Die wissen meist sehr genau, wo ihr System steht. Da ist niemand naiv.

Viele können aber schlicht nicht anders. Ein kompletter Neubau kostet Jahre und sehr viel Geld. Und es gibt Investoren, die so eine Baustelle nicht mittragen wollen. Lieber die nächste Quartalszahl als drei Jahre Umbau mit offenem Ausgang. Also wird angebaut. Noch eine Schnittstelle. Noch ein Modul. Noch ein Begriff auf der Website.

Ich habe da natürlich gut reden. Wir haben uns entschieden, KORONA neu zu bauen, statt immer weiter anzuflanschen. Diese Freiheit hat nicht jeder. Das weiß ich.

Wundern darf ich mich trotzdem. Und fragen auch. Wie weit kommt man eigentlich noch mit einem Tech-Stack, der in einer Zeit entstanden ist, als die Kasse noch ein Gerät mit Schublade war? Wie viele Schichten kann man auf ein altes Fundament legen, bevor es kracht? Und wer merkt das Knirschen zuerst, der Hersteller oder sein Kunde?

Für Sie als Handelsunternehmen ist das keine akademische Frage. Sie kaufen ja nicht die Folie. Sie kaufen das Fundament. Und mit dem leben Sie die nächsten zehn Jahre.

Ich sage übrigens selbst lieber POS-Plattform als Kassensystem. In Ausschreibungen steht aber Kassensystem, gesucht wird auch danach. Also bleiben wir in der Beantwortung meistens dabei.

Das EHI ist da schon einen Schritt weiter. Seine aktuelle Studie heißt „Checkout-Trends 2026. Vom physischen Terminal zur vernetzten Plattform“. Das finde ich gut.

Die Zahlen darin sind deutlich. Die Kassensoftware im deutschsprachigen Handel ist im Schnitt 6,9 Jahre alt. Rund die Hälfte der befragten Händler plant einen Wechsel. Besonders gefragt sind individuelle Lösungen, die sich eng an die vorhandenen Systeme anschließen lassen.

Die letzte Zeile lohnt sich zweimal zu lesen. Der Handel will sich nicht mehr an die Software anpassen. Die Software soll sich an den Handel anpassen. Das klappt nur mit einer Plattform, die wirklich offen ist. Ein API-Kasten auf einer Folie reicht dafür nicht.

Wer jetzt ein Kassensystem auswählt, entscheidet also nicht über ein paar Kassenplätze. Er entscheidet, wie beweglich sein Unternehmen in den nächsten Jahren ist. Dafür ist „Haben Sie eine API?“ deutlich zu wenig.

Statt fünfzig Häkchen würde ich fünf Fragen stellen. Jedem Anbieter. Uns auch. 

Wer darauf klare Antworten hat, braucht keine Folie mit Pfeilen.

Ich nehme uns da nicht raus. Wäre auch ein bisschen einfach.

Auch wir reden über offene APIs, API First und Headless POS. Auch wir haben Folien mit Kästen und Pfeilen (eigentlich nur eine). Also müssen wir uns genau dieselben Fragen gefallen lassen.

Wenn wir sagen, KORONA ist offen, dann glauben Sie uns das bitte nicht einfach. Bringen Sie Ihren schwierigsten Prozess mit. Lassen Sie sich die Dokumentation zeigen. Fragen Sie nach Grenzen, nach Kosten und danach, was noch auf der Roadmap steht.

Und wenn etwas erst auf der Roadmap steht, sagen wir das auch so. Eine geplante Funktion ist noch keine vorhandene. Eine einzelne Schnittstelle macht noch keine Plattform. Und eine gute Präsentation ist noch kein bestandener Praxistest. Unsere auch nicht.

Was wir mit KORONA bauen, sieht so aus: Oberflächen und Geschäftslogik sind getrennt. Unterschiedliche Touchpoints greifen auf einen gemeinsamen Business Core zu. Integrationen können von uns kommen, von Partnern oder direkt vom Entwicklungsteam des Kunden.

Den Test von oben machen wir übrigens auch selbst. Unsere eigene Kassenoberfläche läuft über dieselbe API, die Sie und Ihre Partner bekommen. Die Dokumentation ist öffentlich. Schauen Sie ruhig rein, bevor wir überhaupt miteinander reden.

Das ist unser Anspruch. Ob wir ihn für Ihren Fall erfüllen, finden Sie am besten selbst heraus. Gern auch mit unbequemen Fragen.

Am einfachsten geht das mit einem echten Fall. Schicken Sie uns Ihren kniffligsten Prozess. Wir spielen ihn mit Ihnen durch, live über die API.

Nein. REST beschreibt nur, wie zwei Systeme technisch miteinander reden. Über den Umfang sagt das gar nichts. Offen ist ein Kassensystem erst, wenn die wichtigen Daten und Prozesse über die Schnittstelle erreichbar sind und Sie und Ihre Partner sie auch nutzen dürfen. Dazu kommen die kommerziellen Bedingungen wie Kosten, Limits und Vertrag. Die müssen das im Alltag auch hergeben.

Ein klassisches Kassensystem ist vor allem für den Verkauf an der Kasse gebaut. Alles andere wird drumherum angeschlossen. Eine POS-Plattform stellt die Geschäftslogik zentral bereit, also Preise, Steuern, Aktionen und Belege. Kasse, Self-Service, mobile Geräte, Webshop und eigene Anwendungen greifen auf denselben Kern zu. So rechnet jeder Kanal gleich, und ein neuer Touchpoint braucht keine eigene Logik.

Einen echten Prozess aus Ihrem Unternehmen, live über die API. Am besten den, bei dem Ihr Team heute am meisten flucht. Dazu die Dokumentation und Zugang zu einem Testsystem, und zwar vor der Unterschrift. Fragen Sie auch, wie neue API-Versionen angekündigt werden und wie lange alte weiterlaufen. Und lassen Sie sich einmal einen vollständigen Datenexport zeigen.

Daran, dass der Hersteller seine eigenen Anwendungen über dieselben Schnittstellen betreibt, die auch Kunden und Partner bekommen. Das können Sie im Termin direkt fragen. Eine nachträglich ergänzte API stellt meist nur ausgewählte Funktionen einer bestehenden Anwendung bereit. Die Lücken liegen dann oft genau da, wo es im Alltag hakt, etwa bei Retouren, Gutscheinen oder Aktionen.

Fragen Sie das vor Vertragsabschluss und nicht erst bei der Kündigung. Lassen Sie sich zeigen, wie Artikel, Kunden, Bestände, Transaktionen und historische Belege exportiert werden, in welchem Format und mit welcher Dokumentation. Ein Export hilft nur, wenn ein anderes System ihn auch lesen kann. Schauen Sie außerdem, was Ihr Vertrag zum Wechsel regelt. Der EU Data Act stärkt Ihre Position, den Blick in den Vertrag ersetzt er aber nicht.