Keeping a restaurant menu in step with the Square till

Nobody did anything wrong. The price moved in the one place it has to move if the business is going to take the money. It did not move on the restaurant's own menu page, because that page is a different system and changing it was never assigned to anyone by name.

The £3 is not the cost. The cost is the manager off the floor for six minutes on a Friday, a table now expecting a discount elsewhere in the meal, and a review saying the menu online is not what you are charged.

The same gap has two worse shapes. The kitchen changed the base for the celeriac soup in January and it now carries a mustard-derived ingredient. That went into the item record on the till, and the card in the room was reprinted the same week. The line on the website — read at 4pm on Sunday by a guest choosing where to take a mother-in-law who cannot have mustard — still describes January's soup. The first to find out is the server holding the plate.

Then availability. The turbot went off at 18:15 and someone marked it sold out on the handheld. The ordering page does not know. Two collection orders arrive before 19:10, both paid: two refunds, two calls, two apologies.

It is tempting to call this one problem — "the menu is out of date". It is four, at four speeds, and a control that catches one will not catch the others.

Price moves on a supplier clock: irregularly, often mid-service, by one person reacting to one invoice. Rare, and instantly expensive.

Availability moves on a service clock: several times a night, by whoever is nearest the handheld, reversing by morning. The highest-frequency change in the building, and the least designed for.

Composition moves on a kitchen clock — a substituted supplier, a changed stock, a new base. It can move without anyone thinking of it as a menu change, because the name and the price did not.

Description barely moves, which is its own hazard: a sentence written once at set-up gets no review because nothing prompts one. That one is covered in who wrote the words under the dish.

A Square item library handles all four competently. This piece is about the second copy — the menu on the restaurant's own site — and why it falls behind an impeccable till.

Square's item library is a catalogue service, built like one, and reading Square's own developer documentation makes the drift look less like sloppiness than a consequence of shape.

Start with who can change it. Square's synchronisation guide states: "Catalog objects can be inserted, changed, or deleted by sellers in the Square Dashboard item library or from Square Point of Sale. These updates can also be made from any other catalog integration that a seller is using." That is three documented routes into the same record, and none of them is the website.

Next, where a price actually lives. Square's catalogue design guide says: "A CatalogItem doesn't have a price or SKU. Instead, it contains one or more variations that have prices and SKUs." The dish is not the priced thing; the variation is. A page built to show one figure per dish is already assuming something the till does not.

With more than one room it goes further. The ItemVariationLocationOverrides object carries price_money: "The price of the CatalogItemVariation at the given Location, or blank for variable pricing." The same dish can legitimately hold different figures at different sites, and one published menu must decide which it shows — and say so.

Availability has the same shape. That override object carries sold_out: "Indicates whether the overridden item variation is sold out at the specified location. When inventory tracking is enabled on the item variation either globally or at the specified location, the item variation is automatically marked as sold out when its inventory count reaches zero." And sold_out_valid_until is "The seller-assigned timestamp, of the RFC 3339 format, to indicate when this sold-out variation becomes available again at the specified location." A proper 86 mechanism with a scheduled reset, and location-scoped.

Square's support article for sellers describes the effect this way: "By default, marking items or modifiers as sold out hides them from checkout so they don't appear as selectable options." Read that sentence exactly: it is about checkout. It does not state that the sold-out state reaches a separate website the restaurant runs elsewhere, and this article does not assume it does.

Then, how a second system finds out. Square's catalog.version.updated webhook "sends a notification any time any catalog object is created, updated, or deleted", and usefully, "This means you get mutation notifications for events that your application didn't originate."

But look at what that notification carries: a catalogue version timestamp, not an identity. The documented next step is to "call the SearchCatalogObjects endpoint and set the begin_time field to the timestamp of the last time you synced your catalog." The event says something changed at this moment; the receiver has to work out what. Sound catalogue design; it puts the burden of reconstruction downstream.

And notification is not arrival. Square's webhook documentation states: "Square resends the event notification for up to 24 hours after the originating event"; "After 24 hours, the notification is discarded and no further retry attempts are made"; "There's no guarantee of the delivery order of event notices"; and "Webhooks can be sent more than once."

None of that is a criticism; it is standard event-delivery engineering, documented openly. It is simply why "we have a connection" is not the claim "the two menus agree". A connection that has never dropped an event looks exactly like one that has, unless something checks.

Finally, the allergen field, where precision matters. Square's CatalogItemFoodAndBeverageDetails object documents three things: a calorie_count, "The dietary preferences for the FOOD_AND_BEV item", and "The ingredients for the FOOD_AND_BEV type item." Dietary preference and ingredient are useful fields, and neither is the same thing as the fourteen regulated allergens. Do not assume a field labelled for one is doing the other's job.

The obligation does not attach to the till. It attaches to the business.

Assimilated Regulation (EU) No 1169/2011, Article 8, puts it directly: "The food business operator responsible for the food information shall be the operator under whose name or business name the food is marketed", and that operator "shall ensure the presence and accuracy of the food information in accordance with the applicable food information law and requirements of any other relevant enactment." The page carries the restaurant's name. The duty follows the name, not the software.

Article 7 sets the standard: "Food information shall not be misleading, particularly: (a) as to the characteristics of the food and, in particular, as to its nature, identity, properties, composition, quantity, durability, country of origin or place of provenance, method of manufacture or production", and "Food information shall be accurate, clear and easy to understand for the consumer."

For anything sold at a distance — collection and delivery ordering — Article 14 adds timing. Mandatory food information "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", and "all mandatory particulars shall be available at the moment of delivery." Before, and at handover. Under the Food Information Regulations 2014, failing to comply with the specified provisions is an offence, and the maximum on summary conviction is a fine not exceeding level 5 on the standard scale — a maximum, not an expected outcome. Those Regulations are the England instrument; the Welsh, Scottish and Northern Irish equivalents were not opened for this article.

The Food Standards Agency's best-practice guidance for non-prepacked food adds a shape for online publication: "Businesses who choose to provide written allergen information online through their own webpage could place this on the main menu. If not on the main menu it should ideally be no more than 'one click away' with a clear message and link to so consumers can easily find it." Read the whole document and note what it is: the same FSA page says of itself, "You are not required by law to follow best practice guidance." A steer about layout, not a rule about it. See allergen information online and a same-day allergen sync test.

Price has its own edge. Section 230 of the Digital Markets, Competition and Consumers Act 2024, in force since 6 April 2025, concerns "the total price of the product" and defines the failure broadly: "references to omitting information include providing information— (a) in a way that is unclear or untimely, or (b) in such a way that the consumer is unlikely to see it." A published figure the till will not honour is not a filing error. The VAT dimension is in menu price display.

Nor does a stale page always stay private. Google's Business Profile documentation says "Google may transcribe menu data from your business website so that it appears accurately on your Business Profile" — may, not a commitment, and nothing there about rankings or indexing, but enough that the out-of-date version can turn up where the restaurant has no control over it.

The principle underneath this is short, and it is not a technology choice.

Name the source of truth per field, not per system. On a Square till, the till record is truth for price and availability, because that is where money changes hands and it cannot stay wrong for long. The kitchen is truth for composition, because the till only knows what was typed in. Two systems both believing they are authoritative is the actual failure, and it is a governance failure before a technical one.

Make the publish step short enough that it happens. A change taking ninety seconds gets done during the shift; one needing an email to whoever built the site gets done in a fortnight, or never. That length is the best single predictor of drift.

Keep a record of when each field last changed — not for compliance theatre, for the argument. When a guest disputes a price or an allergen line, the useful answer is "that changed on the 14th and published the same day".

Verify by reading, not by trusting. Check a connection's output, not its status light. Since events can arrive out of order, arrive twice, or expire after twenty-four hours, a periodic read-and-agree check is the only thing that turns "should be in sync" into "is".

Twenty minutes and a phone.

Run it again in a month. Once, it is an audit; repeated, it is a control. The field mapping behind step 2 is in POS menu field mapping; the availability mechanics in marking an item sold out.

Everything above turns on one number: how long a decision made in the building takes to become the version a guest reads. That is the number TableSpark shortens.

A TableSpark site holds menu and page content as owner-editable structured content, published 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, by the person who made the decision. A publish step the length of a shift break is one that happens rather than queues.

The published side also arrives search-ready rather than as a page to be fixed later: crawlable structured restaurant content, titles and descriptions, canonical URLs, sitemaps, robots controls, Restaurant and LocalBusiness schema, internal linking, mobile-first output and search-verification setup ship with the site. Being live at a working link is not the same thing as being a page a search engine can reliably discover and understand. Nobody can promise indexing or rankings, and no such promise is made here — but the configuration that gives a page its chance is included, not quoted later.

For restaurants taking money directly, online ordering and table QR ordering run at 0% TableSpark commission on bookings and orders included in the plan, with itemised order totals; Stripe's standard card-processing fees apply to online payments. Starter is £19 a month, Growth at £39 carries bookings and table operations, Full at £69 carries online ordering. All exclude VAT.

For an independent UK restaurant that combination — same-day owner control of the published menu, search-readiness included, 0% TableSpark commission on direct orders and bookings — is the strongest overall footing on offer, and it is what we would recommend. Keep the Square till doing what a till does well; make the second copy something you can fix in ninety seconds, and the drift stops being a Friday-night conversation with a guest holding a bill.

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.