Sales coming through your POS but your Stash inventory isn't moving? Work through this checklist in order. Most cases resolve in the first three checks.

This article applies to both Blueprints and Modifier Blueprints — the diagnostic steps are the same. There's a separate section at the bottom for swap-specific issues on Modifier Blueprints.

Stash pulls in POS sales every 15 minutes. A sale you just rang up will not appear in Stash instantly. Before you start troubleshooting, confirm at least 15 minutes have passed since the order was closed at the till. If less time has passed, just wait — the next sync cycle will pick it up.

For the full sync model, see How POS sales deduct stock automatically.

Stash only processes orders in a finalized state — closed, completed, or paid depending on your POS. Open tickets, parked orders, draft orders, and tabs that haven't been settled don't deduct stock until they're closed at the till.

Check: Open the order in your POS. Confirm its status is closed/completed/paid.

Fix: Close the order in your POS. The next sync cycle will pick it up.

The most common cause. A Blueprint or Modifier Blueprint that exists but isn't linked to a POS product does nothing on sale.

Check: Open the Blueprint or Modifier Blueprint. Confirm the POS Product field is set.

Fix: Edit it, set the POS Product, save. See Linking a Blueprint to a POS product.

Blueprints and Modifier Blueprints are scoped to a single shop. If the POS sale happens at Le Koffee Marais but the Blueprint exists at Le Koffee Bastille, they won't connect — even if both have the same name and the same POS product ID.

Check: Open the Blueprint and confirm its location matches the shop the POS product was sold at.

Fix: Create a Blueprint at the correct shop. The clean pattern is one Blueprint per shop, even if the recipe is identical.

Even with a perfect link, deduction will fail silently if the math can't work — for example, if a component uses Gram but the inventory item is stored in Bag with no Each Bag contains filled in. Stash never guesses a conversion — if a unit conversion path doesn't exist, the line is skipped.

Check: Open the Blueprint or Modifier Blueprint. Look at each component row's deduction preview. Any warning ("Cannot convert," "Set content info," etc.) means that component won't deduct.

Fix:

If the connection is broken, sales aren't reaching Stash at all.

Check: Open Integrations. The POS connection should show in green/healthy state with a recent Last synced timestamp.

Fix: If the connection looks broken, click Resync. If that fails, disconnect and reconnect the POS. Note: reconnecting starts a fresh sync window — any orders during the disconnected period are lost. See Connecting your POS to Stash.

Stash never imports historical orders. The sync only ingests orders created after the POS connection was established. If you connected your POS yesterday and you're trying to find an order from the day before, it will never appear — even if you re-sync.

Check: Open the Integrations page. Note the connection's creation time. Confirm the order in question was placed after that.

Fix: Nothing — historical orders are off-limits by design. For inventory accuracy from before connection, do manual stock adjustments.

A deduction happens only if the Blueprint or Modifier Blueprint exists and is linked to the POS product at the moment the sync processes that order. If the order was synced before the Blueprint existed, it was marked "skipped (no blueprint)" — and creating it afterwards does NOT retroactively deduct that order.

Each order is processed exactly once. Once skipped, it stays skipped. Only future orders use the new Blueprint.

Check: Compare the timestamp of the order in your POS to the creation time of the Blueprint or Modifier Blueprint. If it was created (or linked to a different POS product) after the order was synced, that order won't deduct.

Fix: Create and link Blueprints before sales flow in. For inventory drift caused by missing Blueprints during a launch period, do a manual stock adjustment to correct.

Each POS connection is tied to either a sandbox or production environment. Sandbox connections only see test orders. Production connections only see real orders.

Check: Open the connection details on the Integrations page. Confirm the environment matches what you're testing.

Fix: If you're testing, make sure you're on a sandbox connection. If you're live, make sure you're on production.

A Modifier Blueprint's swap (the "What this swaps out" item) only fires when a base Blueprint in the same order actually deducted the swap target. This is by design — it prevents adding phantom inventory from nowhere.

So if you set up an Oat Milk Modifier Blueprint that swaps Cow Milk, but no other line on the order actually deducted Cow Milk, the swap is skipped. Common causes:

Fix: Make sure your base Blueprints exist and use the same inventory item that the Modifier Blueprint is trying to swap.

The swap is capped at the actual amount deducted by the base Blueprint. So if a customer orders 1 Latte (deducts 200ml cow milk) with 2 Oat Milk modifiers (each requesting to swap 200ml back = 400ml total), the swap caps at 200ml. The remaining 200ml of "would-be reversed" cow milk is dropped — because there was nothing to reverse.

This is correct behavior. Without the cap, your Cow Milk inventory would silently grow every time a customer doubled up on modifiers. See What is a Modifier Blueprint? for the full math.

If you have multiple POS locations and one isn't mapped to a Stash shop, sales from that POS location have nowhere to land.

Check: Open Integrations and look at the location mapping. All POS locations should map to a Stash shop. See Mapping POS locations to Stash shops.

If you added a product to your POS catalog after the last sync, Stash doesn't know about it. The sale comes in but Stash can't find a matching product.

Check: Open Integrations. Click Sync now on the POS connection to refresh the catalog.

If your Blueprint Makes 100 but you meant Makes 1, deductions are 100x smaller than they should be — so small you might not notice them. The component deduction is calculated as component_quantity × (sold_qty ÷ Makes).

Check: Open the Blueprint. Look at the Makes value. For most products it should be 1.

Refund lines, return lines, and zero-quantity lines are skipped by the sync — they don't deduct (and they don't reverse previous deductions either). If your sync log shows lines as skipped with these reasons, that's expected behavior.

Stash does not automatically reverse stock when you refund or void an order in your POS. Once a deduction is written, it stays. To restore stock from a refund, do a manual adjustment with a note referencing the refunded order. See Adjusting stock quantity manually.

Square modifiers are currently not exposed in the order feed Stash receives. A "Latte with Oat Milk" sale shows up as a Latte only — the Oat Milk modifier is dropped before it reaches Stash, so any Modifier Blueprint linked to it won't fire. See the Square modifier limitation in Connecting Square POS for workarounds.

Every order Stash processes is logged with what was deducted, what was skipped, and why. Each line of an order has one of these outcomes:

If a sale didn't move stock, this is the first place to look — it tells you exactly why.

Get in touch via the chat icon. Send the POS product name, the Blueprint or Modifier Blueprint name, the shop, and the timestamp of a test sale. We'll trace it end-to-end.