On July 1, 2026, Florida's SB 606 took effect. Any automatic charge a restaurant adds — service charge, automatic gratuity, credit card surcharge, delivery fee — must now be disclosed with its amount or percentage and its purpose on the menu, in written contracts, and on any website or app where orders are placed. Receipts must break out gratuity, the operations charge, and sales tax on separate lines. Florida's Department of Business and Professional Regulation issued an advisory on June 26, 2026, telling operators to update menus, POS templates, and online ordering pages, and specifying that disclosure text must be no smaller than the menu item descriptions.
Read that list again and notice what it actually is. Not a legal instruction, a configuration spec, for your POS, your online ordering page, your app, your receipt template, and every third-party menu you publish.
That is the part most coverage of these laws misses. The compliance question is easy to answer and hard to implement, because the answer lives in six systems that were never designed to agree with each other.
The most important thing to understand about the 2026 landscape is that these laws do not point in the same direction. They split into two camps, and each camp requires mutually incompatible menu configurations.
All-in pricing. The advertised price must already contain every mandatory fee. Massachusetts went this way: its regulations, effective September 2, 2025, require the total price — including all mandatory fees — to be disclosed clearly and prominently at the time of initial presentation. Illinois' HB 228, signed June 25, 2026 and effective January 1, 2027, makes it unlawful for any business to advertise, display, or offer a price that does not include all mandatory fees or surcharges before taxes.
Disclosure alongside. The fee may stay separate from the item price, but must be disclosed clearly and conspicuously wherever prices appear. California took this route for food service: SB 478 established all-in pricing statewide, then SB 1524 carved restaurants, bars, food concessions, grocery stores, and grocery delivery back out, on condition the fee is clearly and conspicuously displayed with an explanation of its purpose wherever the item's price appears. Florida's SB 606 is a disclosure regime too — it does not ban the fees; it requires clear disclosure before the customer commits. Colorado's Protections Against Deceptive Pricing Practices law, effective January 1, 2026, requires disclosure of the existence, amount, and purpose of any mandatory service charge, plus an explanation of how it's distributed.
Why this matters operationally: under an all-in regime, a $16 burger with a 3% kitchen fee displays as $16.48. Under a disclosure regime, it displays as $16 with a conspicuous note explaining the charge and where it goes. Two different values in the price field for the same SKU. Operate in both states, and you cannot have one menu record.
Connecticut, Virginia, New York City, and others are in motion with their own versions. Treat this as a snapshot, not a reference.
Illinois is the one to watch, and it isn't settled.
The headline on HB 228 reads as a clean all-in mandate, and several trade write-ups report it that way. But the statute carries modified compliance requirements for food service establishments: reading the act, Arnall Golden Gregory noted that neither retail mercantile nor food service establishments must provide the total price within the display price, and both may disclose additional required fees later in the sales process, before purchase is final. Kelley Drye's reading is consistent; the law provides separate specific compliance requirements for food delivery platforms, food or beverage service establishments, and auctions.
So two defensible readings of what an Illinois restaurant must do on January 1, 2027, lead to opposite configurations. The Attorney General enforces it, with civil penalties up to $50,000 per violation and no private right of action. If you operate in Illinois, take this to counsel now, not in December. If you sell POS or middleware to Illinois operators, build a switch rather than a hardcoded behavior.
Take one menu item at one location and count the surfaces where its price appears: the printed menu, the POS screen and check, the receipt template, your website's ordering page, your app, your DoorDash listing, your Uber Eats listing, your Grubhub listing, your Google Business Profile, and any AI assistant reading your catalog.
Florida's statute reaches most of these by name — menus, written contracts, and any website or mobile application where orders are placed. It doesn't stop at your property line.
Add a second location in another state and the item's correct presentation forks. Add a third, and it forks again. A ten-unit group across three states with four fees isn't managing four disclosures. It's managing a matrix, and every cell is a place to get it wrong.
Three failure modes recur:
Drift. The fee is updated in the POS and not in marketplace menus, because those are maintained separately and often by different people. Now your DoorDash listing discloses 3% when the charge is 4%.
Channel blindness. Operators treat this as a dining-room problem, update printed menus and POS, and forget the statute explicitly names apps and websites. Third-party marketplace menus are the most commonly missed surface, because the restaurant doesn't think of them as its own menu.
Template lag. Receipt formatting is the last thing anyone touches, and Florida's requirement is specific: gratuity, operations charge, and sales tax on separate lines. A template lumping "fees & taxes" into one line fails regardless of how good the menu disclosure is.
None of these is a legal failure. In every case, the operator knew the rule. The configuration just didn't reach every surface.
Which is why the multi-state instinct doesn't work. Faced with eight states, the reflex is to find the strictest rule and apply it everywhere. Here that misfires. All-in pricing hides less, but adopting it everywhere makes your Florida and California prices visibly rise against competitors who kept fees separate, and in California the entire point of the SB 1524 carve-out was to preserve a service-charge model that funds front-of-house and back-of-house wage equity. Folding it in has real consequences for how that compensation is structured.
The workable answer is to standardize the data model, not the display. One menu record per item. One fee registry. A location-level attribute determining presentation. One sync path to every channel. Then a rule change in one state is a configuration change, not a project — the difference between being able to respond to Illinois in December and not being able to.
Before touching any system, list every automatic charge you apply, anywhere. Most operators find two or three they had forgotten. For each:
- Name as displayed to the guest — "kitchen appreciation fee," "wellness surcharge," whatever it actually says
- Amount or percentage, flat or calculated
- Trigger — always, parties over six, delivery only, card payments only
- Stated purpose, since several states require it
- Distribution — wages, tips, or neither, which carries wage-and-hour consequences separate from disclosure, and which Colorado requires you to explain
- Locations applying it, and therefore the governing regime
- Channels it appears on, especially anywhere it appears inconsistently
- Who can change it, in which system, and how long propagation takes
That last row predicts whether you stay compliant. If changing a disclosure requires four people editing four systems, you'll be out of sync within a quarter.
Then, per channel:
POS. The fee needs to exist as a discrete, named, itemizable object — not a percentage bolted on at tender. Receipt templates need separate lines for gratuity, operations charges, and tax. If your POS applies fees only at check level, you may not be able to satisfy item-level disclosure at all.
Your own site and app. Disclosure goes where the price is, not in a footer or a terms link. Florida's rule that notice font be no smaller than menu item descriptions is a useful general benchmark: if the fee text is visually subordinate to the price, assume it isn't conspicuous. In an all-in state, disclosure isn't the question — the displayed number itself has to change.
Third-party marketplaces. The hardest surface, because you control it least. Each platform has its own fee fields, display logic, and menu sync. If those menus are maintained by hand or through each platform's dashboard, nothing guarantees the disclosure survives the next update. This is where middleware stops being convenience and becomes the control point.
Printed menus. Cheapest to fix, easiest to forget when a fee changes mid-year.
For vendors and resellers, this is a roadmap item that will arrive whether you plan for it or not. Your multi-state customers are about to discover their menu tooling assumes a single correct price per item. They will all ask the same question within twelve months, and the vendor with an answer wins the renewal.
Having an answer looks like: fees as first-class objects with name, amount, purpose, distribution and trigger as structured fields rather than free text; location-level presentation rules deciding whether a fee folds into price or displays alongside it; disclosure text propagating through the same sync as the menu so it cannot drift; receipt templates with itemized fee lines as a configurable default; and an audit trail, because when a state AG asks what a guest saw on a given date, someone has to answer.
The federal layer is moving too, and it lands on the same architecture. The FTC issued an advance notice of proposed rulemaking on April 16, 2026, asking whether a rule is needed on unfair or deceptive fees in online food and grocery delivery, and stating that delivery platforms are among the most significant sources of drip pricing. On May 18, 2026, a bipartisan coalition of sixteen state attorneys general led by New York and Tennessee urged the FTC to extend its Unfair or Deceptive Fees Rule to food delivery platforms, asking for total cost displayed at each stage of ordering, accurate descriptions of each fee's purpose and calculation, disclosure of markups over in-store prices, and disclosure of personalized pricing.
Two of those asks land on restaurants rather than platforms. Markup disclosure makes the gap between your dine-in and delivery prices visible to the guest. Price consistency across channels stops being a marketing choice and becomes a disclosure obligation. If that rulemaking advances, the question shifts from "is each channel compliant" to "can you explain why these channels disagree", which is, again, a data question.
For twenty years, menu management was an operations convenience: fewer typos, faster updates, one less thing to chase. That framing is out of date.
Menu data is now the substrate on which a growing body of consumer protection law operates. The statutes are written in terms of what the guest sees at the moment of the price, and what the guest sees is output from your menu configuration, rendered across a dozen surfaces you may or may not control.
Restaurants that treat pricing compliance as a legal review will keep getting surprised, because the review will be correct and the implementation will drift. The ones that treat it as data architecture will absorb the next state law in an afternoon.
KitchenHub's menu management and integrations exist for exactly that: one structured menu with fees as real fields, propagated live to your POS, your own ordering channels and every marketplace you publish to, so what the guest sees is what you configured, on every surface, in every state.
This article is for general information and is not legal advice. Fee disclosure laws vary by state and are changing quickly; consult qualified counsel about your specific operations.
