Stock and availability: your store shows what you can actually ship

Which system owns the quantity?

One system owns each number and every other system receives it. For stock, the owner is the system where goods are received and picked: the ERP, the warehouse management system or the 3PL. The store does not own a count. It contributes the orders it accepted since the last update.

When two systems disagree, the owner's value is written and the difference is logged. A store count of 14 against an ERP count of 11 becomes 11, and the run records that 3 units were removed and which transaction caused it. Without an owner per field, each system overwrites the other in turn and neither number can be trusted.

Stock is one of the five flows described on the integrations overview.

Which stock counts?

On hand is not available to sell. Shopify splits the on-hand quantity of a location into six states: available, committed, reserved, damaged, safety_stock and quality_control. A seventh, incoming, holds goods that are on their way and is not part of on hand. The definitions are in Shopify's inventory states documentation. NetSuite makes the same split per location under its own names: On Hand, Committed, Available, On Order and Back Ordered, where On Hand includes the committed quantity.

A worked example for one item at one location:

on hand                 120
committed (open orders) -18
safety stock             -6
quality control          -4
damaged                  -2
available to sell        90

An integration that sends 120 to the store oversells by up to 30 units. An integration that sends 90 and updates on every order is correct.

The second decision is which locations count. A distributor holds 100 units in the Reno warehouse and 10 on the showroom floor in Sacramento. An integration that adds up every location sends 110. A customer orders 105 online, the warehouse ships 100, and the remaining 5 are display units in another city. The rule that prevents this is set per location: whether its stock counts for the web store, and for which sales channel. Standard connectors and iPaaS platforms map locations one to one or add several ERP locations into one store location. A rule that says which location fulfills first, or that reserves part of a location for a channel, is outside their settings. The multi-location inventory page covers those rules.

The third decision is what zero means. Sold out, discontinued and unknown are three states, and most feeds deliver all three as the number 0. The integration keeps them apart: a status field next to the quantity, and a rule per state for what the product page shows. The notes page on which stock counts goes through each state.

What actually moves

No black box: these are the fields in a stock flow, with the form they take on the way.

A stock write to Shopify sets the available quantity per inventory item and location. The call carries the quantity the integration last saw, so Shopify can refuse the write when an order came in between:

{
  "input": {
    "name": "available",
    "reason": "correction",
    "referenceDocumentUri": "erp://item-receipt/IR-20418",
    "quantities": [
      {
        "inventoryItemId": "gid://shopify/InventoryItem/30322695",
        "locationId": "gid://shopify/Location/124656943",
        "quantity": 90,
        "changeFromQuantity": 96
      }
    ]
  }
}

changeFromQuantity says: set 90, provided the store still shows 96. If a customer bought 2 units a second earlier, the store shows 94, the write is rejected and the integration recalculates from the new state. A write without that check overwrites the sale. From API version 2026-04 the inventorySetQuantities mutation also requires an idempotency key, so a call that is retried after a timeout is applied once.

What goes wrong quietly

A product is missing from the supplier file. This file arrived this morning:

sku;description;qty;eta
00123456;Torque wrench 1/2 in;14;
00123457;Torque wrench 3/4 in;0;11/30/2026
00123459;Socket set 24 pc;> 10;

Item 00123458 was in yesterday's file and is absent today. Treating absence as zero takes a product offline that the supplier has in stock. Treating it as unchanged leaves yesterday's quantity up for a product that is gone. Neither is right by default, so the rule is set per feed: absent means zero, absent means unchanged, or absent means unpublished after three files in a row. The same file has two more problems: > 10 is not a number, and 11/30/2026 is a US date that a European parser reads as invalid or, for a date like 03/04/2026, as the wrong day.

An item has no mapping. Standard connectors keep a mapping record per item. An item without one is skipped by the inventory sync, and no error is raised. The store keeps showing the last quantity it had. In our runs an unmatched item goes on a list in the run report, with the SKU and the reason, and the count of unmatched items is a number on the dashboard.

Today's export did not arrive. The supplier's server was down or the export job failed. Nothing errors, because there is nothing to process. The integration checks the age of the last file: a feed that normally arrives at 06:00 and is still missing at 08:00 raises an alert, and the store shows the age of the data it is running on.

A product drop oversells. At 10:00 the ERP and the store both show 12 units of a limited item. At 10:02 a sales rep enters a wholesale order for 8 in the ERP, which leaves 4. The store syncs every 15 minutes and still shows 12. It takes an order for 2 units at 10:04, 3 units at 10:07 and 2 units at 10:11. At 10:15 the sync runs: 4 minus 7 is minus 3. Three customers have a confirmation for units that do not exist.

With an update sent when the ERP quantity changes, the store shows 4 at 10:03. The first order takes 2, the second is limited to the 2 that are left, and the third sees a sold-out page.

A kit shows stock that cannot be assembled. A kit contains 2 of component A and 1 of component B. With 9 of A and 7 of B on the shelf, the kit quantity is the lower of 9 divided by 2, rounded down, and 7: that is 4. After one loose unit of A is sold the kit quantity is still 4; after two it is 3. The kit has to be recalculated on every component change. See kits and bundles.

Throughput and limits

A catalog of 50,000 variants, written to Shopify one variant per call, is 50,000 calls. A mutation costs at least 10 points and a store on a standard plan restores 100 points a second, so the ceiling is 10 calls a second: 50,000 divided by 10 is 5,000 seconds, or 83 minutes. During those 83 minutes the integration has no budget left for orders or prices.

Shopify accepts up to 250 items in an array input. Sent in batches of 250, the same catalog is 50,000 divided by 250: 200 calls. Sent as changes only, it is smaller again: if 1,200 variants changed since the last run, that is 5 calls.

Sources: Shopify API rate limits and NetSuite concurrency governance, checked on October 3, 2026.

The NetSuite number is shared by every integration on the account. A Standard-tier account with 5 concurrent requests that already runs a shipping tool and a reporting export has less than 5 left. A request over the limit gets HTTP 429 with the code CONCURRENCY_LIMIT_EXCEEDED.

How this is handled: large reads go through bulk operations, changes arrive as events, writes go out in batches of changed records only, and every call runs through a queue that slows down on a 429 and retries with growing pauses. A nightly comparison of the full catalog catches what an event missed. The notes on Shopify API rate limits, NetSuite concurrency limits and real time versus batch work through the numbers.

Buffers

A buffer is the number of units held back from the store to cover the time between a sale elsewhere and the next update. It follows from two numbers: how fast the item sells and how old the store's count can be.

An item that sells 36 units an hour during a drop, with an update that is at most 5 minutes behind: 36 times 5 divided by 60 is 3 units. A buffer of 3 covers it. An item that sells 2 a day needs none.

Standard connectors apply one flat quantity to every item. A flat buffer of 5 on a catalog of 4,000 SKUs holds 20,000 units back from sale, most of them on items that sell once a week. We set the buffer per item or per item group, and per channel: a marketplace that penalizes cancellations gets a higher one than your own store. On Shopify the held-back units are written to the safety_stock state, so the admin shows where they went. The safety stock page has the rules.

Delivery dates and backorder dates

Two items with zero on the shelf are not the same. One arrives tomorrow and the other in six weeks. The date that tells them apart exists in the ERP as the expected receipt date on a purchase order line, and in most supplier feeds as a column. Standard connectors carry the quantity; their inventory flows have no field for an expected or promised date.

Carrying the date takes three conversions:

• Format. 11/30/2026, 30-11-2026 and 2026-11-30 are the same day. 03/04/2026 is March 4 in a US file and April 3 in a European one. The source format is set per feed and stored as ISO 8601.
• Lead time to date. "5 business days" is a duration. An order placed on Monday, November 23, 2026 counts Tuesday and Wednesday, skips Thanksgiving on Thursday the 26th, counts Friday, Monday and Tuesday, and lands on December 1. Without the holiday calendar the answer is November 30.
• Receipt to ship date. Goods received on November 30 ship after your own handling time and before the carrier's cut-off, in the warehouse's time zone.

The result is written to the product, and the store shows a date on an item with zero stock. The delivery dates page covers the fields and the cases where a supplier moves the date.

Supplier stock next to your own

A supplier feed fills gaps. It does not overwrite the count of what is in your own warehouse. The rule is set per connection and per field.

When two suppliers carry the same item, the order between them is a setting. Each product belongs to one connection, so a second supplier sending the same SKU does not overwrite the first.

A file exchange fails in four known ways: a filename that is reused so an old file is read twice, a processed file that is not archived, a file that is read while the supplier is still writing it, and an export that does not arrive. The supplier feeds page covers each one, and supported sources lists the formats and transports. Trading partners that send availability as an X12 document use the EDI 846 inventory advice.

You stay in control

Every run is compared with what it is about to change before anything is written.

• Dry run. The integration runs against live data and writes nothing. You see what it would have changed.
• Approval. Per connection, changes wait for your approval or go through automatically.
• Exclusions. Products with a manual arrangement are left out. The integration cannot overwrite them.
• Overrides. A pinned ship date or a pinned quantity for one product, with an end date.
• Diff per run. Which products changed, from which value to which, and from which file or transaction.

A run that would set most of the catalog to zero is held:

run 2026-10-02 06:00   feed: stock_20261002.csv   rows: 4,160
held: 3,910 of 4,160 rows set available to 0 (94%)
last run: 212 of 4,158 rows at 0 (5%)
action: waiting for release

A truncated export causes this more often than a real stock-out. If it is real, you release the run. Failed calls are retried from a queue, and what still fails after the retries stays in the queue with its original payload and shows in the dashboard. The dry run and approval page describes the controls, and how an integration works shows a run from source to store.

In depth

• Multi-location inventory: which locations count, which one fulfills first, and the 100 plus 10 case.
• Delivery dates: expected receipt dates, business-day calendars and cut-off times.
• Supplier feeds: CSV, Excel and XML from suppliers, and the four file-exchange failures.
• Safety stock: buffers per item and per channel, calculated from sales rate and update delay.
• Kits and bundles: kit availability recalculated from component stock.

Stock connects to two other flows. An accepted order turns available stock into committed stock, which is part of orders, customers and shipping. Which products a buyer sees at all is part of pricing and customer terms.

Systems and platforms

ERP and warehouse systems. NetSuite, Business Central, SAP Business One and Acumatica. Each reports quantity per location and each has its own limit: account concurrency at NetSuite, 6,000 requests per 5 minutes per user at Business Central online.

Store platforms. Shopify, Magento, WooCommerce and BigCommerce. Magento with Inventory Management calculates a salable quantity per stock: the quantity of each assigned source minus its out-of-stock threshold, added up, minus open reservations. Three sources with 20, 25 and 10 units and reservations for 15 give 55 minus 15: 40 salable.

Combinations. Shopify and NetSuite, Magento and NetSuite and Shopify and Business Central each have their own page with the limits of that pair.

A system that is not listed can be integrated when its data can be read and written in a controlled way: an API, a database view, or a scheduled export of at least one file a day. Tell us what you run.