Hypersoft internal fiscal methods
Hypersoft uses the "simplified method", in which bookings from open orders are signed regardless of payment, because the TSE system is not designed to keep any number of transactions open, as is usual in full-service catering.
The information on the date of the first booking is therefore particularly important on the closing document:
The time of the first order within a process is displayed above the signing text. This line is always printed when the TSE system is activated.
Example (note time zone UTC):
First order: 02.11.2023 - 16:28:31
Invoices from a fiscal point of view...
The issuing of invoices is an option at the completion of a transaction. Certain types of forms use invoice numbers. However, there is no form type in the Hypersoft system without an invoice number, which is therefore not entered in the journal, so that all bookings are transferred to the journal at closing regardless of an invoice number or any printout at all. If in doubt, create a form with invoice number for all completed transactions.
Further documentation: Configure number ranges
Protection of invoices...
For a completed transaction, it is not possible to change a transaction that was completed with the form type Invoice to a transaction "Free form type" (i.e. not Invoice). Such changes can only be made if a cancellation document has previously been created for the original invoice.
If transactions created with a form of the invoice type are reopenedEdit Operations Subsequently), the programme creates a cancellation document with reference to the original invoice and enters it in the invoice journal. This is to alert you and the operators that the original invoice has been cancelled by the cancellation document.
Instruct your operators to collect original invoices that are revised and file them with the cancellation receipt, as you are responsible for ensuring that they cannot be used for other purposes.
Internal data designations...
The internal field DOCUMENTNO concerns the invoice number (not something the form type number or number). The document number 0 is created when closing a transaction "without form" or with a form type that does not use an invoice number.
Further documentation: NoCOO - Digital Billing
Connected and integrated 3rd parties from a fiscal perspective
Quote in the application decree:
"Information on the notification in the case of cash registers (systems)
Supplementary to AEAO to § 146a, No. 1.16.2 the following shall apply: If individual electronic recording systems without cash register function are combined with an electronic recording system with cash register function within the meaning of § 146a AO i. V. m. § Section 1 (1) sentence 1 KassenSichV, only the electronic recording system with a cash register function and not the connected electronic recording systems without a cash register function is subject to notification."
For you as a business owner, this means that systems connected to a Hypersoft POS system must also record in Hypersoft. Hypersoft products such as eSolutions Self-Order Kiosk (SOT) and all variants from the eSolution Webshopsand eSolutions In-House Ordering areas are developed to support this accordingly. For 3rd parties, we provide the facilities, but you as a business owner must check the 3rd parties you choose whether they are transferring the data to Hypersoft in line with your obligations. For integration, we provide appropriate interfaces and integrations, such as:
3rd Party Customers, Reservation, Tickets API
Connection to dispensing systems
Vending catering and ticketing connections
Responsibility with 3rd parties and our customers...
Our 3rd party eSolutions API is extensively documented:
3rd party eSolution development
3rd parties have the possibility to retrieve master data and to transmit bookings. All bookings can be signed by us in the standard. Of course, it is possible that 3rd parties do not transmit all bookings to us. An intention to evade tax is not relevant, but our endeavour to treat all bookings correctly. We therefore warn you, our customers and 3rd parties in this area:
3rd Party eSolution fiscal requirements
Expenses from a fiscal point of view
Items that receive the allocation Expenses instead of a VAT rate are treated as expenses. Displays are, for example, cigarettes purchased by the operator for guests, financially laid out and later paid for by payment from the customer to the operator. Expenses appear on the operator report and may or may not appear on the financial report - this is adjustable. Entries that are treated as expenses are also treated like all other entries and, if they are fixed, are also fixed. Set the financial report to show expenses as well. Ensure that such items are only properly entered and used when booking.
Further documentation:
Disbursements in front office reports...
Report numbers (front office) from a fiscal perspective
Auditors must start from the assumption that tax evasion is possible through misappropriation of individual financial statement reports. This does not apply to the Hypersoft // system, but reports still have to be numbered as completely as possible and, if necessary, also kept. If and when you have to prepare and keep a report, please consult your tax advisor. The Hypersoft Front Office reporting system also has seamless numbering. If you only charge your operators on the basis of front office reports, you should also make sure that the numbering is complete for your security, so that you do not fall victim to fraud. The Hypersoft system works with consecutive report numbers. However, there are different variants of reports and corresponding number ranges to close a POS system (with several workstations).
Settle all funds or individual funds...
The number ranges in the Hypersoft // system for daily financial statements were changed with the introduction of the TSE obligation. The cash registers, or "All cash registers" or profit centre designations are still printed on the final reports, but since the TSE system, the number range is no longer separated, but superordinate. There is therefore always a unique sequential number for each cash statement, which is also contained in the DSFinV-K export. For example, the cash register 1 receives the number 1 with its closing and the "profit centre bar" receives the next number with the following closing, i.e. 2, etc....
Trades can be created several times a day. The standard variant of a report is All tills, so that if there are several workstations, all tills can be accounted for together. If All tills are closed, the report is marked All tills and given a sequential number. Another variant is the possibility of concluding individual funds. This can and must be set in the report settings if required. The final report of a cash register then shows "the cash register name" and the next free number from the number range. Another variant is the possibility of concluding profit centres. Profit centres can contain one or more cash registers. For this purpose, profit centres must be created and cash registers assigned. To close a profit centre, the cash registers assigned to the profit centre are closed and receive the next free number from the sequential number range. The final report of a profit centre then shows the name of the profit centre and the number.
The GoBD export always contains all accounting data, regardless of the financial statements of individual cash registers or profit centres.
During the daily closing process, the Hypersoft system checks whether all the cash registers involved are available in the network and clearly displays the status or faults. This is to avoid that unconnected funds are not closed unconsciously when concluding the contract. Uncompleted bookings are then included in a subsequent closing.
Further documentation:
Daily closing procedures and options
Automate best practice day-end closing
Open operations prevent Z closing
Completeness check of the stations involved...
Accounting journal, logic and filing from a fiscal point of view
Each booking is made in one transaction. These can be tables or customers or other processes. If a booking is made without a transaction, a so-called Quick-Service transaction (Freeflow) is automatically used. Transactions that have not yet been settled (mostly tables in the restaurant) are called open orders or open transactions. Settled transactions are transferred to the daily journal. With the recording, which is carried out in the standard with the daily closing, the data is transferred to the booking journal. The data in the daily journal are also saved using the methods described before they are written down.
Changes to text and price when booking, from a fiscal point of view...
You can overwrite their text and price when booking, depending on the operator authorisation and item settings. In the case of other systems from competitors, which only store references such as item numbers in the accounting journal, this was critically checked and a change report of the master data in particular was consulted in order to be able to check settlements. With Hypersoft, (among other things) the item text and price are also saved per booking, so that changes to this data are also included in the booking.
Further documentation:
Historical export of master data from a fiscal perspective
Timing and methods of financial statements...
Underground completions:
Trades can also be made multiple times a day. However, the Report Manager can evaluate all bookings of an opening day together.
We are not aware of any fiscal risks in this regard.
Closures after the dateline:
In practice, trades often take place across the dateline in the morning of the following day. For this, the bookings then receive two different date values. The so-called opening day is maintained beyond zero o'clock, with the booking date from zero o'clock being the date of the new day. All opening day bookings, including those beyond zero o'clock, will be closed under the opening day date. Even if the month or even the year changes at zero o'clock, the turnover is then booked to the opening day.
Forgotten degrees:
Unfortunately, it happens that our customers forget a daily closing and then unintentionally continue to book the next day on the opening day of the previous day. Several methods warn against this, or the timely conclusion can be automated, but it happens in practice. Since the system has an adjustable value as TTA (theoretical daily closing), reporting in the Report Manager can easily evaluate the days separately. In the data, however, the (wrong) opening day remains.
Further documentation:
Daily closing procedures and options
For more information on file storage and open procedures, see the HS-SSP document available on the Hypersoft Portal.
Time of transaction closure...
At the Hypersoft POS or mPOS POS system, bookings are entered into transactions and these bookings are transmitted to the system by closing the transaction or by New Balance (as an open order). The Hypersoft POS system uses the time of booking, the mPOS system uses the time of sending to the POS system.
Examples of this:
At Hypersoft POS at 13:00 booked 1 x Coke , then waited until 13:30 and pressed Close or New Balance. The booking has a time stamp of 13:00.
Booked at Hypersoft mPOS at 13:00 1 x Coke , then waited until 13:30 and pressed Close or New Balance, the booking is processed by the POS system (usually a subsystem). The booking has the time stamp 13:30.
We are not aware of any fiscal risks in this regard.
Secured transfer to the booking journal...
When transactions are completed, the entries are transferred to the journals. A special algorithm monitors this process for technical problems, deals with them and corrects any problems. If, despite these technical measures, it is not possible to create the booking data, a fault message appears on the POS system or on the PC of the corresponding subsystem: Businesslogic and HS-SSP
The affected process remains in the status "In Quarantine" and can in most cases be transferred to your journal with the help of our support.
Manipulation protection of the booking journal...
The Hypersoft system uses an internal algorithm to calculate a hash code for each journal entry and includes the relevant information in this formula. Should someone modify the booking data at database level, the hash code would no longer be valid. With the programme Fraud Protection Status Booking Journal you can have your data analysed accordingly.
Tracking bookings with Hypersoft Trace...
In a high-performance cash register system, requirements from practice are largely supported. If, for example, one of several guests does not want to pay after all, but stays and pays his booking later together with others at another table, this means for the operator: close transaction, process transaction, transfer bookings, close originally closed transaction without the bookings. Later, he will then close the transferred bookings in another transaction. Other possibilities are conceivable. For you or an auditing body, the question may arise as to why a transaction was first closed with a higher sum and then with a lower one and where the bookings were finally settled. In order to be able to trace such "article traces" as far as possible, Hypersoft has integrated a trace number for articles which can be evaluated with the Fraud Protection with Hypersoft Trace Trace programme.
Transaction numbers...
One (former) way of checking is to look for missing operations. It is assumed that a complete numbering of processes is decisive for determining whether data has been manipulatively removed. The journal has a complete ID; in addition, each entry in the journal has a transaction ID that corresponds to the respective transaction. If there are several entries in the same transaction, the ID is incremented further, but the transaction ID still represents the corresponding transaction.
Forms for operations...
Forms can be printed when closing open transactions. The form types are numbered from 1-20 in the Hypersoft system. If forms are used at closing, this is noted internally in the database. Position numbers are used there and 0 stands for the first form, 1 for the 2nd form. etc. The value -1 is used in cases where no form was used when completing the operation. The values 29 and 99 are used when training is involved (the differences between the two numbers only concern internal areas of the programme).
Further documentation:
Data flow diagrams for payment terminal connections
Fraud Protection Status Booking Journal
Fraud Protection with Hypersoft Trace
Export to DSFinV_K
The export of the journal data is carried out in the standard of the journal export as described here: DSFinV_K, GDPdU, AmadeusVerify export
With each daily closing, your client data is stored in the journal data.
If street, city or the VAT ID were missing in the master data, no import was possible.
Since the master data is saved historically for each financial statement, no subsequent correction was possible.
I now take the current data if it is missing from the archive
2) Articles without article text fail the check and result in incorrect follow-up error messages in the Verify, the item number column is now used as text if this is missing.
Further documentation:
Master information Basic settings
Financial data of the master information
Corrections of missing master data
If street, city or VAT identification number were missing in the master data, no export was possible until SP 16. Since the master data is stored historically per transaction, no subsequent correction was possible. From SP 16, any missing historical data is supplemented by the currently stored data so that an export can be carried out.
Historical export of master data from a fiscal perspective
Together with the journal export, the change history of other master data is also exported. Relevant changes to the item master are logged. These minutes can be viewed at any time in the form of a report. Individual item changes or all changes for a specific period can be output.
Further documentation:
DSFinV_K, GDPdU, AmadeusVerify export
Item data without text...
In the Hypersoft// system there are several article texts that can be used. If the receipt text is not filled in, the item can be used without further ado. The programme then uses the internal article ID as text instead when exporting.
Receipts and disbursements from a fiscal point of view
The Hypersoft // system can post deposits and withdrawals. These are signed in the standard, just like other item bookings. The TSE system has a number of special categories that can be used for deposits and withdrawals, such as private withdrawal, private deposit and payroll payments. These are not used by the programme for TSE signing.
When posting such deposits and withdrawals, you must be aware that they are signed with these categories in the TSE, but as standard postings. You should discuss this with your tax advisor and determine whether documenting this circumstance in your procedure description is sufficient or whether you want to do without these functions by not booking these categories with Hypersoft.
Further documentation: Post incoming and outgoing payments
MixMatch and MixMatch Combo prices from a fiscal perspective
MixMatch bookings are made on the fly, during the active sales process, so to speak. If, for example, a special price is applied by the system, this is done automatically and without any special rebooking. For example, if you sell an item A for 2.50, but 4 x item A the item costs only 1.90 per item, then when you post it, you will see that the items cost 2.50 up to the third posting and with the fourth posting all affected postings will be changed to 1.90. Neither the customer nor the operator had any intention of doing anything other than booking exactly this offer when it applied. However, it would not be correct (depending on the system conditions) to book "the discount" from the very first item. To be on the safe side, the MixMatch special prices only act until a transaction is closed, i.e. bookings that have already been closed with a new balance are not processed again by MixMatch when the transaction is accessed again (but only when the current booking is made). The discount can be evaluated in discount reports in the standard.
Further documentation:
Mobile Hypersoft POS mPOS from a fiscal perspective
All mPOS systems are designed in such a way that they must allow the bookings to be processed at the stationary POS system. There is intentionally no offline mode and you can be assured that bookings are securely logged. In addition, invoices and financial statements are only posted when the POS system receives the order for them and transmits the receipts to the mPOS system.
We are therefore not aware of any fiscal risks with Hypersoft mPOS systems (which "work offline", for example).
Negative item price from a fiscal point of view
The Hypersoft // system can also post sales prices with a negative value and calculate a normal consumption of goods in Stock Management. The items are treated like any other entry, saved and exported. The use of negative price items and the optional use of free price entry of a negative price are rarely used. You must bear in mind that these bookings will reduce your turnover and, of course, your operator accounts. You should only use this function when necessary and then with appropriate control. As with all special features, you should document them in your procedure description and agree on their use with your tax advisor beforehand.
Further documentation: Change item text and price
Emergency operation without server fiscal issues
If you find yourself having to re-enter transactions at the offline tills during emergency operation and data access becomes possible again later. Then you can close the original transactions via a corresponding loss entry. You should both define this in your procedure description and explicitly document such emergencies. This explains any unavoidable discrepancies in cashing up, even after a long time.
Safeguarding the invoice number in emergency operation without server...
The existing requirement to assign complete and logically accurate invoice numbers places a high demand on so-called emergency operation (when one or more cash registers of a networked POS system no longer participate in the network). The Hypersoft system solves this task by assigning separate sequential invoice numbers per cash register for offline operation. Later in the online operation, these are integrated into the global invoice journal. This way the receipts are automatically entered in the invoice journal afterwards and can be managed under the makeshift offline invoice number as well as in consecutive invoice numbers in the invoice journal.
The number ranges for normal operation and for offline operation can be set in general. Each number range has an additional prefix that can also provide information about the status of the system when the data was created. Usually there is an "O" in front of the document number offline, i.e. instead of online "AR4711", offline "OAR2001" etc. The field in the table is called DOCUMENTPREFIX. The automatic number ranges can be given individual start values based on manual specifications. The use of the number ranges for document numbers is documented.
Further documentation:
Connections between eSolutions and emergency operation...
Emergency operation without server
NoCOO Digital Billing from a Fiscal Perspective
With the integrated optional digital invoice NoCOO - Digital Billing you can digitise the receipt and establish further simplifications. When issuing a NoCOO voucher, the TSE signatures are created first and then the digital invoice voucher. The invoices are stored on the Hypersoft server and can be accessed via QR code or issued URL. Access to the invoices is given when the service is activated. After a possible termination of the cooperation or after termination of the NoCOO service and continuation of the cooperation, the invoices are at least still available in the POS system. If you require continued online availability of NoCOO invoices, please contact Hypersoft at the time of termination of the Services.
Further documentation:
NoCOO Billing address entered by customer...
You can give your customers the option of entering their own billing addresses once per document.
Coordinate the use with your tax advisor and file this in your procedure description if used.
Further documentation: Best Practice SB Billing Address from User
NoCOO SB payment with eSolutions...
You can give your customers the option to pay their invoices online using our webshop's payment service. For this, the online payment is contractually agreed directly with you and goes through a KYC process (Know Your Customer). You receive these cashless payments via AdyenHypersoft Pay powered by Adyen) just like cashless payments with a payment terminal.
Further documentation: Best Practice SB Enabling Online Payments
Deposit bookings with the TSE system
Deposit postings are item postings in Hypersoft. The sale and also the repayment of deposits are posted and signed as item postings including the VAT rate. The optional "Deposit business transaction" of the TSE system is not used for this purpose.
Further documentation: Deposit system
Power blackout from a fiscal perspective
The Hypersoft system is designed to handle data as quickly and securely as possible. Disconnecting the power supply should not provide an opportunity for fraud.
If one books a transaction (the total of which is displayed on the customer display Quick-Service, for example) and at that moment the power fails, the Hypersoft system will return to exactly that point of booking when it is restarted later and will also load the responsible operator so that this operator can correctly close the still open transaction. Transactions that have been booked to a table number, customer number or similar are also retained.
TSE Downtime and reason
A TSE failure is communicated on receipts and otherwise.
The following applies to you as an "entrepreneur": "The entrepreneur must immediately remedy the respective cause of failure, take measures to eliminate it and thereby ensure that the requirements of § 146a AO are complied with again as quickly as possible".
As an entrepreneur, you should ensure that the respective reason is recorded separately so that it can be presented if required.
POS Invitation Booking from a Fiscal Perspective
Invitations from your customers should also always be booked at the POS. Hypersoft has a loss management system for this. As an example of application, see Best Practice Protection against "false invitations.
Sales and VAT distribution from a fiscal perspective
VAT distribution ensures that the stored VAT rates take precedence in product group distribution. The system runs through the following steps: Firstly, it checks whether a merchandise category distribution exists. If this is the case, the system checks whether a VAT distribution has also been entered. If this is the case, the distribution is carried out using the stored percentages. The system checks whether the sum of the percentages equals 100%. If this is not the case, the remaining share is distributed according to the product groups and VAT rates stored in the item master.
-
If a sales distribution for product groups exists, but no VAT rates have been stored (differentiated by in-house and out-of-house), the product groups are divided according to the stored distribution. These are then redistributed according to the VAT rates stored in the recipe, if applicable. If no VAT distribution is stored in the recipe, only the product group with the VAT stored in the article master is distributed.
-
If no sales distribution has been stored for product groups, the system searches for a specific VAT distribution in the recipe and applies it, if available.
-
These regulations also apply to the distribution in the hotel interface in order to ensure standardised treatment.
Further documentation: Splitting of turnover and value added tax
Operation abort in the order rule
In the requirements for a TSE system, the term operation termination is used. Hypersoft does not have this as a special function. However, in connection with the New Balance function, a transaction may be aborted. Example at table 4 as a non-existent process:
-
Table 4
-
Book 1 x coffee
-
Cancellation before order 1 x coffee
-
Transaction Closing with New Balance (or Cash)
Actually, the process did not exist. To prevent misuse, the bookings 1 x coffee and 1 x cancellation coffee are saved in the journal and signed in the TSE.
Provisional closure of operations not compatible with TSE
The provisional account function cannot be used in Germany in the standard way that a payment voucher is created with a provisional account, as this is then an interim voucher. Interim receipts are not signed TSE, but it is your duty to have receipts submitted for settlement signed TSE beforehand. For example, use this function only to close the transaction temporarily without creating a receipt at the same time, and then create the payment receipt with a TSE signature when you close the transaction.
Back to the parent page: Fiscal Law on the Application Decree on Section 146a AO