A well-functioning POS system is essential for us in the food service industry. The customer doesn't see it, but they feel the effects when something doesn't work, such as the numerous problems and negative experiences we've had since switching to the Lightspeed K series. Many of these problems unfortunately end up with the customer, for example due to long waiting times when cashing up, back and forth when creating invoices, etc. We are currently experiencing considerable problems in our sansaro restaurant, which are noticeable for customers in service due to delays, even when simply taking orders.
Our experience with the Lightspeed K series
Since Lightspeed is an international company whose hotline sometimes leads to nirvana, we are writing down our experiences here in the blog. This is because we are dealing with sometimes dramatic faults that need to be rectified immediately - and the fact that the hotline keeps referring to a feedback form is another problem: apparently there are no contact persons in Germany who can or want to take proper care of things.
Maybe colleagues will use it or someone at Lightspeed who can change something will listen. Because for us as a well-functioning restaurant, changing the POS system (again?) is not easy. A lot of programming and training time goes into every POS system and, ideally, different operational systems should work together.
Why we opted for Lightspeed K
We deliberately opted for Lightspeed K because it can connect to OpenTable, our preferred reservation system for many years, and - theoretically - also to other systems for merchandise management, accounting and so on. From our point of view, it is an essential aspect that a POS system today is not a closed ecosystem (like Gastronovi, for example, which we used for years), but on the contrary is very open and can make contact with all kinds of other systems.
Lightspeed also offers very fast and efficient payment processing, the system looks very modern overall in the back office and also has some setting options that we appreciate. For example, the accounting assignment of product groups can be carried out independently of menu structures. For freaks: this means that we can address mixed items such as sake and wine within a menu, but address different accounting account assignments for both. Theoretically at least... more on this later.
Problems with Lightspeed K in Germany
This article is still under development. After weeks of trying to clarify the problems with Lightspeed with the support, the account manager and even an external IT support for Lightspeed, we are writing down our experiences here and will post them with screenshots and more detailed information for other colleagues.
Basic problems with DATEV export
Unfortunately, we haven't noticed much of this yet - because the automatic connection with DATEV Kassenarchiv online (the only accounting connection Lightspeed offers!) seems to be seriously flawed. And Lightspeed has not responded to requests for Lightspeed Inventory or Rest API in recent weeks.
Heutzutage ist die größte Herausforderung für eine funktionierende Buchhaltung, die verschiedenen Datenströme sauber und effizient zusammenzufassen.
The Lightspeed K series does not have its own cash book. This in itself is somewhat of a problem, as other providers such as Gastronovi have an integrated cash book, which can then be neatly managed by the employees on site.
In theory, it should be easy to connect other cashbook solutions to the Lightspeed K series. But this is where the problems start. This is because Lightspeed offers the transfer to the DATEV cash archive as the only interface for external accounting.
That in itself is not a bad thing - DATEV is, after all, a widely used standard for accounting processes in Germany.
But:
- The interface to the DATEV cash register archive cannot be tested logistically before the first transactions. The transfers only run from live operation of the cash register and even then are like a black box. It can take days before the transfer really works.
- The transmitted data is extremely rudimentary. In particular, the sales are only transferred broken down by VAT - not by product group, let alone with the accounting IDs stored in Lightspeed, e.g. for account assignment. This means that a differentiated evaluation at accounting level is not possible.
- The most dramatic problem: If training turnover is generated on one day, this is also transferred as turnover - without this being recorded anywhere or Lightspeed informing users of this in any way.
This last point is already a Serious error in the implementation.
Training turnovers are always perfectly justified in the restaurant business: a new employee is shown the cash register or a new seasonal menu is programmed and the team checks whether all receipts are coming out correctly.
The fact that there are training modes for something like this is of course extremely important. Incidentally, in our opinion, the times are long gone when restaurateurs with any kind of cash register in training mode Black money could generate: a modern cash register is protected by special security equipment and any tax inspector would immediately notice whether the cash register is strangely „training“ various sales during business operations - or whether the training mode is only used outside of opening hours and only to run through the same menu chains.
However, we had to do some detective work to find out what the problem was with the DATEV export of the Lightspeed K cash register.
The fact is that the DATEV export from DATEV Kassenarchiv Online to DATEV Kassenbuch Online (the necessary next step if you use the Lightspeed K cash register, as it does not keep a cash book and can only automatically transfer the sales to DATEV Kassenarchiv Online) fails if you have used the training mode on one day.
As a user, you only get a vague message that the totals somehow don't match and that you have to transfer the data manually.
Only after further research did the following picture emerge:
- Lightspeed K also transmits the training turnover (!) as normal turnover without any labeling, without any indication
- As a result, the cash book is potentially no longer correct, which means considerable audit risks for the restaurateur
- Depending on the configuration, it may also be that the restaurateur reports higher sales to the tax office = has to pay more VAT than he has taken in
- At the same time, however, DATEV Kassenarchiv Online reports an error during the transfer to DATEV Kassenbuch Online and you have to transfer the day manually.
- We had to work out this information ourselves, nobody (!) at Lightspeed pointed this out to us, neither in the training sessions nor in hotline inquiries on these topics was this mentioned
- In fact, the error has apparently been known internally at Lightspeed for months (!) with an open ticket.
That is an absolute no-go. Lightspeed prides itself on meeting all requirements - in the image of a car manufacturer, you could say: Yes, maybe in theory, but the moment you drive off the yard and onto the road, Lightspeed K already needs repairs.
Our impression: Lightspeed is not investing in a proper localization of the K series for the German market.
Fehler im DATEV Export wie das Übertragen von Testbuchungen als Umsätze sind unverzeihlich und sollten vom Anbieter einer Kassensoftware keinen einzigen Tag wissentlich hingenommen werden. Hier steht die Prüfungssicherheit der Restaurants auf dem Spiel. Die Kunden von Lightspeed müssen sich absolute that the data is transmitted cleanly and reliably.
The fact that there is ONLY the DATEV Kassenarchiv interface and nothing else is also unsatisfactory, that it has such shortcomings is disastrous.
Speaking of localization: There are also some weaknesses in the localization and translation. This is particularly noticeable when talking to the support team, who refer to many menu items with completely different names. It is less dramatic, but still annoying, when you find sections that don't make much sense in German.
Here is an example of how understanding some menu options in Lightspeed K can become a guessing game:
What does the setting „Manual manual input“ mean?
Only when you switch to the English language version at some point can you get a rough idea of what is meant:
„Manual“ here means what we would translate in German as „Manuell“, not „Handbuch“, as it can also be translated, but is completely wrong in this context.
A function that allows you to initiate a card payment manually, i.e. without the card being present. Well, that was something completely different from what we were looking for and hoping for - but once activated, it can no longer be deactivated, not even by the hotline...
Once again: the problem is not a translation error. The problem is that very little love has gone into the localization and then you have to guess together with the hotline which function means what.
Other small and large problems that we notice - and which Lightspeed does not seem to have fixed:
- The Lack of an override query, If someone else books into the table, this is a big problem. You get no warning and simply lose the specified order. This is absolutely unacceptable.
- The list of individual items in the overview is completely confusing. Instead of seeing „3 beers“, three separate entries are displayed for „1 beer“. The display is extremely small and confusing, several items are displayed as individual items instead of being grouped together. This is reminiscent of the computer capabilities of the year 2000, but not of a modern system. Incidentally, this very overview is also tiny on large iPads, which is a nuisance in the fast-paced everyday life of a restaurant.
- For some inexplicable reason, it is not possible to transfer an order from one table to another. The reason for this is not clear.
- It is not possible, Cash tips to orders that have been paid for by card. This is a big problem, as guests often leave cash behind after paying by card. If you want to record this correctly, you're stuck with Lightspeed. This is an unforgivable mistake as it affects the correct handling of money and table payments. Lightspeed has responded to this complaint by stating that no change is planned. For a company like ours, which wants to do and record everything absolutely correctly, where the team has made a rule that tips are shared within the workforce of a day, this is a big problem, means a considerable additional effort for every guest who leaves a cash tip for card payment, and above all no clean documentation solution integrated directly into the system. All the workarounds offered by Lightspeed are completely impractical for us. This point is also something that the management in Canada should change immediately if the POS system is to function properly on the German market.
- There is no haptic or visual feedback when you place an order or order an item. This could easily be improved with subtle animations to facilitate perception.
- The most important point: glaring weaknesses in the transfer of turnover to DATEV Kassenbuch Online. Data can only be transferred to the DATEV Kassenarchiv anyway. This limitation alone is significant. While Lightspeed K allows you to differentiate sales in an exemplary manner (articles are separated according to product groups and summarized independently in menus, so we can split our articles finely in terms of accounting but set up logical menu connections in the cash register operation), this differentiation cannot be exported cleanly because DATEV only allows rudimentary information. The documentation on this is full of euphoria, but ultimately weak in detail and meaningless. However, it becomes really problematic when the transfer from the cash archive to the cash book fails. And this is obviously the case if you have used training data on a particular day, for example because a new menu has been set up and the processes have been checked in training mode or because you keep trying to track down the problems with paying bills with mixed tips. In this case, totals are transmitted that do not match, the DATEV cashbook export fails and you have to rework manually. Lightspeed's suggested solution: simply do not work with payment data on the days when sales are made. Or to put it another way: always close one day and on that day the employees should come in for training. Complete madness!
- The kitchen receipts are (for no apparent reason) only printed in capital letters - not the way they are stored in the system, not the way they appear on the invoice at the end. Capital letters may be great for headlines and advertising posters - but on kitchen receipts they make it harder to read, especially when it comes to longer product names. Changing this is not an option.
Complicated license strategy at Lightspeed K
It is quite natural and legitimate that cash register manufacturers want to earn more if their cash register is used more. That was one of the reasons why we left Gastronovi: because 3 devices at Gastronovi per month cost twice as much as 6 devices at Lightspeed.
So far so good, but in practice it turns out that the strategy is somewhat unworldly.
It refers to hardware that is generally linked to the system, not to users per evening.
In concrete terms, this means that we cannot link the cell phones of all possible employees to the Lightspeed K cash register as before, so that the employees who are there that evening can then log in with their account to use the cash register (and then, in the existing logic, a maximum of 6 cash registers can be logged in at the same time).
No, it means that a maximum of 6 devices (!) can be linked. This means that, in theory, we would have to delete one employee's cash register link every evening so that another one can be linked. A completely impractical process. For us, this has meant that we have had to purchase additional hardware, which is now in the restaurant, just so that it can be used as a cash register.
The crowning glory: the hotline refers the question to the account manager, who has not responded to repeated contact over the last two weeks.
Poor adaptation to the German market
There are many ways in which restaurants handle their accounting and the very pragmatic handling of cash, waiters and settlements on site. Lightspeed also offers a few different options for this.
The problem here is that some of these options are scattered across numerous menu items, are apparently contradictory or mutually exclusive (without this being apparent in the settings) and you can tell that Lightspeed simply doesn't seem to be adapted to the German market to the extent that its own hotline can't explain the various options properly.
There are restaurants, for example, that have a shared change box (like we do) - but then you can't record cash tips in the till. If all waiters are supposed to work on their own wallets, problems quickly arise nowadays because the card tips often exceed the cash takings. And so on and so forth - we'll be happy to go into more detail, but it only makes sense if Lightspeed is prepared to invest more in the German market by providing more practical expertise there.
Restrictions on the creation of tax invoices for business customers
- Subsequent setting of customer data not possible: It often happens that customers with invoices over 250 euros request an invoice with a printed address several days or weeks after their visit because the tax office or internal accounting department insists on it. With a POS system like Gastronovi, this is cleverly solved: a copy of the invoice, which must be available in the system, can be linked to customer data and printed out or sent without changing the invoice itself. Not so with Lightspeed K: for whatever reason, this is only possible on the same day. This causes us numerous problems and additional work in the office.
The following error occurs in connection with the OpenTable integration:
- Customer data was entered for an invoice with address imprint
- At the end of the dialog it is unclear and confusing for the employees because they have the options „Apply“ and „OK“ (in addition to „Cancel") - what should they press here?
- We had pressed OK and received an invoice with the customer's name - but not with his company name, which was also entered!
- So you have to try to process the invoice again afterwards. However, this is not possible because the invoices are already linked according to Lightspeed. Support then suggests things like „Enter the company name in the street“, which of course is simply not a clean procedure - but is also simply not possible!
- When we let the bill out again as a copy, there is a different name on the bill: namely the person who reserved the table in OpenTable (which we never entered!).
- Lightspeed Support is now of the opinion that we have set the name incorrectly and must now change it. But both are wrong, we did not set the name and we can no longer change the name on the system side.
Lightspeed K cash register currently inadequate for Germany
State of affairs 02/22/2026: Lightspeed K Kasse is seriously flawed for a restaurant in Germany that relies on correct, automated accounting.
Problems with the DATEV export, which simply transfers training sales as normal sales, are too dramatic, and the support is too weak, where you are passed to a different contact person every few minutes but ultimately don't get a solution.
Our subjective assessment as a restaurant operator: Hands off until Lightspeed has fixed these problems!
