Die ISCA-Prinzipien einfach erklärt

Das Team von fiskaltrust kennt viele der Stolpersteine auf dem Weg zu einem gesetzeskonformen POS-System in Frankreich. Die Legislative hat es im Gesetz prinzipiell umrissen, was sie von Kassenherstellern und -betreibern erwartet. Danach kamen noch einige Verordnungen, welche die Umstände noch genauer präzisierten. Und am Ende passten sich die beiden Zertifizierungsstellen mit ihren Regeln darauf an und interpretieren die Vorgaben auf ihre Art. Aber was hat es jetzt wirklich mit diesen Prinzipien auf sich? Lesen Sie weiter um eine neutrale und unabhängige Darstellung zu erhalten.

Warum nur vier Eckpfeiler?

In Frankreich hält man nicht so viel von exakten Regeln, welche bis in den letzten Winkel alles genau definieren. Nein! Man geht viel mehr davon aus, wenn die Eckpfeiler definiert sind, kann jeder diese so umsetzen wie es perfekt ist. Diese Freiheit gibt den Kassenherstellern sehr viel Möglichkeiten und auch Freiheiten an die Hand.

Im BOI-TVA-DECLA-30-10-30 vom 30. Dezember 2020 werden im 2. Abschnitt die vier Prinzipien oder Vorgaben näher definiert. Auch wir werfen einen Blick darauf um die Mythen darum zu verringern und mit einem klaren Blick ein sicheres und gesetzeskonformes POS-System anbieten zu können.

Die vier Prinzipien brauchen ein Fundament!

Der Gesetzgeber legt eindeutig fest, dass nur Kassensysteme bzw. bei Multifunktionssoftware (PMS für Hotels, ERP-Systeme, oder ähnliches) nur das Kassenmodul zu sichern ist.

Als Ziel wird ganz klar die Überprüfung der aufgezeichneten Daten durch die Finanzverwaltung festgelegt. Doch wird keine genaue Vorgabe oder technische Lösung im Gesetz bzw. der Verordnung vorgeschrieben. Damit wird die Entwicklung der technischen Lösung in die alleinige Verantwortung der Privatwirtschaft übergeben.

Die eingesetzte Software muss daher alle ursprünglichen Zahlungsdaten erfassen, unveränderbar machen, sicher aufbewahren und eine Archivierung ermöglichen.

Die 1. Säule – Unveränderlichkeit

Dies ist das I für Inaltérabilité in ISCA und legt als ersten Schritt das Verhindern von nachträglich Veränderung fest. Werfen wir einen Blick auf die Daten welche hier betroffen sind. Zu aller erst geht es primär um Daten welche Waren und/oder Dienstleistungen betreffen für die eine Gegenleistung erwartet wird und für die eine Quittung ausgestellt werden. Ob dies tatsächlich zutrifft ist hier nicht wesentlich, es reicht das die Gegenleistung erwartet wird und die Quittung erstellt werden soll.

Welche Daten sind jetzt betroffen?

Es kann noch zusätzliche Daten geben (durch andere gesetzliche Grundlagen festgelegt), doch die folgende Liste legt die untere Latte dafür fest.

• Belegnummer
• Datum und Zeit
• Kassennummer (bzw. Terminalnummer)
• Gesamtbetrag der Quittung (inklusive aller Steuern)
• Details zum Artikel und/oder zur Dienstleistung (Bezeichnung, Menge, Einzelpreis, , Gesamtbetrag ohne Steuer, angewendeter Mehrwertsteuersatz)
• Alle Daten welche die Zahlungsmethoden betreffen

Zusätzlich müssen auch noch alle Daten welche die Nachvollziehbarkeit und Integrität der oben genannten Daten sicherstellt.

Darf der Administrator die Daten ändern?

Hier wird auch ganz eindeutig festgelegt, dass einmal gespeicherte Daten von niemanden mehr direkt verändert werden dürfen. Damit ergibt sich auch die Konsequent, dass alle Änderungen nur mehr mit Plus/Minus-Transaktionen erfolgen können. Es geht sogar soweit, wenn keine verknüpften Belege/Transaktionen erstellt werden, dass der ursprüngliche Beleg storniert werden muss und ein neuer mit den gewünschten Änderungen erstellt wird.

Als erster Schritt soll sichergestellt werden, dass die Daten auf Applikationsebene sicher sind. Dadurch wird dem Anwender jede Möglichkeit der Veränderung durch das POS-System verwehrt. Es dürfen damit keine Funktionen oder Module oder Tools existieren, welche eine direkt Änderung am Datenbestand möglich machen.

Der nächste Schritt ist die Sicherheit auf Ebene des Datenbestandes. Da ein Zugriff auf die Daten bzw. eine Datenbank nie verhindert kann, muss hier der Nachweis erbracht werden, dass die Daten nicht verändert wurden. Dies kann durch eine oder mehrere Techniken sichergestellt werden. Beispiels weise ist ein digitaler Fingerabdruck (Hashwert über alle Daten), eine ein- bzw. mehrfache Verkettung möglich oder ein sofortiges Spiegeln auf einen Datenträger außerhalb des Systems möglich.

Und wie erreicht man dies technisch?

Der Gesetzgeber macht hier mehrere Vorschläge:

1. den Benutzerzugriff auf alle Änderungsmöglichkeiten verhindern
2. jeden Zugriff/jede Veränderung Daten zu erkennen und jede mögliche Veränderung zu verfolgen
3. Ein Nachweis, dass die ursprünglichen Daten nicht verändert wurden
4. ein entsprechendes Beweissystem zur Verfügung stellen

All vier Punkt sind valide, doch nicht alle sind technisch umsetzbar. Daher wird eine Mischung aus allen vier Bereichen vorkommen. Der Zugriff auf Daten wird so weit es technisch möglich ist eingeschränkt und mit Hashing und Verketten können zumindest Änderungen erkannt werden. Obwohl der ursprünglichen Datenbestand nicht wieder hergestellt werden kann.

Die 2. Säule – Sicherheit

Dies ist das S für Sécurisation in ISCA und legt als zweiten Schritt das Verhindern von Löschen oder Veränderung fest. Hier liegt das Hauptaugenmerk auf dem Sichern der aufgezeichneten Daten und dem Hinterlassen von Spuren, falls Daten gelöscht oder verändert wurden.

Der Begriff Sicherheit wird nicht im Sinne der Zugriffseinschränkung verwendet. Sondern alle Zahlung, welche in einem POS-System von einer beliebigen Person erfasst werden, sollen gespeichert werden. Aber auch alle Änderungen an den Ursprünglichen Daten unterliegen der Sicherheit und müssen gespeichert werden.

Um auch jede weitere Möglichkeit auszuschließen müssen Daten welche im Trainingsmodus eines POS-Systems erfasst werden eindeutig gekennzeichnet werden. Nach außen mit einem klar erkennbaren Hinweis auf jeder Quittung und intern mit eben diesen Hinweis und dem speichern des Benutzers der den Trainingsmodus aktiviert hat.

Die 3. Säule – Speicherung

Dies ist das C für Conservation in ISCA und legt als dritten Schritt das Speichern der Daten durch das POS-System fest. Besonders wichtig ist hier das Betrachten des Löschens von Daten, falls nicht ausreichend Speicherplatz zur Verfügung steht.

Generell müssen alle Daten im gesetzlich vorgeschriebenen Zeitraum (6 Jahre, plus das laufende Geschäftsjahr) aufbewahrt werden. Dies steht außer Frage und hat auch nichts mit dieser Verordnung zu tun. Jedoch kann es sein, dass POS-Systeme nicht genügend Speicherkapazität aufweisen und daher Daten gelöscht werden müssen.

Der Gesetzgeber hat diese Problematik erkannt und auch die Zeichen der Zeit. Daher müssen die Daten nicht ausgedruckt vorliegen, sondern können elektronisch verarbeitet werden. Jedoch müssen die betroffenem Daten vor dem Löschen exportiert werden und es muss ein Archiv vor dem Löschen erstellt werden. Erst danach darf der Löschvorgang durchgeführt werden.

Die auf einem externen Speichermedium abgelegten Daten unterliegen natürlich auch den ISCA-Prinzipien, müssen vor jeder Veränderung geschützt werden und die Archivierung muss nachvollziehbar sein.

Es reicht nicht, nur die Belegsummen, kumulative Daten eines Beleges oder ähnliches aufzubewahren. Dies ist zwar nicht in der Verordnung (BOI-30-10-30) festgehalten, jedoch legen die Paragraphen L102B – L02E im Steuergesetzbuch (article L102b Livre des procédures fiscales) die Aufbewahrungspflichten und -fristen für ein Unternehmen fest.

Es gibt ein wenig mehr als nur Speichern!

Bei dieser Säule werden jedoch auch zusätzliche Prozesse definiert, welche ein POS-System ermöglichen und die daraus gewonnen Daten speichern muss. Diese zusätzlich erzeugen Daten dürfen niemals aus dem System gelöscht werden und natürlich müssen sie nach den ISCA-Regeln verwaltet werden.

Wir sprechen hier von den Summenzählern und den notwendigen Abschlüssen. Reine POS-Systeme müssen einen Tages, Monats- und Jahresabschluss anbieten. Und dieses Ende einer Periode muss vom POS-Benutzer auch durchgeführt werden. Bei einem Abschluss müssen die jeweiligen Summen für die Periode gesichert werden. Zusätzlich ist bei jedem Abschluss der dauerhafte Zähler zu ergänzen. Denn dieser zeichnet die Umsätze seit Beginn der Nutzung des POS-Systems auf.

Periodenzähler dürfen nur am Ende der betroffenen Periode auf Null gesetzt werden. Alle anderen Zähler dürfen nur dann auf Null gestellt werden, wenn die Soft- bzw. Hardware gewechselt wird. Bei einer einfachen Änderung der Software (bspw. ein Versionssprung) werden die Zähler nicht berührt.

Auch wird hier immer wieder darauf hingewiesen, dass die Daten im POS-System oder der Software gespeichert werden müssen. Dabei wird jedoch die Ausnahme für zentral geführte System gemacht. Diese dürfen die detaillierten Daten nur in einem zentralen Computer/Rechenzentrum ablegen.

Die 4. Säule – Archivierung

Dies ist das A für Archivage in ISCA und legt als vierten Schritt das Archivieren der Daten durch das POS-System fest. Jedes POS-System muss eine Archivierung anbieten und ein Archiv darf nicht mehr Daten als jene eines Jahres bzw. Geschäftsjahres enthalten.

Der Sinn des Archivs ist das Fixieren des Datenbestandes zu einem bestimmten Zeitpunkt. Der Gesetzgeber unterscheidet eindeutig zwischen Datensicherung und Archivierung. Denn auch das Archiv unterliegt den ISCA-Regeln und muss daher gesichert und unveränderlich abgelegt werden. Es darf jedoch von Anfang an, auch außerhalb des POS-Systems gespeichert werden.

Auf jeden Fall darf das Archiv kein proprietäres Format haben. Es muss jederzeit von der Finanzverwaltung ohne spezielle Software lesbar sein. Da der Inhalt nicht normiert wurde, muss den Finanzbehörden eine Erklärung des Inhalts in französischer Sprache zur Verfügung gestellt werden.

Auch den Speicherort legt der Gesetzgeber nur so weit fest, als das er sicher sein muss. Jedoch auch hier ziehen wieder die ISCA-Regeln und es deutet alles auf einen revisionssicheren Speicher hin.

Das Gebäude aus den ISCA-Prinzipien

Wie wir sehen steht das Gebäude auf einem breiten Fundament mit vier mächtigen Säulen. Natürlich ergeben sich daraus einige Konsequenzen für die Auto-Testierung Ihrer POS-System oder auch für das Erhalten eines Zertifikats.

Einerseits müssen Sie bestimmte Daten (zum Beispiel die Version des POS-System oder den Bruttopreis und die Steuer und den Einzelpreis, …) auf jeden Fall in Ihrem POS-System aufzeichnen. Weiters müssen Sie den gesamten Datenbestand Verketten und elektronisch Signieren. Und am Ende müssen Sie sogar noch ein Prüftool für die Archive zur Verfügung stellen. Denn auch diese müssen verkettet und gesichert werden. Sonst könnte am Ende ja jemand den Inhalt der Archive verändern ohne das es jemand bemerkt.

Sie sehen das Gebäude ist stabil, aber nicht ganz so leicht zu bauen! Mit fiskaltrust steht Ihnen jedoch ein verlässlicher und transparenter Partner zur Seite, mit dem Sie den Weg für ein gesetzeskonformes POS-System jederzeit beschreiten können.