Stock and availability
Safety stock per channel: the last unit is sold once
Each sales channel gets its own number: the free quantity minus that channel's buffer, calculated per item group from how fast the item sells and how old the channel's count can be. We set those rules in one place, apply them on every run and show which items the buffer holds at zero.
One word, two numbers
Safety stock means one thing in the ERP and another in the store. In NetSuite the item record carries safetystocklevel, a quantity, or safetystockleveldays, a number of days of supply. NetSuite's own description: the amount of an item you prefer to keep in stock at all times, used to calculate the reorder point. Business Central has a Safety Stock Quantity on the item for the same purpose: the planning system suggests a supply order when projected inventory falls below it. Both are purchasing numbers. They say when to buy, and nothing about what a customer may order.
In the store a buffer is the number of units a channel sees less than what is free. Shopify has a state for it, safety_stock: units that are on hand and set aside to guard against overselling.
An integration that copies one into the other makes an error that raises no alarm. Item 00123456 has a NetSuite safety stock level of 40, set for a 10-day lead time. Sent to the store as a buffer, the store shows 96 minus 40, which is 56, and shows zero as soon as 40 units are free.
The number of settings grows with the channels. One store with 200 items can live with one flat buffer. 4,000 items on three channels are 12,000 combinations of item and channel, and nobody sets those one by one. They become rules per item group and per channel, and the integration does the arithmetic. What counts as free stock is on the stock and availability page; this page covers the rules.
How it works
The integration calculates per channel: free quantity minus that channel's buffer, then the threshold. The result is never below zero. Take item 00123456 in the Reno warehouse:
on hand 120
committed (open orders) -18
quality control -4
damaged -2
free 96
web store, buffer 6 90
marketplace, buffer 9 87
wholesale portal, 0 96
How large the buffer is
A buffer covers what other channels sell between two updates of this one. The sum is units sold per hour times the minutes the channel can be behind, divided by 60.
| Item group | Peak sales | Channel behind by | Buffer |
|---|---|---|---|
| Fast movers | 36 an hour | 5 min, plus one missed update | 36 x 10 / 60 = 6 |
| Fast movers on a 15-minute feed | 36 an hour | 15 min | 36 x 15 / 60 = 9 |
| Middle group | 2 an hour | 10 min | 0.33, rounded up to 1 for count errors |
| Slow movers | 1 a week | 10 min | 0 |
| Supplier stock | unknown | 12 hours | threshold 3 instead of a buffer |
When the update goes out within seconds of each order, the time behind shrinks and so does the buffer. When the source sends no event and the integration polls every 15 minutes, the fast movers on the web store need 9 as well.
Buffer or threshold
A buffer subtracts a fixed number. A threshold sets everything below a number to zero and leaves the rest alone.
| Free | Buffer 6 | Threshold 3 |
|---|---|---|
| 96 | 90 | 96 |
| 10 | 4 | 10 |
| 3 | 0 | 3 |
| 2 | 0 | 0 |
| 1 | 0 | 0 |
A buffer belongs to stock you count yourself. A threshold belongs to stock someone else reports. A supplier that sends a file twice a day with 2 units may have sold those 2 before the file arrives. At 400 units the age of the file does not matter, so nothing is subtracted. How supplier stock sits next to your own count is on supplier feeds.
Where the buffer goes in Shopify
Shopify keeps the buffer inside on hand. Moving 6 units from available to safety_stock keeps on hand at 120 and shows the 6 as Unavailable in the admin, so the warehouse can see where they went:
{
"input": {
"reason": "safety_stock",
"referenceDocumentUri": "gid://erp-connector/BufferRule/fast-movers",
"changes": [{
"inventoryItemId": "gid://shopify/InventoryItem/30322695",
"quantity": 6,
"from": { "locationId": "gid://shopify/Location/124656943",
"name": "available", "changeFromQuantity": 96 },
"to": { "locationId": "gid://shopify/Location/124656943",
"name": "safety_stock", "changeFromQuantity": 0,
"ledgerDocumentUri": "gid://erp-connector/Buffer/00123456-reno" }
}]
}
}
changeFromQuantity makes the move fail with CHANGE_FROM_QUANTITY_STALE when an order changed the count in between, and the integration recalculates. Since API version 2026-04 inventoryMoveQuantities also requires an idempotency key. Two consequences of this model: the safety_stock state is per location, so it applies to every channel that sells from that location, and Shopify sends no webhook when safety_stock changes. A different buffer for a marketplace is calculated in the integration and written to that marketplace's feed.
Low stock goes first
The risk of an oversell sits with items that are nearly gone. When 300 quantities changed in a run, the items with, for example, 5 or fewer free go to the channels first. An item that moves from 240 to 234 can wait a few seconds. An item that moves from 3 to 1 cannot.
What goes wrong quietly
None of these raises an error. The run succeeds and the channel shows a number.
| What happens | Example | Result |
|---|---|---|
| ERP safety stock becomes the channel buffer | safetystocklevel 40 subtracted from 96 |
56 in the store, zero at 40 free |
| The buffer is subtracted twice | the integration writes 90 and Shopify also holds 6 in safety_stock |
the store sells 84; the real buffer is 12 |
| The sum goes below zero | 1 free minus buffer 6 | without a floor, minus 5 goes to the channel; the integration writes 0 |
| One buffer for every item | buffer 5 on a catalog where 1,300 of 4,000 items have 5 or fewer free | 1,300 items, 32.5% of the catalog, at zero on every channel |
| Buffer on the kit and on its parts | kit of 2 A and 1 B, all three with buffer 2 | the kit drops further than the rule intends |
| Buffer on a location that should not count | showroom with 10 units, buffer 2 | 8 units counted that should be 0 |
The second row appears when an existing integration is replaced. The old setting stays in the store and the new integration subtracts again. The first run therefore lists, per channel, where the buffer is subtracted, and that is one place. Kits are covered on kits and bundles, locations on multi-location inventory.
What it covers
- A buffer per channel. The web store sees 90, the marketplace 87, the wholesale portal 96, from the same 96 free.
- A rule per item group. Fast movers buffer 6, slow movers 0, clearance always down to the last unit.
- A threshold per supplier. Everything under 3 units in supplier A's file goes through as zero.
- Temporary exceptions with an end date. Buffer 12 on one item through December 31, 2026, then the group rule applies again without anyone resetting it.
- The cost of the buffer in view. After each run: how many items the buffer or threshold holds at zero, for example 310 of 4,000.
A new rule runs dry first. The dry run shows which items change number before a channel sees anything.
Which systems
Each system has a field that looks like a buffer. The integration uses it, or sets it to zero on purpose.
| System | Field or setting | What it does |
|---|---|---|
| Shopify | safety_stock state per item and location |
inside on_hand, outside available; moved with inventoryMoveQuantities |
| NetSuite | safetystocklevel, safetystockleveldays on the item |
feeds the reorder point: lead time days times demand, plus safety stock |
| Business Central | Safety Stock Quantity, a planning parameter | planning suggests supply below it; not a property of the API v2.0 item |
| Adobe Commerce | Out-of-Stock Threshold | positive without backorders, negative with backorders |
| WooCommerce | Out of stock threshold, a store setting | at this count a product gets the out-of-stock status |
| Walmart Marketplace | cancellation rate | 2% or below; out of stock counts against the seller |
The Walmart standard gives the marketplace buffer a measure. At 400 orders in the period, 8 cancellations are 2%. The ninth makes it 2.25%. Walmart evaluates seller performance over the last 30 or 60 days and lists out of stock as a seller-accountable cause, per its seller performance standards. The Shopify states are in Shopify's inventory states documentation. Both checked on October 3, 2026, together with NetSuite's item record, Business Central's planning parameters and the Adobe Commerce and WooCommerce settings.
Per system: Shopify, NetSuite, Business Central, Magento and WooCommerce.
Where standard connectors stop
Standard connectors and iPaaS platforms offer the buffer as one setting: a flat quantity subtracted from every count, the same for every item and every channel. That is the fourth row of the table above. A buffer of 5 chosen for a marketplace takes 1,300 items off the web store as well.
What is missing is the rule: a different number per channel, a different sum per item group, a threshold for supplier stock, and an exception with an end date. The report is missing too. A flat subtraction does not show which items it holds at zero, and an item that sits at zero for a week with 4 units on the shelf goes unnoticed.
The integration we build holds your rules as you set them, applies them on every run, and stores per run what was subtracted and why. When a platform changes its inventory model, we change the integration. Tell us which channels you sell on and where your stock is.
Frequently asked questions
How large should a buffer be?
As large as the number of units sold on other channels between two updates of this one. An item that sells 36 units an hour at peak, on a channel that is at most 5 minutes behind, needs 36 times 5 divided by 60: 3 units. Doubled to cover one missed update, that is 6. An item that sells once a week needs no buffer. The sum is made per item group, not once for the whole catalog.
Is a buffer not lost revenue?
A buffer that is the same for every item is. Six units held back on an item with 300 on the shelf costs nothing; six units held back on an item with 5 on the shelf takes it off sale. That is why slow items get a buffer of zero and every run reports how many items the buffer holds at zero, so you can see what the rule costs and adjust it.
Is the safety stock in my ERP the same as the buffer in the store?
No. In NetSuite and Business Central safety stock is a purchasing number: the quantity you want on hand at all times, used to calculate when to reorder. The buffer is the number of units a channel sees less than what is free. A NetSuite safety stock level of 40 next to a store buffer of 6 is a normal combination, and the integration keeps the two apart.
Can the buffer differ per marketplace?
Yes, because the cost of an oversell differs. Walmart Marketplace counts seller cancellations against a cancellation rate of 2% or below, and out of stock is one of the causes it holds the seller accountable for. A wholesale customer whose order is reviewed before confirmation gets a phone call instead. The first gets a larger buffer than the second.
What happens to an item with one unit left?
It follows the rule of its item group. With a buffer of 6 the sum is 1 minus 6, which is below zero, and the integration writes 0: the item is not for sale on that channel. With a buffer of 0 the last unit is for sale. Clearance and discontinued items usually get 0, since the point there is to sell the last unit.
Tell us what you need
Tell us which systems you use and what needs to work better. We reply personally within one working day. We help you define the work, then agree the price and timing before you commit.
- You know the price and the timeline before you commit to anything
- We work out the connection that takes the work off your hands
- We handle the build, hosting, monitoring and maintenance
- Your team has less information to retype and fewer discrepancies to chase