Hypersoft procedure with tip bookings

Basic recommendation and objective

Hypersoft generally recommends that all tips are recorded in full, regardless of whether they are paid in cash or non-cash.

Non-cash tips can be recorded largely automatically via Hypersoft Pay. Booking cash tips also offers significant advantages:

  • Tips do not have to be manually separated from sales during a cash register audit

  • The tip share is traceable and can be calculated at any time

  • Analysable tip information is available per business and per operator

  • Tipping can be used as a KPI for quality and service control

Further topics: Accounting journal, logic and filing from a fiscal point of view

System logic of the tip booking

In the Hypersoft POS system, tips are recognised as a separate business transaction.

Tips to which employees are entitled (TipsAN) are recognised:

positive booking on the system side

signed via the TSE when recorded via the electronic recording system

The tip is recognised regardless of whether it is paid in cash or non-cash.

Further topics: Book a tip

Differentiation from sales and reporting

Tips (AN) do not represent a turnover of the company, but an amount collected in trust that is economically attributable to the employee. In order to ensure that sales-related evaluations, tax totals and product group reports are not distorted, Hypersoft has been using an internal offsetting logic: the positive tip entry is neutralised within the system and tips are not included in sales-related calculations.

This offsetting entry is:

an internal clearing entry

only required for correct revenue recognition

not an independent business transaction

Signing and export relevance

The internal offsetting entry is not signed via the TSE and is not output in audit-relevant exports (e.g. DSFinV-K, GoBD).

The positive, signed tip postings and no corresponding neutralisation or disbursement postings therefore appear in audit-relevant exports. This corresponds to the clear separation between signed business transactions and internal clearing entries.

Effects on aggregated analyses

Aggregated analyses (e.g. cash per currency) are based on signed payment transactions.

As the internal offsetting entry is not signed and not exported, it is possible that TrinkgeldAN increases the reported cash balance. This deviation is system-related and does not represent an incorrect posting. It results from the deliberate separation between fiscally relevant business transactions and internal sales corrections.

Tipping during receipt creation

With the function Remaining amount is tip, the tip is already known when the voucher is created and is posted and signed correctly in the standard system.

With the function Remaining amount is tip, the tip is already known when the voucher is created and is also posted in the standard.

Treatment of Tip Subsequent

By default, customers ask for a bill and then pay a tip later. When (in Germany) customers are presented with a billing document, this has been signed beforehand. If a customer then pays a tip, the signature must be counter-booked and re-signed with the new payment. For this purpose, Hypersoft has developed the Tip function retrospectively.

Payment database...

Payments are stored in the payment database. Item bookings in the booking journal. The original bookings are retained and are counter-booked with a congruent set of bookings and the number (NH_GVNO+1). This neutralises the original booking. Subsequently, new payment records containing the tip are posted again under the (NH_GVNO+2):

The transaction database receives this NH_GVNO number as the current NH_GVNO number:

A record is added to the existing transaction (TransactionID) in the journal. (Tip Subsequent with the sum), this sum receives the new NH_GVNO number:

 

In the AddOn table, the signature is stored for the respective NH_GVNO numbers:

 

ID 28 - NH_GVNO = 0 the original signature

ID 29 - NH_GVNO = 1 the neutralisation (cancellation) of the original signature.

ID 30 _ NH_GVNO = 2 the New Signing including the tip.

 

In the info table, the process (Tip Subsequent) is documented:

Status = 21 = Tip retrospectively

IntVal1 = Date of the action

IntVal2 = Time of the action

IntVal3 = SigTransNo from the TSE for signing neutralisation

IntVal4 = SigTransNo from the TSE for the new signature

DblVal1 = Total of the tip

DblVal3 = TSE ID of neutralisation (Belongs to IntVal3 TSE unit of neutralisation).

DblVal4 = TSE ID of re-signing (belongs to IntVal4 TSE unit of re-signing)

NH_GVNO = Business transaction number

Tip retrospectively on transactions without signature

For example, a transaction cannot be signed due to TSE failure. The TSE failure is provided for in the TSE system according to precise conditions. If a tip is subsequently given on a transaction that is not signed, for example due to technical problems, the tip is not subsequently signed on this transaction because the original signature is not present. The entries in the journal and in the payment data are posted in the standard.

Change journal export tip retroactively and payment type

The processing of a transaction by tipping afterwards is mapped in the export. The unique consecutive TransactionID from Hypersoft is used as the Receipt_ID in the export. The Receipt_ID contains (from SP 16) the number of the respective work step:

The receipt ID 620123 thus becomes 620123-00 (-00 is the original transaction here).

If a tip is booked subsequently, 2 further processing steps are always logged for the transaction.

-01 is the "credit" of the original operation -00

-02 then maps the complete process after adding.

Further subsequent changes then result in "-03" & "-04" etc.

Change during export...

Change receipts and payments are not recorded in our turnover journals but in a separate database. Thus, it is now not possible to export the "Receipt_ID" numerically consecutively.

We use the "ID" from the change database here and add to this value

2000000000 ( 2 billion )

The "BON_ID" from the change thus forms its own number range (over 2 billion), which is then continuous in itself.

Warning against mishandling tip bookings

Train your staff to make the bookings as promptly as possible and according to the actual situation. Not allowed are for example:

  • Post subsequent tip entries on any transaction.

  • Collect subsequent tip entries and post them cumulatively to one transaction.

  • Post tip entries to a separate transaction that is not the associated payment transaction.

These wrong practices lead to tips no longer being traceable. For tips to be tax-exempt in Germany, there must be a relationship between the giver and the recipient (who must not be the owner).

Extensions and corrections

With Hotfix 7 from 16.01.2024, the tip function was subsequently optimised in conjunction with the TSE. Equivalent tips that have been entered twice can now be traced more easily.

Further topics: Change Hypersoft procedure for payment type

Back to the overarching topic: Fiscal Law on the Application Decree on Section 146a AO