Written by
Nomni
The ultimate hospo solution
From 1 July 2026, every hospitality business in Australia that serves seafood must tell customers where that seafood comes from before they order. If you run a single menu in one venue, that is a rewrite. If you run several menus across several venues, the hard part is not writing the label. It is making the same change everywhere a customer might see it, and keeping it right when a supplier or a season shifts a dish from Australian to imported. On Nomni's Enterprise Management System (EMS), that is one change made once at the head office, then published across your Nomni channels together.
What changed on 1 July 2026?
Australian Consumer Law now requires seafood origin to be disclosed on menus using the AIM model: A for Australian, I for imported, or M for mixed. The rule covers any business serving seafood for immediate consumption, which includes dine-in, takeaway and home delivery, and it reaches restaurants, cafes, pubs, clubs, hotels and food trucks alike.
There is no small-business exemption.
If seafood is on the menu, the rule applies, whether you are one cafe or a national group.
The label has to be in writing, clear and legible, and visible before the customer orders. You can use the single letters with a legend, or the full words Australian, imported and mixed. Businesses also need to keep origin records for at least three months after a dish was last available, and the standard is enforced under the ACL by the ACCC together with state and territory regulators. Penalties for getting it wrong can be significant. Because the origin sits in the wording of each dish, this is really a menu-content task, which is exactly the kind of change EMS is built to make once and apply everywhere.
Where does the seafood origin label have to appear?
Anywhere a customer decides what to order. That means printed menus, chalkboards, digital and QR menus, your online ordering page, in-venue menu boards, and third-party delivery listings. The label has to be there before the order is placed, not on the receipt afterwards.
This is where the work multiplies for multi-channel operators. The same dish can appear on a printed menu, a kiosk, an online ordering page, an app and a delivery platform, and each one has to carry the same correct letter. On Nomni, the A/I/M origin lives in the centrally-managed item description or product label, the same fields you already use to describe a dish. Set the origin on the item once at HQ, and it reads through to every Nomni surface that shows that description, rather than being retyped on each one.
How do you keep the label consistent across every menu and venue?
You manage the dish once, centrally, and let EMS carry it. This is the "write once, publish anywhere" model behind Nomni's centralised menu management: one master menu at head office, applied to any location with a few clicks, with location-specific changes still possible where you need them. Site Groups let you cluster venues that share a menu or supply chain, so a change can target the venues it applies to without touching the rest.
When you set or update the origin on an item and publish, it flows across your Nomni channels: Nomni POS, Nomni Online Ordering, the Self-Ordering Kiosk, table ordering and the Magic App. One correction, not fifty.
Third-party delivery platforms sit slightly outside that loop. Because delivery menus sync through a middleware layer rather than reading your live menu directly, the update reaches them on publish rather than the instant you save it, and it is worth confirming the change has pushed through to each platform. It is still one edit at your end, but delivery is the one place to double-check, since it is also squarely in scope for the new rule.
Do you have to learn a new system to do this?
No. If you already run your menu on Nomni One, adding seafood origin is the same central workflow you use to update a description, a price or a dietary note. You are editing the item once at the head office and publishing, not learning a new tool. The A/I/M label goes in the item description or on the product label, alongside the detail that is already there, and travels the same way the rest of your menu content does.
That is the real point behind a rule like this. On a fragmented stack, a new compliance requirement lands as cost and risk: the manual updates, the channels that fall out of step, the venue that misses the memo. On one connected system, it lands as a short job you do once. Seafood labelling is not the reason to bring your menu onto one platform. It is a clean, current example of why it pays off when you already have.
Further reading
