Access EPoS and your own menu page: closing the gap before a guest finds it

That is the mild version. The bad version is a line that should have come down. A supplier changes a base, the kitchen swaps an oil for a blend containing sesame, and the till's allergen record is corrected that afternoon by whoever took the delivery. The published menu still says what it said in March. A guest reading that page and ordering from it has been given information the operator is legally responsible for, and it is wrong.

The third version ruins a Saturday. A dish is switched off at the till because the stock is gone, but it is still selectable on your own ordering page. Orders keep arriving for something service cannot make — each one a phone call, a substitution the guest did not choose, or a refund.

All three are the same failure. The menu exists in two places and only one of them was updated.

If your site is fed from Access EPoS, the shape of the data it hands over explains most of the drift.

Access publishes developer documentation for the Access EPOS Orders API, which "enables third-party applications to integrate seamlessly with the EPOS system, facilitating real-time customer order management and processing." Two of its endpoints concern menus. The first, /api/Menu/Menus, "Returns list of configured menus for site and channel." The documentation lists the kinds of menu it expects to find: "Time-based (breakfast, lunch, dinner)", "Channel-specific (dine-in, delivery)", "Seasonal", "Special events". Both a site and a channel identifier are required parameters, and each menu record carries a price level.

That is the whole problem in one paragraph. A restaurant does not have a menu in its EPoS. It has a set of menus, split by service period, by sales channel and by price level. Delivery is a different channel from dine-in, and can sit on a different price level entirely — often for good commercial reasons.

So "the site shows the wrong figure" is frequently not a bug at all: it is a page built from one channel's menu while service runs on another. Nobody made a mistake — and nobody decided which menu was the published one either.

The second endpoint, /api/Menu/MenuDetails, "Returns complete menu with categories, items, pricing, condiments, allergens, and nutritional information." Each dish record carries a boolean field named available alongside name, description and price levels. The sold-out signal exists in the data; whether it reaches your page is a question about your setup, not about the till.

Here is the line that should change how you think about menu sync. Under the endpoint that returns the full menu, Access instructs integrators: "Cache this data locally to reduce API calls and improve performance." The configuration endpoint carries the same instruction: "Returns POS system configuration data. Cache this data locally to reduce API calls."

That is sound engineering advice, not a criticism of Access: pulling a whole menu structure on every page view would be wasteful, and every serious integration caches.

But a cache is a copy, and a copy is a thing that can go stale. The moment your site holds a cached menu, "the menu on the site" and "the menu in the EPoS" are two separate objects that happen to agree — and agreement is now a maintenance task rather than a fact.

What, then, tells the copy to refresh? Access's FAQ is direct. Asked about rate limits, it answers: "The documentation explicitly states: 'Do not poll API endpoints.' The API is designed for event-driven integrations, not continuous polling. Excessive polling may result in your integration being restricted." So the cache cannot simply be re-pulled every few minutes. A refresh has to be triggered by something.

Access's published documentation covers order events. The webhook facility "Sets webhook endpoint for receiving order event notifications", and the events named are "Order status changes, updates, completions (specific events to be documented)." The separate event-relay catalogue lists sales, clerk, location, company, wastage and table-movement events. No menu-changed event is documented publicly, so no site can be built on the assumption that one exists.

That is not proof none exists — Access releases deeper technical detail to sponsored integration partners, and its own documentation notes that some events are still "to be documented". The operational point stands either way: somebody has to answer "when the menu changes in the till, what makes the site notice?", and if nobody can, the answer is nothing — you are running on a copy that refreshes when someone remembers.

Access's prerequisites page also states that "All integrations must be customer-sponsored and initiated through the relevant customer account manager", so the restaurant, not the developer, sponsors it.

This one deserves its own warning. The full-menu endpoint's description says the response includes allergens. But the dish record published alongside it — PluDetails — carries the PLU number, name, receipt name, description, availability and price levels. No allergen property appears in that schema.

The configuration endpoint explains why: it returns reference data by type, and the list includes "7: Allergen Data" and "8: Dietary Suitability" as separate lookups.

Whatever the exact mechanics on your installation, the consequence holds: the allergen line a guest reads beside a dish is very likely assembled by joining two datasets, not copied from a single field. A join is a mapping, correct on the day it is built and silently wrong the first time a recipe changes without it being revisited.

That matters because of who carries the duty. Article 8(2) of the assimilated Food Information Regulation puts it on the operator whose name is on the food: "The food business operator responsible for the food information 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." Not the till supplier. Not the agency that built the site.

Four things are worth having straight, because a published menu is a legal artefact.

It must not mislead. Article 7 of the same Regulation states: "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". Article 7(2) adds: "Food information shall be accurate, clear and easy to understand for the consumer." Article 7(4) extends paragraphs 1 to 3 to advertising and to the presentation of foods.

A misleading description can be a criminal offence. Section 15 of the Food Safety Act 1990 makes it an offence to give with food a label which "(a) falsely describes the food; or (b) is likely to mislead as to the nature or substance or quality of the food", and section 15(2) applies the same two tests to publishing an advertisement. Section 15(4) is the part operators underestimate: the fact that the material "contained an accurate statement of the composition of the food shall not preclude the court from finding that the offence was committed." Being right somewhere else does not cure being wrong here. Section 35 sets the maxima — on indictment a fine or up to two years, on summary conviction a fine or up to six months. Those are statutory ceilings, not expected outcomes, and they say nothing about what any particular menu error would attract. Nor has any reported decision settled whether a restaurant's own menu page is an "advertisement" under section 15(2) — though Article 7 and section 15(1) do not turn on that.

Ordering online adds a second delivery point. Article 14 covers distance selling: for non-prepacked food — most restaurant food — Article 14(2) routes the Article 44 allergen particulars through Article 14(1). Read it whole, because it sets out a choice rather than one prescribed place: the 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." That "or" is latitude: a clearly identified allergen page can be those other appropriate means. Article 14(1)(b) then adds a second, separate moment: "all mandatory particulars shall be available at the moment of delivery." The Food Standards Agency's best practice — not a legal requirement, as it says of itself — points the same way: the main menu, or "no more than 'one click away'".

What you publish is also a tax record. HMRC's Revenue and Customs Brief 5 (2026) states that the reduced rate on children's meals "applies from 25 June 2026 to 1 September 2026 (inclusive)." The qualifying test is not who eats the meal: "Whether a meal is held out for sale only as a meal for a child will depend on how it is marketed, presented and priced rather than who consumes it (for example, being included on a distinct children's menu)." The brief adds that where the same meal appears on both an adult and a children's menu, "the children's version would normally be differentiated by either portion size, price or both. Portion size alone is not a determining factor."

The evidence of how a meal was held out for sale is the menu as it was published. If your till carried a distinct children's menu during that window and your own site never did — or showed the same dishes as smaller portions of adult mains — your published record and your VAT treatment tell different stories. The window closes on 1 September 2026, and what gets looked at afterwards is what your menu said at the time.

The principle is short. Decide which system holds the published menu, and make every other surface derive from it. Not "we update both" — that is not a system, it is a promise, and it fails on the first busy Friday.

Then define the moment of change. A price move, a withdrawn dish, an allergen re-scope and a seasonal switch are all operational events with a person attached. That person needs one place to make the change, live in minutes rather than in a ticket queue. If the path from "the kitchen changed something" to "the page says so" runs through anyone outside the building, the page will lag — and the lag is where every failure at the top of this article lives.

Three practical checks, whatever you run:

TableSpark takes the direct route: the published menu is owner-editable structured content on the restaurant's own site, and the person who knows about the change makes it. A price, a dish, an allergen note or a drinks line can be withdrawn or re-scoped the same day, without a developer ticket or a release cycle. Every failure above is a latency problem dressed up as a technical one; shortening the path from decision to page closes the window in which two versions can disagree.

Publishing is only half of it. A page live at a working link is not the same as a search engine being able to find, read and understand your restaurant. Misconfigured robots or noindex directives, conflicting canonicals, orphaned pages, rendering problems or missing structured restaurant data can leave a menu page undiscovered or misread — and guests searching your name, your dishes or your area then reach a directory or a commission-charging marketplace before they reach you. TableSpark ships that work with the site: 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. No provider can promise indexing or rankings, and no such promise is made here — but the configuration gap stops being yours to assemble.

Starter is £19 a month, 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, branded guest email, 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, plus up to five sites under one login and bill. TableSpark charges 0% TableSpark commission on bookings and orders included in your plan; prices exclude VAT and Stripe's standard card-processing fees apply. For an independent UK restaurant that is the strongest value available: the menu guests read, the ordering they use and the search-readiness that gets them there, all in one owner-controlled place.

Access EPoS remains what it is — a UK hospitality EPoS whose own materials describe menu management as the ability to "Quickly update and manage menus across multiple sites, ensuring consistency and ease of control for site-wide menu adjustments". Keeping it as the engine of service is entirely reasonable. The question here is narrower, and it is yours to answer: which system holds the menu your guests actually read, and how fast does a change reach it?

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.