Square Variations Not Tracking Inventory: A Fix

The count that never moved

You sold 60 drinks on Saturday. Monday morning you open the item in Square, and the stock count sitting next to the small size is the same number it was on Friday. Not off by a few. Identical, like the weekend never happened.

Then you check the forum threads, because that is where this question lives. Every one of them is a different owner asking the same thing about variations and stock, and the replies are a scatter of workarounds. So here is the ordered version, four checks, from the one that fixes it most often to the one nobody mentions. Run them in order and stop at the first one that explains what you are seeing.

Check one: tracking is a switch per variation, not per item

The first thing to know is that Square has two switches here, not one, and turning on the obvious one does not turn on the other.

At the item level there is "Track stock," which enables inventory tracking for that item. Underneath, in the Variations section, each variation has its own switch: Square's instruction is to "toggle on Advanced Stock Tracking to set stock counts at the variation level" (Square support article 8331, accessed September 2, 2026).

So the failure mode is an item that reads as tracked while some of its variations were never switched on, or were added later and never picked it up. An untracked variation does not warn you. It sells all day and reports a stock figure that simply never moves, which looks exactly like a broken integration and is not one.

Open the item, expand every variation, and confirm each one individually. If one was dark, that is your answer, and the count starts moving on the next sale. Note that it does not backfill: everything sold while it was off is gone from the record, so recount that item by hand before you trust the number again.

Check two: variations do not share one pool of stock

The second check is the one that surprises people, because it is a structural rule rather than a setting.

Owners reach for variations expecting them to draw down a shared supply. Sixteen ounce and twenty ounce both pour from the same jug, so the natural assumption is that Square holds one quantity and both sizes eat into it. It does not work that way. Stock lives on the variation. Two variations of one item are two separate counts that know nothing about each other.

The community answer to this, from a Square Champion in a thread about variations pulling from the same stock, is blunt about the boundary: "If you have Item Burger with Variation Single Double and Triple this may not work. If you have Items Single Burger, Item Double Burger, Item Triple Burger this would work" (Square Seller Community thread 774515, accessed September 2, 2026). The recommended route is Bundles, where each bundle names its component quantities, so a double deducts two patties. It works, and the noted cost is that a customer cannot substitute components at the register once the bundle is built. For a burger that is a fair trade. For a drink whose whole point is that people substitute the milk, it is the wrong shape.

If what you were expecting is one number that goes down whether the small or the large sells, variations were never going to give it to you. Nothing is broken. The model is.

Check three: a recipe will not attach to a variation at all

The third check applies if you turned on Square Recipes hoping to track the ingredients rather than the finished drink.

Square's documented limit: "Items with multiple variations (for example, Small, Medium, Large) can't have recipes" (Square support article 8629, accessed September 2, 2026). Not a partial attach, not a warning. The recipe layer skips those items entirely.

For a drink menu that is most of the menu, because most drinks carry a size or a hot and iced split. So the ingredient tracking you switched on last week is quietly running on the short list of items that have no variations, which in a cafe is usually the pastry case and the retail shelf. The full set of places Square Recipes stops for a cafe is worth reading before you spend a weekend building recipes it will not use.

The catalog trap I walked into myself

The fourth one is not in any help article. I hit it in my own shop this summer and it cost me two days of confusion.

I added two new drinks to the menu. Rather than create standalone items, I built them the tidy way: as variations on an item that already existed. Clean catalog, one button, two options underneath. Then I ran the sync that reads my Square catalog into my ingredient math, and the new drinks did not appear. Not an error, no failed job. The sync saw the parent item, which it already knew about, and never saw that anything had changed underneath it.

That is the trap: a catalog read that walks the item list can be perfectly successful and completely blind to what you added, because what you added was not an item. Anything downstream of your catalog, an inventory tool, a menu display, a reporting sheet, may only be looking at the item layer. The variation you created is a child record, and a child record only shows up if something went looking one level down.

The check takes a minute. After you add anything to the menu, open whatever reads your catalog and confirm the new thing is listed there by name. If it is not, you have not added a drink to your system, you have added a row inside a drink. I now build genuinely new drinks as their own items and reserve variations for sizes of a drink that already exists.

What I run instead

After all four checks, the honest summary is that Square's variation stock is built to count sellable things, and it counts them well when the thing that sells is the thing on the shelf. A bag of beans in three sizes, three variations, three counts, correct. That is finished goods, which is what a register was built for.

A drink is not a finished good. What left your shelves when a large iced oat latte sold was milk, matcha or espresso, a cup, a lid, and a straw, and none of those are the variation. So chasing accurate variation counts on drinks is work spent on the wrong unit. The number you actually order against is the ingredient one.

What I run now is the split that respects both. Square keeps variation stock on the retail side, the bags and the bottles and the cans, where its counting is exact and the reorder alert is genuinely useful. The drink side runs on ingredients instead: a physical count from a phone, 58 items in about 8.5 minutes on our last full one, plus depletion computed from every ticket with its modifiers read, so the days between counts are covered. Sales tell me what was used, the count tells me what is there, and the difference is the waste I would otherwise never see. That connection, and what changes once it exists, is laid out in connecting Square sales to the ingredient math.

Before you rebuild anything, run check one tonight on the item that started this. Open it, expand every variation, and look at how many of them were never switched on. Most of the time this ends there.