Your till withdrew the dish. Your menu page is still selling it.

The chef takes the hake off on a Tuesday afternoon because the delivery was short. He does it the way he always does: opens the product in the Epos Now back office, changes what needs changing, gets back to prep. The till is correct inside a minute. Every screen on the floor is correct.

At eight on Saturday, a four-top orders the hake — from a phone, off the menu page on the restaurant's own domain, which nobody has touched since March. The server takes it to the pass, comes back, apologises, and the table re-orders around a dish that has not existed for four days. One of them chose the restaurant for it.

The same gap has two other shapes, and both are worse.

The ribeye went to £32 in the back office in June. The published menu still says £29. A guest who read £29 and is charged £32 is not being unreasonable, and the disagreement happens at the card machine with a full room listening. The restaurant either absorbs the difference or wins an argument it should never have had.

And the tempura batter changed supplier in the spring. The kitchen's allergen record was updated the same week. The description under that dish on the website was typed once, at launch, by whoever built the site, and has not been read since.

None of these is a synchronisation failure. There was never a synchronisation. There are two separate records of the same menu — one in the till, one on the site — and they were only ever going to agree on the day somebody typed them both.

Epos Now publishes its V4 API specification publicly, and the documented Product model is worth reading directly. A product carries Name, Description, CategoryId, Barcode, Sku, SortPosition, images, tags and user-defined fields — and money in more than one place.

A dish does not have a price. It has a SalePrice and an EatOutPrice, each with its own flag for whether the figure includes tax — IsSalePriceIncTax and IsEatOutPriceIncTax. On top of that sits ProductLocationAreaPrices, in which each LocationAreaId can hold its own SalePrice and EatOutPrice, so the same dish can legitimately be one figure in the bar and another in the dining room. And if IsVariablePrice is set there is no fixed figure to publish at all, because the number is entered at the point of sale.

Modifiers carry their own money: a MultipleChoiceGroup has a MinSelection, a MaxSelection and a set of MultipleChoiceProducts, each with its own SalePrice and EatOutPrice. A burger with a compulsory side is not one number.

Two fields deserve special attention. Each product carries SellOnWeb and SellOnTill as separate booleans, and each category carries ShowOnTill. The till system already models the idea that the till's list and the web's list are not the same list. Most drift begins by ignoring that and pulling everything.

Withdrawal has its own field: IsArchived. A dish taken off is normally archived rather than destroyed, which is correct — last year's transactions still reference it. But "retired by the kitchen" and "absent from the data" are then two different states, and a read that ignores the flag will republish something the kitchen took off months ago.

Epos Now's setup documentation is explicit about where the interface sits: "The API interacts with the data stored in the cloud and therefore cannot be used to interact directly with the till." Anything a website shows is downstream of a cloud record, itself downstream of what happened on the floor. Every hop is a place where the picture can be hours old, and a few hours is a whole service.

Read the documented Product model again and notice what is missing. There is a Description. There is no allergen field.

That absence matters more than any other gap here: allergen information is the one part of a published menu where accuracy is not a matter of house style.

The Food Standards Agency's best-practice guidance for non-prepacked foods — published 24 February 2025, explicitly covering meals in cafés and restaurants — is careful about its own status, and the whole sentence matters more than the headline. On legal status: "You are not required by law to follow best practice guidance." And on what has and has not changed: "The approach set out in this document represents a change in best practice to meet the expectation for there to be both written allergen information and a conversation. The minimum legislative requirement for information to be provided by any means (with a sign indicating when it will be provided verbally) has not changed."

So a restaurant is not compelled to put a full allergen matrix online. A sign and a trained conversation still meet the legal minimum.

The same guidance is equally plain about what happens once information does exist. "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." Among its stated principles for written information: "accurate - it can (and must) be regularly reviewed and updated to ensure that it remains accurate, correctly displaying the presence of allergens in each dish."

That is the trap, stated cleanly. Publishing allergen information online is a choice. Publishing accurate allergen information is not. The moment a menu page lists allergens, the restaurant has volunteered to keep that page true for as long as it stays up, through every supplier substitution and every recipe change that moves allergen text out of step.

For distance selling the guidance goes further, still in "should" language: "Food businesses providing non-prepacked food through distance selling such as online or by telephone should make written allergen information available to the consumer both before the food is ordered and when it is delivered." On pre-orders it adds a warning that applies to any published menu: it "may not be sufficient to rely only on information supplied in advance as ingredients could have changed".

The operational reading is short. A Description field on a till product is not an allergen record and must never be pressed into service as one. If allergen text appears on the site it comes from the kitchen's own allergen record, with a named person who approves it — never from a sentence typed into a product row eighteen months ago. That is the discipline behind publishing allergen information at all.

Prices are governed by a newer body of law. The Digital Markets, Competition and Consumers Act 2024 replaced the 2008 unfair trading regulations for this purpose, and GOV.UK's summary for businesses puts the date plainly: "The changes came into force on 6 April 2025."

Section 226 defines a misleading action as a commercial practice involving "the provision of false or misleading information relating to a product, a trader or any other matter relevant to a transactional decision". Section 225 supplies the test that makes it unfair: the practice must be "likely to cause the average consumer to take a transactional decision that the consumer would not have taken otherwise".

That test is the uncomfortable part. A guest who books because the menu showed £29 has taken a transactional decision on a figure the till no longer honours. Section 230 opens a second route, and it bites on an invitation to purchase — information "which indicates the characteristics of a product and its price" and which enables the consumer to decide whether to purchase. If your page takes the order you are inside it; if it only displays the menu the fit is less direct. Where it applies, the required information includes, in the operative words of section 230(2)(b), "the total price of the product" — a paragraph itself qualified "(so far as paragraph (c) does not apply)", which covers prices that cannot be calculated in advance.

GOV.UK's business-facing summary makes the online point without hedging: "This can also include how information is presented online, so you must think about your website or online presence, and whether required information is prominent enough."

The enforcement ceiling is genuinely large — "The CMA and the courts can now fine traders who do not comply with the law up to 10% of their worldwide turnover. You may also have to compensate affected consumers." — and it deserves honest scaling. A forty-cover restaurant with a stale ribeye figure is not what a turnover-based penalty was built for. What actually arrives is smaller and more frequent: the refund at the card machine, the review that quotes the published figure back, the trading standards enquiry answered in writing — and in each exchange the restaurant is arguing against something it published itself. The practical checks live in keeping displayed menu figures and VAT treatment straight.

Nobody buys their way out of this with a connector. Drift is a governance problem in a technical costume, and five rules settle it, all on paper, before anything is configured.

Decide the system of record field by field, not system by system. "Epos Now is the source of truth" is too coarse to act on. Price and live availability belong to the till, where service changes them under pressure. Allergen data belongs to the kitchen's allergen record. Description, photography and the story under the dish belong to whoever is accountable for those words. Write it down: field, owner, where it lives.

Publish a projection, not a mirror. A published menu is a filtered view of the product list, not a copy. Honour IsArchived so retired dishes stay retired. Honour SellOnWeb — the field is in the model, but Epos Now documents no meaning for it, so treat the reading as inference — and keep the till's internal lines, the staff meal, the corkage line, the void code, away from guests. Choose deliberately between SalePrice and EatOutPrice, and read the inc-tax flag before showing the number rather than assuming it. Refuse to publish what cannot be stated correctly: a Weighted product priced per kilogram is not a dish price, and an IsVariablePrice item has no figure to show. Silence is better than a wrong number. The field-by-field version is in mapping till product fields to menu fields.

Let change push, rather than waiting to be noticed. The V4 API exposes a webhook subscription — a base URL plus a set of triggers — and the documented event types include CreateProduct, UpdateProduct, DeleteProduct, UpdateOutOfStockProduct, UpdateInStockProduct and the equivalent category events. A change that announces itself closes the gap between four o'clock and eight. A nightly job re-reading the whole catalogue two hundred records to a page cannot, by construction.

Keep writing one-way. The V4 documentation for updating products is direct about its semantics: "This method supports only full updates, you must supply the full object model when updating. If you do not provide required parameters the operation could fail, optional parameters that are not provided will be set to their default value." It is unforgiving of casual two-way sync: a site that writes back a partial product silently resets fields nobody was looking at. Let the menu read. Let the till write.

Keep a same-day human override. Automation narrows the gap; it does not cover the case where a line must be gone in ten minutes and the right move is for a person to remove it. A menu an owner cannot edit at nine on a Saturday evening stays wrong until Monday. The routine is the same one behind marking a dish sold out without waiting for anyone.

The till stays the till. Epos Now is where the floor works, and nothing above argues for changing that. The question is what sits on the published side of the line, where independent restaurants are usually left to improvise.

TableSpark ships owner-editable structured menu and page content that publishes without a developer ticket. A price, a dish, an allergen note or a drinks line can be withdrawn or re-scoped the same day, by the person who knows it is wrong, at the moment they know it. Every other control here is a way of shortening the interval between a change in the kitchen and a change on the page, and the shortest possible interval is an owner with edit access.

Search readiness is packaged into the site rather than left as a technical errand. Being live at a working link is not the same as being reliably discovered and understood: misconfigured robots or noindex directives, conflicting canonicals, orphaned pages, rendering problems, missing structured restaurant data or incomplete search verification can leave a menu page undiscovered or misread, and guests searching by name, dish or location land on a directory, a commission-charging marketplace or a neighbouring restaurant instead. TableSpark includes crawlable structured restaurant content, titles and descriptions, canonical URLs, sitemaps, robots controls, Restaurant/LocalBusiness schema, internal linking, mobile-first output and managed search-verification setup as part of the site. No provider can promise a ranking or guarantee that a page is indexed, and no such promise is made here — what it does is stop that work being an errand the owner has to source separately.

Plans start at £19 a month for Starter, "For one restaurant that needs to launch direct and stay easy to update." Growth at £39 carries bookings and table operations — live availability, floor plans, deposits and reminders, email campaigns, branded guest email and team access, custom domain and managed SSL. Full at £69 carries online ordering and table QR ordering for dine-in service, with itemised order totals. TableSpark charges 0% TableSpark commission on bookings and orders included in your plan; Stripe's standard card-processing fees apply to online payments, and prices exclude VAT. Guest records sit under the restaurant's own TableSpark 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 billed as a project, 0% TableSpark commission on the bookings and orders in the plan, from £19 a month — makes TableSpark the best-value and best overall choice for the published side of the menu. The till keeps doing what it does well, and the site stops being where last month's menu goes to survive.

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.