Terminology
As a PosCreator, PosDealer or PosOperator, you should not lose time searching and understanding any information due to linguistic ambiguity. This list clarifies the terms we use in the fiskaltrust.Portal and in the documentation.
| Terms in our documentations | Explanation |
|---|---|
| fiscal terms | partly relevant only for individual countries |
| Abgabenordnung (AO) | The Abgabenordnung (AO), a central German tax law, sets out the essential requirements for bookkeeping and thus also for cash management. TSE and cash audit are dealt with in Sections 146a and 146b, while Section 379 lists fines for violations. |
| Application decree (Anwendungserlass) | Instruction from a ministry to subordinate authorities on how to interpret and apply a particular law and its regulation. |
| BMF | Bundesministerium für Finanzen or Federal Ministry of Finance |
| Business transaction | Definition in the German Abgabenordnung (AO): Business transactions are all legal and economic transactions that document or influence or change the profit or loss or the asset composition in a company withi**. |
| DSFinV-K | The Digitale Schnittstelle der Finanzverwaltung für Kassensysteme (DSFinV-K) is a German standardization of cash register records. This standardization describes primarily the taxonomy for cash register data defined by DFKA e.V. The taxonomy maps the data by default in a JSON format (which, for example, is easily extensible). In addition, it provides a way to convert the data into a CSV structure (multiple interlinked tables). Since the tax authorities can only evaluate CSV data, DSFinV-K uses this representation. |
| GoBD | The Grundsätze zur ordnungsmäßigen Führung und Aufbewahrung von Büchern, Aufzeichnungen und Unterlagen in elektronischer Form (GoBD) are principles for the proper keeping and storage of books, records and documents in electronic form as well as for data access - Decree on the formal requirements for bookkeeping, the storage of documents and electronic data relevant under tax law as well as data access regarding the principles of proper bookkeeping (GoB). |
| Kassensicherungsverordnung (KassenSichV) | The German Fiscal Code (Abgabenordnung, AO) contains the basic regulations on the taxation procedure applicable to all types of taxes. In addition, the general rules are to be concretized in the Cash Security Ordinance (Kassensicherungsverordnung). |
| Single record | The tax authorities understand a single record to mean the separate recording of each business transaction so you can trace its content. According to the German application decree for Section 146, you must record the following for this purpose: the designated item sold, the final retail price, the associated sales tax rate and amount, agreed price reductions, the method of payment, the date and time of the transaction, and the quantity or number sold. |
| Taxonomy | In our context, taxonomy always refers to the DFKA cash register data taxonomy. This taxonomy standardizes the individual records and daily financial statements of POS-Systems, irrespective of manufacturer and industry. A taxonomy allows it to provide standardized data for POS-System inspections and audits. A taxonomy enables the creation of a uniform interface between POS-Systems and accounting. |
| TSE | According to the legal definition in Germany, POS-Systems need hardware-based or cloud-based TSE (Technische Sicherheits Einrichtung). TSE means a technical security device consists of a security module, a storage medium and a uniform digital interface. Therefore, you may only use a TSE certified by BSI (Federal Office for Information Security), which is responsible for the conception and certification. |
| TSE: Authenticity | In the context of TSE, authenticity means that the data actually originates from the alleged originator, e.g., the respective company. |
| TSE: Integrity | Integrity in the data context means that they have remained unchanged since creation. In the context of the TSE, it also means that nobody removed records. |
| TSE-as-a-Service | TSE-as-a-Service is one of fiskaltrusts products that guarantee the availability of a functional TSE for a POS-System. |
| Unified digital interface | The term from German § 146a AO was not yet clearly defined when the law was formulated. Therefore, three interfaces have emerged from this in practice: the export interface of the TSE (interface for data retrieval from the TSE), the integration interface of the TSE (interface for the communication of the cash register with the TSE, which, however, is only a recommendation and thus not uniform due to the technology openness) and the DSFinV-K. |
| technical terms | |
| Account | A company registers in the fiskaltrust.Portal with an account, which can, for example, close the agreement as PosOperator, PosDealer or PosCreator. |
| AccountAccessToken | API access credential Token for the account. You can find it on the Companies account overview page in the fiskaltrust.Portal. |
| AccountID | API access credential ID for the account. You can find it on the Companies account overview page in the fiskaltrust.Portal. |
| ActionJournal | This journal collects all operational incidents by special receipts, further date and time of start or failure of the fiskaltrust.Middleware. |
| CashBox | The CashBox is a configuration container that contains the configuration of the individual components like a queue, SCU and various helpers. The CashBox can link several configurations with each other. |
| CashBox serial number | The CashBox serial number is a piece of unique information that has to be printed on the receipt. For this purpose, fiskaltrust uses the ftCashboxIdentification and encodes this in Base64. Special characters are removed. The fiskaltrust.Middleware returns this data set in the signature-lock in the response (ftSignatureType). The ftCashboxIdentification itself is the freely selectable, unique identifier for a queue. The SCU also uses it as ClientId for the TSE. It is therefore essential to enter a printable string with a maximum of 20 characters. |
| CashBoxAccessToken | API access credential Token for the CashBox. You can find it in the fiskaltrust.Portal (Configuration / CashBox). |
| CashBoxId | API access credential Token for the CashBox. You can find it in the fiskaltrust.Portal (Configuration / CashBox). |
| CashBoxIdentification | Value to identify the Queue. You can find it in the fiskaltrust.Portal (Configuration / Queue). |
| Certificate | A certificate does not mean the certification document for a product but a cryptographic certificate. This certificate is a data record that links cryptographic keys with other data, such as a person's identity, in a secured form. You can use, for example, a certificate to check whether a digital signature was created by a person authorized to do so. |
| Certification | Certification in this context means confirming the successful compliance check with legally defined requirements. In the case of TSE, the BSI has published several technical guidelines and so-called protection profiles. TSE manufacturers can have the compliance of their product with these requirements examined by a so-called test center, which prepares an evaluation report. The BSI then issues certification based on this report. |
| ChargeItems | ChargeItems are products or information lines in the product table of the receipt. In the JSON structure of a receipt, they are used as an array. Each element contains the necessary information on the specific product like name, quantity, price, VAT, VAT amount, and unit price. |
| Compliance-as-a-Service | PosCreators integrate the fiskaltrust.Middleware into their POS-Systems. By transmitting the receipt data, transactions and other relevant data to the fiskaltrust.Middleware, compliance as a service is achieved and the legal requirements for PosOperator are met. |
| Entitlement | A product claim that you as a PosDealer can purchase in advance and deliver at a later date as an actual product. |
| fiskaltrust.iPOS | Standardized interface for connecting POS-Systems with the fiskaltrust.SecurityMechanism. |
| fiskaltrust.Launcher | The bootstrap part of the fiskaltrust.Middleware handles the overall service launch and upgrades any relevant version of its configured components. |
| fiskaltrust.Middleware | A Middleware is a type of computer software that provides services to software applications beyond those available from the operating system. The fiskaltrust.Middleware offers the possibility to use the fiskaltrust.SecurityMechanism with national laws with a unified interface. |
| fiskaltrust.Portal | The country-specific portal where PosDealers and PosOperators manage all configuration settings and the relevant extensions. |
| fiskaltrust.SecurityMechanism | The fiskaltrust.SecurityMechanism provides information for processing a receipt according to national laws necessary through its configuration. |
| fiskaltrust.SignatureBox | The fiskaltrust.SignatureBox is a pre-configured hardware solution with a network interface and a signature creation device. |
| fiskaltrust.SignatureCard | The fiskaltrust.SignatureCard consists of a Smart Card, which stores the certificate, and of a reader, which can be an external device attached to the machine using a USB cable or an internal device installed inside the machine. |
| fiskaltrust.SignatureCloud | The fiskaltrust.SignatureCloud is a pure online solution that handles the receipt linking and the signature creation entirely online. |
| Helipad | The central point of the API for configuration purposes and data upload is accessible on https://helipad.fiskaltrust.cloud. |
| Helper | A helper is a module that extends the fiskaltrust.Middleware. For example, a helper is used to change the SQLite database that is usually used to an MS-SQL database or to enable the REST protocol instead of SOAP. |
| Journal | The Journal is a facility for the electronic storage of receipts on a storage device in a high-accuracy data format. It manages a wide range of national provisions in parallel. You can find a ReceiptJournal and an ActionJournal in the fiskaltrust.Portal (Configuration / Queue). |
| Knowledge base articles | PosDealers and PosCreators find answers and solutions for several questions or problems in the fiskaltrust.Portal (Help / Knowledge Base Articles). |
| Outlet | Outlets are locations of an enterprise, meaning such places (areas, delimited rooms) to which operational performance potential is assigned for the execution of performance processes, e.g., event locations in the context of a performance fulfillment in the gastro/catering area.). Outlets are also geographic locations of an establishment (e.g., production, distribution, administration site) and owned by a PosOperator. |
| Packages | Package repository from where fiskaltrust.Middleware obtains the configured software components. |
| PayItems | PayItems are means of payment or information lines in the table of payment methods of the receipt. In the JSON structure of a receipt, they are used as an array. Each element contains the necessary information on the specific payment method like name, quantity, or amount. |
| PosArchive | The fiskaltrust.PosArchive is the general product for archiving data in respect of national laws. This archive stores the data transferred by the fiskaltrust.Middleware for a period depending on the national market. |
| PosCreator | A PosCreator is a software developer who develops POS-Systems, meaning software for vending machines, ERPs, PMS, or cash registers. This company integrates the fiskaltrust.Middleware to archive easy and reliable compliance with the French law. The PosCreator has access to 2nd and 3rd level support of fiskaltrust. In Germany KassenHersteller. |
| PosDealer | A PosDealer is a company buying vending machines, POS-Systems, or cash registers from one or more PosCreators. On the one hand, a PosDealer has an in-depth knowledge of the functionality of the POS-Systems. On the other hand, he knows best his clients and their infrastructure. The PosDealer configures and sells the fiskaltrust.Middleware and fiskaltrust.Products in addition to the POS-System. The PosDealer can contact the 1st and 2nd level support with questions concerning the products and configuration. In Germany KassenHändler. |
| PosOperator | The PosOperator is a company selling its products or services to the final clients. The company uses one or more cash registers, POS-Systems, and vending machines to record all its business transactions. In case of an audit (fiscal control) this company must provide several information (e.g. certificate of the POS-System, fiscal archives, …) to the auditor. The PosOperator is using the POS-System and fiskaltrust.Products bought from his PosDealer(s). The PosOperator has no access to the fiskaltrust.Support. |
| POS-System | POS-Systems are electronic recording systems (also: electronic cash register, cash register system, input station, terminals, electronic or computer-based), meaning technical solutions specialized for the sale of goods or the provision of services and their settlement and have a cash register function. A cash register function means using POS-Systems to record and process at least partially cash payment transactions. A cash register function also applies to comparable electronic forms of payment used on-site (electronic money such as cash cards, virtual accounts or bonus point systems from third-party providers) as well as vouchers, credit cards, receipts and the like accepted in place of cash. A storage facility for the money managed (e.g., cash drawer) is not required. For example, cash register functions integrated into ERP or merchandise management systems fall within the definition of electronic recording systems. Not included are Ticket vending machines, ticket printers, electronic accounting programs, vending and service machines, automated teller machines, taximeters and odometers, and cash and merchandise gambling devices. A POS-System corresponds to the queue, which you configure in the portal. This queue represents, at the same time, the unit to be fiscalized and reported to the tax office. You can flexibly map a POS-System via one or more queues, as well as one or more configuration containers (CashBoxes). |
| POS-System inspections | As of January 1, 2018, the tax authorities have the new legal option of carrying out unannounced checks on cash management outside of standard company audits. Before this, there were also individual POS-System inspections, which used the already existing instrument of the VAT inspection. |
| Queue | (general) A queue in this context is the storage or receipt chain for all receipts sent to the fiskaltrust.Middleware. A queue needs a connection with an SCU. You must have a queue for activating the fiskaltrust.SecurityMechanism as well as the StartReceipt. To deactivate a queue, you must send a StopReceipt via the POS-System. (terminology) Receipt processing equipment to guarantee required serial recording of receipts internally using the continuous numbering of receipts and independent control of the cumulative counter. These components become an integral part of all processed receipts. (France) Guarantees independent control of the cumulative counters and totals of periods: shift, daily, monthly, yearly and perpetual. These components become an integral part of all processed receipts. |
| Receipt | A receipt is a document sent to the fiskaltrust.Middleware or issued by a POS-System. |
| ReceiptCase | The POS-System transfers the data of an entire receipt request to the fiskaltrust.Middleware using the ReceiptRequest data structure. To identify the kind of receipt or even special receipt, the ReceiptCase is of the highest importance for the correct processing. This field defines the receipt type, determines if the receipt must be secured accordingly to the national law, and establishes how to calculate the correct values for each national counter. You can find a complete list of receipts cases in the documentation. |
| ReceiptJournal | The ReceiptJournal is used to record, hash, and chain all requests to the fiskaltrust.Middleware and the resulting responses. The first part of the returned ReceiptIdentification is an up-counting number generated by ReceiptJournal. |
| Sandbox | The Sandbox has roughly the same functions as the live system of fiskaltrust. You can reach it via the URL https://portal-sandbox.fiskaltrust.at/ for Austria, https://portal-sandbox.fiskaltrust.fr/ for France or https://portal-sandbox.fiskaltrust.de/ for Germany. In the Sandbox, you can register, just like in the live system, with your company data or also with freely invented information; the accesses remain independent of each other in any case., The severe difference is, that the Sandbox serves to get to know and test existing or new functions of the fiskaltrust.Portal without entering into any legal obligations. |
| Signature | With the aid of a secret signature key (the private key), you can calculate a digital signature for a digital message (i.e., for any data). This signature verifies the message's non-repudiable authorship and integrity with the public verification key. To be able to assign a signature created with a signature key to a person, you must assign the associated verification key to this person without any doubt. |
| Signature Creation Unit (SCU) | The SCU is a component of the fiskaltrust.Middleware responsible for signing the receipt using the applicable third-party signature mechanism (i.e., an SSCD or a digital certificate). Once you have connected an SCU to a queue, you can’t change it. |
| SignatureItems | SignatureItems are answer elements to a request sent to the fiskaltrust.Middleware. In the JSON structure of a response, they are used as an array. Each answer element contains data and caption elements. Your POS-System must print both elements without any change on a receipt. |
| Special-Receipts | You have to use Special-Receipts to send a command to the fiskaltrust.Middleware or save/export data in the queue. The Zero-Receipt, for example, is a receipt without any products or means of payment and no amount on it. Two types are allowed only once during a queue operation: the StartReceipt starts the queue and should be the first receipt sent by the POS-System. After this initial receipt, the fiskaltrust.Middleware signs any received data. The StopReceipt is the counterpart for the StartReceipt. It ends the signing in the queue and finishes working with the POS-System. After sending it, you can never reinitialize the queue. |
| TAR | You can use TAR as a data format to combine many files into one, the TAR file. In our context, the standardized data export of a TSE results in a TAR file. |
| Test value | In various regulations, this term is used instead of signature. |
| Verification | Verification means, in the context of digital signatures to check secured data for whether it is unchanged and complete (integrity) and whether it originates from the alleged sender (authenticity). However, this check does not include an examination of the correctness of content, e.g., whether it has been entered correctly. |