Build one current sellable quantity before publishing by channel
Start with one declared inventory field, then subtract only commitments and reserves that are not already represented in it:
current sellable pool = max(0, source quantity - unrepresented commitments - unrepresented reserve)
That pool is the most the business can expose across the channels covered by the calculation. It is not automatically the quantity to copy into every marketplace. Before publishing, decide whether every channel reserves against one shared pool or whether the pool is divided into controlled channel allocations.
The important word is unrepresented. If the source field already excludes open orders, damaged stock and safety stock, subtracting them again makes the result wrong in the other direction. A reliable available-to-sell rule therefore records both the number and what the number already contains.
This article covers the current quantity of an imported SKU that can be offered for sale. It does not calculate a delivery date, authorise backorders or promise that overselling can never occur. Its purpose is narrower: reduce avoidable double-booking and make a mismatch visible before another channel relies on it.
Keep current available-to-sell separate from delivery-date ATP
Inventory systems use similar terms for different jobs. A current available-to-sell quantity answers: “How many units can these channels offer now under our declared rules?” A time-phased available-to-promise calculation asks whether supply and demand on particular dates support a customer commitment.
Microsoft's order-promising documentation describes ATP as a date calculation using unreserved inventory together with planned production, purchases, transfers and sales returns. It also distinguishes capable-to-promise scenarios for supply that is not presently available.
Those are legitimate planning functions, but they are outside this article's admitted scope. An Australian ecommerce operator can control today's sellable quantity without making a future-delivery representation. Keep incoming stock, planned receipts and customer-facing dates out of the current pool unless a separately approved process governs that promise.
Write a state dictionary before choosing a formula
Begin with the state model used by the system that supplies the number. Shopify's inventory-state documentation distinguishes on-hand, available, committed, unavailable and incoming quantities. In that model, on hand is the sum of available, committed and unavailable stock. Incoming stock is separate until it is received and changed to available.
That is a Shopify definition, not a universal warehouse vocabulary. A marketplace, ERP and 3PL may attach different meanings to the same label. Record the operational meaning beside the field instead of translating by name alone.
| State to map | Practical question | Current-pool treatment | Evidence to retain |
|---|---|---|---|
| On hand | Is this every physical unit recorded at the location? | Do not publish directly unless commitments and holds are separately deducted | Location, unit, timestamp and state breakdown |
| Committed | Is the unit already assigned to an open order or transfer? | Exclude once, through the source field or an explicit deduction | Order or reservation reference |
| Unavailable | Is the unit held for damage, quality, safety stock or another reason? | Exclude once while the hold is active | Hold reason, owner and release event |
| Incoming | Has the destination received and released the unit? | Exclude from current sellable stock until the agreed receipt event | Transfer, receipt and release evidence |
If Shopify available is the source, committed and unavailable units are already outside that field. If physical on-hand is the source, they may need separate deductions. The record should answer already represented? for every line in the bridge.
The unit and location scope matter just as much as the state. Fifty eaches at one fulfilment location are not fifty cases, and fifty units split across locations are not necessarily one pool if an order cannot be routed between them.
Choose the reservation authority and timestamp
When two systems can accept orders, they need an agreed authority that evaluates the same remaining stock. Microsoft documents a soft-reservation model in which parallel order-taking systems submit reservations to Inventory Visibility. A successful request reduces the available-for-reservation quantity even though the physical quantity in the source system may not change immediately. Microsoft's returned soft-reservation ID is tied to product and dimension values rather than being a unique identifier for one individual reservation record, so retain the order-line reference, dimensions and full request/response evidence together.
The useful principle is portable: define the event that consumes sellable capacity, the system that decides whether capacity exists and the reference set needed to release or reconcile the reservation later. Do not infer that a storefront quantity update is itself the reservation.
For each published quantity, retain:
- SKU and exact variant;
- base unit and fulfilment location or location group;
- authoritative source field and extraction time, including timezone;
- reservations or orders not yet represented in that source field;
- separately approved reserve not already represented;
- resulting sellable pool and publication model;
- quantity sent to each channel and channel read-back time; and
- exception owner when expected and observed quantities differ.
If the WMS, ERP and storefront disagree before this calculation begins, resolve the state and cutoff using the 3PL, WMS and ecommerce inventory reconciliation workflow. Publishing the largest number is not reconciliation.
Calculate a sellable pool without subtracting the same hold twice
Assume one fulfilment location records 240 physical units of SKU K. Its source system already classifies 35 as committed and 12 as unavailable, leaving 193 available units. Eight marketplace orders have been accepted elsewhere but are not yet represented in that source snapshot. The business has also approved a ten-unit operational reserve that is not already recorded as unavailable.
| Bridge line | Quantity | Already in source available? | Effect on sellable pool |
|---|---|---|---|
| Source available | 193 | Starting field | +193 |
| External marketplace reservations | 8 | No | -8 |
| Separately approved reserve | 10 | No | -10 |
| Current sellable pool | 175 | Result | 175 |
The arithmetic is max(0, 193 - 8 - 10) = 175 units. The 35 committed and 12 unavailable units are not subtracted again because the source available field already excluded them.
If the ten-unit reserve were already recorded as unavailable, the result would remain 185 before the external orders, not 175 after a second reserve deduction. This is why a list of familiar inventory labels is insufficient: each subtraction needs a scope and representation test.
A result below zero indicates an exception, even though the publication quantity is floored at zero. The floor prevents a negative channel quantity; it does not explain which order, hold or stale snapshot created the overcommitment.
Choose shared-pool or allocated-pool publication
There are two broad operating models. In a shared-pool model, every channel checks and reserves against one current central quantity. Publishing 175 to several channels does not mean the business owns 175 units for each channel; it depends on every accepted order consuming the same pool before another system can promise the same unit.
In an allocated-pool model, the business divides capacity into mutually exclusive channel ceilings. Using the hypothetical 175-unit pool, it might assign 80 units to its own store, 60 to marketplace A and 35 to marketplace B.
| Channel | Published allocation | Reservation authority | Read-back requirement |
|---|---|---|---|
| Own store | 80 | Declared central or channel ledger | Observed quantity and timestamp |
| Marketplace A | 60 | Declared central or channel ledger | Observed quantity and timestamp |
| Marketplace B | 35 | Declared central or channel ledger | Observed quantity and timestamp |
| Total | 175 | Must not exceed the pool | All three confirmed or held |
These ratios are illustrative, not recommended. A useful allocation reflects the business's own channel commitments, order flow, update behaviour and recovery process. There is no universal buffer or safe synchronisation interval.
Do not mix the models silently. If a marketplace receives a fixed allocation while the webstore still assumes access to the full shared pool, the same units can reappear in both promises. Record transfers between allocations as controlled events rather than informal spreadsheet edits.
Keep incoming stock and delivery promises outside current ATS
Incoming stock can be commercially important without being sellable now. A supplier dispatch, vessel milestone or warehouse appointment does not prove the destination received the expected SKU, quantity and condition.
Shopify's state model keeps incoming separate until receipt. If an inbound transfer arrives short, damaged or mismatched, route it through the warehouse receiving discrepancy record before increasing the current pool.
Future supply can support a separately controlled ATP or preorder process, but that process needs its own dates, dependencies, customer wording and review. This article does not advise how to make those representations. Treat “incoming” as evidence to monitor, not a shortcut for current availability.
Handle bundles and variant mappings before publication
The stock rule must operate at the identity that an order consumes. If two channel listings map to the same exact variant, both claims belong against that variant's pool. If the mapping points one channel to a product family and another to a colour or size, the totals can appear consistent while the required variant is unavailable.
Bundles add another constraint. A parent offer may need several units of one component and one unit of another. Use the bundle and kit component-availability calculation to determine complete-set capacity, then constrain the channel quantity to the smaller applicable limit. Do not publish the parent from aggregate component totals or add competing bundle limits that consume the same stock.
Keep the recipe revision, component identities and reservation event linked. An order for one bundle may consume several component units even if the channel presents it as one line.
Test the events that change the number
Test the controlled path before relying on it during a promotion or low-stock period. Begin from a recorded snapshot, state the expected changes and inspect the source and every channel after each event.
| Test event | Expected evidence | Failure to hold |
|---|---|---|
| Order on channel A | One accepted reservation and reduced shared or allocated capacity | Another channel can still commit the same final unit |
| Cancellation before fulfilment | Reservation release linked to the original reference | Quantity returns before the reservation is actually released |
| Quality hold and release | Available-to-unavailable movement, then approved reverse event | Held stock remains published or returns without release evidence |
| Return received | Actual receipt, inspection and authorised stock state | Refund or return label alone restores sellable stock |
Include a simultaneous-order test when two channels can act against low stock. Preserve order IDs, reservation references, product/location dimensions, timestamps and observed quantities. The aim is not to prove impossibility of overselling; it is to verify the designed sequence and reveal where two systems believe they own the same capacity.
Operate an exception board and read back every channel
A successful outbound update is not proof that the channel stored the intended quantity. Read the value back where practical and record the time. If a connector or marketplace transforms, caps or delays the value, preserve expected and observed quantities rather than overwriting the discrepancy with a fresh estimate.
An exception record should include the SKU, channel, expected quantity, observed quantity, source snapshot, last confirmed reservation event, age, business consequence, owner and closure evidence. Prioritise exceptions that can expose unavailable units or suppress genuinely sellable stock.
After the current state is controlled, use the reorder-point and safety-stock workflow for the separate purchasing decision. Current available-to-sell control does not replace demand forecasting, lead-time measurement or replenishment planning.
The operational payoff is a defensible number with a traceable consumption path. Every channel need not use identical software, but each must receive a quantity derived from the same declared stock reality—or from an allocation whose total stays within it.
Sources
.png)
