Square Recipes Limitations for a Coffee Shop

It is 7:40 on a Saturday, mid-rush. The ticket reads iced oat latte, extra shot. You pour the oat milk, pull two shots, cap it, slide it down the bar. Square logs the sale. What it does not log is the oat milk you just poured, even though you switched on Square Recipes last week specifically so it would.

That gap is not a glitch. It is exactly where the feature is built to stop.

What Square Recipes does, and the line it stops at

Square Recipes is Square's own answer to the ingredient question. You turn it on if you carry Square for Restaurants Plus or Premium, build a list of ingredients, attach a recipe to a menu item, and Square deducts that ingredient's stock every time the item sells. It works out a cost of goods and a margin per item along the way. For a shop that sells a fixed thing built a fixed way, that is genuinely useful.

Square publishes its own limits, plainly, in its support documentation (accessed July 24, 2026). Three of them decide whether the feature fits a cafe: it does not read modifiers, it does not work on items that carry variations, and it does not do batch recipes. Each one sounds like a footnote. In a specialty cafe, each one is a hole your consumption falls through. Here is where each stops, mapped to a scene behind your own bar.

Limit one: it cannot read your modifiers

Square's words, verbatim: "Modifiers don't track inventory or costs. Add-ons like extra cheese or sauce shots won't decrement ingredient stock or appear in recipe-level COGS."

Read that as a cafe owner and translate the examples. Extra cheese is your extra shot. A sauce shot is your pump of vanilla. And the big one Square does not even list: the milk swap. In a specialty shop the modifier is not a garnish on the drink. It is the drink.

Walk your own menu. The base item is "Latte." Whole milk lives in the recipe. Every oat, every almond, every extra shot, every large-instead-of-small rides in as a modifier on the ticket. So when a customer orders an iced oat latte with an extra shot, Square Recipes deducts the whole milk and the single shot from the base recipe and ignores the rest. The oat milk you actually poured never leaves the books. The second shot never leaves the grinder on paper.

Do the arithmetic to feel the size of it. Recipe costing starts from what a drink truly uses. Put a matcha latte at about 2 g of matcha and 12 oz of oat milk, round numbers to make the point, and a day of 47 of them works out to 94 g of matcha, 564 oz of oat milk, and 47 cups. Those per-drink amounts are an illustration, not your exact recipe, but the shape holds at any numbers you plug in. Now swap twelve of those drinks to whole milk at the register. The receipts are identical. The oat number should drop and the whole-milk number should rise, and a modifier-blind tool moves neither. Multiply that silence across every milk swap and every extra shot you ring up in a week, and the gap between what Recipes says is on the shelf and what is actually in the fridge widens every single day. That is the same sold-versus-used gap a register has by design, except now you have a tool that looks like it closed it and did not.

For most cafes this one limit is the end of the evaluation. If the money in your shop moves through milk and shots, a tracker that cannot see either is not tracking your shop.

Limit two: hot and iced are two items to it

Square's second limit: "Items with multiple variations (for example, Small, Medium, Large) can't have recipes."

A cafe lives on variations. Small and large. Hot and iced. Here and to go. However you built your Square catalog, the moment a menu item carries variations, Recipes stops attaching to it. That leaves two workarounds, and both cost you something.

Option one: flatten every variation into its own standalone item so each can hold a recipe. Two sizes times hot-or-iced is already four buttons for one drink, before milk even enters as a modifier that, per limit one, still does not track. Your baristas now hunt a wall of buttons during the rush, and you have rebuilt your entire catalog to feed the inventory tool instead of the counter.

Option two: leave the variations in place and accept that those items simply have no ingredient tracking at all. For a drink menu, that is most of the menu.

Either way, the useful information, the size and the temperature that change how much milk and ice and how many cups leave the shelf, is exactly the information the feature refuses to hold.

Limit three: no batch recipes

The third limit, in Square's words: "You can't create a recipe for an ingredient that itself has a recipe." No nested recipes, no batch prep. Square's guidance is to "model these as simple, one-level recipes."

Every cafe I know breaks this rule before 8 in the morning. You batch simple syrup on the stove. You cold brew a tank overnight. You pre-mix a matcha base, a chai concentrate, a Vietnamese coffee batch. Those are recipes that feed other recipes. A cup of simple syrup is sugar plus water made in advance; a drink then pulls an ounce of that syrup back out.

Tell a one-level tool about it and you are stuck. You either log the syrup as if it were a raw purchased ingredient, so the sugar and water it is made from never deplete, or you skip the batch entirely and the syrup pours into drinks off the books. Anything you prep in advance and portion into drinks, which is a real slice of a specialty menu, sits outside what Recipes can model.

Where Square Recipes is the right call

This is not a case that Square built something bad. It built something for a different shop, and for that shop it is the native, correct answer. Be honest about where that is.

If what you sell is what sits on the shelf, Recipes fits. A pastry case where a scone is a scone, a bottle program, a kitchen plating fixed dishes with no build-your-own step: those are finished goods with stable, one-level recipes and few modifiers, and Recipes handles them without a separate tool. No account manager, no migration, no second app to learn. If your menu genuinely does not move through modifiers and variations, turn it on and stop reading here.

The trouble is that a specialty coffee and matcha menu is the opposite shape. It is almost entirely variations and modifiers, and a meaningful part of it is batched in the back before service. The three limits are not edge cases for that shop. They are the middle of it.

Count the drinks Square Recipes cannot see

Before you decide, run one audit on your own menu. It takes about ten minutes and it settles the question with your numbers instead of mine.

Open your Square catalog and go line by line:

1. Count every drink that carries a variation: any size choice, any hot-or-iced split. Per limit two, Recipes cannot attach to a single one of them.
2. Of the drinks that are left, count how many go out with a milk swap or an extra shot on a normal day. Per limit one, the modifier part of every one of those is invisible.
3. Flag anything you batch in the back: syrups, cold brew, concentrates, a matcha or Vietnamese base. Per limit three, none of it models cleanly.

Add up the drinks touched by any of the three, and divide by your menu. That percentage is the share of your consumption Square Recipes is structurally blind to, straight from its own documentation. For a retail-forward shop it might be small. For a specialty cafe it is usually most of the board.

If the number is high, the fix is not a better tool living inside the same three limits. It is a layer that reads the whole ticket, modifiers and all, takes a count from your phone as the ground truth, and runs depletion off real sales in the days between counts. That is a different job than the one Recipes was built for, and it starts by connecting your Square sales to the ingredient math the register was never meant to carry.