Implementation KassenSichV
The "KassensichV" is a regulation issued by the Federal Ministry of Finance (BMF). A technical secure element (TSE) is needed, which has to be certified by a fiscal authority institute. At the moment there are a few certified TSE on the market.
The further use of the POS system without a TSE after 01.01.2020 is forbidden.
The only exceptions (status June 2024) are:
- Ticket vending machines and ticket printers
- Pay stations and parking ticket machines for parking space management and charging points for electric or hybrid vehicles
- Electronic accounting programs
- Vending machines for goods and services
- ATMs
- Cash and vending machines
efsta implements various certified TSEs of different vendors in the EFR middleware for the German law.
The TSE must be certified by BSI - please find a list of certified TSEs here (status June 2024)
An appropriate certified TSE can be bought from efsta. Additionally, the EFR enables a failure free operation in case of a TSE absence (Offline Mode) and the data of the TSE can be stored automatically in the efsta Cloud.
Functional Requirements
Interface to POS
Compared to the fiscal regulation of other countries, the German fiscal law requires an incremental protocolling of the checkout process. The process starts by calling the /register function with a <TraS> Tag. After the payment, the process has to be closed by calling /register with a <Tra> Tag.
In between there might be update requests for long running orders. There, requests can be sent by calling /register with a <Tra> Tag and NFS="Order". Orders also have to be started with a request with a <TraS> Tag.
The incremental protocolling is just for POS, not for other systems like scales or pre-register systems.
Process Workflow
A sales process will be started by sending a request with a <TraS> Tag. At the completion of a transaction, the whole transaction data has to be sent to the EFR within a <Tra> Tag per /registers request. Long running orders can be recorded by sending a request with a <Tra> Tag and NFS="Order". Also, orders have to be started by sending a <TraS> request.
ESR Format
Transaction data is sent to EFR as XML or JSON web request. See ESR format for ESR (efsta Simple Receipt) request and response format.
The following fields have specific meaning when generating the message to the fiscal system: 0
| Attribute | Name | Mandatory | Description | Datatype |
|---|---|---|---|---|
| ESR.TL | Transaction Location | No | Serial number of POS* | Text |
| ESR.TT | Transaction Terminal | No | Serial number of POS* | Text |
| ESR.TID | Transaction ID | Yes | The Transaction ID is returned from the start of a transaction and has to be transmitted in update and finish transaction requests | Number |
| ESR.NFS | Non-fiscal Signed | No | Can be used to sign training transactions or other non fiscal transactions | Text |
* For fiscal signature [TL + /] + TT is used.
Simplified Rules
We recommend using the simplified rules, as the EFR will handle many things that would otherwisehave to be done by the POS.
Gastronomy and Hospitality: long-running orders
For long-running orders, an /updateTransaction request should be sent. But as relief you can send a /finishTransaction with type "Order" (in the EFR NFS=Order) like shown in the picture above.
- Advantage: The updates are canceled, so the POS does not have to remember the TID. Bills can be splitted.
- Requirement: The timestamp of the first "order" (in the EFR D0) has to be printed on the receipt - this is mandatory by law.
Scales
Separate scales are pre-systems, so they do not have to send data to the TSE. POS with scanners register the data directly to the positions, so no update is needed.
QR Code
A receipt in germany must contain the following data - these are legal requirements of the ministry of finance and are also included in the fiscalization regulations KassenSichV:
- Full name and address of the issuing company
- Date and time the receipt was issued
- Tax number or sales tax identification number (USt-IdNr.)
- Type and quantity of the product sold or service purchased
- Total amount and tax rate of all products sold or services purchased
- Amount by payment type
- Consecutive transaction number that can be clearly assigned to the transaction made
- In the case of a previous order (e.g. in the hospitality industry), the start time of the first order
- Signature counter of the cash register respectively security module TSE
- Check value of the receipt
These values must be printed on the receipt as a text and number combination. Optionally, they can also be displayed on the receipt in the form of a QR code. There is no obligation to use the QR code - however, such a code can help to significantly simplify a possible cash register inspection.
Retention periods
In Germany, invoices must be kept for ten years.
Digital storage: Digitization makes it possible to store invoices in electronic form. It is important that the documents remain available and legible unchanged for the entire retention period. Proper archiving: In addition to pure storage, proper archiving of invoices is also crucial. This means that the documents should be stored systematically so that they are easy to find when needed. Archiving is part of the esfsta archive.
Link to § 6 Requirements for the receipt: https://www.gesetze-im-internet.de/kassensichv/__6.html
According the BMF (DSFinV-K p. 109ff): The QR-code is not necessary for the fiscal law. But if the bon contains the QR-code, a tax auditor may only verify the single Bon via QR-code. If there is no QR-code printed on the bon, you have to make a DSFinV-K export and a TSE export, so that the tax auditor can verify the data.
The data of the QR Code is returned in the <Code> tag.
<TraC SQ="362">
<Result RC="OK" />
<Fis ...>
...
<Code>2;1/1;Kassenbeleg-V1;Beleg^528.90_0.00_0.00_0.00_0.00^537.40:Bar;16;102;2019-12-20T12:36:33.000Z;2019-12-20T12:36:33.000Z;ecdsa-plain-SHA384;unixTime;e2Pgb4XpCMH/rbVj/EQwedMu84Xs7V0wU7/r0ppiG/GjlOGYDpnUs0dZLuei/XNBTIL5Ve5fig/QcZW1bk2+26q3NAgOh0qVzu76tIkf6HvNOBl109JslBGZrESy6adA;BHdNMW1vSvYYdQqRKgzHq9AnG1ZavfpacMU1pfXkXheFaJnLLmE6gsFEHceHKs0iOR6oSqatFzwy6+cSKAzKFfHndVz+9zgGwgN9cn/RVEudbgdfishfyKkmP2HpBm0ruA==</Code>
</Fis>
</TraC>
If the attribute "Fis_QR" is set in the EFR profile, the data of the base64 coded image will be in the response of the EFR, e.g.: Fis_QR=type=bmp&size=4
GET /control/verify – Verify Signature
For support purposes only. With this method the qr code can be verified.
| Query | code | Enter whole Fis.Code |
| Request Example | http://localhost:5618/control/verify?code=... | |
| Response Header | Content-type | text/plain |
VAT Handling
Following rates are used by default, if only TaxG is delivered, but no tax rate in TaxA element:
| Tax group | TaxG | Tax rate |
|---|---|---|
| Normal | A | 19% |
| Reduced | B | 7% |
| Average tax rate (§24(1)Nr.3 UStG) | C | 10,7% |
| Average tax rate (§24(1)Nr.1 UStG) | D | 5,5% |
| Not taxable | E | 0% |
| VAT-exempt | F | 0% |
| Tax rate can not be determined | G | 0% |
| Corona Normal | H | 16% |
| Corona Ermässigt | I | 5% |
Specifics
Tax of old parts (Altteilsteuer)
A detailed description and an example can be found in the country specific business cases Altteilsteuer
Difference tax rate (Differenzbesteuerung)
A detailed description and an example can be found in the country specific business cases Differenzbesteuerung