Ein Kunde bezahlt in einem Münchner Café einen Flat White. Das Tablet auf der Theke schickt den Verkauf an einen Signaturdienst, erhält eine Signatur zurück und druckt sie auf den Beleg, bevor die Milch fertig aufgeschäumt ist. An der Theke denkt niemand darüber nach, aber an diesem Schritt von einer Sekunde sind alle vier Akteure der Fiskalisierung beteiligt: das Café, das Unternehmen hinter der Kassensoftware auf dem Tablet, der Anbieter der Sicherheitskomponente, die den Verkauf signiert hat, und die Steuerbehörde, die die Regeln durchsetzt, welche die Signatur überhaupt erst nötig machen.
Jeder von ihnen trägt einen anderen Teil der Aufgabe, und das Gesetz verteilt diese Teile von Land zu Land unterschiedlich. Wer was verantwortet, ist vor allem dann wichtig, wenn Sie Kassensoftware entwickeln: Ihr Produkt ist der Ort, an dem die anderen drei zusammenkommen.
Das Wichtigste in Kürze
Das Unternehmen erfasst den Verkauf und behält die rechtliche Verantwortung für seine Aufzeichnungen, auch wenn es jede technische Komponente zukauft. Der EPOS- oder MPOS-Anbieter liefert das System und hat in mehreren Märkten eigene gesetzliche Pflichten. Der Anbieter der Sicherheitskomponente signiert jede Transaktion, damit sie nicht unbemerkt verändert werden kann. Die Steuerbehörde erhält die Daten entweder per Übermittlung (in Italien täglich, im spanischen Verifactu-Modus Datensatz für Datensatz) oder auf Anforderung bei einer Prüfung (Deutschland, Österreich, Frankreich, Schweden).
Wer sind die Akteure der Fiskalisierung?
Die Fiskalisierung hat vier Akteure: das Unternehmen, das Verkäufe erfasst, den EPOS- oder MPOS-Anbieter, der sein Kassensystem baut, den Anbieter der Sicherheitskomponente, dessen Signatur jede Manipulation an einem Verkauf erkennbar macht, und die Steuerbehörde, die die Regeln durchsetzt und die Daten erhält. Die ersten drei sind durch Verträge und Integrationen verbunden; das Gesetz legt jedem von ihnen direkt Pflichten auf.
Es hilft, sich ein Dreieck vorzustellen. Das Unternehmen, der Kassenanbieter und der Anbieter der Sicherheitskomponente sitzen an den Ecken, verbunden durch Lizenzen und API-Aufrufe. Die Steuerbehörde sitzt in der Mitte, denn die Regeln, die sie durchsetzt, erreichen jede Ecke direkt, statt entlang der Kette weitergereicht zu werden.
Die Aufteilung hat einen Grund: Keine einzelne Partei kann einen Verkaufsdatensatz allein vertrauenswürdig machen. Ein Datensatz, den das Unternehmen von Anfang bis Ende kontrolliert, beweist einem Prüfer wenig, denn es ist das Unternehmen, das darauf Steuern zahlt. Der Kassenanbieter schreibt die Software, kann aber nicht für jeden Verkauf einstehen, der damit getätigt wird. Der Sicherheitsmechanismus liefert den Nachweis, dass ein Datensatz seit seiner Entstehung nicht verändert wurde: in den meisten Märkten eine Signatur von einer Komponente, die das Unternehmen nicht kontrolliert.
Das Unternehmen: trägt die Pflicht und die Aufzeichnungen
Die meisten Fiskalisierungsgesetze wenden sich zuerst an das Unternehmen. Nach § 146a der Abgabenordnung (AO) muss, wer Geschäftsvorfälle mit einem elektronischen Aufzeichnungssystem erfasst, dieses durch eine vom BSI zertifizierte technische Sicherheitseinrichtung (TSE) schützen und die Aufzeichnungen für Steuerprüfungen verfügbar halten. Dieselbe Vorschrift verpflichtet das Unternehmen, seinem Finanzamt die verwendeten Systeme mitzuteilen. Österreichische Unternehmen registrieren ihre Signaturerstellungseinheiten bei FinanzOnline, und schwedische Unternehmen melden ihre Kassen bei Skatteverket an und teilen Änderungen innerhalb von zwei Wochen mit.
Kurz gesagt: Das Unternehmen schuldet die Steuer, also gehört ihm auch der Nachweis.
Das gilt auch dann, wenn jede technische Komponente zugekauft ist. Ein Restaurant kann seine Kasse bei einem Anbieter beziehen und seinen Signaturdienst bei einem anderen, aber wenn ein Prüfer vor der Tür steht und die Transaktionsdaten verlangt, richtet sich die Anforderung an das Restaurant. Wer die Technik auslagert, lagert die Pflicht nicht mit aus.
Daraus ergibt sich, was das Unternehmen von den anderen beiden Ecken braucht. Es braucht ein System, das jeden Verkauf so erfasst, wie es die Regeln verlangen. Und dieses System muss alles liefern, was das Unternehmen einreichen oder vorlegen muss: Registrierungsdaten, Exporte, Belege. fiskalys Leitfäden zur KassenSichV in Deutschland und zur RKSV in Österreich behandeln diese Pflichten Markt für Markt.
Der EPOS- oder MPOS-Anbieter: baut das System, an das die anderen andocken
Kassenanbieter bauen und liefern das Kassensystem: ein EPOS (Electronic Point of Sale) auf einer festen Kasse oder einem Backoffice-Server oder ein MPOS (Mobile Point of Sale) auf einem Smartphone oder Tablet. In dieser Ecke wird aus einer gesetzlichen Anforderung ein Knopf, den eine Kassenkraft drückt. Hier verbinden sich auch die anderen beiden Ecken, denn das Unternehmen arbeitet im System, und die Sicherheitskomponente läuft darin.
Man nimmt leicht an, die Pflicht ende beim Händler. In mehreren Märkten sagt das Gesetz etwas anderes:
- Deutschland: § 146a Abs. 1 AO verbietet, Systeme, Software oder TSEs, die die Anforderungen nicht erfüllen, gewerbsmäßig zu bewerben oder in den Verkehr zu bringen.
- Spanien: Nach Artikel 13 des Real Decreto 1007/2023 bescheinigt der Hersteller für jede Version seiner Rechnungssoftware die Konformität in einer declaración responsable, einer unterschriebenen Erklärung, die er seinen Kunden übergibt. Seit dem 29. Juli 2025 müssen Hersteller angepasste Software anbieten. Die eigenen Pflichten der Unternehmen sollen im Oktober 2028 beginnen; eine offizielle Bestätigung steht mit Stand Oktober 2026 noch aus.
- Frankreich: Die Kassensoftware selbst muss ihre Konformität nachweisen, entweder durch eine Zertifizierung durch Dritte oder durch eine zweiteilige Attestierung. Den ersten Teil unterschreibt der Softwareherausgeber, den zweiten der Händler. Gültig ist die Attestierung nur mit beiden Teilen.
- Schweden: Für die Kasse selbst gilt eine Herstellererklärung nach SKVFS 2014:9, der Vorschrift von Skatteverket über die Anforderungen an Kassensysteme.
Händler, die ihre eigene Kasse bauen, besetzen zwei Ecken zugleich: Die Pflichten des Händlers und die des Anbieters liegen im selben Unternehmen. Frankreich zeigt, was das bedeuten kann: Ein Herausgeber, der an Dritte verkauft, darf seine Konformität selbst attestieren; Software, die nur für den internen Gebrauch entwickelt wurde, braucht dagegen eine Zertifizierung durch Dritte.
Der Anbieter der Sicherheitskomponente: signiert jede Transaktion
Eine Sicherheitskomponente ist der Teil des Systems, der einen Datensatz nachweisbar macht. Sie signiert jede Transaktion bei der Erfassung und verkettet sie in mehreren Märkten mit der vorherigen, sodass eine spätere Änderung oder Löschung die Kette bricht und bei einer Prüfung auffällt. Je nach Markt ist sie ein Hardwaremodul, eine Smartcard oder ein Cloud-Dienst, den die Kasse über eine API aufruft.
Das Bundesamt für Sicherheit in der Informationstechnik (BSI) beschreibt die Arbeitsteilung klar: Kassenhersteller integrieren in der Regel eine bereits zertifizierte TSE, statt selbst eine zu entwickeln und zertifizieren zu lassen, und die Zertifizierung umfasst nur die TSE, nicht die Kasse oder ihre Software. Wo ein Markt eine eigene Komponente vorsieht, wiederholt sich das Muster: Die Kasse integriert sie, und die Zulassung, die der Markt verlangt, bringt die Komponente mit, nicht die Kasse.
Was diese Zulassung ist, unterscheidet sich stärker, als das Wort „zertifiziert“ vermuten lässt: von einem BSI-Zertifikat in Deutschland bis zu gar keiner Produktzertifizierung in Österreich, und in Spanien und Frankreich kennt das Gesetz keine separate Komponente. Die Tabelle weiter unten stellt sechs Märkte nebeneinander.
Für den Kassenanbieter bedeutet das in der Regel eigene Anforderungen und eigenen Papierkram in jedem Markt. Für das Unternehmen bedeutet es, dass die Komponente meist unsichtbar bleibt: Sie erscheint als Code oder Signatur auf dem Beleg und, wo eine Registrierung vorgeschrieben ist, in den Angaben, die bei der Steuerbehörde eingereicht werden.
Die Steuerbehörde: setzt die Regeln durch und erhält die Daten
In den meisten Märkten ist der vierte Akteur eine nationale Steuerbehörde: das österreichische Bundesministerium für Finanzen über FinanzOnline, die Agenzia delle Entrate (AdE) in Italien, die AEAT in Spanien, die DGFiP in Frankreich und Skatteverket in Schweden. Spanien hat regionale Ausnahmen: Die baskischen Provinzsteuerbehörden (Haciendas Forales) betreiben TicketBAI, und die Hacienda Foral von Navarra betreibt NaTicket.
Deutschland teilt die Rolle weiter auf. Das Bundesministerium der Finanzen (BMF) erlässt die Kassensicherungsverordnung (KassenSichV), das BSI legt im Benehmen mit ihm die technischen Anforderungen fest (§ 5 KassenSichV), und die Finanzämter der Länder nehmen die Mitteilung jedes Unternehmens entgegen und führen Prüfungen durch.
Wie die Daten zur Behörde gelangen, folgt einem von zwei Modellen. Im Übermittlungsmodell erhält die Behörde die Daten, ohne sie anzufordern. Italiens Registratori Telematici (RT) senden die Tagesumsätze einmal täglich an die AdE. In Spanien sendet Software im Verifactu-Modus jeden Rechnungsdatensatz an die AEAT, während Systeme, die diesen Modus nicht nutzen, die Datensätze stattdessen speichern.
Im Modell auf Anforderung bleiben die Daten beim Unternehmen, bis ein Prüfer sie anfordert. Nach der österreichischen RKSV (§ 7 und § 19) exportiert das Unternehmen sein Datenerfassungsprotokoll (DEP) für den angeforderten Zeitraum. Auch Deutschland, Frankreich und Schweden prüfen die Aufzeichnungen bei Kontrollen.
Die beiden Modelle legen das Gewicht an unterschiedliche Stellen. Auf Anforderung trägt die Signatur alles, denn die Behörde sieht die Daten Monate oder Jahre später und verlässt sich auf sie als Beweis, dass sich zwischenzeitlich nichts verändert hat. Die Übermittlung braucht eine stabile Verbindung und eine saubere Logik für erneutes Senden.
So sehen die vier Rollen in sechs Märkten aus
Die vier Rollen sind überall dieselben; was sich ändert, ist die Form der Sicherheitskomponente, wer für sie einsteht und wie die Daten zur Behörde gelangen.
| Markt | Sicherheitskomponente | Wer für sie einsteht | Wie die Steuerbehörde die Daten erhält |
|---|---|---|---|
| Deutschland | Technische Sicherheitseinrichtung (TSE), Hardware oder Cloud | BSI-Zertifizierung | Auf Anforderung, bei Prüfungen |
| Österreich | Signaturerstellungseinheit, Smartcard oder Cloud | Qualifiziertes Zertifikat eines eIDAS-Vertrauensdiensteanbieters; die Einheit muss die eIDAS-Anforderungen erfüllen, keine separate fiskalische Zertifizierung | Auf Anforderung, als DEP-Export (§ 7, § 19 RKSV) |
| Italien | Registratore Telematico (RT) | Von der AdE genehmigtes RT-Modell | Tägliche Übermittlung an die AdE |
| Spanien | Anforderungen in der Rechnungssoftware selbst | Declaración responsable des Herstellers (Art. 13, RD 1007/2023) | Jeder Datensatz im Verifactu-Modus; sonst zur Prüfung gespeichert (Pflichten der Unternehmen ab 2028) |
| Frankreich | Anforderungen in der Kassensoftware selbst | Zertifizierung durch Dritte (LNE oder InfoCert) oder Selbstattestierung des Herausgebers (wieder zulässig seit dem 21. Februar 2026) | Auf Anforderung, bei einer Prüfung der DGFiP |
| Schweden | Kontrolleinheit (kontrollenhet, Hardware) oder Cloud-Kontrollsystem (kontrollsystem) | Akkreditierte Zertifizierungsstelle | Auf Anforderung, bei Kontrollbesuchen von Skatteverket |
Liest man die mittlere Spalte von oben nach unten, fällt eines auf: Die Steuerbehörde genehmigt die Sicherheitskomponente selten selbst. Italien ist der klare Fall, in dem sie es tut, über die Genehmigung der RT-Modelle durch die AdE. Überall sonst steht eine Zertifizierungsstelle, ein Vertrauensdiensteanbieter oder die unterschriebene Erklärung des Herstellers für sie ein. fiskalys Leitfäden zu Drittzertifizierung versus Selbstzertifizierung und zu Hardware- versus Cloud-Komponenten gehen beiden Fragen genauer nach.
Was das bedeutet, wenn Sie Kassensoftware entwickeln
„Compliance ist Sache des Händlers, nicht unsere.“ Rechtlich stimmt das weitgehend: Die Pflicht liegt beim Unternehmen, und in Deutschland, Österreich und Schweden ist es das Unternehmen, das seine Systeme bei der Steuerbehörde meldet.
Aber der Händler kann diese Pflicht nur über das System erfüllen, das Sie ausliefern. Deshalb landen drei Entscheidungen auf Ihrer Seite des Dreiecks:
- Welche Sicherheitskomponente Sie in welchem Markt einsetzen, und ob ihre Zulassung die Art abdeckt, wie Sie sie betreiben.
- Ob jede Transaktion sie durchläuft. Ein Verkauf, der den Signaturschritt überspringt, etwa wegen eines ungetesteten Codepfads oder eines Ausfalls, den die Software nicht abfängt, hinterlässt eine Lücke in den Aufzeichnungen des Händlers, die der Händler nicht sehen kann.
- Was das Unternehmen von Ihnen braucht, um seine Meldungen abzugeben. Ein österreichischer Händler, der sich bei FinanzOnline registriert, muss die Seriennummer des Zertifikats, die Art der Signaturerstellungseinheit und die Kassenidentifikationsnummern angeben. Wenn Ihr System diese Angaben nicht bereitstellt oder Ihr Anbieter die Registrierung nicht automatisiert, kann der Händler sie nicht abschließen.
Für Sie als Kassenanbieter ist Compliance zugleich die gesetzliche Pflicht des Händlers und eine Funktion Ihres Produkts.
Die wichtigsten Erkenntnisse
- Die Pflicht bleibt beim Unternehmen. Wer Kassensoftware und einen Signaturdienst einkauft, verlagert die technische Arbeit, nicht die gesetzliche Pflicht oder die Aufzeichnungen.
- Anbieter haben eigene Pflichten. In mehreren Märkten hat die Partei, die das System herstellt oder verkauft, gesetzliche Pflichten, deshalb ist „der Händler ist verantwortlich“ nie die ganze Antwort.
- „Zertifiziert“ braucht eine Präzisierung. Prüfen Sie, wer in jedem Markt für die Sicherheitskomponente einsteht, bevor Sie sich auf das Wort verlassen.
- Das Datenmodell bestimmt die Entwicklung. Wo Daten übermittelt werden, planen Sie Ausfälle und erneutes Senden ein; wo sie auf einen Prüfer warten, müssen Signatur und Export jahrelang standhalten.
So passt fiskaly ins Bild
fiskaly ist ein Anbieter von Cloud-APIs für Fiskalisierung und Umsatzsteuer-Compliance: die Ecke der Sicherheitskomponente im Dreieck. fiskaly verkauft keine Kassensysteme und wickelt keine Zahlungen ab.
In Deutschland ist SIGN DE die marktführende und BSI-zertifizierte Cloud-TSE. SIGN SE ist ein Cloud-Kontrollsystem (kontrollsystem) nach SKVFS 2020:9, zertifiziert von einer akkreditierten Zertifizierungsstelle, und SIGN ES deckt Verifactu, TicketBAI und NaTicket über eine einzige API ab. SIGN AT signiert Belege, erstellt das DEP und automatisiert die Registrierung bei FinanzOnline.
Die Ecken bleiben in jedem Markt dieselben; was sich ändert, ist das Regelwerk in der Mitte.
