Lightspeed menu sync: keeping your restaurant's own menu page in step

Your own menu page has not forgotten. It still lists the hake. It still shows the figure that was right in the spring, not the one the till has charged since the summer change. And it still carries the allergen line written before the supplier for the crumb changed.

A guest reads that page on the way over and arrives having already decided. They order the hake; there is no hake. They order the dish beside it, see one number on their phone and another on the bill, and a server who did nothing wrong is defending a figure they never saw. Later that week someone asks whether the crumb is gluten free, because the page said so, and the honest answer from the floor is "let me go and check" — the sentence you never want a guest with an allergy to hear after they have ordered.

None of this is a fault in the till. Lightspeed did exactly what it was asked, straight away, everywhere it reaches. The problem is that your own menu page is not one of the places it reaches — and nothing in the system is going to raise its hand and tell you so.

Withdrawal drift. Something goes off: a supplier misses, a section is down a chef, a seasonal dish ends. In Lightspeed this is routine. Item availability, in Lightspeed's words, "lets you manage your menu so customers can only order available items", and an item can be snoozed so that it is "unavailable for purchase" until it comes back. Lightspeed also states that "when items reach zero quantity, these items are automatically marked as unavailable in Order Anywhere (or other supported third-party partners)". Read that sentence to its end. The automatic part is scoped: Order Anywhere and supported third-party partners. A menu page you built separately is neither.

Price drift. Prices in Lightspeed are not necessarily one number per dish. Price lists, per Lightspeed, "allow you to create preset pricing schemes to apply to menu items based on restaurant location and order profile" — with a constraint worth knowing first: "Once you enable price lists, you cannot use other methods of updating prices." So once a site or a service window has its own scheme, "what does this dish cost?" has more than one correct answer, and whichever single number sits on your published page is right for some services and wrong for others.

Composition drift. The quietest and the worst. The recipe changes, or the supplier does, and a description and an allergen line that were accurate last month now describe a dish that no longer exists. Nothing about this change looks like a menu edit. It looks like a delivery.

Lightspeed is clear about where the authority sits. "The Menu section of the Back Office is where you manage your items, menus, production instructions, accounting groups, and price lists", and "menus determine the items that are available to order on the POS". That is the arrangement to keep: one place where change is made, everything downstream taking its cue.

How far does downstream reach? Lightspeed's own ordering surface is inside the fence — Order Anywhere is "a mobile-friendly online ordering platform that integrates directly with the Restaurant POS app". A delivery marketplace can be brought inside it too, and how that is done is instructive. For Uber Eats, Lightspeed states that "once you link your Uber Eats account, Lightspeed Restaurant pushes your menu, item names, descriptions, and item images to Uber Eats". But the ongoing routine is not silent and automatic: "After making your menu changes in the Back Office, sync them to Uber Eats through the Uber Eats integration, then reload your POS device". And the discipline that keeps it honest is stated plainly: "Don't make menu changes directly in Uber Eats Manager."

That is one source of truth, written out by a vendor for a single connected surface. Make the change in one place. Push it. Never edit the copy.

Here is the part owners assume away. Lightspeed does expose the menu to software: it "offers a REST API in order to communicate with the data in the system", and the online ordering API includes endpoints that provide "a list of all available menus for a specified Business Location" and "detailed information about each item within a specified menu", alongside a way to retrieve item availability. So the data is reachable.

But reachable is a pull. Something has to go and ask. On the push side, the developer documentation for online ordering says, in full, "Webhooks provide notifications about orders and payments." Orders and payments. Not "an item was withdrawn at 16:04". A menu page that is not wired to poll that API — a hand-kept page, a page a designer updates for you, a PDF — receives no signal at all that the till's menu moved underneath it. The drift is not detected and ignored. It is never detected.

This is why "we have a good EPOS, so the menu is handled" is the assumption that costs you. A good till handles the till.

The published menu is food information — a defined term, not a figure of speech. Regulation (EU) No 1169/2011, assimilated law in the UK, defines it at Article 2(2) as "information concerning a food and made available to the final consumer by means of a label, other accompanying material, or any other means including modern technology tools or verbal communication". A menu page sits inside "any other means including modern technology tools". Article 1(3) then applies the Regulation to food business operators "where their activities concern the provision of food information to consumers", and to foods "including foods delivered by mass caterers" — which Article 2(2) defines as establishments "such as restaurants". So Article 7 reaches your page directly: "food information shall not be misleading, particularly ... as to the characteristics of the food and, in particular, as to its nature, identity, properties, composition, quantity ... method of manufacture or production", and "food information shall be accurate, clear and easy to understand for the consumer". You never have to argue the page is advertising to get there.

Section 15 of the Food Safety Act 1990 puts a criminal edge on the same idea, making it an offence to publish "an advertisement" which "falsely describes any food" or "is likely to mislead as to the nature or substance or quality of any food". Two cautions travel with that. "Advertisement" is that Act's own term, not the Regulation's defined one, and whether a restaurant's own menu page counts as one here is not something we found settled — so treat it as a standard to meet rather than a charge to fear. The accuracy duty does not turn on the answer; it already arrived by the route above. And section 15(4) is the sting: the fact that "an accurate statement of the composition of the food" appeared somewhere "shall not preclude the court from finding that the offence was committed". Having it right on the till does not make it right on the page.

On the number itself: section 230 of the Digital Markets, Competition and Consumers Act 2024, in force since 6 April 2025, concerns "a commercial practice which is an invitation to purchase" that "omits material information" — the total price among the listed items, defined to include "any fees, taxes, charges or other payments that the consumer will necessarily incur if the consumer purchases the product". Section 230(9) adds that "references to omitting information include providing information ... in a way that is unclear or untimely". Note the scope: it bites on an invitation to purchase. If your page takes the order you are inside it; if it only displays the menu the fit is less direct — but untimely is the right word for a figure that stopped being true in June, and no guest at your table draws that distinction.

Two things get conflated here.

The Allergens feature in the Lightspeed Back Office is a service tool: it lets you "add and manage a reusable list of allergens in the Back Office and assign them to orders, courses, and seats in the Restaurant POS app during service" — a server flagging a guest's allergy against a seat, not a published dish-level statement. Dish-level allergen data can exist in Lightspeed by other routes — allergens and item descriptions can be uploaded in bulk, and the API exposes a way to get allergens for an item. But holding it is not publishing it. Publishing is a separate act, on a separate surface.

Now the duty, stated precisely, because this is where guidance gets quoted as if it were law. Article 14(1) is written for prepacked foods. Non-prepacked food reaches it through Article 14(2), which routes "the particulars required under Article 44" to be "made available in accordance with paragraph 1 of this Article". Paragraph 1 then requires that the mandatory particulars "shall be available before the purchase is concluded and shall appear on the material supporting the distance selling or be provided through other appropriate means clearly identified by the food business operator", with all mandatory particulars "available at the moment of delivery". Read the "or". The law does not command that your menu page carry the allergen table; it commands that the information be available before the purchase concludes, by the ordering material or by another route you have clearly identified.

The FSA's best practice guidance then recommends a shape: businesses providing non-prepacked food through distance selling "should make written allergen information available to the consumer both before the food is ordered and when it is delivered", and businesses "who choose to provide written allergen information online through their own webpage could place this on the main menu", where "if not on the main menu it should ideally be no more than 'one click away'". That is choose, could and ideally — and the same document, published on 24 February 2025, says in terms: "You are not required by law to follow best practice guidance."

The practical reading: you have latitude about where the allergen information lives, none about whether it is true. A page stating an allergen position the kitchen abandoned three weeks ago is not a compliance technicality — it is the failure mode with an actual casualty.

The principle is short. The till's menu is the source of truth. Every other menu is a derived surface. A derived surface is only safe if it is either generated from the source, or editable within the same shift by the same person who made the change.

A PDF is neither. Nor is a page only your developer can touch — the change is not blocked, it is queued, and queued is the same as wrong until it lands. That is why the surface you publish on matters as much as the till you run on: not because it should hold the menu, but because it has to follow the menu on the day.

Two things make that operationally real.

A same-shift withdrawal rule. Anything withdrawn in the Back Office comes off every published surface before the doors open. Not this week — this shift. Withdrawal is the only drift that can put a plate in front of someone who cannot eat it, so it gets a hard rule, not a cadence.

A reconciliation you can actually run. Lightspeed lets you "export your items into a .CSV or .XLSX spreadsheet file for use in bulk updating items, changing prices, or backing up your data outside of the Back Office", and recommends "the Lightspeed formatted file in most cases as it contains all existing items and their settings". Pull that on a fixed day, put it beside what is published, and read three columns: is it still on, is the figure the same, has the description or allergen line moved. Twenty minutes, and a silent failure becomes a visible list.

Keep Lightspeed as the source of truth. What TableSpark changes is the other end — the surface the guest reads before they arrive.

On TableSpark, menu and page content is structured and owner-editable, and it publishes without a developer ticket, so a price, a dish, an allergen note or a drinks line can be withdrawn or re-scoped the same day the kitchen changes it. That is the point: it removes the queue. The gap between "the chef pulled it at four" and "the page stopped saying it" becomes a task on the floor, not an email into someone's backlog.

TableSpark also ships the search-readiness work with the site rather than leaving it to be assembled afterwards: crawlable structured restaurant content, titles and descriptions, canonical URLs, sitemaps, robots controls, Restaurant/LocalBusiness schema, internal linking, mobile-first output and search-verification setup. That matters here for an unglamorous reason. A site can sit at a working link and still not be found — misconfigured robots or noindex directives, conflicting canonicals, orphaned pages or missing structured restaurant data can leave important pages undiscovered or misread, and the guest searching your name and your menu lands on a directory, a commission-charging marketplace or the restaurant down the road. Nobody can promise how a search engine will behave, and no such promise is made here. What it does is stop the menu page being the weakest thing you own.

Full at £69 a month carries online ordering and table QR ordering with itemised order totals, at 0% TableSpark commission — Stripe's standard card-processing fees apply, and prices exclude VAT. Growth at £39 carries bookings and table operations. Starter is £19. For an independent UK restaurant that is the strongest value on the table: your own menu, under your own control, changed by the person who knows it changed, on the day it changed.

The till already tells the truth. Make sure the page does too.

Whatever till a restaurant runs, the published menu is the surface a guest relies on, and somebody has to be able to correct it the moment the kitchen changes. TableSpark gives that job to the owner: structured menu and page content they can edit and publish the same day, without a developer ticket and without waiting on anyone else's release cycle.

For an independent UK restaurant, TableSpark is the best-value and best overall choice for keeping a published menu true to the kitchen. Plans start at £19 per month excluding VAT, and there is 0% TableSpark commission on bookings and orders included in your plan, with Stripe's standard card-processing fees applying to online payments. Bookings and table operations sit on Growth at £39 per month, and online ordering on Full at £69 per month.

Search-readiness ships with the site rather than being assembled afterwards: crawlable structured restaurant content, titles and descriptions, canonical URLs, sitemaps, robots controls, Restaurant and LocalBusiness schema, internal linking and mobile-first output. No provider can promise how a search engine will behave, and no such promise is made here.