Your Square sale records that the customer asked for oat milk. In many setups the milk count still drops as if they got whole. That mismatch is the modifier gap: the POS knows what was sold, and nothing downstream knows what the sale actually used. Below is the gap worked out on 50 lattes, the workarounds, and what an ingredient layer has to do to close it.
I run Stella Coffee, so this is written from the owner's side of the counter. Every figure in this post is an example I made up to show the arithmetic. None of them come from our books.
What a POS tracks, and where it stops
A Square sale line is built from an item variation (say, "Latte, 12 oz") plus any modifiers the barista tapped: oat milk, extra shot, vanilla. In most POS systems, stock tracking attaches to the item or variation. That is a sensible design for retail, where one scan removes one unit of one thing.
A latte is a different kind of sale. It is 18 g of espresso, 9 fl oz of milk, a cup, a lid and a sleeve. The sale line tells you a latte left the building. It doesn't say how much of each ingredient went with it, unless something converts the sale into ingredients.
Square has recipe and ingredient features, and what they cover changes over time. I'm not going to audit them in full, because a summary written today will be stale in a few months, so the paragraph below is dated. The more reliable evidence is the one-latte test later in this post, which is how you find out what your setup deducts today.
As of 2026-10-13, per Square's help page "Track ingredient costs with Square Recipes" (squareup.com/help/us/en/article/8629-beta-track-ingredient-costs-with-square-recipes), Square Recipes is a beta for Square for Restaurants Plus and Premium subscribers. When a menu item with a recipe sells, Square reduces the ingredient stock. The same page says that modifiers don't track inventory or costs, that items with multiple variations can't have recipes, and that there are no recipes of recipes. Square labels the feature a beta that may change, so check the page again before you rely on any of this. A fuller comparison, with Square's plan prices, is on Square's own inventory vs the MarketMan add-on vs ShelfCount.
The oat swap, worked on 50 lattes
Take a 12 oz latte with a recipe of 9 fl oz of milk. Say 50 are sold in a day: 30 with whole milk and 20 with an oat swap. Whole milk is $3.60 a gallon (128 fl oz) and oat milk is $4.50 for a 32 fl oz carton. All of these are example numbers.
Cost per fluid ounce:
- Whole milk: $3.60 / 128 = $0.028125
- Oat milk: $4.50 / 32 = $0.140625
If every latte is deducted as whole milk, the system believes you used:
- 50 x 9 fl oz = 450 fl oz of whole milk, which is 3.52 gallons
- Milk cost it books: 450 x $0.028125 = $12.66
What actually left the fridge:
- Whole: 30 x 9 = 270 fl oz (2.11 gallons), costing 270 x $0.028125 = $7.59
- Oat: 20 x 9 = 180 fl oz (5.6 cartons), costing 180 x $0.140625 = $25.31
- Total: $32.91
The gap on one day of one drink is $32.91 - $12.66 = $20.25. Per swapped latte that is $1.01, because oat costs $0.1125 more per ounce and the recipe uses 9 ounces of it. If the menu charges a flat $0.75 for the swap, you lose margin on every one of them and the books never show it.
There is a second error inside the first, and it is in the count. The system thinks you burned 1.4 gallons more whole milk than you did and 5.6 fewer cartons of oat. A few days later the oat shelf is empty while the app says you have plenty. That is a par level problem caused by a data problem.
The one-latte test: what your POS deducts today
Ring one latte with an oat swap, then check what your inventory says moved. If whole milk dropped and oat didn't, that is your gap. If oat dropped and whole milk didn't, your setup already handles the swap and you can skip ahead. The test is how you find out, and it takes two minutes.
Sizes: variations or modifiers
A cafe with three sizes has two ways to model them, and the two behave differently for inventory.
Sizes as variations. "Latte 12 oz," "Latte 16 oz" and "Latte 20 oz" are separate variations. Each can carry its own recipe: 9, 12 and 15 fl oz of milk, say. This is the cleaner model for costing, since the size drives the quantity and the sale line already says which one was sold.
Sizes as modifiers. One latte item with a size modifier list. The menu is shorter, but the base recipe is one size and every other size is an adjustment on top of it.
I prefer variations for size and modifiers for anything that swaps or adds an ingredient. A size changes every ingredient in proportion: milk, espresso grams, cup, lid. A milk swap changes one ingredient. They are different jobs, and a good ingredient layer handles them differently. In ShelfCount the recipe lives on the variation, and the mapping screen is where you point each variation at its recipe once.
House-made syrups and cold brew
The next place stock tracking breaks is anything you make in-house. Vanilla syrup starts as sugar and vanilla that you buy, make into a batch, and pump into drinks.
Example batch: 1 kg of sugar at $1.30 per kg, plus 15 mL of vanilla extract at $0.50 per mL ($7.50), yielding 1,500 mL of syrup.
- Batch cost: $1.30 + $7.50 = $8.80
- Cost per mL: $8.80 / 1,500 = $0.005867
- One 30 mL pump: 30 x $0.005867 = $0.18
If your POS only knows the syrup as an item, it never sees the sugar and extract go down, and it can't relate a vanilla latte to either. You need a prep recipe: sugar and extract in, syrup out, drinks drawing on the syrup. Cold brew concentrate works the same way, with grounds and water in and a yield in liters out.
ShelfCount calls these prep recipes, and the cost of a latte rolls up through them. When sugar goes up in price, the syrup cost and every drink using it update together. The recipe cost calculator walks through the same layering by hand if you want to cost one drink before you commit to anything.
Workarounds inside Square, and what they cost
Before you buy anything, here is what people do with the POS alone.
- One variation per combination. Latte x 3 sizes x 5 milks x hot or iced is 30 variations, and a 12-drink menu is 360. Stock tracking works, but ringing a drink means scrolling a wall of buttons, and adding a sixth milk means creating 72 more variations.
- Count and estimate. Skip per-sale tracking, count the milk weekly and estimate usage from that. It is cheap, and it works until you want to know why milk cost jumped.
- Export and reconcile in a spreadsheet. Export sales with modifiers every week and multiply by recipe quantities in a sheet. This is accurate if you do it. If it takes an hour a week, that is 52 hours a year, and the sheet breaks the first time someone renames a modifier. I compare that path with a purpose-built tool on the spreadsheets comparison page.
None of these is wrong. The question is which cost you would rather pay: menu complexity, estimate error, or weekly admin.
What an ingredient layer has to do
Whatever you use, I think it has to do five things, and you can hold any tool to this list.
- Map each sellable item to a recipe once. One mapping per item, done once.
- Apply modifier effects. Every modifier gets one of a few behaviors: add an ingredient (extra shot), replace one (oat for whole), change a quantity (light ice), change packaging (large cup), or do nothing to cost (hot versus iced, if the recipe is the same).
- Cost through prep recipes. Syrups, doughs and concentrates roll up into the drinks that use them.
- Convert units safely. Fluid ounces to gallons is easy. Milliliters to grams needs a per-item density, and a tool should stop and tell you when it is missing instead of guessing.
- Freeze the cost at the time of sale. When oat milk goes from $4.50 to $4.90, last Tuesday's lattes shouldn't change.
In ShelfCount the modifier effects are add, replace, change quantity and change packaging, plus "no cost impact", all set on one page. Sales sync from the POS, each line resolves through its recipe and modifiers, and the result lands in the theoretical usage for each ingredient. The setup steps are in the mapping your menu guide and the recipe building guide.
The same gap on Toast and Clover
Toast and Clover both record modifiers on each order line, as far as I can tell from their developer docs (check those for the current shape), and neither one is a recipe system.
- Toast's order data can nest modifiers (check Toast's API docs). ShelfCount's reader is built to walk nested modifiers, but it is not yet verified against live Toast data. Toast is built and waiting on partner approval, so it isn't open to everyone yet. The Toast integration guide says what is live.
- Clover attaches modifier groups to items and a sale line lists the chosen modifiers (check Clover's developer docs). ShelfCount connects with a Clover dashboard API token today, and Clover App Market approval is pending. The Clover guide covers the connection.
- Square connects with an access token you create in your Square dashboard. ShelfCount reads sales, catalog and locations and never writes to Square. Read-only OAuth is on the roadmap. The Square guide has the details.
The modifier problem follows you if you change POS. If you are considering a switch, or run one shop on Square and another on Clover, an ingredient layer that reads all three keeps your recipes and costs in one place.
Try it on one drink
You don't need to model your whole menu to find out how big your gap is. Pick the drink you sell most. Write its recipe in grams and fluid ounces, rerun the oat example above with your own prices, and see what a day of swaps costs you.
If the number is small, you have your answer and a few hours back. If it isn't, ShelfCount is $50 a month flat, 14-day trial; see pricing for terms. The demo loads a cafe so you can see modifier effects before you connect anything.