In the summer of 2019, the Ministry of Finance clarified further questions on the KassenSichV and specified some open points. We explain what is currently happening and what you need to know now.
Unternehmer, Finanz & Technik-Experte
The German Federal Ministry of Finance (BMF) published in June the final version of the Anwendererlass § 146a AO. Reminder: The § 146a AO, in other words the Kassensicherungsverordnung, was introduced on December 22, 2016 by the Act on Protection against Manipulation of Digital Records (Kassengesetz) and applies from 1.1.2020.
The letter clarifies and provides detailed definitions of individual AEAO sections of § 146a. We summarize the most important points for you.
By and large, KassenSichV is mandated to ensure the tamper-proofing of business records and recording systems. More specifically, a protection structure based on:
The latest information given by the Ministry of Finance includes a definition of business transactions, namely:
“Business transactions are all legal and economic transactions that document, or influence, or change the profit or loss or the composition of assets in a company within a certain period of time.”
There are also examples of business transactions that can occur in electronic recording systems. These are:
The regulation also refers to “other operations” — meaning recording processes that are triggered not by a business transaction, but by other events in the use of the electronic recording system and that are required for verifiable documentation of the correct and complete recording of the business transactions.
This is concerning, for example:
Noteworthy: a transaction is based on at least one transaction. While the process relates to the operations in the recording system, a transaction sums up the security steps that occur within the technical security device (TSE) to the operation in the respective recording system.
Yes! A cloud-based implementation of the technical safety system is intended by the BSI and BMF (The Federal Ministry of Finance).
In order to get a more on-point definition of the technical safety system, the required protocol data and their storage are thoroughly defined below.
In the latest statement of the BMF, the requirements regarding the reliability of the storage medium are explicitly formulated.
It is clear that a physical identity of security module and storage medium is not required. The storage medium can thus be met with a cloud storage or even with a conventional data storage menium (memory card or similar). We recommend the up-to-date and future-proof option of storage in the cloud.
Also in this area, there is now more transparency:
In the case financial audits, the secure application data must be made available for verification of the logging.All data recorded with the electronic recording system must be made available in a machine-readable format . The data, as well as its format are defined in the“Digital interfaces of the financial administration for electronic recordingsystems” (DSFinV).
The DSFinV‑K applies to electronic or computer-aided cash register systems and cash registers.
The “Digital Financial Administration for Cashiers” interface (DSFinV‑K) is a standardization of data standards for cash registers. It is an important step in the direction of planning and legal certainty for entrepreneurs. Version 2.0 was released in August and brings even more clarity. The details will be published here shortly on the KassenSichV blog.
The receipt can be provided both electronically and printed. If the receipt is submitted in electronic format (for example, via SMS or e‑mail), the customer must firstly agree.
Only displaying the receipt on the cash register’s screen is not enough to fulfill the receipt issuing obligation. However, it is possible to transfer the document via QR-code or NFC. Basically, a standardized data format must be used for electronic document output. Customers must be able to access the receipt by using a standard software. Customers must be able to access the receipt by using a standard software.
Therefore, there is no reason anymore not to use a paperless cash register in the future! This saves tons of toxic thermal paper — an important step in the right direction. Incidentally, fiskaly has been relying on the innovative technology of e‑receipts for many years. Find out more on fiskaly.com.
On a document, certain data must be printed in order to validate the correct recording in the case of a check in the recording system.
The presentation of the inspection characteristics of a document with a QR codeis possible. The application of the QR code is voluntary. We definitely recommend the use of QR codes, as this supports the testing process.
The BZSt provides the following example:
Feld | Beschreibung |
<qr-code-version> | Versionsnummer des QR-Codes, ist immer: V0 |
<kassen-seriennummer> | Seriennummer (Client-Id) der Kasse |
<processType> | processType (siehe oben) |
<processData> | processData (siehe oben) |
<transaktions-nummer> | Transaktionsnummer der TSE |
<signatur-zaehler> | Signaturzähler der finishTransaction-Operation der TSE |
<start-zeit> | Log-Time der startTransaction-Operation der TSE im Format |
<log-time> | Log-Time der finishTransaction-Operation der TSE im Format |
<sig-alg> | Signaturalgorithmus |
<log-time-format> | Log-Time-Format |
<signatur> | Prüfwert / Signatur der finishTransaction-Operation der TSE |
<public-key> | Öffentlicher Schlüssel (base64 codiert) |
Beispiel QR-Code des Bundeszentralamts für Steuern (BZSt)
V0;955002–00;Kassenbeleg-V1;Beleg^0.00_2.55_0.00_0.00_0.00^2.55:Bar;
18;112;2019–07-10T18:41:04.000Z;2019–07-10T18:41:04.000Z;ecdsa-plain-
SHA256;unixTime;MEQCIAy4P9k+7x9saDO0uRZ4El8QwN+qTgYiv1DIaJIMWRiuAiAt+s
aFDGjK2Yi5Cxgy7PprXQ5O0seRgx4ltdpW9REvwA==;BHhWOeisRpPBTGQ1W4VUH95TXx2
GARf8e2NYZXJoInjtGqnxJ8sZ3CQpYgjI+LYEmW5A37sLWHsyU7nSJUBemyU=
If failure of the technical security system occurs, the downtime and its reason must be documented. However, the receipt issuing obligation under § 146a (2) AO shall not apply only if the recording system is completely out of service.
If the electronic recording system can continue to operate without the functioning certified technical security system, this failure must be noticeable on the receipt. This can be done by means of missing transaction number or by any other unique identifier.
If the failure only affects the technical security system — whether hardware or cloud-based — the electronic recording system is allowed to be used, if you can record the loggings, until fixing the TSS issue. In case of failure of printing or transmission unit for the receipt, the recording system can still be used.
In either case, the entrepreneur must immediately solve the cause of the failure, take measures to remedy it and ensure that the requirements of § 146a AO are met again as soon as possible.
WATCH OUT! A failure of the TSE does not relieve you of the obligation to issue a receipt. If not all the required values can be provided for the document, the electronic recording system must provide at least the date and time document details.
There are only two situations where the obligation to issue a receipt does not have to be met:
The recording system must ensure that the following procedure is detected by a TSS. Most importantly is that the start, changes and the end of a business case or activity are to be recorded.
It is now stipulated that the recording system must start a logging in the technical security system immediately after the start of a business transaction (see chapter 3.3.1 of Technical Guideline BSI TR-03153).
In this case, a clear and continuous transaction number of a signature counter is mandatory, together with a test value generated by the certified technical security system.
No later than 45 secondsafter a change in the data of the operation, the data of the certified technical security system must be updated. Here, generating a test value by the technical security system is optional. he transaction number can be retained and the signature counter is increased by 1 each time it is updated with test value calculation.
If the operation is completed, the transaction must be completed within the certified technical security system. The TSS must generate a test value in this case. Again, the transaction number is retained and the signature counter is increased by 1. Only at this logging step, the completion time is included in the log data.
In principle, the time at which the electronic recording system starts or ends an operation is crucial here. Before issuing a receipt, the operation must be completed.
The operation data content can be defined differently depending on the nature of the operation. In principle, however, all data recorded with the electronic recording system must be made available in a machine-readable . This is defined in the “Digital Interfaces of Financial Management for Electronic Recording Systems”(DSFinV). For cash registers, the format (DSFinV‑K) is based on the DFKA taxonomy — i.e. the uniform, cross-industry format for cash register data.
The technical guidelines regarding the technical content of the data to be backed up were kept rather general. Hedging can be done for a wide variety of types of data. The nature of the process makes it possible to distinguish the structure of the content that is to be protected
. The following transaction types are defined:
For cash registers which are acquired after 25/11/2010 and before 01/01/2020, a temporary derogation applies. If the cash registers already meet the requirements of the Federal Ministry of Finance letter of 26.11.2010 but are not upgradeable to fulfill the KassenSichV requirements due to their design, they may continue to be operated until latest 31.12.2022. In this case, this must be demonstrated and attached to the procedural documentation.
Attention: the exemption does not apply to PC cash register systems!
Here the rules are clearly defined. According to the KassenSichV §1 Abs 1 Satz 2 the following categories are to be excluded:
This includes a special case:
“An electronic recording system with cash function that meets the requirements of ‘Minimum Requirements for Risk Management — MaRisk’ and the ‘Banking Supervision Requirements for IT’ (BAIT) of the Federal Financial Supervisory Authority, as amended, and by a credit institution i.S.d. § 1 (1) KWG. ”
DSFinV‑K: The data standard for cash registers explained in detail Last August, version 2.0 of DSFinV‑K was released. Here we explain the most important points
Belegausgabepflicht — what you need to know With theKassenSichV there are several topics that you need to consider. The obligation to issue a receipt (Belegausgabepflicht)
Presentation of our cloud-based fiskaly TSS at the DFKA workshop on the 5th of July in Berlin Many questions remain unanswered when it comes to
Copyright fiskaly GmbH 2019
