What happens if my POS system goes down?

A POS outage does not automatically mean service has to stop

If my POS system goes down, service can often continue depending on the cause, but not in the usual digital workflow. What matters then is not improvisation at any price, but a predefined outage process: orders are taken manually for a while, payments are documented separately and clearly, open tables are marked, and all later entries are worked back into the day in a traceable way. I treat an outage as a real operating mode with clear roles, not as an embarrassing mishap where everyone tries something different. For guests, that mainly means it may take longer, but their order should not vanish and their payment should not disappear into chaos.

Legally, an outage is not a free pass for messy records. In Germany, electronic cash register systems still have to meet proper recording duties; cancellations and corrections must not erase the history without a trace, and outage procedures need to be defined. That follows from Section 146a of the German Fiscal Code and the German Ministry of Finance FAQ on cash register rules. The relevant jurisdiction is Germany, status September 2026. So I decide in advance who takes charge during an outage, which backup receipts we use, and how we do the rework later, instead of arguing about basic rules in the middle of a busy dinner rush.

First I separate a full outage from a device defect or payment issue

Not every POS stoppage is the same. A black screen on one terminal is different from a network issue, a disrupted card connection, or one broken handheld in service. So in the first minute, I have the shift lead separate three things: what still works, which areas are affected, and which transactions are currently open. Example: the bar station still works, but two mobile devices on the floor no longer respond. Then I move new table orders to the remaining device or onto paper instead of shutting down the whole operation by default. That makes the problem smaller, because we narrow it down calmly before everyone starts touching everything at once.

What helps is that a modern system normally keeps table, order, payment, and closing linked as one shared process. In BonZumo, orders, partial payments, receipts, and open balances remain traceable in the same data base as long as the information was already entered. So if only one part of the flow breaks down mid-service, I can address exactly that point instead of reinventing every open table. That matters for my team: we first check the transactions already visible in the POS context, and only then switch new cases into emergency mode. This avoids duplicate charges, for example when a table has already paid part of the bill and later gets charged the full amount again by mistake.

This is what my restaurant emergency mode looks like in practice

In emergency mode, I deliberately reduce service to a few reliable steps. New orders go onto numbered paper chits or preprinted outage slips with date, time, table, guest count, items, and the server’s initials. The kitchen or bar gets one copy, and service keeps one. Every reorder is added to that same table slip instead of starting a second imaginary transaction. A practical example: table 14 orders drinks first, later two pasta dishes without cheese, and finally three espressos. Then everything appears on one slip in clear sequence. That is slower than digital entry, but far safer than loose handwritten notes that nobody can reconstruct after the rush.

At the same time, I tighten responsibility. One person keeps the outage list, a second monitors payments, and only the shift lead decides on voids, discounts, or goodwill gestures. In stressful situations, teams otherwise make well-meant but conflicting promises to guests. If a dessert is complimentary because of a long wait, that has to be written explicitly on the outage slip. I tell my team this openly: during an outage, maximum speed is not the goal, unambiguous documentation is. It is better for a guest to wait one minute longer for the bill than for us to spend the night guessing whether 48 euros were actually paid in cash or whether that payment was only announced and never completed.

Payments are the most sensitive part, so I keep the rules simple

The most delicate point is paying the bill. If card payment or the POS itself falters, servers must not start splitting amounts from memory or closing open tables by shouting figures across the room. So I define in advance which fallback routes are allowed: for example, taking cash against a handwritten receipt, or if only the payment side is affected, directing the guest to a working station in an orderly way. What matters is that tip, sales amount, and any remaining balance are written down separately. Example: 100 euros in consumption, 5 euros tip, 50 euros paid in cash, the rest later by card. If someone notes that only as “105 paid,” later differences in closing are almost guaranteed.

This is exactly where the normal system logic helps, because it teaches the structure I also want in an emergency. In BonZumo, sales amount, partial payments, tip, and the remaining table balance are recorded separately; bill splitting by item or by equal shares is clearly built into the regular payment flow. If operations fail, I mirror that structure on paper and then enter the same information cleanly once the system is back. For teams that often host larger groups, that is extremely valuable: staff who already understand how open balances are separated in everyday work make fewer mistakes under pressure. That is why I explain the regular process to new employees not just as button clicks, but as a way of thinking for exceptions as well. More on that structure is in Finish a good visit with a clear payment experience.

Once the outage ends, the real work begins: enter it cleanly, do not smooth it over

As soon as the system works again, I do not rush to enter everything somehow just to make the screen look tidy. First I reconcile open tables, paper chits, payments, and any kitchen copies. Then I decide transaction by transaction: what has already been fully paid, what was only ordered, what was voided, and what was given away as goodwill. A typical case is a partly paid group table where two guests have already left while three others ordered dessert later. If I re-enter that without order and sequence, the whole end-of-day closing will collapse later. So I always work from the physical documentation back into the digital system, never the other way around.

For this follow-up work, it matters that transactions remain findable and reviewable afterward. In BonZumo, regular operations keep transactions, receipts, timestamps, authorized actions, Z reports, and day-end closing connected. That does not solve an outage by itself, but it makes reconstruction fairer and faster. I can check after restart which transactions already exist in the system, which payments were assigned, and where gaps remain. Then I use reports, archive views, and closing screens to investigate differences specifically instead of accepting some vague “shrinkage amount.” For the end of the day, that link between single events and closing really matters: Understand the day's activity before you close up.

Guests mainly want honesty, speed and a clear statement

For guests, a POS outage is rarely a technology topic. They want to know whether their order arrived, whether they can still pay today, and roughly how long it will take. So I speak up early and simply: “Our POS system has a disruption right now, we are taking your order safely and we will settle it properly, it may just take a little longer.” That short sentence lowers tension because it neither dramatizes nor sugarcoats the problem. In an example with a birthday group of eight, I would also say early on that split payments may take more time today. That creates clear expectations before frustration builds at the very end when the bill comes.

At the same time, I protect my team from unfair conflict. A server should not have to stand alone at the table explaining why card payments are lagging, why tickets are handwritten, and why the kitchen has follow-up questions. In those moments, I visibly add support, for example through the shift lead or the bar supervisor. That signals to guests that someone is taking responsibility. I use goodwill carefully, not everywhere at once out of guilt. A complimentary espresso for a clearly delayed closing can make sense; random discounts usually make the situation less clear. My rule is simple: transparency first, decision second. Guests are far more likely to forgive a disruption than contradictory answers or the impression that nobody is in charge.

The calmest operations come from preparation before the first outage

The best way to handle a POS outage is built before the disruption happens, with a short process the team has actually practiced. I keep a simple outage folder or wallet at the POS: numbered emergency slips, pens, fixed responsibilities, permitted payment routes, wording for guests, and a sequence for the later re-entry work. New employees learn this in ten calm minutes on a quiet afternoon, not for the first time on Saturday at 8 pm. A good practice case is a fictional table with a starter, one changed order, a split bill, and tip. Anyone who can document that special case cleanly on paper will usually stay capable of acting when a real outage happens.

I also set up normal operations so a disruption does not immediately become blind flight. Clear table assignment, traceable order notes, organized permissions, and a clean closing process are not luxury features; they are outage prevention. In BonZumo, table context, order path, payments, and later evaluation belong to the same transaction, which helps me not only in the ideal case but especially when restoring order after an interruption. Just as important is who is responsible for the tax side in Germany: electronic cash register systems within scope must have recording duties, receipt obligations, the TSE connection, and notification duties organized properly; the details come from Section 146a of the German Fiscal Code and the Ministry of Finance notice on the reporting procedure. An outage is still unpleasant then, but it is no longer a loss of control.