POS system requirements in Germany: what is legally required?

What is truly mandatory, and what is not mandatory across the board

If I use an electronic POS system with cash register functionality in Germany, I must record transactions properly, protect the system with a certified technical security device, comply with the receipt requirement, and meet tax-related export requirements. That is the core rule under Germany’s Fiscal Code, section 146a and the Federal Ministry of Finance FAQ on receipt issuance and cash register security, current for Germany as of 30 September 2026. But that does not automatically create a universal duty for every business to use an electronic cash register at all times. An open cash drawer setup is still subject to strict record-keeping rules.

In my restaurant, that means the decisive question is not whether something sounds digital or modern, but whether I am using an electronic recording system to capture cash sales. If I am, then I need the legally required protection and a process that stays traceable in day-to-day service. A common mistake is to confuse TSE certification with a blanket certification of the entire restaurant software. That is not how the rule works. What is certified is the technical security device, not automatically the full hospitality management software. So when I introduce or replace a system, I check four things separately: cash register function, TSE setup, receipt handling, and export plus retention capability.

The TSE is not a formality; in the relevant case, it is mandatory

Once my operation falls within the rules for electronic recording systems, the TSE is not an optional add-on but a legal component of the setup. I do not treat it like an accessory that can be added later. Imagine a Friday evening: drinks are sold at the counter, menus are paid at the table, and a group asks for split payments midway through service. Every affected transaction has to be recorded within a setup where the legal protection is already accounted for. Anyone who starts taking payments first and hopes to “connect the compliant part later” is organizing the process in the wrong order. Before go-live, I want a concrete explanation of how the real sales flow is secured.

The boundary matters as well. Software can give me operational order without that automatically amounting to tax approval. With BonZumo, I therefore check the legal TSE component separately and do not promise my team anything that is not verified. What BonZumo demonstrably helps with is the traceability of the transaction itself: order, payment, receipt, cancellation, timestamps, and authorized actions remain visible in context. That matters when someone later asks why a table was split first and partly paid in cash afterward. Instead of relying on a tired team member’s memory after a long shift, I can reconstruct the path from the same recorded transaction and clarify the issue where it actually arose.

The receipt requirement means the guest must be able to receive a receipt

For electronic POS systems in Germany, the legal framework also includes a receipt issuance duty. For me, that does not mean I have to force a paper slip into every guest’s hand unasked, but it does mean I must organize service so that a receipt can actually be provided. According to the Ministry FAQ, electronic receipts can also be possible if the process is set up accordingly. The important point is that the receipt must not exist only in theory. In a fast to-go café, the process will differ from a full-service restaurant where one person pays for the group at the end, but in both cases the handover has to work in practice.

I therefore explain this to my team not only as a tax topic but as a guest situation. A useful example is a small lunch group paying separately, with one guest also needing a hospitality receipt for business purposes. Then it must be clear who enters the recipient data, at what moment the receipt is created, and how any remaining balance stays visible until the table is really settled. BonZumo helps me organize exactly that practical sequence because split payments, receipts, and the remaining open table amount all stay tied to the same transaction. That cuts down on checkout confusion and avoids the classic mistake of closing the table first and then frantically trying to recreate the right document afterward. This fits closely with Finish a good visit with a clear payment experience.

Notification, documentation, and clear responsibility remain the operator’s job

Since 2025, Germany has had an electronic notification procedure for affected cash register systems. For me as the operator, that means I need a reliable list of systems per business location and a clearly assigned responsibility for reporting acquisition and decommissioning. In practice, trouble often starts not with the device itself but with unclear responsibility during a rebuild, an added bar station, or a seasonal point of sale. The key administrative guidance is the Federal Ministry of Finance letter of 28 June 2024 on the notification obligation; for Germany, the procedure has been active since 1 January 2025.

I do not solve that in the office with a loose spreadsheet that nobody updates after a hectic weekend. I assign a fixed responsibility and keep a written record for each checkout point: which system is used, since when, at which establishment, and in what status. If a device fails and is temporarily replaced, I document that transition as well. The most frequent pitfall is that the team is already selling, but no one clearly distinguishes between “technically switched on,” “tax-relevantly reported,” and “set up only for internal testing.” Testing without real sales is one thing; productive use is another. That distinction sounds boring, yet it saves a remarkable amount of time and anxiety when questions arise later.

Cancellations, corrections, and outages must not create invisible gaps

Cancellations, later corrections, and technical failures are especially sensitive under German tax rules. The verified legal basis makes clear that tax-relevant histories must not be overwritten without a trace. In day-to-day restaurant terms, that means if a ticket was sent to the wrong table or an item was entered incorrectly, the correction must not function like an eraser. It needs to remain understandable what was originally recorded, who intervened, and why. This matters even more on a packed evening when three team members are simultaneously handling payments, moving guests between tables, and adding last-minute drinks to an existing check. Invisible changes are exactly what I want to prevent.

Operationally, I handle that through permissions and defined escalation paths. Not every server should be able to correct everything; shift management handles specific interventions, and every outage has a documented fallback process plus later reconciliation. BonZumo supports that organization through roles and access rights, and by keeping cancellations, timestamps, and authorized actions attached to the underlying transaction. If, for example, card processing at one station stalls and we need to complete the situation differently for the moment, I can later review the chain inside the transaction itself. That helps because, as described in Keep every sale connected to the service around it, the system keeps order and completion connected instead of treating them as unrelated islands.

Retention and export are not optional back-office niceties

Legal POS requirements do not end at the moment of payment. Tax-relevant records also have to be retained and kept available in an orderly way if needed later. Under Germany’s Fiscal Code, section 147, retention periods differ by document type: books and records are regularly retained for ten years, accounting documents for eight years, and certain other tax documents for six years. For my restaurant, the practical conclusion is simple: I cannot rely on a patchwork of printed slips, stray PDFs, and human memory. I need a structure in which reports, receipts, and closing documents remain findable after the rush of service has long passed.

This is exactly where many businesses confuse export with order. An export helps only if the underlying transactions were captured and assigned cleanly beforehand. BonZumo supports me here with daily closing, stored Z reports, an archive, and a DATEV batch export for preparatory accounting. That is not fully automated bookkeeping and it does not replace tax review, but it does create a clean handoff. Transactions are brought together in a traceable way, reports remain accessible, and the material handed to accounting or tax advisers is based on the recorded process rather than a manually rebuilt list after midnight. For back-office questions, that is much more robust than hoping someone still remembers a discrepancy from three services ago.

How I put the legal rules into practice without making service worse

I do not introduce this topic to my team as a threat from the tax office. I introduce it as a binding working standard that protects guests, staff, and the business. A new colleague should know from day one what they may do themselves, when they must involve the shift lead, and why “I’ll remember that and fix it later” is not a valid answer to a cash register error. So I train from real situations: wrong table assigned, a guest wants to split the bill by items, gratuity is added only after the card amount is discussed, or a receipt is requested again later. Each situation gets a fixed path. That way, compliance is created through repeatable actions, not by expecting every server to interpret statutes on the fly.

If I operate a POS system in Germany, I make sure six questions are answered in a usable order: does my setup fall under the rules for electronic recording systems, is the TSE configured appropriately, does receipt issuance actually work in service, are notification duties and responsibilities assigned, do corrections remain traceable, and are export plus retention organized in the background. That sequence matters more than shiny features or speed claims. A POS should feel easy for guests and staff in the dining room, but behind the scenes it has to be rigorously organized. For me, that is not bureaucracy for its own sake. It is the basis for running a fair, dependable restaurant where the process still holds up when someone asks hard questions later.