Mit Sicherheit zur digitalen Kassenführung: Was machen TIM und TSE?

Zum Entwicklungsstand zweier ungleicher Brüder

I. Bausteine zur Umsetzung von Kassengesetz und KassenSichV

1. E-AEAO zu § 146a

[i]Neu im AEAO: DSFinV-KDer Entwurf des Anwendungserlasses enthält Ausführungen zum „Kassengesetz“, zur KassenSichV und zur TR-03153 (vgl. folgenden Abschnitt) sowie zu weiteren S. 518Dokumenten des BSI. Der einzige wirklich neue Aspekt ist eine dritte Schnittstelle, nämlich die „Digitale Schnittstelle der Finanzverwaltung für elektronische Aufzeichnungssysteme (DSFinV-K)“.

Diese technischen sowie fachliche und organisatorische Bausteine ist der E-AEAO bemüht, miteinander zu einem nachvollziehbaren System zu verbinden, da die Anforderungen für die Umsetzung nicht strukturiert und zusammengefasst vorliegen, sondern aus einer Vielzahl von – zum Teil in englischer Sprache verfassten – Dokumenten zusammengetragen werden müssen.

2. Technische Richtlinien des BSI

[i]Technische Sicherheitseinrichtung (TSE)Die Technische Richtlinie TR-03153 „Technische Sicherheitseinrichtung für elektronische Aufzeichnungssysteme“ beschreibt die Architektur einer Technischen Sicherheitseinrichtung (TSE), mithin die Aufgabenverteilung zwischen

• Sicherheitsmodul,

• Speichermedium und

• einheitlicher digitaler Schnittstelle.

Weiterhin werden verschiedene Begrifflichkeiten definiert. Der zentrale Begriff ist derjenige der Transaktion. Diese wird zusammen mit einzelnen Absicherungsschritten durch Log-Dateien dokumentiert.

Zudem werden Abläufe für Erzeugung, Aktualisierung und Abschluss einer Transaktion beschrieben sowie die grundsätzlichen Spezifikationen des Sicherheitsmoduls, des Speichermediums und der Einbindungs- und Exportschnittstelle.

[i]Weiterführende DokumenteInsoweit verweist das BSI u. a. weitergehend auf folgende Dokumente:

• Technical Guideline TR-03151 – Secure Element Integration API: Eine in englischer Sprache abgefasste Beschreibung einer allgemeinen, stark abstrahierten Schnittstelle zwischen der TSE und den anderen Komponenten des Gesamtsystems nebst Java API-Vorlagen v. 20.12.2018;

• Technische Richtlinie TR-03116 – Kryptografische Vorgaben für Projekte der Bundesregierung (Teil 5);

• Technische Richtlinie TR-02102 – Kryptografische Verfahren, Empfehlungen und Schlüssellängen: Aufstellung der momentan akzeptierten kryptografischen Verfahren;

• Technical Guideline TR-03145 – Secure CA Operation: Anforderungen an die Stellen, die kryptografische Zertifikate erzeugen und verwalten;

• Common Criteria Protection Profile PP-SMAERS [8];

• Common Criteria Protection Profile PP-CSP [9].

Am 5.2.2019 wurden zudem Testspezifikationen und XML-Testfälle hierzu auf der Website des BSI veröffentlicht.

[i]Umfang von ca. 400 Seiten!Insgesamt sind damit rund 400 Seiten zu lesen – zum Teil in englischer Sprache abgefasst. Allein die drei vom BMF im Schreiben v. 28.2.2019 [10] originär genannten TR [11] S. 519umfassen – ohne Testspezifikationen und Java API-Vorlagen sowie ohne jedwede Ausführung zu fachlichen Implementierungen – 128 Seiten, die DSFinV-K zusätzlich 92 Seiten. Hinzuzuaddieren sind die Seiten des AEAO zu § 146 AO, § 146b AO und bald auch zu § 146a AO.

Im Wesentlichen dient der Inhalt besagter 400 Seiten dazu, beliebige Datensätze mit einer Nummer, einer Zeitinformation und einer elektronischen Signatur zu versehen, sie zu – wiederum fortlaufend nummerierten – „Transaktionen“ zusammenzufassen, abzuspeichern und schließlich auf Anforderung in eine Datei zu speichern. Trotz des enormen Umfangs und der hohen technischen Komplexität sind spezifisch fachliche Anforderungen zur Absicherung von Daten aus elektronischen Registrierkassen und PC-Kassen jedenfalls derzeit in keiner Weise berücksichtigt.

[i]Personalisierung der TSE So soll etwa die TSE offensichtlich auf das jeweilige Kassensystem personalisiert werden, was erheblichen Nachfolgeaufwand zur Folge hat – und das nicht erst bei der Registrierung elektronischer Registrierkassen und PC-Kassen, sondern vor allem bei deren Verkauf, Verschrottung, ggf. auch bei Versetzung an einen anderweitigen Einsatzort. Weiterhin führt die TSE keinerlei steuerfachliche [i]Keine steuerfachliche PlausibilisierungPlausibilisierung durch und stellt nicht permanent Umsatzdaten zu Prüfzwecken bereit.

[i]Becker, Der Gesetzentwurf zum Schutz vor Manipulationen an digitalen Grundaufzeichnungen, BBK 21/2016 S. 1039 NWB KAAAF-84918 Der Deutsche Fachverband für Kassen- und Abrechnungssystemtechnik e. V. (DFKA) hat zur Umsetzung der Kassensicherungsverordnung im September 2018 eine „kritische Analyse“ zur Umsetzung der KassenSichV durch das „TSE-Verfahren“ herausgegeben [15], die im Dezember 2018 ergänzt wurde [16]. Ebenso scharfsinnig wie präzise werden dort nicht nur die unnötige technische Komplexität und die Mängel in der Projektstruktur aufgezeigt, sondern mit bemerkenswert steuerfachlichem Know-how auch die Folgen auf „Prüfbarkeit und Nachvollziehbarkeit“ (§ 145 Abs. 1 AO) [17] dargestellt. Dem ist nur wenig hinzuzufügen. S. 520

3. Digitale Schnittstelle der Finanzverwaltung für elektronische Aufzeichnungssysteme (DSFinV-K)

[i]Einführung einer dritten SchnittstelleIn den Abschnitten 4.2 und 4.3 des E-AEAO zu § 146a wird – erstmalig – die sog. DSFinV-K [18] eingeführt. Diese basiert inhaltlich auf der unter Führung des DFKA e. V. entwickelten Taxonomie Kassendaten [19] und ist technisch deren Darstellung im CSV-Format mit entsprechenden Erweiterungen, um sie mit der zertifizierten Technischen Sicherheitseinrichtung (zTSE) zu „verheiraten“. Sie ist – neben der Einbindungsschnittstelle (E-AEAO zu § 146a, Abschnitt 3.2.10) und der Exportschnittstelle (E-AEAO zu § 146a, Abschnitt 3.2.11) für die Anwendungsdaten der zTSE – somit die dritte Schnittstelle für „alle mit dem elektronischen Aufzeichnungssystem aufgezeichneten Daten“. [20] Insoweit heißt es dort:

Hierauf wird nachfolgend im Gesamtzusammenhang näher eingegangen.

II. Entwurf zum Anwendungserlass – E-AEAO zu § 146a

[i]Anforderungen an den AEAO zu § 146aDer Erlassentwurf selbst umfasst rund dreizehn DIN A4-Seiten. Er dient als Bindeglied zwischen Gesetz und KassenSichV einerseits sowie zu den diversen technischen Vorschriften andererseits. Damit müsste spätestens dieser Anwendungserlass sämtliche fachlichen Definitionen abschließend und für die technische Umsetzung eindeutig festlegen und erkennen lassen:

• das Sicherheitskonzept,

• das Betriebskonzept,

• das Prüfkonzept und

• die Abstimmung dieser drei Konzepte aufeinander.

Dies ist allerdings nach wie vor nicht der Fall. Daneben stehen geringere Mängel, die das Gesamtverständnis jedoch unnötig erschweren:

1. „Verbundsysteme“

[i]ZTSE für Verbundsysteme zulässigIn Abschnitt 1.2 E-AEAO zu § 146a wird ausgeführt, dass jedes eingesetzte elektronische Aufzeichnungssystem i. S. des § 146a AO i. V. mit § 1 Satz 1 KassenSichV sowie die damit zu führenden digitalen Aufzeichnungen grundsätzlich durch eine zertifizierte technische Sicherheitseinrichtung zu schützen sind.

Werden jedoch mehrere einzelne elektronische Aufzeichnungssysteme wie z. B. Verbundwaagen, Bestellsysteme ohne Abrechnungsteil oder App-Systeme mit einem Kassensystem i. S. von § 146a AO i. V. mit § 1 Satz 1 KassenSichV verbunden, wird es nicht beanstandet, wenn die damit zu führenden digitalen Aufzeichnungen mit einer S. 521zertifizierten technischen Sicherheitseinrichtung geschützt werden, die alle im Verbund befindlichen elektronischen Aufzeichnungssysteme gemeinsam nutzen.

[i]Netzwerk-zTSE strittigDaraus könnte man im Umkehrschluss ableiten, dass mehrere elektronische Registrierkassen oder PC-Kassen eine zTSE nicht gemeinsam nutzen dürfen, was eine gemeinsame zTSE in einem Netzwerk ausschließen würde.

In Abschnitt 9.2.4 E-AEAO zu § 146a heißt es dann allerdings: „Sollten in Verbundsystemen mehrere Geräte mit einer zertifizierten technischen Sicherheitseinrichtung verbunden sein, so ist jedes einzelne verwendete Gerät dem Finanzamt mitzuteilen“. Diese Aussage wiederum legt nahe, dass sich doch mehrere elektronische Registrierkassen oder PC-Kassen eine zTSE teilen können, was den bisherigen Verlautbarungen des BMF entspräche.

2. Übergangsregelung bis zum 31.12.2022

[i]Keine Übergangsregelung für PC-Kassen Im letzten Satz in Abschnitt 2.2.2 E-AEAO zu § 146a wird die Übergangsregelung bis zum 31.12.2022 für PC-Kassen generell ausgeschlossen – was nachvollziehbar ist; denn ein PC-System ist von der Bauart her in jedem Fall nachrüstbar: Es mag zwar kein Software-Update geben, was allerdings wiederum keine Frage der Bauart ist.

Im Übrigen gliedert sich der E-AEAO wie folgt:

3. Zertifizierte Technische Sicherheitseinrichtung – Abschnitt 3 E-AEAO zu § 146a

[i]Komponenten der zTSE Der Satz in Abschnitt 3.2.1 „Insbesondere muss eine zertifizierte technische Sicherheitseinrichtung nicht notwendigerweise in einer physikalischen Einheit verbaut sein“ lässt zwei Auslegungen zu:

• entweder, dass auch reine Softwarelösungen denkbar sind,

• oder, dass die Komponenten der zTSE – also Sicherheitsmodul, Speichermedium und Schnittstelle – keine physische Einheit bilden müssen.

3.1 Sicherheitsmodul – Abschnitte 3.2.3 bis 3.2.6 E-AEAO zu § 146a

[i]Funktion des SicherheitsmodulsDie Funktion des Sicherheitsmoduls nach dem E-AEAO zeigt schematisch die Abbildung auf der folgenden Seite.

[i]Abgrenzung der „anderen Vorgänge“ unklarDer einzelne zusammengehörige Aufzeichnungsprozess wird als Vorgang bezeichnet,

• der eine oder mehrere Geschäftsvorfälle sowie andere Vorgänge umfassen kann (Abschnitt 1.4 E-AEAO zu § 146a) und

• der mindestens eine Transaktion(snummer) erzeugen muss (Abschnitt 1.5 E-AEAO zu § 146a).

Die „anderen Vorgänge“ werden nicht abschließend definiert, sondern lediglich zum „Geschäftsvorfall“ negativ abgegrenzt und im Übrigen nur beispielhaft beschrieben. Dies ist umso weniger nachvollziehbar, als über die „dritte Schnittstelle“ doch ohnehin „alle mit dem elektronischen Aufzeichnungssystem aufgezeichneten Daten“ aufbewahrt werden sollen. Damit dürfte es zumindest in Einzelfällen weiterhin Diskussionen darüber geben, ob denn nun das Zutreffende aufgezeichnet wurde.S. 522

[i]Aufzeichnung des Vorgangsbeginns unnötigGemäß Abschnitt 3.2.6 E-AEAO zu § 146a müssen die Zeitpunkte für Vorgangsbeginn und Vorgangsende vom Sicherheitsmodul bereitgestellt werden. Die durch die – fachlich unnötige – Aufzeichnung des Vorgangsbeginns erzeugte Komplexität [21] zieht sich durch das gesamte System. Dies belegt schon die Differenzierung der Position „Daten des Vorgangs“ in „Bestellung“ einerseits und „Kassenbeleg“ andererseits, da hierdurch zugleich der Grundsatz durchbrochen wird, dass jeder Vorgang im Aufzeichnungssystem einer Transaktion in der zTSE entspricht.

[i]Zeitquellen Möglich sind eine interne Zeitquelle, eine externe Zeitquelle (Signed NTP) oder eine Mischform. Für die Zeitquelle ist lediglich entscheidend, dass die Zeitführung im Sicherheitsmodul erfolgen muss und damit die Transaktionszeit streng monoton wachsend ist.

[i]Becker, Die Kassensicherungsverordnung (KassenSichV) – Eine vertane Chance, BBK 17/2017 S. 803 NWB ZAAAG-54729 Eine Begründung für eine aus fachlicher Sicht erforderliche Aufzeichnung des Vorgangsbeginns steht auch hier ebenso aus wie – angesichts fortlaufender Vergabe einer eindeutigen und fortlaufenden Transaktionsnummer sowie eines Signaturzählers (siehe Abschnitt 3.5 Nr. 1 E-AEAO zu § 146a) – eine Antwort auf die Frage nach der Notwendigkeit einer Zeitführung durch das Sicherheitsmodul [23]; denn § 146 Abs. 1 AO fordert – nach wie vor – lediglich Zeitgerechtigkeit der Aufzeichnungen. S. 523

Nach Abschnitt 5.4 Nr. 9 E-AEAO zu § 146a hat der Beleg als eine Mindestangabe u. a. einen „Prüfwert“ zu enthalten. Diese Angabe ist derzeit durch § 6 KassenSichV nicht gedeckt; die nächste Änderung der Kassen(daten)sicherungsverordnung noch im laufenden Projekt steht also an.

[i]Prüffähiger Beleg erforderlichTrotz zahlreicher Hinweise im Vorfeld [26] ist das BMF offensichtlich erst jetzt zu der Erkenntnis gelangt, dass ein kontrollfähiger Beleg für ein funktionierendes Sicherheitssystem für Kassendaten unabdingbar ist. Ein Prüfwert dient dazu, im Rahmen der systemisch erforderlichen Feldüberwachung schnell und unkompliziert – d. h. ohne aufwändigen Datenzugriff – zu kontrollieren, ob das Sicherheitsmodul bei Buchung des entsprechenden Geschäftsvorfalls eingesetzt wurde.

[i]Immer noch offen: Wie und womit soll der Beleg geprüft werden?Wie und womit der Beleg allerdings geprüft werden soll und worauf man aus dem Beleg in jedem Fall sämtliche für eine effektive Kontrolle nötigen Informationen zur Datenauthentizität und -integrität zurückführen können soll, bleibt vorliegend allerdings offen. Eine Rückführung auf die Datei mit den Informationen der Mitteilungen nach § 146a Abs. 4 AO kann jedenfalls ausgeschlossen werden, da diese den Zugriff auf die zur Verifikation notwendigen Schlüssel nicht zu gewährleisten vermag, da nicht einmal die Mitteilung der Seriennummer jeder zTSE obligatorisch ist.

Ebenso bleibt offen, ob es sich bei dem mit den Protokolldaten an die Anwendungsdaten übergebenen Prüfwert (siehe Abbildung oben: Nr. 6) um denselben wie in den Anwendungsdaten handelt oder ob dieser Prüfwert (siehe Abbildung oben: E) wiederum eigenständig vergeben wird.

3.2 Speichermedium – [i]Vorgaben für das SpeichermediumAbschnitte 3.2.7 bis 3.2.8 E-AEAO zu § 146a

S. 524 [i]Datenexport erforderlich Gemäß § 146a Abs. 1 Satz 4 AO sind die digitalen Aufzeichnungen auf dem Speichermedium zu sichern und für Nachschauen sowie Außenprüfungen durch elektronische Aufbewahrung verfügbar zu halten. Nach Abschnitt 8.2 E-AEAO zu § 146a ist demgegenüber „die Überführung der abgesicherten Anwendungsdaten aus der zertifizierten technischen Sicherheitseinrichtung in ein Archivierungssystem zulässig, sofern dieses einen späteren Export der Daten nach der in Kapitel 5.1 der Technischen Richtlinie BSI TR-03153 vorgeschriebenen Form ermöglicht (TAR-Files in definierter Form)“. Nach diesem Export können die Daten auf dem Speichermedium der zTSE sogar – contra legem – gelöscht werden.

[i]Cloud-Speicher zulässig?In Abschnitt 3.2.8 E-AEAO zu § 146a wird ohne weiteres zugelassen, dass als Speichermedium der zTSE ein Cloud-Speicher genutzt werden kann. Offen bleibt zum einen, welche aus der TR-03153 resultierenden Anforderungen ein derartiger „externer Speicher“ erfüllen müsste. Zum anderen entspricht eine Speicherung von Kassen- bzw. Buchführungsdaten in Cloud-Systemen auf einem Server außerhalb des Geltungsbereichs der Abgabenordnung selbst innerhalb der Europäischen Union ohne Zustimmung des Finanzamts weder dem Wortlaut noch dem Telos des § 146 Abs. 2a AO. Ein Hinweis auf diese Vorschrift fehlt.

[i]Gesetzlicher Grundfall: Aufzeichnungen in DeutschlandGesetzliche Vorgabe ist, dass Bücher und sonst erforderliche Aufzeichnungen – mithin auch Kassendaten – im Geltungsbereich des Gesetzes zu führen und aufzubewahren sind. Unter Aufbewahren ist auch die alleinige Speicherung auf einem Server zu verstehen. Ebenfalls ist gesetzlich geregelt, dass die zuständige Finanzbehörde abweichend davon gem. § 146 Abs. 2a Satz 1 AO auf schriftlichen Antrag des Steuerpflichtigen bewilligen kann, dass elektronische Bücher und sonstige erforderliche elektronische Aufzeichnungen oder Teile davon außerhalb des Geltungsbereichs dieses Gesetzes geführt und aufbewahrt werden können.

[i]Server im Ausland möglich?Aufgrund der gesetzlichen Vorgaben ist die alleinige Aufbewahrung bzw. Speicherung der elektronischen Bücher und sonstiger erforderlicher elektronischer Aufzeichnungen – so auch Aufzeichnungen aus Vorsystemen wie etwa Kassendaten – auf Servern auch in anderen Mitgliedstaaten der EU ohne Bewilligung des Finanzamts nach § 146 Abs. 2a AO unzulässig. [29] Ein Verzicht auf die Bewilligung würde mithin eine Gesetzesänderung voraussetzen. Insoweit ist allerdings gerade bei der hier zu behandelnden Materie nicht außer Acht zu lassen, dass die Möglichkeiten der Strafverfolgung bei Speicherung von Daten auf externen Servern im Ausland beschränkt sind.

3.3 Einheitliche digitale Schnittstelle – Abschnitte 3.2.9 bis 3.2.11 E-AEAO zu § 146a

4. Datenexport bei Kassen-Nachschau und Prüfung – Abschnitte 4 und 8 E-AEAO zu § 146a

Aus den Abschnitten 4 und 8 E-AEAO zu § 146a folgt, dass zwei Arten von Aufzeichnungen vorzulegen sind:

• die Aufzeichnungen aus der zTSE (die TAR-Files [30]) und

• diejenigen im Format DSFinV-K [31], die mithin eine „dritte Schnittstelle“ bildet.

[i]ZTSE allein nicht ausreichend Es erschließt sich nicht, warum die „Vorhaltung der abgesicherten Anwendungs- und Protokolldaten (...) für Zwecke der Durchführung steuerlicher Außenprüfungen oder Nachschauen allein nicht ausreichend“ ist. Die dazu gegebene Begründung, dass eben „nicht alle erforderlichen Daten in die Protokollierung durch die zertifizierte technische Sicherheitseinrichtung einfließen“, qualifiziert sich selbst:

[i]Fachliche Vorgaben dienen dazu, eine unendliche Datenmenge sinnvoll zu beschränkenDenn es ist gerade die Aufgabe fachlicher Vorgaben, die unendliche Datenmenge, die ein elektronisches Aufzeichnungssystem zu produzieren in der Lage ist, auf das für steuerliche Prüfzwecke absolut notwendige Maß zu reduzieren und eben nur diese Daten zu sichern; schon ein akzeptables Laufzeitverhalten beim Import der Daten auf die Rechner der Prüfer erzwingt eine derartige Anforderung nachgerade.

[i]Becker, Der Gesetzentwurf zum Schutz vor Manipulationen an digitalen Grundaufzeichnungen, BBK 21/2016 S. 1039 NWB KAAAF-84918 Angesichts dieses Befundes ist evident, dass eine ernsthafte interdisziplinäre Auseinandersetzung zwischen den Vertretern des BSI einerseits sowie den Vertretern der Finanzverwaltungen des Bundes und der Länder andererseits nicht stattgefunden haben kann. [33]

Die so definierten zwei getrennten Datenbestände und Prüfpfade werden in der Praxis zudem sowohl auf technischer als auch auf Verifikationsebene eine Vielzahl von Schwierigkeiten verursachen, namentlich Performance-Probleme infolge fehlender inhaltlicher Standardisierung der Daten einerseits und dem Wunsch, möglichst auf sämtliche vom Kassensystem gespeicherte Daten zugreifen zu können, andererseits.

[i]Überarbeitung der Technischen RichtlinienOb und inwieweit darüber hinaus mit Redundanzen zu rechnen ist, ist derzeit unklar; insoweit heißt es in Abschnitt 1.3 der DSFinV-K lediglich: „Darüber hinaus wird die DSFinV-K in Kürze um die notwendigen Datenfelder ergänzt, die sich aus der Exportschnittstelle der TSE (Log-Nachrichten) ergeben (insbesondere Schlüsselfelder zur Verbindung von DSFinV-K und Log-Nachrichten der TSE). Derzeit befinden sich die Technischen Richtlinien des BSI jedoch noch in Überarbeitung.“

Dass dieser komplexe und sich zwangsläufig erheblich negativ auf die Zeiten des Datenimports auswirkende Ansatz nicht erforderlich ist, beweist die Kombination aus TIM-Card und DFKA-Taxonomie; denn dort gibt es nur einen einzigen steuerfachlich definierten Datenbestand.

5. Weitere im E-AEAO behandelte Fragen

5.1 Beleg – Abschnitte 5 und 6 E-AEAO zu § 146a

5.2 Ausfall der zTSE – Abschnitt 7 E-AEAO zu § 146a

[i]Ausfall der zTSE Abschnitt 7 behandelt die Frage, wie Transaktionen während eines Ausfalls der zTSE zu dokumentieren sind. Das System sieht die Aufzeichnung im Speichermedium der zTSE vor. Aus diesem Speicher werden die Daten bei einer Prüfung bereitgestellt. Bei einem Ausfall der zTSE dürfte jedoch deren Speicher ebenfalls nicht nutzbar sein (vgl. insoweit Abschnitt 8.3 E-AEAO zu § 146a).

[i]Kein Lösungsansatz vorhanden Wie dieses Dilemma aufzulösen ist, wird nicht mitgeteilt.

5.3 Mitteilungspflicht nach § 146a Abs. 4 AO – Abschnitte 2.2.3 und 9 E-AEAO zu § 146a

[i]Einrichtung eines Meldeverfahrens bis 2020Nach Abschnitt 2.2.3 ist die Mitteilung nach § 146a Abs. 4 AO für elektronische Aufzeichnungssysteme, die unter den Anwendungsbereich des § 146a AO i. V. mit § 1 Satz 1 KassenSichV fallen und vor dem 1.1.2020 angeschafft wurden, bis spätestens zum 31.1.2020 zu erstatten. Es wird mithin davon ausgegangen, dass die Finanzverwaltung deutlich vor dem 31.1.2020 ein funktionierendes Meldeverfahren für elektronische Registrierkassen und PC-Kassen hat. Dies erscheint derzeit zumindest optimistisch.

Nach Abschnitt 3.6.1 muss jedes Kassensystem eine Seriennummer haben, die von der Kassensoftware an die zTSE zu übermitteln ist. Dies stellt für manche Typen von Registrierkassen – etwa Tablets – vermutlich ein Problem dar, das bei ausschließlicher Nutzung der TSE-Seriennummer nicht existieren würde.S. 527

[i]Einschränkung der NachvollziehbarkeitIn Abschnitt 5.4 wird ausgeführt, dass man die Seriennummer der Kasse oder diejenige der zTSE auf dem Beleg verwenden darf. Entscheidet man sich für die Seriennummer der zTSE, ist es ausgeschlossen, Belege anhand des zentralen Melderegisters für elektronische Registrierkassen und PC-Kassen zuzuordnen [36].

Da zu Kontroll- und Prüfverfahren keinerlei Ausführungen gemacht werden – ein Prüfkonzept ist mithin nicht erkennbar –, lässt sich nicht beurteilen, ob dies ein größeres Problem ist. Die Nachvollziehbarkeit leidet darunter jedenfalls erheblich.

5.4 Zertifizierung, Werbeverbot und Rechtsfolgen – Abschnitte 10 bis 12 E-AEAO zu § 146a

[i]Rechtsfolgen bei VerstößenIm Übrigen verweist der E-AEAO zur Zertifizierung durch das BSI auf § 5 KassenSichV (Abschnitt 10), wiederholt im Wesentlichen zum Verbot des gewerbsmäßigen Bewerbens und In-Verkehr-Bringens den Wortlaut des § 146a Abs. 1 Satz 4 AO (Abschnitt 11) und weist mit Blick auf die Rechtsfolgen bei Verstößen lediglich darauf hin, dass nur die Belegausgabe- und die Mitteilungspflichten nach §§ 328 ff. AO erzwungen werden können (Abschnitt 12).

Ausführungen oder auch nur Hinweise auf den und zu dem insoweit geänderten § 379 Abs. 1 und 4 AO fehlen.

6. Nicht im E-AEAO zu § 146a enthaltene Regelungen

6.1 Schutzprofile, Sicherheitsniveau und „neuartige Zertifizierung“

[i]Neue Schutzprofile mit geringerer PrüftiefeDie Schutzprofile [37] in ihrer Endfassung wurden erst vor kurzem auf der Webseite des BSI veröffentlicht. [38] Um den ohnehin zu engen Zeitplan dennoch zu retten, lässt man sich einiges einfallen:

Zunächst einmal eine Zertifizierung nach „BSI-CC-PP-x-y ´Cryptographic Service Provider Light´ (CSP light)“: Dabei werden die kryptografischen Verfahren mit einer wesentlich geringeren Prüftiefe (CC EAL2) evaluiert. Der Einsatz eines solchen Kryptomoduls wäre nach Angaben der Bundesregierung möglich, „wenn die Komponente in einem gesicherten Einsatzbereich betrieben wird und geeignete organisatorische Sicherheitsmaßnahmen getroffen werden, z. B. durch ein Audit nach BSI-Grundschutz.“ [39]

[i]Nicht erprobtes ZertifizierungskonzeptWeiterhin hat das BSI – trotz oder wegen des Zeitdrucks – ein neuartiges, bisher in der Praxis ebenfalls nicht erprobtes Zertifizierungskonzept entwickelt. [40] Insoweit hat die Bundesregierung erklärt, derzeit entstünden Kriterien, unter denen eine vorläufig befristete Freigabe einer in der Zertifizierung befindlichen TSE möglich sei. [41] S. 528

[i]Kostenrahmen soll eingehalten werdenMithin werden ein späterer Austausch der Hardware der zTSE und die damit verbundenen Kosten bewusst in Kauf genommen. Gleichwohl versichert das BMF namens der Bundesregierung, dass dieser „derzeit keine Erkenntnisse vor[liegen], die eine geänderte Kostenschätzung zur Folge hätten.“ [43] Diese beträgt – zur Erinnerung – nach wie vor 10 € pro zTSE. [44]

6.2 Der „Plan“ des BMF

[i]„Planmäßige“ Umsetzung des Kassengesetzes In der Sitzung des Finanzausschusses am 3.4.2019 haben die Vertreter des BMF für die Bundesregierung erklärt, die Umsetzung des Gesetzes zum Schutz vor Manipulationen an digitalen Grundaufzeichnungen laufe „planmäßig“ [45]. Vor aufgezeigtem Hintergrund stellt sich zwangsläufig die Frage, was dieser Plan wohl beinhalten mag:

Eine Zertifizierung nach EAL2 benötigt mindestens sechs Monate. Mit dem Projekt 380 „ZERSIKA“ wurden allerdings keine Implementierungen [46] beauftragt. Allein für die Implementierung eines Signatursystems vom Beginn der Entwicklung bis zu einem stabilen, fehlerfreien Produkt wird eine Zeit von rund einem Jahr benötigt. [47]

6.3 Billigkeitsmaßnahmen nach § 148 AO

[i]AEAO zu § 148 steht weiterhin ausDas BMF erklärte für die Bundesregierung gleichwohl, „dass die zertifizierten technischen Sicherheitseinrichtungen rechtzeitig in den Verkehr und flächendeckend in Einsatz gebracht werden können“. [49] Und weiter: „Im Rahmen der Erörterung der obersten Finanzbehörden des Bundes und der Länder des Entwurfs des Anwendungserlasses zu § 146a AO sind u. a. Aspekte der Anwendung des § 148 AO intensiv diskutiert worden. Mangels derzeit ersichtlicher Kriterien für die Bewilligung von Erleichterungen im Einzelfall oder für bestimmte Gruppen hinsichtlich der sich aus den §§ 140 ff. AO ergebenden Pflichten, ist gegenwärtig noch nicht absehbar, ob und wann mit einem Anwendungserlass zu § 148 AO zu rechnen ist.“ [50]

[i]Finanzverwaltung stellt Ausnahmeregelungen „im Einzelfall“ in Aussicht Der Presse gegenüber wurde weitergehend mitgeteilt, dass – sollte es zu Problemen kommen – vorgesorgt sei; dann könnten „im Einzelfall“ Anträge gestellt werden, in denen die Schwierigkeiten dargestellt werden. Die Finanzverwaltung werde darauf „angemessen in Abwägung aller Umstände reagieren“. [51]

Den dafür erforderlichen Personalaufwand in sämtlichen (Festsetzungs-)Finanzämtern aller Bundesländer mag sich niemand vorstellen. Da Implementierungen der zTSE in rund 1,2 Mio. Kassensysteme bis zum 1.1.2020 jedenfalls in der Fläche nicht zu bewerkstelligen sein werden, müssten Anträge sowie Art, Umfang und Zeitraum jeder S. 529Bewilligung nach § 148 AO der jeweiligen Meldung nach § 146a Abs. 4 AO elektronisch zugeordnet werden können, damit die „im Einzelfall“ getroffenen Ausnahmeregelungen der Verwaltung sowohl für zeitnahe Kassen-Nachschauen als auch für spätere Betriebsprüfungen verfügbar sind. Dass diese Notwendigkeit bisher überhaupt in Erwägung gezogen wurde, ist ebenfalls nicht ersichtlich.

7. Fazit zur zTSE

[i]E-AEAO ist mit „heißer Nadel“ gestrickt Der Entwurf des Anwendungserlasses bewegt sich – wie nicht anders zu erwarten – im Rahmen von KassenSichV und TR-03153. Der einzig wirklich neue Aspekt ist die „Digitale Schnittstelle der Finanzverwaltung für elektronische Aufzeichnungssysteme“ (DSFinV-K).

Nach wie vor fehlt es bereits an einer ebenso eindeutigen wie abschließenden Definition des zentralen Begriffs der „Transaktion“.

[i]Keine Datenintegrität und -authentizitätZwar ist der Ausweis eines Prüfwerts auf dem Beleg an sich zu begrüßen [52]; die offenbar intendierte Verifikation von Datenintegrität und Datenauthentizität ohne Datenzugriff erscheint unter den dargestellten Voraussetzungen allerdings nicht durchführbar. Ungeklärt ist, in welcher Art, auf welchem Weg und auf was der Prüfwert eines Belegs zurückgeführt werden soll, um Datenauthentizität und -integrität verwaltungsseitig verifizieren zu können.

Die Meldedatei nach § 146a Abs. 4 AO ist dazu ungeeignet, weil sie einerseits vom jeweils örtlichen Finanzamt geführt wird und andererseits wesentliche Daten nicht enthält – insbesondere die öffentlichen Signaturschlüssel. Belege wären also trotz angebrachten Prüfwerts nicht prüfbar. In den exportierten Daten müssen sie laut Technischer Richtlinie vorhanden sein; eine für Prüfer nutzbare andere Quelle – typischerweise [53] ein Server als Teil einer Public-Key-Infrastructure (PKI) – ist nicht vorgesehen.

[i]Maßnahmen unter enormem ZeitdruckDie erforderlichen Schutzprofile in Endfassung sind jetzt zwar veröffentlicht, die Technischen Richtlinien befinden sich nach Angaben im Papier zur DSFinV-K allerdings weiterhin in Bearbeitung des BSI. Die Zeit drängt, der 1.1.2020 naht; das sieht auch das BMF. Denn das Sicherheitsniveau bei der Zertifizierung wurde bereits deutlich gesenkt – S. 530d. h. von CC EAL 4+ auf CC EAL2 [55] – bei gleichzeitiger Einführung einer „neuartigen“, allerdings ebenfalls unerprobten Zertifizierung. [56]

[i]Schnellste Lösung ist vorhanden, wird aber ausgeschlossen Gleichwohl werden die nach wie vor fachlich unbegründet gebliebenen – und nach Auffassung des Autors auch steuerfachlich unbegründbaren – Erfordernisse einer Aufzeichnung des Vorgangsbeginns sowie einer Zeitquelle innerhalb des Sicherheitsmoduls bekräftigt. Letzteres schließt die einfachste und schnellste Lösung aus – nämlich die [i]Becker, Kassenführung und kryptografischer Manipulationsschutz – Freiwillig und technologieoffen?, BBK 22/2015 S. 1049 NWB VAAAF-07914 Verwendung einer am Markt sofort verfügbaren, zertifizierten Smartcard-Hardware.

Das Prädikat „technologieoffen“ – wonach das „Was“ festgelegt, jedoch das „Wie“ so weit wie möglich offen gelassen wird [57] – verdient ein solches System sicherlich nicht.

Wer sich weitergehenden Aufschluss über den Verfahrensstand durch Beantwortung der fünfzehn von der FDP-Bundestagsfraktion gestellten Fragen zur Umsetzung des Gesetzes zum Schutz vor Manipulationen an digitalen Grundaufzeichnungen [58] erhofft hatte, sieht sich enttäuscht: Die vom BMF für die Bundesregierung gefertigten Antworten [i]Parlamentarische Anfrage oberflächlich beantwortetbleiben an der Oberfläche und sind allein vom bloßen Willen geprägt, das gesetzliche Einführungsdatum 1.1.2020 unter allen Umständen zu halten.

Die Hoffnungen von Wirtschaft und Länderfinanzverwaltung dürften jetzt beim Auftragnehmer des Projekts „ZERSIKA“ und seinerzeitiger Mitentwickler des INSIKA-Verfahrens, der cv cryptovision GmbH, liegen, die auf der diesjährigen Mindshare-Konferenz am 14. und 15. Mai diesen Jahres erstmals ihr CSP-Sicherheitsmodul „Jacolyn“ präsentierte. [59]

III. Feldversuch „DFKA-Taxonomie-Kassendaten®/TIM-Card“

[i]DFKA-Taxonomie Kassendaten®, http://go.nwb.de/8d877 Seit März 2016 entwickelte eine Arbeitsgruppe des DFKA e. V. und der DATEV e. G. unter Beteiligung von Vertretern der Finanzbehörden des Bundes und der Länder eine Taxonomie. Diese dient – vergleichbar der E-Bilanz – einer Standardisierung von Form und Inhalt buchhaltungsrelevanter Daten elektronischer Registrierkassen und Abrechnungssysteme, also für die Einzelbewegungen und den Tagesabschluss. Die Taxonomie Kassendaten erhebt den Anspruch, den Austausch, das Archivieren und die automatisierte Weiterverarbeitung dieser Daten in der Buchführung sowie die Prüfung durch Finanz- und andere Behörden zu vereinfachen.

[i]Test unter PraxisbedingungenUm einerseits Erfahrungen bei der Implementierung zu sammeln und andererseits das entwickelte Verfahren unter Praxisbedingungen zu testen, wurde im Februar 2018 ein Feldversuch gestartet. An diesem waren 26 Unternehmen (Hersteller, Softwarehäuser, Anwender) und Vertreter verschiedener Finanzbehörden des Bundes und der Länder beteiligt.

[i]Zielsetzung des FeldversuchsDie wichtigsten Ziele waren der Nachweis einer praxistauglichen Umsetzung der Taxonomie in Verbindung mit einer technischen Sicherheitseinrichtung und der grundsätzlichen Geeignetheit der Taxonomie-Daten für Betriebsprüfungen. Außerdem sollten S. 531die Interoperabilität verschiedener Systeme und der Gesamtaufwand bei Anwendung der Taxonomie mit Sicherheitseinrichtung untersucht und getestet werden.

[i]Zisky, Die DFKA-Taxonomie Kassendaten® im Praxistest, BBK 11/2019 S. 540, in diesem Heft Bereits am 23.7.2018 hatte der DFKA e. V. zu den bis dahin erzielten Ergebnissen einen vom 19.7.2018 datierenden Zwischenbericht bekannt gegeben. [61] Am 6.2.2019 wurde nun der Abschlussbericht zum „Feldversuch DFKA-TaxonomieKassendaten®/TIM-Card“ aus November 2018 veröffentlicht. [62]

Zisky hat in seinem Beitrag in diesem Heft [63] Vorbereitung, Verlauf und Ergebnisse des Feldversuchs ebenso umfassend wie anschaulich dargelegt und – auch was die steuerfachlichen Implikationen angeht – sorgfältig und präzise analysiert. Aufgrund dessen sollen an dieser Stelle nur einige, Struktur und praktische Auswirkungen betreffende Aspekte herausgegriffen werden:

1. Notwendigkeit der konsequenten interdisziplinären Entwicklung und Erprobung

1.1 Entwicklung des TIM-Verfahrens

[i]Historie zum TIM-VerfahrenDie Entwicklung des TIM-Verfahrens lässt sich grob in vier zeitliche Abschnitte einteilen:

[i]14 Irrtümer über INSIKA, http://go.nwb.de/t4lmnDas TIM-Card-Verfahren, d. h. dasjenige mit einer von der D-Trust GmbH – einer Tochtergesellschaft der Bundesdruckerei GmbH – ausgegebenen Tax-Identification-Module Card, [73] ist in sicherheitskonzeptioneller [74] und sicherheitspraktischer Hinsicht [75] vielfach dokumentiert. Trotz zahlreich verbreiteter Irrtümer ist bis heute kein erfolgreicher Angriff auf das Sicherheitssystem bekannt oder auch nur beschrieben worden. [76]

[i]Hohe FunktionssicherheitAuch in diesem Test konnte dem TIM-Card-Verfahren angesichts der geringen Verifikationsfehlerrate vom 2,8 % [77] und unter Berücksichtigung der Ergebnisse aus der Datenanalyse, nach der fast alle Verifikationsfehler aufgeklärt werden konnten, eine sehr hohe Funktionssicherheit bescheinigt werden. [78] Dabei waren oder sind alle im Feldversuch noch aufgetretenen Verifikationsfehler innerhalb kurzer Zeit durch Programmkorrekturen zu beseitigen; es handelt sich also nicht um Probleme des Sicherheitssystems oder der Spezifikationen von Taxonomie oder TIM. [79]

[i]Untersuchung des Betriebs- und PrüfkonzeptsInfolgedessen soll der Schwerpunkt nachfolgend auf das Betriebs- und das Prüfkonzept gelegt werden. Auf die hohe Bedeutung, denen Tests im Feld auch dabei zukommen, wurde an anderer Stelle bereits eindringlich hingewiesen. [80] Auch im „Feldversuch 2018“ traten selbst bei Kassen eines Herstellers, der diese bereits seit mehr als vier Jahren mit der TIM-Card im Feld betreibt, einige der für kryptografische Sicherheitslösungen typischen Probleme, die zu Verifikationsfehlern führten, erst im Praxistest mit Massendaten auf. Der Grund: Die entsprechenden Sachverhalte kamen in den entwicklungsbegleitenden Tests schlicht nicht vor. [81] Die Abbildung auf der folgenden Seite stellt das System stark vereinfacht dar – nunmehr ergänzt um die Taxonomie. [82]

1.2 TIM-Card

[i]TIM deckt Manipulationen auf Die TIM-Card sichert durch digitale Signatur gezielt – d. h. gem. dem Grundsatz der Datenvermeidung – nur den steuerfachlich notwendigen Teil der aufzuzeichnenden Kassendaten. Diese können von jeder Kasse bereitgestellt werden, die die vorgeschriebenen Einzelaufzeichnungen erzeugen kann. Durch die Absicherung dieser Daten sind Manipulationen, die zu einer Steuerverkürzung führen könnten, zweifelsfrei erkennbar. Die für jeden beleghaften Geschäftsvorfall zu speichernden Daten sind im Wesentlichen:

• verkaufte Produkte oder Dienstleistungen mit Menge, Bezeichnung, Preis und Umsatzsteuer,

• Gesamtumsätze pro Steuersatz,

• Zeitpunkt des Geschäftsvorfalls (Datum-/Zeitmarke),

• Information über den jeweiligen Bediener (Name oder ID),

• Dateneigentümer (Unternehmer-ID = St.-Nr., USt-ID-Nr. oder W-ID-Nr.),

• Nummer der TIM-Card zur Unternehmer-ID,

• herstellerunabhängige, transaktionsbezogene Sequenznummer und

• die zugehörige Signatur.S. 533

1.3 Taxonomie

[i]Vereinheitlichung der Datenstruktur durch TaxonomieDie Taxonomie ist eine unter Berücksichtigung der – seinerzeit durch die „AG Registrierkassen“ erarbeiteten – steuerfachlichen Anforderungen erstellte semantische Datensatzbeschreibung. Sie definiert einheitliche Strukturen für Kassendaten – d. h. Einzelbewegungen, Stammdaten und Abschlüsse. Deshalb sind sie für eine progressive und retrograde Prüfung zwischen den Grundaufzeichnungen und der Erfassung im Hauptbuch (Finanzbuchführung) verwendbar.

1.4 Beleg

Auf dem Beleg werden [i]Beleganforderungen alle Daten ausgedruckt, die eine Verifikation der Signatur des Geschäftsvorfalls ermöglichen. Neben dem Ausdruck der bekannten Informationen eines Belegs müssen die TIM-Sequenznummer des Geschäftsvorfalls, der Hashwert über die Artikelpositionen und die Signatur auf dem Beleg vorhanden sein, und zwar entweder in Druckform oder als Abbildungsvorschrift der Belegdaten in einem QR-Code. [84]

1.5 Prüfprogramm

[i]IDEA als Prüfprogramm ungeeignetDas von den Prüfungsdiensten der Finanzverwaltungen des Bundes und der Länder eingesetzte Revisionsprogramm IDEA verfügt – jedenfalls derzeit – über kein Modul zur Prüfung von Signaturen. Deshalb ist die Verifikation der mit dem TIM signierten Taxonomie-Daten mittels eines Prüfprogramms erforderlich.

Das im Feldversuch verwandte Prüfprogramm „TIMiVerify“ kann gleichermaßen Daten im CSV- und JSON-Format im Hinblick auf Integrität, Authentizität und Vollständigkeit verifizieren. [85] Die dazu erforderlichen Referenzdaten stammen aus der Public-Key-Infrastructure (PKI). S. 534

2. Versuchsauswertung

2.1 Technische Erkenntnisse

[i]Messung der VerarbeitungsgeschwindigkeitDie Verarbeitungsgeschwindigkeit von Registrierprozessen ist ein Qualitätsmerkmal für Kassen.

Smartcards wie das TIM benötigen typisch etwa 150 Millisekunden zur Berechnung einer ECDSA-Signatur. Die Reaktionszeit insgesamt ergibt sich aus der Summe der Zeiten für

• Signaturanfrage,

• Signaturanfrage-Plausibilisierung,

• Berechnung der Signatur und

• Rückgabe der Signaturantwort.

Die Reaktionszeit für die Antwort auf ein Kommando darf insgesamt 500 Millisekunden nicht übersteigen. [86]

[i]Keine Verzögerung durch TIM Bei den im Feldversuch eingesetzten Kassen wurden keine bzw. geringfügig wahrnehmbare Veränderungen der Reaktionszeiten ermittelt. Die Signaturberechnungszeiten im Feldversuch von durchschnittlich 280 Millisekunden wurden von den Herstellern als schnell genug bewertet. Wahrnehmbare Veränderungen traten selten und auch nur dann auf, wenn parallele Signaturanfragen auf ein von mehreren Kassenplätzen genutztes TIM erfolgten. [87]

Die Taxonomie hatte auf den laufenden Betrieb praktisch keinerlei Einfluss, da die entsprechenden Dateien bei diesem System erst zu einem späteren Zeitpunkt auf Abruf erzeugt werden. [88]

Die ermittelten Verarbeitungszeiten für die Verifikation von Daten im JSON-, CSV- oder XML-Format liegen zwischen 1 Millisekunde bis 5 Millisekunden je Transaktion und sind sehr stark rechnerabhängig. [89]

[i]Speicherbedarf Der monatliche Speicherbedarf für die Daten der Taxonomie betrug im Test zwischen 0,3 und 38,7 Mbyte im CSV-Format und zwischen 0,9 und 300,0 Mbyte im JSON-Format. Unter Anwendung geeigneter Kompressionsverfahren kann der Speicherbedarf für JSON-Dateien allerdings deutlich verringert werden. [90]

2.2 Kassenhersteller

Die D-TRUST GmbH – eine Tochter der Bundesdruckerei GmbH – stellte für den Feldversuch Testkarten „TIM256“ mit Zertifikaten zur Verfügung. [91]

[i]Implementierung in wenigen Monaten möglichEin Kassenhersteller, bei dem die Implementierung des TIM zu Beginn des Feldversuchs bereits abgeschlossen war, bezifferte den Entwicklungsaufwand bei Einführung eines neuen oder anderen Signatursystems auf rund drei Monate. Für die Implementierung eines Signatursystems vom Beginn der Entwicklung bis zu einem stabilen, fehlerfreien Produkt wird eine Zeit von einem Jahr angegeben. [92]

[i]Implementierungskosten bis zu 50 €In Abhängigkeit von der Kassenhardware liegen die Kosten zur Implementierung des TIM im Kassenumfeld – d. h. die Mehrkosten für die Hardware pro Gerät – zwischen wenigen Euro bei PC-Kassen bis zu 50 € bei Embedded-Kassen. S. 535

Der Entwicklungsaufwand für die Software und die Integration der TIM-Card in Embedded-Kassen liegt nach aktuellen Erkenntnissen zwischen vierzehn Tagen bis zu zwei Monaten. [93]

2.3 Kassenanwender

[i]Problemloser PraxisbetriebInbetriebnahme und Betrieb der Kassen bei den Anwendern verliefen – auch nach deren Auffassung – durchweg problemlos. Im Kassenbetrieb selbst wurden keinerlei Unterschiede im Verhalten zwischen den Feldversuchskassen und dem herkömmlichen Kassenbetrieb bemerkt. Das Kundeninteresse bezüglich der Belege mit QR-Code war gering. Nur in Einzelfällen wurde erhöhter Papierbedarf für die Belege erwähnt, allerdings ohne weitere Wertung. [95]

[i]TIM-Kosten Im Kassenbetrieb fallen in erster Linie die TIM-Kosten an. Diese liegen aktuell bei 69 € netto bei einer Laufzeit von drei Jahren. [96]

2.4 Technische Vorprüfung der Kassendaten

[i]Senkung der Verifikationsfehlerrate durch Vorprüfung Da beim Feldversuch die Daten aus den Kassen ohnehin fortlaufend zur Klärung von Problemen verifiziert werden mussten, führte eine von den Kassenherstellern unabhängige Vorprüfungsstelle die technische Verifikation der Daten durch. Dadurch konnte einerseits die Verifikationsfehlerrate reduziert und andererseits das Prüfprogramm permanent verbessert werden. Diese Verbesserungen dienten in den meisten Fällen der Erhöhung der Fehlertoleranz bei Verifikationsanfragen mit fehlerhaften Daten. [98]

[i]Ursachen für Verifikationsfehler Die Verifikation der Daten in den drei Formaten JSON, CSV und XML war positiv. Die Ursachen für die Verifikationsfehler waren [99]

• Implementierungsfehler,

• Mappingfehler bei der Übergabe der Daten aus der Kasse/TIM-Kommunikation in Taxonomie-JSON,

• Konvertierungsfehler JSON in CSV und

• Ausfall der Sicherheitseinrichtung bei Weiterbetrieb der Kasse.

[i]100%ige FehlerentdeckungsquoteSämtliche Fehler – und das ist für die Prüfpraxis entscheidend – waren bei der Verifikationsprüfung erkennbar.

Insgesamt wurden 302.314 Datensätze (Transaktionen) an die Prüfer der Finanzbehörden im Taxonomie-Format CSV übergeben, davon

• 300.046 vom TIM signierte Datensätze mit einer Fehlerrate von 2,8 % und

• 2.268 unsignierte Datensätze.S. 536

2.5 Prüfung durch die Finanzbehörden

2.5.1 Betriebsprüfung

[i]Datenprüfung mit IDEADie Ziele der Prüfungen wurden vor der Datenübergabe in Abstimmung mit dem Bundeszentralamt für Steuern (BZSt) definiert. [100] Für die Prüfungen standen insgesamt Daten von 24 Kassen über Zeiträume von bis zu drei Monaten zur Verfügung. Die Auswahl der Daten zur Prüfung war den Prüfern selbst überlassen. Die Prüfung der Taxonomie-Daten konnte wegen der Konvertierung der Daten in das CSV-Format wie geplant mit dem Prüfprogramm IDEA erfolgen.

Die Ergebnisse der Vorprüfungen zur Verifikation der Daten wurden bestätigt, soweit sie ausgeführt und bewertet wurden. Die Verifikation lief technisch ohne Probleme und schnell. [101]

Bezüglich einzelner Prüfungsschritte ist – nach wie vor – die Kreativität des einzelnen Prüfers gefragt. Nach ganz überwiegender Meinung konnten die Prüfungen anhand der Daten gut durchgeführt werden; zudem ließen sich konkrete Umsätze – welche etwa in einem Testkauf festgestellt wurden – einfach in den Daten finden.

[i]IDEA ohne SignaturprüfmodulWenngleich die Prüfer durchgängig die Vorteile bei Verwendung einer Sicherheitseinrichtung und diejenigen einer Datenverifikation vor Prüfung anerkannten, wird einem Prüfprogramm nur unter der Voraussetzung vertraut, dass die erzeugten Belege prüffähige Merkmale enthalten. Insoweit wurde zu Recht als umständlich bemängelt, dass die von der Finanzverwaltung eingesetzte Revisionssoftware IDEA – natürlich – (noch) kein Signaturprüfmodul enthält.

[i]Taxonomie- Dokumentation Die Taxonomie-Dokumentation wurde als grundsätzlich ausreichend angesehen und trotz ihrer Komplexität als verständlich bezeichnet. Insoweit wurde ausgeführt:

[i]Verifikationsprüfprogramm Die Anwendung des Verifikationsprüfprogramms wurde als unkompliziert und problemlos bewertet; die Ergebnisse der Prüfung bezeichneten die Prüfer als verständlich. S. 537

2.5.2 („Virtuelle“) Kassen-Nachschau

[i]Zielsetzung von Kassen-NachschauenAus Zeitgründen konnten Kassen-Nachschauen lediglich „virtuell“ durchgeführt werden. Als deren Ziele wurden beschrieben: [105]

• die Prüfung des ordnungsgemäßen Betriebs der im Einsatz befindlichen Kassen,

• die Prüfung der ordnungsgemäßen Aufzeichnung der Geschäftsvorfälle,

• die Prüfung und Bewertung der Datenspeicherung der Grundaufzeichnungen sowie

• die Bewertung der Schutzmaßnahmen gegen mögliche Datenveränderungen.

[i]Prüfkriterien Mit neun Prüfkriterien konnte ein formalisiertes Vorgehen bei der Kassen-Nachschau erreicht werden. Diese Vorüberlegungen wurden derart konkretisiert, dass unter Nutzung der übergebenen Daten und gedruckter Belege eine Kassen-Nachschau simuliert werden konnte. [106]

Nur in einem Bericht der Prüfer wurde auf die Frage Kassen-Nachschau eingegangen. [107]

Insoweit wurden Belege von zwei Kassen untersucht. Dabei wurden mit einem Handy die QR-Codes der Belege gescannt und die positive Antwort des Verifikationsservers dokumentiert. Es wurde ausgeführt: [108]

3. Schlussfolgerungen aus dem Feldversuch

[i]Einfache TIM- Implementierung Die Implementierung des TIM in die Kasse ist mit geringem Aufwand ausführbar. Der Betrieb von Kassen wird durch TIM- und Taxonomie-Einsatz für die Anwender und deren Personal nicht spürbar beeinflusst.

Bei Nutzung der vorhandenen, erprobten kryptografischen Sicherheitslösung mit dem TIM werden Daten auf hohem Sicherheitsniveau (CC EAL4+) gesichert; diese sind – jederzeit für Dritte prüfbar – authentisch, integer und zeitlich geordnet.

[i]Interoperabilität gewährleistetDie Interoperabilität verschiedener Systeme wurde erfolgreich getestet. Kassen und Sicherheitseinrichtungen arbeiteten ohne Ausfälle; entsprechende Störungen wurden erkannt und sind dokumentiert. Die Taxonomie ist mit einer technischen Sicherheitseinrichtung funktionsfähig; Taxonomie-Daten lassen sich mittels eindeutiger Abbildungsvorschriften in verifizierbare Datenstrukturen überführen. S. 538

Trotz hohen Entwicklungs- und Reifegrads von Sicherheitseinrichtung und Taxonomie sowie verfügbarer öffentlicher Dokumentation [109] war der Aufwand zur Zusammenführung beider Systeme immer noch deutlich höher als erwartet.

[i]Prüfbarkeit und Nachvollziehbarkeit Zur Prüfbarkeit und Nachvollziehbarkeit gem. § 145 Abs. 1 AO ist festzustellen, dass die Taxonomie-Daten für Betriebsprüfungen grundsätzlich tauglich sind. Die Daten aus dem Feldversuch genügen den steuerlichen Anforderungen, d. h. der Zweck, den sie für die Besteuerung erfüllen sollen, wird erreicht. Damit ist die zentrale Anforderung des § 145 Abs. 2 AO erfüllt.

[i]Übertragungsgeschwindigkeit steigerungsfähigDie Geschwindigkeit des Imports der Daten auf die Rechner der Prüfer ist angemessen, bei noch stärkerer Standardisierung auch weiter steigerungsfähig. Die Prüfung großer signierter Datenmengen ist möglich. Nach Beseitigung der bei den Prüfungen erkannten Softwarefehler führten sämtliche Verifikationen und Prüfungen der Daten zu verwertbaren Ergebnissen.

Der Nachweis einer Nutzung der Sicherheitseinrichtung mit Belegen im Rahmen einer Kassen-Nachschau wurde erbracht.

[i]Prüfer-Schulungen und Prüfanweisungen erforderlichLetztlich lassen die Ergebnisse des Feldversuchs sowie die Antworten in den von den Prüfern abschließend ausgefüllten Fragebögen [110] zudem Folgendes erkennen:

• Die Durchführung entsprechender Schulungen zum System ist in jedem Fall erforderlich. Deren Zeitbedarf dürfte mit etwa sechzehn Stunden pro Prüfer(in) zu veranschlagen sein, soweit ausreichende Kenntnisse und Erfahrungen im Umgang mit der Revisionssoftware IDEA vorhanden sind. Die meisten Finanzverwaltungen der Bundesländer dürften über systemisch hinreichend geschulte Multiplikatoren verfügen.

• Für effektive und einheitliche Prüfungen ist die Erarbeitung von Prüfanweisungen dringend erforderlich.