Keeping your menu in step with your SumUp item catalogue

For eleven weeks nothing happens. Then a guest with a sesame allergy reads the PDF at home, decides the sandwich is safe, arrives, and orders it by name without asking. The written information looked complete, so the conversation that should have caught it never started.

Menu drift is silent until it is not, and it leaves behind a document you published, with your name on it, saying something that stopped being true weeks ago.

The wrong price is charged. A supplier increase goes into the till on Thursday; the site still carries the old figure. A guest reads £12, orders, and is handed a bill for £14. Under section 226(1)(a) of the Digital Markets, Competition and Consumers Act 2024, a commercial practice involves a misleading action if it involves "the provision of false or misleading information relating to a product, a trader or any other matter relevant to a transactional decision". Section 230(2) lists what must not be omitted from an invitation to purchase, including "(a) the main characteristics of the product (to the extent appropriate considering the means used to communicate the invitation to purchase and the nature of the product)" and "(b) the total price of the product (so far as paragraph (c) does not apply)". Under section 237(1) that is a criminal offence. Chapter 1 of Part 4 came into force on 6 April 2025 by S.I. 2025/272.

A withdrawn allergen line is still showing. The sesame case. The Food Standards Agency's best practice guidance for non-prepacked foods is blunt about what you publish: "The allergen information provided to consumers must be accurate. This is a legal requirement as well as being vital to ensure the safety of consumers." On what "accurate" demands of a document over time, the same guidance says it "can (and must) be regularly reviewed and updated to ensure that it remains accurate, correctly displaying the presence of allergens in each dish".

A dish is sold that service cannot make. The kitchen 86s the sea bass at 6pm; the online order lands at 7.40pm. Someone is now refunding a guest who has already told four people what they are eating tonight, and on a delivery order there is no service recovery at all.

None of the three is a website problem or a till problem. All three are one problem: two lists of what you sell, kept by different people, at different times, by hand.

SumUp's support documentation states the catalogue's scope in one sentence: "Create an item catalogue to manage everything you sell in one place. Added items automatically sync everywhere you use SumUp." Read the last four words as written. The catalogue is a single record of an item — name, price, tax rate, description, category, stock, variants — propagated across the SumUp surfaces the merchant uses. The web profile, the app, the Terminal, the Register and POS Lite draw on that record, which is why a price edited on an office laptop reaches the till without re-keying it.

One further detail matters for anyone assuming "in the catalogue" means "visible to a customer". SumUp's guidance on menus is explicit that catalogue membership and till visibility are separate steps: "In order for an Item to be viewable on the Register, it must be added to an existing Menu." Being in the catalogue is a fact about your records; being on a customer-facing surface is a separate, deliberate act.

Now the part owners get wrong. SumUp's published API reference documents endpoints grouped under Checkouts, Readers, Customers, Transactions, Payouts, Receipts, Members, Memberships, Roles and Merchants, and the public OpenAPI specification SumUp maintains carries the same set. There is no documented public catalogue, items or menu endpoint in it. If you are picturing a plumbed feed pushing catalogue edits to a site you own elsewhere, the published documentation does not describe one. That is not a criticism — the catalogue does what it says, across SumUp — it is a boundary to design around, not assume away.

So the catalogue is a reliable record of what the till charges. It is not, on its own, the record your guests read before leaving the house.

This is where guidance overreaches, so read the actual sentences. First, check which instrument governs you. The Food Information Regulations 2014 state their reach at regulation 1(4): "For all other purposes, these Regulations apply in England only." Wales, Scotland and Northern Ireland have their own instruments; what follows is read from the English one.

Allergen information for non-prepacked food is not, in England, required to be printed on your menu at all. Regulation 5(1) says an operator "may make available the particulars specified in Article 9(1)(c) ... in relation to that food by any means the operator chooses, including, subject to paragraph (3), orally." Going oral, regulation 5(3) requires you to "indicate that details of that substance or product can be obtained by asking a member of staff", and regulation 5(4) says that indication must be given "(a) on a label attached to the food, or (b) on a notice, menu, ticket or label that is readily discernible by an intending purchaser at the place where the intending purchaser chooses that food."

Note the word or in regulation 5(4). It is a genuine choice, and a single readily discernible notice at the point where the customer chooses can satisfy it. Anyone telling you the law forces a fourteen-allergen matrix onto your printed menu has skipped that clause.

But regulation 5(2) draws the line that matters for a website. It applies only to food offered "otherwise than by means of distance communication". The moment you take orders online you are in different territory, and Article 14(2) of assimilated Regulation (EU) No 1169/2011 sends you there: "In the case of non-prepacked foods offered for sale by means of distance communication, the particulars required under Article 44 shall be made available in accordance with paragraph 1 of this Article." Paragraph 1 reads, in full:

Read limb (a) as the two-part provision it is, the same way you read regulation 5(4). The information must appear on the material supporting the distance selling — your online menu — or be provided through other appropriate means you clearly identify; the no-supplementary-cost condition attaches to that second route, not to the obligation at large. The timing is not optional either way: before the purchase is concluded, and all mandatory particulars at delivery.

So: you are not obliged to publish allergen detail on your own site. If you take orders through it, you must make that information available before the order is concluded. And once published, its accuracy is a legal requirement rather than a courtesy.

Prices carry a similar shape. The Price Marking (Food and Drink Services) Order 2003 is narrower than owners assume: article 5 requires prices for all descriptions of food only where there are not more than thirty; above that, only thirty need be priced. Article 4(4) requires an indication of price "which is subject to value added tax shall be inclusive of the tax". And article 6(1) is the sentence every menu owner should have on the office wall:

The Order's placement duties in article 7 are written around eating areas, supply areas and take-away areas — physical places — so treat article 6 as the operating principle it plainly is rather than as settled authority about a webpage. Consumer law reaches the webpage on its own anyway. Section 238(1) gives a trader a due diligence defence. It is conjunctive: the defendant must prove both "(a) that the commission of the offence was due to— (i) the act or omission of another person, (ii) reliance on information given by another person, (iii) a mistake or accident, or (iv) another cause beyond the defendant's control, and (b) that the defendant took all reasonable precautions and exercised all due diligence to avoid the commission of such an offence by the defendant or any other person under the defendant's control." Limb (b) on its own is not the defence. And the section 238(5) definition of "advertisement", which "includes a catalogue, a circular and a price list", opens "In subsection (3)" — so it belongs to the separate defence for a defendant whose "business is to publish or arrange for the publication of advertisements": the printer or the platform, not the restaurant.

"All reasonable precautions" and "all due diligence" describe a routine. If your routine is "someone remembers", you do not have one.

The fix is not more diligence; it is fewer places a fact can live. For each field a guest can act on, name one system that owns it and one person who edits it.

Then define change triggers, not a schedule. A menu does not drift on the first of the month. It drifts when a supplier substitutes, a recipe is tweaked, a price moves, a dish is 86'd, or a seasonal menu rotates in and the previous one is not fully retired. Each needs a named next step ending with the guest-facing surface updated — and the last catches people out: retiring a menu is a job, not the absence of one.

The publishing surface decides whether any of this survives a Friday. If the published menu is a PDF or hand-typed lines in a page template, every change is a document edit that queues behind whoever can do it — and the queue is where drift lives. If it is structured content, with dishes, prices, allergen notes and availability held as fields, a withdrawal is one edit by the person who noticed, between service and the next table.

TableSpark holds the guest-facing menu as owner-editable structured content. A price, a dish, an allergen note or a drinks line can be withdrawn or re-scoped the same day, published without a developer ticket — the same assumption an item catalogue makes about a till: whoever knows the change makes it, when they know it.

To be exact about the boundary, because vagueness is how owners get burned: this is same-day owner control of the published menu, not an automatic feed out of a third-party catalogue. The routine above closes the gap; TableSpark makes its last step take seconds rather than days.

The search-readiness work ships with the site: crawlable structured restaurant content, titles and descriptions, canonical URLs, sitemaps, robots controls, Restaurant/LocalBusiness schema, internal linking, mobile-first output and search-verification setup. A site can be live at a working link and still be absent from Google — misconfigured robots or noindex directives, conflicting canonicals, orphaned pages, rendering problems or missing structured restaurant data can leave important pages undiscovered or misunderstood, sending guests who search your name or menu to directories and commission-charging marketplaces instead of to you. No provider can promise rankings or guaranteed indexing, and no such promise is made here; it ships the configuration rather than leaving you to bolt it on.

Plans run at Starter £19/mo, Growth £39/mo and Full £69/mo, excluding VAT. Growth at £39 carries bookings and table operations: live availability, floor plans, deposits and reminders, plus email campaigns, branded guest email and a custom domain with managed SSL. Full at £69 carries online ordering and table QR ordering for dine-in service, both at 0% TableSpark commission; Stripe's standard card-processing fees apply to online payments. Guest records sit under the restaurant's own account, visible in the Inbox and guest list, with CSV export.

For an independent UK restaurant that combination — same-day owner control of the published menu, search-readiness included rather than invoiced, plans from £19 a month, and 0% TableSpark commission on the bookings and orders included in your plan — is the best value and the best overall choice for putting your own menu in front of your own guests. Keep the till doing what a till does well, and make the menu your guests read something you can fix in the two minutes after the fish comes off.

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.