How POS sales deduct stock automatically

Once your POS is connected, locations are mapped, products are synced, and your Blueprints (and Modifier Blueprints) are linked, Stash automatically pulls in your sales and updates your inventory. Here's exactly how that works — useful when you're troubleshooting, training your team, or just want to know what to expect.

The flow, step by step

A customer buys something at your POS. The cashier rings it up, the customer pays, the order is closed.
Stash pulls in new orders every 15 minutes. A scheduled sync runs in the background, fetches any newly closed orders from your POS, and processes them. This means inventory updates land within ~15 minutes of an order being closed — not instantly.
Stash matches each line on the order to a Blueprint or Modifier Blueprint. For every line, Stash looks up the POS product ID against linked Blueprints (and Modifier Blueprints) at the order's shop. If something is linked, its components get deducted. If nothing is linked, the line is skipped (logged with reason "no blueprint").
Stash calculates the deduction. For each component, Stash converts the recipe quantity into the inventory item's stocking unit (using "Each container contains" if the item is in packaging). Fractional results are kept as-is — no rounding.
Modifier swaps run as part of the same order. If a line matches a Modifier Blueprint with a swap configured, Stash deducts the modifier's components AND adds back the swap target — but only up to the amount that was actually deducted by a base Blueprint on the same order. See What is a Modifier Blueprint? for the full math.
Stash deducts inventory atomically. All of an order's deductions and swap reversals are written together. A transaction is logged for each affected item with a reference to the original POS order, marked as POS Sale.
Notifications fire. If any item dropped to or below its low stock threshold (or went negative), a notification is sent. See Managing notifications.

Important: when sync starts and what gets ingested

Stash never imports historical orders. The sync only picks up orders created after your POS was connected to Stash. This is by design — backfilling old orders would deduct inventory you've already adjusted manually and produce phantom shortages.

What this means for you:

Connect the POS before a busy day, not after.
Orders placed before connection time will never appear in Stash, even if you re-sync.
If you delete and recreate a connection, any orders placed during the gap are lost forever.

Blueprint timing — what gets deducted and what doesn't

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. Sync runs every 15 minutes, so:

Order at 11:38, Blueprint linked at 11:41, sync at 11:45 → Blueprint exists when sync runs, deduction happens. ✅
Order at 11:00, sync at 11:15 (no Blueprint yet), Blueprint linked at 11:30 → The order was already processed at 11:15 and marked "skipped (no blueprint)." Linking afterwards does not retroactively deduct it. ❌

Bottom line: orders processed by sync before the Blueprint existed stay un-deducted forever. Always create and link your Blueprints before sales start flowing.

Only closed orders deduct stock

Stash only processes orders that are in a finalized state (in most POS systems, called closed, completed, or paid). Open tickets, parked orders, draft orders, and tabs that are still being added to are ignored until they're closed.

This is why a sale you just rang up may not show in Stash for a few minutes — the order needs to close at the till AND wait for the next sync cycle.

Refunds, voids, and cancellations

Stash does not automatically reverse stock when you refund or void an order. Once a deduction is written, it stays.

If you refund a sale and need the stock to come back, you have two options:

Manual stock adjustment — open the inventory item, click Adjust stock, add the refunded quantity back, and add a note like Refund of POS order #1234. See Adjusting stock quantity manually.
Leave it — for low-value items where the manual reversal isn't worth the effort, the small variance will surface in your next stock count.

Automatic refund reversal is on our roadmap. Until it ships, the manual flow is the only path.

Each order is processed exactly once

Stash tracks which POS orders it has already processed by their unique order ID. Even if a sync re-fetches an order it has seen before, the deduction won't run twice. You can safely trust that a busy 15-minute window won't double-count anything.

The flip side: once an order has been processed (deducted, skipped, or errored), Stash will not re-process it. So if a Blueprint was missing or misconfigured at processing time, fixing it later doesn't retroactively deduct that order — only future orders use the new configuration.

What if the POS product isn't linked to a Blueprint or Modifier Blueprint?

The line is skipped, logged in the order's sync record with reason "no blueprint," and no inventory moves. Stash does not auto-match POS products to inventory items by name or SKU — every product that should deduct stock needs an explicit Blueprint or Modifier Blueprint linked to it (even simple 1-to-1 products like a bottle of water).

For products that intentionally shouldn't deduct anything (service charges, tips, bag fees), leaving them unlinked is fine — they'll just be skipped silently each time.

What gets skipped — and where to see why

Sometimes a line on an order doesn't deduct anything. The most common reasons:

The POS product isn't linked to a Blueprint or Modifier Blueprint
The Blueprint exists at a different shop than the POS location
The order was placed before the POS was connected
A component uses a unit that can't be converted to the inventory item's unit (no guess is made — the line is skipped)
The line is a refund or zero-quantity
A Modifier Blueprint's swap is skipped because no base Blueprint on the order deducted the swap target

Each processed order is logged in the POS sync log so you can see what was deducted, what was skipped, and why. If a sale didn't move stock, that's the first place to look.

What you see in Stash after a sale

Within ~15 minutes, the inventory item's quantity drops
The item's transaction history shows a new POS Sale entry attributed to Stash (not a specific user) with a reference to the POS order
If the new quantity is below threshold or has gone negative, a notification appears in the bell icon
The Order Planner and Dashboard KPIs update accordingly

What can break the flow

If sales aren't deducting, check these in order (most common first):

You're still within the 15-minute window since the sale closed — wait and check again
The order isn't actually closed in your POS yet (still open or parked)
The POS connection shows a warning on the Integrations page
The POS location isn't mapped to a Stash shop
The POS product isn't linked to any Blueprint or Modifier Blueprint
The Blueprint and POS product are at different shops
A component has a unit conversion problem
The order was synced before the Blueprint was linked (no retroactive deduction)

For the full diagnostic walkthrough, see Why my Blueprint isn't deducting stock.

Reliability

Sync runs every 15 minutes regardless of order volume
Each order is processed exactly once — no double deductions
Each order's deductions are written atomically — either everything in the order succeeds or nothing does
If a sync misses an order due to a temporary error, the next run picks it up
Inventory transaction history is immutable — once a transaction is written, it's preserved permanently for audit. Corrections happen via offsetting adjustments, never by editing history.