Description of the safety mechanism (E 131)

Batch Kassenrichtlinie

Type of Cash Register

The GASTROFIX system is a cloud- and app-based cash register system based on a SQL database and complies with the Cash Register Guidelines of 2012  (BMF-010102/0007-IV/2/2011) of Cash-Register type 3.


Gastrofix GmbH
Austrian Devision
Simmeringer Hauptstr. 24
A-1110 Vienna

1. Observations, Business Cases & Receipts

  • A document is issued for each completed business transaction (transaction), which corresponds and complies with the cash-register guidelines (section 4.3.). A consecutive transaction identification number is generated per transaction.
  • In addition, each transaction is clearly identified with an UUID (Universally Unique Identifier) which contains the a time-stamp indicating the exact date and time that the consecutively numbered transaction was generated.
  • The document number, chronological and consecutive numbering ensures the completeness of the business transactions.
  • Each transaction is immediately transferred from the cash terminals to the GASTROFIX cloud servers, where the data is sotred invariably on the GASTROFIX’s redundant SQL servers.
  • GASTROFIX guarantees its customers and the financial tax authorities the unchanged storage and archiving of all business transactions for a period of 10 years.
  • Whilst data that has been saved to GASTROFIX’s web-based servers, can be evaluated by the customer at any time in a variety of ways (spot audits), manipulation or changes to the data is not possible. The SQL-Transaction-Database is only available over the web interface (cloud Back Office) in a read-only manner.
  • The decentralized storage of the transactional data both physically and from a technical stand-point, outside the access of the cash-register user, makes manipulation impossible.
  • In instances that a partial order has not be completed and recorded via a business transaction (for example an order change or void), the previous transaction is not changed or deleted. Instead, a new registration number is generated with a unique digital signature (UUID) so that the non-business case in documented in the journal and reports.
  • Thus, any entry booked in the system – even if it does not result in a business transaction such as payment – is permanently saved and stored for auditing and counterfeit-identification purposes.

2. Fiscal Journal

  • At the same time, the contents of the business transaction or the bookings to be recorded, including the UUID, are also logged directly into a fiscal journal which cannot be manipulated or changed.
  • This means that in terms of auditability, even those transactions that did not lead to a business transaction such as payment, are protocoled and recorded.
  • Following the registration of each new business case, the fiscal journal is signed with an UUID, as well as an exact date and time stamp as well as a checksum.
  • Voids, changes to payment methods or other corrections do not result in a deletion of the original transaction or journal entry. Instead, we generate additional corrective transactions to log the changes (For example, if a table on which 4 colas have been posted, but 2 were voided, the ordering transaction for the 4 colas is not changed, instead a void transaction is logged in which -2 colas are booked and the exact employee, time and even possibly reason for the void can be logged).
  • This ensures that a business transaction or booking which did not lead to a payment are recorded in the Fiscal Journal so that any possibilities for manipulation can be prevented before the invoicing process.

3. Controlling & Data Export

  • The Fiscal Journal, along with all other transactions, are immediately transferred (every 30 seconds) to the external storage medium (SQL server) of the GASTROFIX cloud. If the internet connection is not available, all data is stored temporarily in the cash terminal on the devices and sent as soon as the Internet connection is available again.
  • Date import into the cloud is only possible via the predefined interface (internal API) of the POS system and is protected against all other write-accesses.
  • This ensures data security, integrity and unchageability of the stored content.
  • The Fiscal Journal can be viewed and exported at any time via special reports in the cloud Back office. This export can be carried out as a table, PDF or in CSV format so that the data can also be automatically processed by financial authorities.
  • In a typical scenario, a representative of the financial authority will initiate such and export together with the owner of the establishment.
  • Thus, the owner can quickly provide proof of a complete recording of business transactions resulting in payment along with all other transactions that may have taken place due to changes.