3rd Party eSolution fiscal requirements
This chapter covers the finalisation of bookings submitted to the Hypersoft POS system via 3rd parties and other systems.
These are minimum requirements which are extended by other requirements depending on the situation. We assume that Hypersoft has interpreted the requirements correctly and reproduced them here, but we cannot assume any legal liability for this. However, we ask all partners for understanding when we must insist on meeting the requirements in order to be able to connect the system to Hypersoft.
No tax or legal advice
The following information is for general guidance only and does not constitute tax or legal advice, as we are not authorised to give such advice. Please check the contents carefully and, if necessary, consult your tax advisor or other specialised experts to ensure that your approach complies with legal and tax requirements. Supplement or adapt our recommendations if this is necessary in your specific case. We also recommend that you document the results in your procedural documentation.
Some issues that are often overlooked in this context:
|
subject |
General information |
Germany (German) |
Austria |
| item master Synchronization | required (1) | requisitely | perhaps |
| signing | - | from 2020 | requisitely |
| Form printing in Hypersoft | Vote (2) | requisitely | requisitely |
| Cancellation before order recording | - | from 2020 | not |
| tips | Vote (2) | requisitely | see General |
| payment method | required (1) | requisitely | requisitely |
(1) = Function required by Hypersoft and expected to be supported by the user community.
(2) = The coordination is important for the conformity and security of the POS.
Training bookings are not supported in the eSolutions interface.
Booking inactive items via eCOM API...
If an inactive item is nevertheless booked at a location via the eSolutions interface, this is created as an incident with the ProductID and processed by Hypersoft. If we are not responsible for this, you will have to adjust your programme accordingly.
Requirement for conformity and consequences
Hypersoft assumes that 3rd party connections are legally compliant. Due to the available technical possibilities, fraud cannot always be excluded.
If Hypersoft becomes aware or believes that a 3rd party connection is (may be) being used to abridge taxes or otherwise manipulate accounting data, Hypersoft will request immediate change of the technical situation and may disable the 3rd party connection altogether until the situation can be resolved. Regardless, stakeholders must assume that Hypersoft documents the incident (such as its own risks and incidents) and makes this information available to the appropriate authorities.
Hypersoft also points out that in such cases a complaint will have to be filed.
The Hypersoft system processes the item master data. item change reports are required for tax audits (especially in Germany). For this it is necessary that 3rd parties also use the item data from the Hypersoftsystem. The publishing function from Hypersoft must also be supported as if a Hypersoft POS system were being used. Only in this way can the application time of the items (changes) take place according to the protocols.
For quality reasons, Hypersoft expects all item information relevant to the 3rd party to be used from the eSolutions interface; this also applies, for example, to item images (from a fiscal point of view, different images may also contain different information about the sale).
Signing bookings via the eSolutions API
For a signature to take place, a form number must be transmitted with the booking from the 3rd party provider, which assigns an invoice in the Hypersoft system. Herewith the signing can be used in Austria.
In this context, Hypersoft interprets the requirements of the KassenSichV 2020 as follows (without guarantee):
- 3rd Party SB cash registers that (maximum) only allow cashless payments and are not connected to cash register systems do not necessarily have to sign, but must meet the GoBD guidelines (invoice printing, unchangeable storage, GoBD export, etc:)
- With cash register interface, the order must be signed when it is sent to the cash register system. After consultation with the 3rd party provider, Hypersoft can, if necessary, perform the signing and also fulfill the GoBD requirements (see above) downstream.
- With the standard use of Hypersoft and the eSolutions API, all parties involved can assume that. that every order receipt and invoice issued by the Hypersoft system is proof that the bookings have also been processed in Hypersoft's TSE system. If the technical security device has failed, this will be indicated for bookings from 3rd parties as well as for bookings from the Hypersoft system itself. The notification of a technical failure is defined accordingly in the Cash Register Security Ordinance. Further documentation: TSE failure
Form printing in Hypersoft
Form printing or invoicing is to take place in Hypersoft. Any other documents coming from the 3rd party system must point this out.
Cancellation before order recording
See the chapter on the definition of terms: Cancellation bookings in practice
In Germany, the following applies: Based on the already existing GoBD requirements and even more clearly defined in the Cash Register Ordinance 2020, bookings must also be recorded in an evaluable manner if no order is placed.
The Kassenverordnung 2020 clearly prescribes the use of the signing unit at the beginning of a process.
Hypersoft must assume until nothing else is known that this also applies to 3rd party system.
Tips with eSolutions integrations
Tips can be booked and evaluated in Hypersoft. If the 3rd party application allows tips, the use must be agreed with Hypersoft and the tax advisor of the operator.
In Germany, among other things (short form) applies:
Tips can be tax-free. If these run via the operator, the tax exemption is not applicable.
The complete tipping topic is covered here: Book a tip.
payment method
The payment channels must be transmitted in the interest of the company itself and in order to meet complex legal requirements. This means that any payment at the terminal with terminals (EC- KK cards, crypto currency, points, credits or other) must be transferred to Hypersoft as well as the information that the payment is still open. or in Hypersoft.
Further documentation:
Fiscal Law on the Application Decree on Section 146a AO
Hypersoft process with eSolutions
Back to the parent page: 3rd Party eSolution API